SymontySez 1.0 – Why Size Doesn’t Matter


Welcome to the first edition of SymontySez. I am Symonty and I hope to be able to present some views and ideas about connectivity and the IFE industry (now strangely being renamed the Passenger Experience Industry) from my 12-year journey in this field. My company, SymonTek, is responsible for the software and servers that support inflight connectivity and we work anonymously with some of the biggest names in this industry.

I am completely sure loads of you will disagree with me. That’s okay. The purpose of my commentary is to make you think and ask questions. Masticate on it for a bit, and if you bite, watch out for your uvula! And if you disagree, why not drop me an email at: I appreciate healthy intellectual discussions.

“Why Size Doesn’t Matter”
A Satcom’s Tale of Time and Distance

This issue of satellites, aircraft, and data pipes comes live from the Utopian anarchy of the Internet connected world. We rejoice in our collective consciousness, as the laws of physics seem to melt away in an interconnected world no longer ravaged by the disparity of distance.

Now wake up silly pants, you are on a plane over the Pacific… so sit down and think about the problem…

Geostationary satellite-based Internet on an aircraft is difficult, in fact a single TCP/IP packet has to travel over the 44,000+ miles from an aircraft to your favorite web server and cannot achieve more than 64 Kbits/s no matter the size of the pipe. Let me explain how technologists are able to “fix” this limitation and why it is ultimately of no value.

Satellite data services, such as Inmarsat Swift, Ku, Ka, etc., have unique benefits over ground-based connection technologies — they require far less infrastructure. Only 3 or 4 satellites and ground stations are required to cover almost the whole planet (the poles remain an issue for all Geostationary satellites). Additionally, the technology is stable and mostly off-the-shelf; you can buy either direct data services from Inmarsat, for example, or rent spectrum from satellite service providers.

Now the hard part, lets face some facts about GEO satcom without getting too heavily into TCP Slow Start, MTU window management and the congestion algorithm in general.

Geo satcom start to be scary because the marriage with TCP is not a match made in heaven. This was first recognized in 1972 (RFC346). Since TCP and some payload management systems, like streaming video, use latency and packet loss to indicate congestion and or link speed. Some serious side effects come into play when the distance is taken into account. The problem is: each connection takes so long to get back and forth TCP thinks the link is either congested, slow or lossy and re-sizes each “window” into smaller and smaller chunks until the throughput, when multiplied by latency, seems to level out at around 64Kbits per second. Interestingly enough, the net effect is an efficient multiplexing that works very well with high numbers of users and very poorly with a single user.

To increase the single request throughput on a high bandwidth and highly latent link the use of Performance Enhancing Proxies (PEP) have seen widespread usage for some time, specifically in the fixed terminal world. While PEP works by fooling TCP with local packet acknowledgments (prior to the packets actually arriving at the other end successfully) it requires that the underlying link is virtually error free*. Also remember, this only increases the achievable single connection throughput, and it will still take up to a second for each new request to be answered by the other end.

So now there is an increase in the available throughput of large requests, for example streaming video, that passengers can watch while flying the pacific? Well yes and No. With streaming technologies, such as YouTube HD, available at 1280×720 H.264 at only 2mbits/s, which on Inmarsat (if you could bond the channels together to get it) will cost the passenger around $5 per second. Even if you are the satellite service provider and you have available satellite spectrum, that one YouTube viewer, on one plane is gobbling 8% of the total capacity of a transponder or… $2 per second. This is based on a $250K per month 30Mb/s transponder.

This is “Why Size Doesn’t Matter”

The underlying technology and the distance limits any effective throughput without costly compromises and poor customer experience. And the cost per MB means that any increase in usable capacity quickly becomes too expensive for most pax to use. Finally, the only real reason a larger pipe size would be of value would be for multiple users, and with the take up rates we have seen to date, this is not an issue.

I don’t think size matters for open Internet access, but may I suggest the “little blue pill for your pipe?” Tune in next time.

E-mail Comments:

* A geo stationary satellite signal has to pass signals over twice the circumference of the earth before it is even routed to it’s final destination, so the space segment is round 250ms for a single hop and as much as 1 second from your airborne laptop to the web-server. To put this in perceptive try ping and see how your connection fares against 1000ms.

* As error rates increase the extra traffic caused by the overlay of PEP and TCP are geometric and degrade far quicker with PEP than without in states of increasing error rates. To decrease error rates more of the bandwidth is allocated to the error correction protocols and delays due to computations, this looses bandwidth for end-to-end usage and also slows the initial connection to each new server, so you have to balance the benefits.


One Response to “SymontySez 1.0 – Why Size Doesn’t Matter”


Check out what others are saying about this post...
  1. […] time in “Why Size Doesn’t Matter” I outlined the specific issues limiting timely connectivity communication due to satcom […]

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!