Re: [EToSat] What we are looking for from QUIC

[Kuhn Nicolas <[e-mail]>]

De : EToSat <[e-mail]> De la part de Christian Huitema
Envoyé : mercredi 4 décembre 2019 00:42
À : Border, John <[e-mail]>; [e-mail]
Objet : Re: [EToSat] What we are looking for from QUIC



On 12/4/2019 2:43 AM, Border, John wrote:

     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.

Yes, that's what I have been testing for with Picoquic. Once the windows are established, we can certainly get >200Mbps on the simulator -- we get 600 Mbps in loopback connections. The congestion control and flow control algorithms are designed to find the right window values. Starting with 0 knowledge it takes time, but given time they do find them. The challenge is to shorten that adaptation time in the general case.

[NK] The challenge is to shorten that adaption time indeed - and to let client and server know about the network underneath for 0-RTT connections. This is what we tried to achieve with the 0-RTT BDP draft that we need to update.

Detecting 1% loss and retransmitting the missing packets is obvious. I don't think we need FEC, unless we value timeliness over efficiency. The big challenge is to distinguish between congestion losses happening at the bottleneck and random losses happening elsewhere on the path. That's possible if the congestion algorithm uses delay variations and ECN marks instead of losses to detect congestion.

[NK]  For short flows, 1% losses is not really a big deal. However, when it comes to long files transfers, things are different. 0.1% random losses may halve the goodput. Considering FEC in QUIC has been proposed in NWCRG [https://tools.ietf.org/html/draft-swett-nwcrg-coding-for-quic-03] but it looks like going further in this discussion needs to consider the impacts between FEC and loss-based congestion control [which we tried to initiate in https://tools.ietf.org/html/draft-kuhn-coding-congestion-transport-00]. If the congestion control is delay based, life is easier but otherwise, distinguishing congestion and random losses is a chimera to me, if there is no efficient in network signaling.

Then there is a issue of asymmetric links. That requires sending way fewer ACK than what is specified in the QUIC recovery spec.

[NK] Indeed. Looking at the QUIC transport document [https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md], I can see : "An ACK frame SHOULD be generated for at least every second ack-eliciting packet. This recommendation is in keeping with standard practice for TCP {{?RFC5681}}." However, there do not seem to be a generic transport parameter for changing dynamically this value. Should we file an issue and change the SHOULD for a RECOMMEND and propose other values and the need for a transport parameter?
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.

Let's deal with that later. Multipath is on the work list for QUIC v2.



     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....

The good news is that while satellite links are special, the three challenges above are also present in other environments. Faster adaptation, recognizing non congestion losses or sending fewer ACKs is beneficial in general. So there is hope...
[NK] Indeed !

John

-- Christian Huitema