Re: [Last-Call] [tsvwg] Opsdir last call review of draft-ietf-tsvwg-aqm-dualq-coupled-24

[Bob Briscoe <[e-mail]>]

Sheng,

On 31/08/2022 00:27, Sheng Jiang wrote:
> Hi, Bob,
>
> If you have documented the reasons that ECT can be used and the other 
> questions you mentioned in another document, it is worth of mentioning 
> it in this document and reference to the another document. I am fine 
> with your explanations. Overall, I do not know L4S much. I just review 
> it from the general operational perspective.

[BB] ecn-l4s-id is a normative reference in this aqm-dualq-coupled 
draft, which cites it 19 times.


Bob


>
> Thank and regards,
>
> Sheng
>
> On Sun, 28 Aug 2022 at 02:20, Bob Briscoe <[e-mail]> wrote:
>
>     Sheng,
>
>     Pls see [BB]...
>
>     On 26/08/2022 11:03, Sheng Jiang via Datatracker wrote:
>     > Reviewer: Sheng Jiang
>     > Review result: Has Issues
>     >
>     > Reviewer: Sheng Jiang
>     > Review result: Has Issues
>     > Document: draft-ietf-tsvwg-aqm-dualq-coupled-24
>     > Review Date: 2022-08-26
>     >
>     > I have reviewed this document as part of the Operational
>     directorate's ongoing
>     > effort to review all IETF documents being processed by the IESG.
>     These comments
>     > were written with the intent of improving the operational
>     aspects of the IETF
>     > drafts. Comments that are not addressed in last call may be
>     included in AD
>     > reviews during the IESG review. Document editors and WG chairs
>     should treat
>     > these comments just like any other last call comments.
>     >
>     > This experimental document defines a framework for coupling the
>     AQM algorithms
>     > in two queues intended for flows with different responses to
>     congestion. It is
>     > the network part of the L4S architecture that enables both very
>     low queuing
>     > latency and high throughput at the same time.
>     >
>     > I have concerns on the operational description in this document.
>     This document
>     > claims its mechanims can be deployed in the current network. But
>     it lacks the
>     > description on how and why it can works back-compatibly. I heard
>     there were
>     > intensive debate regarding to the usage of ECT (I did not
>     participate it
>     > myself), but the document has not introduced the reason or
>     background why it is
>     > allowed to use ECT from the urgement.
>
>     [BB] I'm afraid this comment is directed at the wrong draft,
>     because it
>     confuses two things:
>     * This document (DualQ) is about where a bottleneck buffer /has/ been
>     updated with L4S support. The DualQ draft is entirely about a
>     backwards
>     compatibility mechanism.
>     * The intensive debates were about possible cases where a bottleneck
>     buffer had previously supported Classic RFC3168 ECN, and it had /not/
>     been updated for L4S.
>
>     The remedies for the second case are in the requirements for L4S
>     sending
>     hosts, which is where that debate was directed (
>     draft-ietf-tsvwg-ecn-l4s-id ). The WG has now moved past that debate,
>     onto the next stage, which is to measure the size and severity of
>     this
>     issue, experiment with the required backward compatibility
>     mechanisms in
>     senders and to record all this in the l4sops draft.
>
>     The main question was how prevalent cases might be where L4S and
>     non-L4S
>     flows could compete in a queue that supports Classic RFC3168 ECN,
>     versus
>     whether they would nearly always be separated by a per-flow
>     scheduler,
>     and how serious and how sustained the problem would be if they did
>     mix
>     sometimes. That's nothing to do with this DualQ draft.
>
>     >
>     > Another minor comments, there is another reason that can cause
>     the result
>     > mentioned in 4.2: if irresponsible terminals labels classic
>     ect(0) flows into
>     > l4s ect(1), it would overload l4s queue.
>
>     [BB] That's not the case with this DualQ system. The two queues feed
>     into the same capacity, and either queue can use it all. So
>     there's no
>     more overload if traffic is switched from one to the other, even if
>     source(s) are unresponsive. And the system is designed so that the
>     priority scheduler gives no advantage to overload with ECT1.
>     Because if
>     the total load into both queues is greater than the capacity, the
>     overload mechanism kicks in. It couples the two queues together as
>     one,
>     and applies an equal proportion of AQM drop to both. Here's the
>     overload
>     experiments showing that, which were explained in the WG:
>     https://l4steam.github.io/overload-results/
>
>     Thank you for taking the time to write up your review.
>
>
>     Bob
>
>     >
>     > Regards,
>     >
>     > Sheng
>     >
>     >
>     >
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoe http://bobbriscoe.net/
>
>
>
> -- 
> Sheng Jiang

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/