Re: [tsvwg] RTT-independence

[Greg White <[e-mail]>]

On 2/11/20, 4:54 AM, "tsvwg on behalf of Jonathan Morton" <[e-mail] on behalf of [e-mail]> wrote:

    > 15ms comes from the amplitude of the sawteeth of typical traffic at typical Internet bottlenecks over typical paths. 
    
    For this to be true, as a peak-to-peak measure, while maintaining 100% throughput, the baseline RTT would have to be 15ms (for basic Reno) or 35ms (for CUBIC as implemented in Linux).  This does not square with other research which has established typical Internet path RTTs in the region of 80ms.
    
[GW]  It's not a peak-to-peak measure.  The PIE or PI2 controller aims to keep the "average" queue delay at the target value of 15ms.  This means that for a single Reno flow to fully utilize the link, its baseline RTT needs to be 30ms or less, and cubic more like 50ms or less.  Keep in mind that cubic is also a bit less sensitive to under-buffering than Reno.  You can quibble with his wording if you like, but setting the latency target in existing AQMs comes down to (as Bob indicated) a tradeoff between minimizing occasions where the link is underutilized and minimizing delay.  I'm not aware of a specific goal of ensuring 100% utilization for a single 80ms base-RTT flow.


    NB: Codel has an even lower queue target of 5ms by default, but this is for controlling the *standing* queue, not peak nor average queue depth.  Some reduction in link utilisation is accepted in the design, in service of keeping the queue short.
    
[GW] It has been argued that way, but I'm not sure that argument actually holds up.  CoDel only aims to ensure that the minimum queue delay over the last interval (100ms) is below the target value.  Van and Kathie's definition of "standing" queue (or "bad" queue) was queue delay that lasts for more than about one RTT, and their description of why they landed on that definition appears to relate to handling stretch ACKs and other sources of burstiness rather than dealing with congestion control dynamics.  The other definition of standing queue (the queue to eliminate if 100% utilization for a single flow is desired) is the remaining queue at the trough of the TCP sawtooth.  These two definitions only align when the sawtooth period is less than 100ms. As a result, CoDel only supports 100% link utilization in the single flow case when that is true.  Since the period of the sawtooth for Reno or Cubic can be measured in seconds (or minutes) for typical broadband speeds and RTTs today, this doesn't really work as described, and CoDel reverts to more-or-less acting as a short (5ms-ish) drop-tail queue.  For 100Mbps links, CoDel only supports 100% utilization for RTTs less than ~3.5ms.  For 1Gpbs links, CoDel only supports 100% utilization for RTTs less than ~1ms.  Sebastian has mentioned a few times that there is a theoretical basis for the 5ms target in CoDel.  I've not seen one, and wonder if someone could point me where to find it. 




    In any case, from a scientific perspective, when testing a claim that a given system is less RTT-dependent than the status quo, it is of course necessary to choose a variety of test conditions which are capable of exposing this property.  Tests to date actually suggest *greater* RTT dependence of the L4S system compared to conventional TCPs with conventional AQM, largely because of the moderating effect (with a very short baseline RTT) of keeping a modest standing queue which L4S specifically avoids.
    
    It is this evidence which the L4S team must defend against on this particular claim.  I think Sebastian is asking important questions here.
    
     - Jonathan Morton