Re: [tsvwg] L4S issue #22: CE Ambiguity and Reordering

[Bob Briscoe <[e-mail]>]

Jonathan,

On 24/02/2020 17:11, Jonathan Morton wrote:
>> On 24 Feb, 2020, at 5:15 pm, Holland, Jake <jholland=[e-mail]> wrote:
>>
>> What I was aiming toward when asking the question originally was that if there’s something that already exists and could be cited that demonstrates the scope of the problem justifying a normative SHOULD for RACK-like behavior, it would be beneficial to include it.  If there is no such source to cite, I didn’t mean to say it’s necessary to create one before moving forward.
>>   
>> To me the reordering issue itself seems so minor that I’m confused why there’s so much text and meeting time discussion about it.  I was worried I was missing something.  If the whole issue is addressed by the appendix text, it seems like even the “SHOULD” for RACK-like behavior from the transport is not justified, since there’s basically no harm even without it?
> My understanding here is that the root of this issue is that CE-marked packets originating upstream of the DualQ may be classified into a different queue than the rest of their flow, and may therefore be delivered out of order.  DualQ treats CE packets as always belonging to the L4S queue, so this issue affects Classic flows only.
Yes.
>
> The maximum expected quantity of reordering is easiest to define in time units; the CE packet would be about 0.5ms late if the L4S queue was at its target depth while the Classic queue was empty,
A CE packet from a Classic flow will never be delivered late.
I think you have not understood how the Coupled DualQ works.
> while it would be 15ms early if the reverse were true.
This part is correct.

This is why the phenomenon can only occur if there are (or have very 
recently been) two bottlenecks on the path:
1) a Classic AQM with a queue sufficient for for it to mark the Classic 
flow with CE
2) a Coupled DualQ with a queue built up in its Classic queue


> The behaviour of a RACK-type transport can be directly predicted based on those values, while predicting the behaviour of a traditional stack may require those times to be converted into packet serialisation times by way of the flow's throughput.
>
> The "RACK requirement" applies only to L4S flows, so I believe it is not relevant to resolving this.  Classic flows will continue to use a mixture of RACK (eg. Linux) and traditional (eg. default FreeBSD at this time) stacks.  It is the latter that are most likely to be affected, so testing (and thought experiments) should focus there.
Correct.


Bob
>
>   - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/