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

[Luca Muscariello <[e-mail]>]

I think issue #22 (https://trac.ietf.org/trac/tsvwg/ticket/22) is more than
just out of order.
It is related to issue #28 and #26.

I did not follow the WebEx recording (not yet shared I think) so I do not
know what
has been discussed during the virtual meeting. Please share the recording.

Out of order is an effect of mis-classification that can happen frequently
in presence of
unresponsive traffic in either the priority or non-priority queues (see
issue #26).
Depending on the rate of unresponsive traffic, not only average rate but
instantaneous rate,
out-of-order events can oscillate frequently. I still have not found any
reference that
proves this does not happen. I tried to raise this point in the past but
it's been ignored
or dismissed by saying that unresponsive traffic is negligible. I disagree.

https://mailarchive.ietf.org/arch/msg/tsvwg/gKFIrBVcNCEZm9wQOIDvyBEi0yM/

There are several potential issues coming from that phenomenon. One in
particular is that (issue #28)
the overall system will not be able to guarantee the latency targets at
stake.

It looks like most of the discussion on this issue is about how this
affects TCP, but the applications
that would mostly benefit from the priority queue are not really using TCP.
So out-of-order/mis-classification for real-time traffic would be worse.

I think that this issue is also related to how much dualQ can provide
predictable performance
under a general traffic mix which constitutes today and future Internet
traffic.

The problem of predictability looks fundamental here, even to deploy an
experiment.
The risk is that we build something to satisfy customers' low latency
request that won't meet the
expectation. Building dualQ has a cost and we better know what we get out
of it before building it
in silicon (issues #22 #26 #28 at least).

Luca



On Mon, Feb 24, 2020 at 6:12 PM Jonathan Morton <[e-mail]>
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.
>
> 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, while it would be 15ms
> early if the reverse were true.  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.
>
>  - Jonathan Morton
>
>