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

[Bob Briscoe <[e-mail]>]

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 
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-17.html#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 
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-17.html#I-D.briscoe-tsvwg-l4s-diffserv>]), 
the Non-Queue-Building (NQB) per-hop behaviour [I-D.ietf-tsvwg-nqb 
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-17.html#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 
<https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-17.html#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/