Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Jonathan,

Third attempt: pls respond to the thread below. We have not seen a 
response for 7 weeks now.

You have made the dramatic claim that the L4S DualQ provides a fast 
lane, but your experiment doesn't even do an A/B comparison (comparing 
the throughput of your 'tweaked' flow with one classified as ECT0 rather 
than ECT1).

Koen's experiments showed that throughput is identical whether ECT0 or 
ECT1 for a flow presumed to be like yours (about 70% of link capacity 
and unresponsive).
https://github.com/L4STeam/l4steam.github.io/tree/master/overload-results#readme
In other words: your claim that there is a fast lane or throughput bonus 
seems to be false.

So, the WG either needs you to do a proper A/B experiment or to explain 
your 'tweak' in sufficient detail for someone else to reproduce your 
results.
Otherwise we can only assume that you are finding it difficult to admit 
a mistake (given you are clearly following and responding to other IETF 
business).

I notice that a reference to your experiment is in the Shepherd's 
writeup for the DualQ, presumably at your request. I'm afraid, if you 
expect your experiments to be referenced, especially when accompanied by 
such dramatic claims, you need to respond to queries and criticisms in 
reasonable time.


Bob


On 23/03/2022 18:44, Bob Briscoe wrote:
> 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/

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