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

[Kuhn Nicolas <[e-mail]>]

-----Message d'origine-----
De : Gorry Fairhurst <[e-mail]> 
Envoyé : mercredi 4 décembre 2019 12:00
À : Kuhn Nicolas <[e-mail]>
Cc : 'Christian Huitema' <[e-mail]>; Border, John <[e-mail]>; [e-mail]
Objet : Re: [EToSat] What we are looking for from QUIC

On 04/12/2019, 07:51, Kuhn Nicolas wrote:
>
> *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.
>
[GF] The params from John seem fine - but for me I'd also like to ensure we test 10/2 Mbps as a baseline - hinted in John's email, because this is also a current service datapoint.
[NK] I guess we should at least keep 3 three scenarios : (10/2 Mbps or 50/10 Mbps) (250 Mbps no loss) (250 Mbps with François loss model). I will push an updated version of the regression tests ASAP. 
>
> */[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-t
> ransport.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 cha/**/nge the SHOULD for a RECOMMEND 
> and propose other values and the need for a transport parameter? /*
>
[GF} We at Aberdeen are digging in this space again. I think what I'd like most to see is a recommendation of how to safely adapt 2 to 10. The number is important because it impacts CC dynamics and the basic smoothness/burstiness of the cwnd growth; and a flow should be more than
x10 more aggressive than a new flow. I will argue that the number 10 seems a credible safe number to propose - because we alreday allow IW=10 as a burst (that should of course be paced if you can), but at least the notion exists that 10 buffers are often available on the path.

[GF] If this argument stands, I think we should propose adding a decription of why more than 10 needs mroe care, and how you could decide between needing 2 or 10 as the number of packets that are cumulatively ACKed.
[NK] I totally agree that we should add that description and change the text on the QUIC draft. 
>
>     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
>
>
>
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat
Gorry