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

[Sheng Jiang <[e-mail]>]

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.

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