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

[Greg White <[e-mail]>]

On 4/3/19, 7:28 PM, "iccrg on behalf of Jonathan Morton" <[e-mail] on behalf of [e-mail]> 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? 

[...]
    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.  
    
[...]
    (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
    [e-mail]
    https://www.irtf.org/mailman/listinfo/iccrg