Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Jonathan,

I notice that you have returned to responding to IETF-related emails in 
the last few days.
The long email thread started below (or that following Koen's similar 
response to you sent at roughly the same time) are still waiting for you 
to confirm whether your experiment effectively disabled congestion 
control, even though it said it didn't. Because, if so, sending the same 
traffic into the C queue would have achieved just as much throughput as 
sending into the L queue.

Reason: the accusation that the L queue of the DualQ coupled AQM 
provides a 'fast-lane' is contrary to everything we stand for, so this 
point needs to be cleared up.


Bob

On 17/02/2022 18:33, Bob Briscoe wrote:
> Jonathan,
>
> David has pointed me at the description of your scenario about a 
> throughput bonus that he was talking about in the interim yesterday, 
> and I have traced it back to an experiment you described in the paper 
> linked in your August posting below.
>
> 1/ Firstly, let's get a goal straight. In the L4S architecture, where 
> it offers either an FQ or a DualQ option, it says:
>            The L4S architecture does not require the IETF to commit to
>            one approach over the other, because it supports both, so that
>            the 'market' can decide.  Nonetheless, in the spirit of 'Do
>            one thing and do it well' [McIlroy78  <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch#ref-McIlroy78>], the DualQ option
>            provides low delay without prejudging the issue of flow-rate
>            control.  Then, flow rate policing can be added separately if
>            desired.
> Do you understand and accept that as a goal of the L4S activity, 
> irrespective of whether you would advocate per-flow throughput control 
> yourself?
>
> 2/ Turning to your scenario, you say the following:
> "Both flows were configured to use CUBIC congestion control with ECN 
> negotiated, but one was additionally tweaked to set ECT(1) instead of 
> ECT(0) on all
> data segments, and to pace its output at 40Mbps."
> Does "pace" mean sending at 40Mb/s irrespective of congestion feedback?
>
> You say "This latter measure [the pacing] prevents the L queue from 
> seeing any need to apply congestion signals, because it is always empty."
> However, in the scenario shown, although the L queue is indeed always 
> empty, it will see a high level of congestion signals (~10% in this 
> case) via the coupling.
>
> Your paper reads as if you don't understand how the coupled AQM works. 
> So I don't know whether you /thought/ the L queue would see no 
> marking, or whether you actually measured the marking. If you found 
> none, there must have been something wrong with your setup.
>
> If we assume your setup was fine, then the 'tweaked' ECT(1) CUBIC flow 
> would have seen about 10% ECN marking which would have driven its rate 
> down well below 40Mb/s. This is why I suspect that the 40Mb/s pacing 
> was actually unresponsive pacing.
>
> If so, the DualQ would have been working as intended. This is not a 
> 'fast lane' or a 'bonus' to L4S. Because whether you had fed the 
> 'tweaked' unresponsive 40Mb/s flow into the L queue or the C queue, it 
> would have got 40Mb/s.  Because that's what unresponsive traffic gets 
> in a FIFO, which is what the DualQ is intended to emulate (as in the 
> quote at the start). Then the operator can add per-flow rate policing 
> if it wants to, just as it can in a FIFO today (but hardly any do).
>
>
>
> Bob
>
> On 26/08/2021 23:20, Jonathan Morton wrote:
>>> On 29 Jul, 2021, at 7:18 pm, Wesley Eddy<[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.
>> I have read through these drafts more times than I really wanted to, and frankly can't shake the feeling of listening to a mistuned piano whilst doing so.  I hereby object to the advancement of these drafts to the next stage of publication, as they are clearly in no state to do so.
>>
>> My detailed comments, which among other things provide a technical justification for the bullet points read out by David Black during the recent meeting, are available here:
>>
>> 	https://sce.dnsmgr.net/downloads/L4S-WGLC2-objection-details.pdf
>>
>> - Jonathan Morton
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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