[EToSat] Encrypted Transports over Satellite

["Border, John" <[e-mail]>]

Apologies for the primer (since the discussion has moved past this already) but I want to get some terminology into the record...

Geosynchronous Earth Orbit (GEO) satellites have an up to the satellite and back delay of ~250 milliseconds.  That does not include queueing, etc. in the satellite ground equipment.  Round trip time for a TCP or QUIC connection, in the best case, will be on the order of 600 milliseconds and can be considerably longer.    RTTs on this order of magnitude have significant performance implications.  These include:


  *   The maximum throughput of the connection is limited by the maximum window size which can be used by a connection.  If the window is smaller than the bandwidth delay product, the maximum connection speed is artificially limited.  In the case of the satellite, the delay portion is large.  But, with modern Internet over satellite technology, the bandwidth is also large.  25+ Mbps is a typical plan today with 200+ Mbps possible.  (200+ has been publicly demonstrated using TCP spoofing with our system.)  Some BDP examples:



     *   25 Mbps * 600 ms = 15,000,000 bits or 1,875,000 bytes or ~1460 1280 byte packets
     *   200 Mbps * 600 ms = 120,000,000 bits or 15,000,000 bytes or ~11700 1280 byte packets
     *   200 Mbps * 1.5 sec = 300,000,000 bits or 37,500,000 bytes or ~29000 1280 byte packets

TCP stacks can support large BDPs but are generally not tuned to provide windows this large.  So, TCP spoofing is used to compensate.  However, spoofing will not work for an encrypted transport (e.g. QUIC).  Our recent tests show that Version 43 of Google's QUIC will now cover the first case (with a maximum window of 2000) but does not come close to the second case.  (What does the current version of IETF QUIC support?  What is the default?)


  *   Slow start is also an issue when long latency.  For TCP, spoofing addresses this issue by splitting the connection into two or three parts.  This allows the transmit window to grow at terrestrial speeds on each side of the satellite link.  The common end to end approach is to use large initial windows.  And, this works even with encryption.  However, the values needed to handle GEO satellite latencies are much too large to just safely use all of the time.  So, some sort of learning algorithm is needed.  There is, of course, a relatively easy to use metric for it, the RTT.


  *   Packet loss recovery is another area where splitting the TCP connection into different parts helps.  Packets lost on the terrestrial links can be recovered at terrestrial latencies.  Packets lost on the satellite link can be recovered much more quickly by the link layer or PEP layer than they can end to end.  Again, encryption breaks this.  Enhanced error recovery at the link layer helps for the loss on the satellite link but doesn't help for the terrestrial links.  Another aspect of recovery is that terrestrial loss is highly likely to be congestion related but satellite loss is more likely to be transmission errors due to link conditions.  Transport slow down reaction to the latter unnecessarily reduces performance.  But, at the end points, the difference between the two is not easily distinguished.



John


P.S.  Originally, I was going to put in some stuff about NWCRG, PANRG and LOOPS solutions to address some of the above.  But, the list discussion is taking care of that.