Re: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-24.txt

[Sebastian Moeller <[e-mail]>]

Dear list,




> On Jul 7, 2022, at 23:22, Bob Briscoe <[e-mail]> wrote:
> 
> tsvwg list,
> 
> We have just posted new revisions of the 3 main L4S drafts to address the Area Director's review comments, for which many thanks to Martin Duke).
> This email concerns the Coupled DualQ AQM.
> 
> A link to a diff since the previous rev can be found in the announcement below.
> Here is a brief summary in English:
> 
> ==Changes to Normative text==
> 
> None
> 
> ==Technical/Editorial Changes==
> 
> Appendix A.  Example DualQ Coupled PI2 Algorithm
> A.1.  Pass #1: Core Concepts
>     An alternative to using sojourn time to measure queuing delay had been added a few revisions ago, to address concerns about marking a mix of bursty and smooth traffic. 
>     However, it had only been added in a note about something else, and it hadn't been referred to consistently wherever sojourn marking was discussed.
>     This has now been corrected, and It has been moved to an earlier note.
> 
> ==Editorial Changes==
> 
>     Minor clarifications and corrections and updated references.
> 


However, sojourn time is slow to detect bursts.  For instance, if
       a burst arrives at an empty queue, the sojourn time only fully
       measures the burst's delay when its last packet is dequeued, even
       though the queue has known the size of the burst since its last
       packet was enqueued - so it could have signalled congestion
       earlier.  To remedy this, each head packet can be marked when it
       is dequeued based on the expected delay of the tail packet behind
       it, as explained below, rather than based on the head packet's
       own delay due to the packets in front of it. [Heist21] identifies
       a specific scenario where bursty traffic significantly hits
       utilization of the L queue.  If this effect proves to be more
       widely applicable, it is believed that using the delay behind the
       head would improve performance.


Is "it is believed that using the delay behind the
       head would improve performance." really the level of confirmation applicable to make recommendations? Would it not be more convincing to cite the paper/data that is the foundation of that believe. 

Would it not be more prudent to actually demonstrate (empirically with data) if the proposed alternative method is:
a) an improvement under conditions of bursty traffic*
b) actually implementable (for variable rate links predicting the service time for the existing queue is a non-trivial problem)

instead of basing a recommendation on "believe"?


Regards
	Sebastian


*) By "punishing" earlier packets for later bursty the probability is high to hit the wrong flow with a marking while the offender might squeeze through unmarked (so higher than deserved probability to avoid a mark). This might in effect not actually make bursty transmission a bad strategy as the cost of that might be borne by others. With plain sojourn time the tail packet of a burst will see the full latency cost of the previous packets in the burst.


> 
> Bob 
> for the co-authors.
> 
> 
> On 07/07/2022 20:59, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>> 
>>         Title           : DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
>>         Authors         : Koen De Schepper
>>                           Bob Briscoe
>>                           Greg White
>>   Filename        : draft-ietf-tsvwg-aqm-dualq-coupled-24.txt
>>   Pages           : 65
>>   Date            : 2022-07-07
>> 
>> Abstract:
>>    This specification defines a framework for coupling the Active Queue
>>    Management (AQM) algorithms in two queues intended for flows with
>>    different responses to congestion.  This provides a way for the
>>    Internet to transition from the scaling problems of standard TCP
>>    Reno-friendly ('Classic') congestion controls to the family of
>>    'Scalable' congestion controls.  These are designed for consistently
>>    very Low queuing Latency, very Low congestion Loss and Scaling of
>>    per-flow throughput (L4S) by using Explicit Congestion Notification
>>    (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
>>    could only be deployed where a clean-slate environment could be
>>    arranged, such as in private data centres.  The coupling acts like a
>>    semi-permeable membrane: isolating the sub-millisecond average
>>    queuing delay and zero congestion loss of L4S from Classic latency
>>    and loss; but pooling the capacity between any combination of
>>    Scalable and Classic flows with roughly equivalent throughput per
>>    flow.  The DualQ achieves this indirectly, without having to inspect
>>    transport layer flow identifiers and without compromising the
>>    performance of the Classic traffic, relative to a single queue.  The
>>    DualQ design has low complexity and requires no configuration for the
>>    public Internet.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/
>> 
>> 
>> There is also an HTML version available at:
>> 
>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-24.html
>> 
>> 
>> A diff from the previous version is available at:
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-24
>> 
>> 
>> 
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>> 
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/