[EToSat] Things needed for QUIC to work well over satellite...

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

    The discussion about the default response timeout at the QUIC meeting (and the fact that QUICv2 discussion is getting ready to start up) got me to thinking...

    Some things QUIC needs to work well over [geo] satellite...

Long enough timers.  The 1 second default with learning should cover this.

Big window size to support a large BDP.  State of the art throughput for spoofed TCP over satellite is at least 200 Mbps.  (And, it is growing with each generation of satellite technology.)  A RTT of 1 second means that 200 Mbps requires 200,000,000/8 = 25,000,000 bytes in flight.  While I keep forgetting to check, I am pretty sure QUIC can handle that number protocol-wise.  The question is will the implementations.  (Last time we looked a few months ago, gQUIC supported only a tenth of that, i.e. we maxed out at 20 Mbps.  Of course, two years ago, it was only 3 Mbps.)

Large initial window.  This will definitely require some memory because we need really big numbers that will (probably) not be safe to use in the general case.

A way to signal congestion.  Packet drop and ECN should work.  And, it is reasonable to expect good queue management.  The problem, though, is that a lot of the packet drop will actually not be congestion, especially during fade conditions.  We will need stuff under QUIC to try to minimize non-congestion packet drop.  Specific link layers will be have techniques and we can look at LOOPS-like approaches for applying techniques across larger portions of the path.

TBC

Besides retransmission, there is also the possibility of using FEC (as is being discussed in NWCRG) either under QUIC or inside of it.  For the inside version, we again need to learning to know when to use it.  The last version of Ian Swett's draft I read still required picking the FEC at startup.  It would be nice to figure out a way to turn it on after start-up...


John