Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation

Hi Greg,

> On Apr 4, 2019, at 01:28, Greg White <g.white@CableLabs.com> wrote:
> 
> On 4/3/19, 7:28 PM, "iccrg on behalf of Jonathan Morton" <iccrg-bounces@irtf.org on behalf of chromatix99@gmail.com> wrote:
> [...]
>    It is actually common for OpenWRT devices to include "ingress shaping" to exert some control over bufferbloat on downloads.  The terminology, in fact, comes from this practice, as the port in question is facing the WAN link and has two qdiscs attached, one for egress traffic towards the Internet, and one for ingress traffic received from the Internet.
> [...]
>  It is of course better for AQM to be installed on the upstream side of where the congestion actually occurs.
> [...]    
>    The motivating reason for ingress shaping is that, generally, the BRAS or equivalent device in the ISP does not perform AQM at all (though some do policing, which doesn't involve ECN).
> 
> [GW] It will be the case that many such "equivalent devices" can (and will) support a dual-queue AQM (not fq), which (where available) will eliminate the need for ingress shaping, and provide a better result.    If fq_codel (or CAKE) were updated to utilize the L4S-style of ECN (or even just treat ECT(1) as non-ECT), this would be a non-issue.   How feasible would that be?

[SM]: I happen to believe that head-end AQM will ameliorate the need for an ingress AQM for a lot of casual users, but all those that are constantly running against capacity limits (think ADSL) typically desire a more fine-grained prioritization than a head-end AQM is going to offer, includsing restricting bandwidth to certain proiorety classes to say keep latency increas for game traffic tightly bound. I believe in that case the guarantees L4S offers are not sufficient, as the gaming case requires "guaranteed bandwidth at a certain latency level" as compared to the low_queueung latency guarantee L4S offers (which basically moves the que back into the sending end-host, which is fine, but all it does not help if I need to send @ X Hz).

> 
> [...]
>    I did spend a few minutes today sketching out what happens if an L4S flow hits fq_codel on an ingress shaper.  The theoretical results are that, in congestion-avoidance mode, the L4S flow takes about twice as long to drain the dumb bottleneck queue as a Classic ECN flow after the onset of saturation.  But the real shocker is what happens in the terminal phase of slow-start, where a rapid correction is required after the minimum 2x overshoot in exponential growth (because it takes an RTT for the CE/ECE/CWR signal to circulate and take effect).
>    How many RTTs does it take for the cwnd to be halved in L4S, when the only CE signal is ramping up linearly at one-per-RTT-per-RTT?  Hopefully enough for L4S to detect the delay induced by the dumb FIFO and fall back to RFC-compliant behaviour.
> 
> [GW] One of the optimizations being investigated for L4S (both TCP/QUIC Prague and (I think) BBRv2) is a revised startup process that avoids the 2x overshoot from slow-start.  Nonetheless, you are right that an issue to be understood (and addressed?) with TCP Prague / fq_codel compatibility is how to prevent TCP Prague seeing worse latency than classic TCP at flow startup.  As you indicated, once the Prague sender falls back to Reno behavior, things are fine.  
> In fq_codel/CAKE currently, does the AQM switch from CE mark to packet drop at some higher threshold of sojourn time?  If so, would this provide for a faster fall-back to Reno than you considered in your analysis?  Alternatively, if fq_codel/CAKE were to treat ECT(1) as non-ECT (or implement the L4S style ECN) this would again not be an issue, I believe.  

[SM] I believe this to be just as viable as having L4S AQMs interpret ECT(1) as pulse-modulated continuous congestion information. In the end, after the dust has settled, one of these is going to happen, as there is only going to be a single graded congestion signaling (if at all). IMHO the jury is still out which approach will win.

> 
> [...]
>    (Yes, we have a real solution sketched out for SCE.  It will be tested soon.  We already have running code.)
> 
>     - Jonathan Morton
> 
>    _______________________________________________
>    iccrg mailing list
>    iccrg@irtf.org
>    https://www.irtf.org/mailman/listinfo/iccrg
> 
> 