[EToSat] What we are looking for from QUIC

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

     With TCP spoofing, we can currently achieve very high speeds (e.g. > 200 Mbps).  Mostly this is in the lab but we have shown it over the air at tradeshows.  TCP spoofing also provides minimal degradation to these speeds in the face of packet loss.  Ideally, we would like QUIC to evolve to match this performance without spoofing.  The ideal is probably not achievable but we want to get as close as possible.  We are looking at FEC to help with the packet loss problem and large windows to address the throughput problem.  Since enabling FEC and very large windows (especially initial windows) will not be good defaults for general use, we need some sort of learning capability to know when they should be used.  I think all of this is well known.  But, we are also looking ahead.  More and more, satellite is being paired with terrestrial connectivity.   Multipath QUIC will work when that pairing happens at the client.  But, it doesn't help when the client is not aware of the existence of the multiple paths.  Specifically, if the client is connected via WiFi to some sort of access port and that access port has parallel satellite and terrestrial (e.g. LTE) connectivity, the existence of the multiple paths is hidden from the client.  One solution path is to somehow have the access point interact with the client to make the client aware.  (A proxy comes to mind but there are other options.)  The other solution path is to make QUIC be able to adapt quickly to changes in path characteristics.

     We just wanted to throw the above out there so we can keep it mind when working on solutions to the shorter term problem of making QUIC work well over satellite in the first place....


John