Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

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/