This document summarizes a talk about simulating satellite internet links to small islands using a hardware-based simulation. The simulation aims to demonstrate how coding and performance enhancing proxies impact link utilization and packet loss. It consists of configuring the simulated satellite link parameters, running background traffic from servers to clients to generate demand, capturing traffic on both ends, and measuring the impact of coding and proxies on large file transfers and ping times. Preliminary results show that medium earth orbit links have higher goodput than geostationary links under high load, and that performance enhancing proxies help large file transfers without significantly impacting overall throughput. Future work will explore forward error correction coding and balancing redundancy with spare capacity.

1. Simulating the behavior of satellite
Internet links to small islands
Ulrich Speidel
Lei Qian
Department of Computer Science
September 2018
(adapted from a talk at APAN2018 Auckland)

2. Motivation for the present work
• Satellite connections used on islands: Long latency and typically
low bandwidth
• Surprise: Many island satellite links suffer from link underutilisation
and packet loss during peak times
• Poor TCP performance results!
• Would like to learn how to utilise precious narrowband satellite link
bandwidth more efficiently

3. Potential solutions
• Performance enhancing proxies (PEP)
– TCP connection splitting
– partially solves long RTT problem
– Creates potentially tricky failure modes
• Coding-based solutions
– encode/decode packets instead of just forwarding
– linear coding
– forward error correction / concealment

4. Research questions
• Can we …?
<long list / snip!>
• In this talk: How do we demonstrate what is happening on a
link with and / or without coding, PEP, etc.?

5. Simulation of real world traffic
• Why simulate in hardware?
– Impossible to achieve all the criteria below on a real link
– Pure software simulators not powerful/realistic enough
• Link type
– Want to simulate GEO/MEO delay, jitter, different bandwidths, queue capacities
• Demand level
– Need enough traffic generation while controlling the demand
• Demand profile
– Want realistic flow distributions: mix of different flow sizes
• Terrestrial latency profile
– Want configurable latency distribution between world-side gateway and different parts of the world

6. Simulation topology

7. Simulation topology

8. Simulation configuration
• Purpose-built software
– Purpose-developed client/server software
– Able to fulfill controlled demand level requirements + customised demand profile (flow mix)
• Standard tools
– Reachability, traffic dumping, remote and traffic injection
– Stand tool sets in Linux. E.g., ping, tcpdump, ssh/pssh, iperf3
• Experiment control and analysis software
– scripting and post experiment analysis
– Shell scripting and PHP

9. Experiment step 1
Step 1: Configure “satellite link”:
bandwidth, latency, buffer

10. Experiment step 2
Step 2: Configure experiment mode:
PEP(s), encoder/decoder (where
applicable)

11. Experiment step 3a
Step 3a: Start capture on “island side”

12. Experiment step 3b
Step 3b: Start capture on “world side”

13. Experiment step 4a
Step 4: Start world servers
to be able to provide
background traffic

14. Experiment step 4b
Step 4b: Start island clients to
create demand for background
traffic. Background traffic now
ramps up

15. Experiment step 5
Step 5: Send start UDP signal from world special
purpose Pi to island side – creates common timestamps
with unique IP in all capture traces!

16. Experiment step 6
Step 6: Start large file transfer from sats-sp to
one of the NUCs

17. Experiment step 7
Step 7: Rapid-fire ping across the satellite chain to
measure RTT/queue sojourn time

18. Experiment – quality assurance
• Pre-experiment checks
– link setup confirmation
– reachability test (are all RTTs what we expect?)
– link test (bandwidth + max. queue sojourn time)
• Post-experiment checks
– experiment running time verification (Start and stop signals present in traces?)
– active node verification (Did all expected nodes participate? Did they share the load?)

19. Selected result 1 of 5
large file transfer time
queue mostly empty due to low demand level

20. Selected result 2 of 5
standing queuestanding queue
Repeat with higher load:

21. Selected result 3 of 5
no standing queues, queue oscillates inside buffer throughout the entire experiment period
Repeat with less queue capacity:

22. Selected result 4 of 5
Comparing geostationary (GEO) with
medium earth orbit (MEO) links
Link capacity
• More goodput on MEO
• But: under high load,
large transfers are faster
on GEO!

23. Selected result 5 of 5
Link capacity
• PEPsal helps large
file transfers
• Little impact on
overall goodput
Comparing a performance-enhancing
proxy (PEPsal) with a plain vanilla link
16 Mbps GEO link
PEPsal setup: symmetric on both sides of link.
80 ms latency between sender of large file transfer and world sat gate

24. Conclusion and future work
• Hardware based simulation of traffic is feasible.
• Forward error correction coding with input queue could result in
better link utilisation and overall goodput improvement.
• Need to strike balance between redundancy and spare capacity on
coded links.
• Small and short flows present serious problem on satellite link.

25. Acknowledgements
• Thanks for valuable comments to Nevil Brownlee, Brian Carpenter and many
more.
• Thanks to APNIC and Internet NZ for supporting this project with multiple
grants.

26. Questions ?