Re: [tsvwg] start of WGLC on L4S drafts: DualQ AQM

[Sebastian Moeller <[e-mail]>]

Hi List,

so this post of Bob's highlights an inconsistency in the DualQ draft:
for one he writes:

"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."

but later it is stated

"Priority of L4S is required to be conditional to avoid total starvation of Classic by heavy L4S traffic."

Which really just admits that the indirect "coupling" mechanism from the introduction does not work as promised, as without such an emergency scheduling get-out-of-jail card, L4S traffic can very much compromise "the performance of the Classic traffic" when both compete in the DualQ. 


Regards
	Sebastian


> On Oct 23, 2021, at 18:18, Bob Briscoe <[e-mail]> wrote:
> 
> Gorry, 
> 
> Thanks for your (as always) diligent review. Unless I've responded below with [BB], consider them accepted as written...
> 
> On 12/08/2021 11:30, Gorry Fairhurst wrote:
>> I have reviewed DualQ Coupled AQMs for  L4S 
>> 
>> I re-reviewed: draft-ietf-tsvwg-aqm-dualq-coupled-16 in the WGLC. As an inidvidual, I support publication as a PS, and have some comments below on -16, that 
>> 
>> 1) 
>> The abstract is unnecessarily long. It does not need to provide this level of background information. I’d suggest the editors shorten this. 
> 
> [BB] I've compressed it down to the size of the first of the two paras. I haven't run this past my co-authors, so you might see some (hopefully minor) changes in the version that gets submitted.
> 
> 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 achieve 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. The solution has low complexity and requires no configuration for the public Internet.
> 
>> --- 
>> 2) The 'Low Loss" part of the name denotes 
>> - This has mixed quote marks. In other places, double quotes are used. 
>> --- 
>> 3) There appears to be some repetition of topics in section 1.4 between this and the L4S arch specifications. This just gives more to read. Please do consider removing duplicate examples/discussion. 
> 
> [BB] The "Problem Outline" section was rewritten over Drafts 09 & 10 (both July 2019) to be specific to the Problem the DualQ solves, and other material was moved to l4s-arch.
> 
> The Scope section was also rewritten. It has a couple of paras putting the DualQ in the wider context of scalable congestion controls, then refers to l4s-arch for details. The rest of the scope section is specific to the DualQ. Yes, it does pick some pieces out of l4s-arch (e.g. most likely deployment scenario for the dualQ). But the aim was to give implementers who are only interested in the DualQ what they need.
> 
> This might not be the way you would have chosen to decide which material to include or exclude, but I hope you'll understand that this means I really don't want to go through the exercise of rewriting these sections again,... except to address specific concerns. 
> 
>> --- 
>> 4) Typo - additional space: 
>> “[RFC5681] .” 
>> --- 
>> 5) Unpublished Individual ID as a Ref explaining a “MUST”: 
>> “The two queues can be part of a larger 
>>    queuing hierarchy [I-D.briscoe-tsvwg-l4s-diffserv].” 
>> - Since this relates a to a requirement, I do not think this is appropiate. The reference provided is out of date, and does not appear to be progressing. Could this reference be removed? 
> 
> [BB] You're right the normative section about Functional Requirements is not the right place for this. I've deleted the whole second sentence.
> 
> Nonetheless, an implementer will need to have an idea how this DualQ fits into their existing queuing structures, so this sentence is worth keeping somewhere. I've stuck it at the end of §2.4 "Overall DualQ Coupled AQM Structure". I've also kept the ref, 'cos there is no other place an implementer could go for this information. But it's not in a normative section any more, and I've added some fluff to make it clearer that this reference is just early ideas:
>     "The two queues could optionally be part of a larger queuing hierarchy, such as the initial example ideas in [I-D.briscoe-tsvwg-l4s-diffserv]."
> 
> BTW, as I understand the chairs' position on the l4s-diffserv draft, it is 'on hold' while the WG focuses on the main L4S drafts. That means there will be no request for adoption (yet), but it also hasn't been refused adoption.
> 
>> --- 
>> 6) Unpublished Individual ID as a Ref: 
>> “and Voice-Admit 
>>    service classes (see [I-D.briscoe-tsvwg-l4s-diffserv]), 
>> - I’d prefer to leave this without a REF that to refer to an individual draft submission. 
> 
> [BB] I've replaced all 4 refs in this para with one ref to §5.4.1 of ecn-l4s-id. We can then confine this discussion of which refs are appropriate to that doc.
> 
> CURRENT:
> For instance addresses of specific applications or hosts (see [I-D.ietf-tsvwg-ecn-l4s-id]), specific Diffserv codepoints such as EF (Expedited Forwarding) and Voice-Admit service classes (see [I-D.briscoe-tsvwg-l4s-diffserv]), the Non-Queue-Building (NQB) per-hop behaviour [I-D.ietf-tsvwg-nqb] or certain protocols (e.g. ARP, DNS). 
> 
> PROPOSED:
> For instance addresses of specific applications or hosts; specific Diffserv codepoints such as EF (Expedited Forwarding), Voice-Admit or the Non-Queue-Building (NQB) per-hop behaviour; or certain protocols (e.g. ARP, DNS) (see Section 5.4.1 of [I-D.ietf-tsvwg-ecn-l4s-id]). 
> 
>> --- 
>> 7) NiT: “The scheduler SHOULD be work-conserving.” 
>> - This “SHOULD” introduces a design decision: Please add a one sentence explanation what happens if it is not. 
> 
> [BB]
> PROPOSED:
> The scheduler SHOULD be work-conserving, or otherwise close to work conserving, given Classic service will often rely on borrowing from the L4S service.
> 
>> --- 
>> 8) Dead reference (used multiple times) 
>> "if the packet is Not-ECT, the appropriate action depends on 
>>          whether some other function is protecting the L queue from 
>>          misbehaving flows (e.g. per-flow queue 
>>          protection [I-D.briscoe-docsis-q-protection] or latency 
>>          policing)" 
>> "Therefore per-flow policing 
>>    (e.g. [I-D.briscoe-docsis-q-protection]) needs to be separable from a 
>>    basic AQM, as an option under policy control." 
>> "However, the addition of DOCSIS per-flow 
>>    Queue Protection [I-D.briscoe-docsis-q-protection] turns this into 
>>    'delay on saturation" 
>> - The tracker shows draft-briscoe-docsis-q-protection has expired and is no longer active. What is the current status of this ID? 
> 
> [BB] The ISE has indicated it is OK in principle to proceed to publication. I have a couple of edits to it and I just haven't prioritized them. Sorry.
> 
>> --- 
>> 9) RFC2119 usage: 
>> " The following 
>>    parameters MAY be operator-configurable, e.g. to tune for non- 
>>    Internet settings:" 
>> - To me this does not seem like a standards interoperability statement. Do we need RFC2119 language, would it be OK to just say: 
>> " The following 
>>    parameters can be operator-configurable, e.g. to tune for non- 
>>    Internet settings:" 
> 
> [BB] I thought this was one of the few occasions where MAY is appropriate. But obviously you don't. If an implementer doesn't follow this MAY, their device won't be able to interoperate well with congestion controls in non-Internet environments. But whether this is a concern depends on the market their device is intended to address. 
> To me that's nearly word-for-word what RFC2119 says about the intended use of MAY.
> 
> I'll leave it for now, and see what you say in response.
> 
>> --- 
>> 10)RFC2119 usage: 
>> "The maximum queue 
>>       delay per queue per interval MAY also be recorded." 
>> - I'd sa surely a system can record anything? --  So this does not seem to need RFC2119 language, would it be OK to just say "can"... I'd also be interested to see a sentence that helps me understand *why* this might be useful as a log entry. 
> 
> [BB] I've added "..., to aid diagnosis of faults and anomalous events"
> Again, this is really about interop - not data plane, but management plane - interop with typical monitoring systems. So there's the same argument for a 'MAY' as above. 
> Again, I'll leave in the MAY and see if you disagree.
> 
>> --- 
>> 11) NiT: 
>> "Curvy RED can be used as is when 
>>    the RTT range to be supported is limited, otherwise an adaptation 
>>    mechanism is required." 
>> /required/needed/ - for avoidance of doubt? 
> 
> [BB] I'm impressed that you've found this in the depths of an appendix! 
> Agree with 'needed' in this first case, but...
> 
>> --- 
>> 12) NiT: 
>> "Priority of L4S is required to be conditional to avoid total 
>>    starvation of Classic by heavy L4S traffic." 
>> /required/needed/ - for avoidance of doubt? 
> 
> [BB] Here, 'required' is actually correct. So I've added a pointer to the requirement:
>     "Priority of L4S is required to be conditional (see Section 2.5.1) to avoid..."
> 
> Thank you very much.
> 
> 
> Bob
> 
>> -------------- 
>>> 
>>> On 29.07.21, 18:18, "tsvwg on behalf of Wesley Eddy"<[e-mail] on behalf of [e-mail]>  wrote: 
>>> 
>>>     This message is starting a combined working group last call on 3 of the 
>>>     L4S drafts: 
>>> 
>>>     - Architecture:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/ 
>>> 
>>>     - DualQ: 
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ 
>>> 
>>>     - ECN ID:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ 
>>> 
>>>     The WGLC will last through 4 weeks from today, and then we'll see what 
>>>     to do next.  Please submit any comments you have on these to the TSVWG 
>>>     list in that timeframe. 
>>> 
>>>     The chairs are considering a possible virtual interim following the 
>>>     close in order to work through feedback received. 
>>> 
>>>     The work on the L4S operational guidance draft is continuing in 
>>>     parallel, but that draft is not being last called yet. 
>>> 
>>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/