Re: [tsvwg] L4S vs SCE

[G Fairhurst <[e-mail]>]

Helpful, see in-line.

On 20/11/2019, 11:46, Holland, Jake wrote:
> From: Wesley Eddy<[e-mail]>
> Date: 2019-11-20 at 01:24
>> • concern that there can only be one of L4S or SCE happening
> There was a side discussion about this I think is worth mentioning:
>
> It might not be hard to consider the consequences of mis-classification
> that could occur in the "both experiments" scenario.  If the concern
> about co-existence is primarily technical, at first glance it doesn't
> seem too dire:
>
> (PS: I acknowledge that there may be legitimate non-technical concerns
> with running both experiments simultaneously, but have nothing else
> to add to that discussion right now--if your concerns are only non-
> technical feel free to skip this section.)
>
> 1. If a SCE connection runs across a chained SCE-L4S link,
> then there's a risk that the SCE node would mark ECT(1), which
> would then be mis-classified as an L4S packet by the L4S box
> box.  This makes the marked packet likely to be re-ordered,
> plus gives it a higher probability of being marked CE, which
> would cause a higher backoff than necessary for the SCE sender.
>
> This seems like not a disaster, since at least it fails safely
> with a MD backoff.  The cost is some performance penalty to
> SCE, but only when both aqms were lightly congested, and the
> sender responds as if at least one was heavily congested.
>
> (In the reverse direction, ECT(0) would already be classic traffic
> for the L4S queue, so there's no impact.)
>
> 2. If an L4S connection runs across a chained SCE-L4S link, the
> ECT(1) packets from the L4S sender would be mis-classified in the
> SCE node as already-marked SCE by upstream.
>
> If I understand the SCE versions of CNQ and CAKE correctly, this
> would have no impact--the ECT(1) packets would be marked CE when
> the congestion level is high enough (and won't get any SCE marks
> since they already appear to be SCE-marked), but this is no
> different from the behavior of any other 3168 aqm.
Since the chief aim of L4S was towards low latency, I'm also interested 
in queuing properties of the traffic, some initial questions:

Would an SCE router likely preserve or change the queueing of ECT(1) L4S 
traffic? - is this behvaiour different to any existing ECN-marking router?

And would SCE traffic arriving at the L4S queue meet L4S expectations in 
terms of responsiveness?

>
> Are there other scenarios that need consideration?
>
> As far as technical concerns go, these 2 situations don't seem
> like a high barrier to running both experiments simultaneously, but
> of course I'd welcome comments about other considerations this
> brief analysis misses.
>
>
>> • maybe lack of understanding about how and where people are hoping to use/deploy L4S?  (like as an operator, what else would be there that mitigates some of the concerns people have, and that supports gathering experimental results, etc)
> +1, these suggestions sound very helpful to me.  Mitigation strategies,
> expectations, end conditions for the experiments, monitoring and
> evaluation plans, any restrictions on scope of intended deployment;
> all these would be valuable additions to the docs IMO, and it would
> strongly mitigate my safety concerns if there were reasonable guard
> rails described.
 From what I recall when we discuused the EXP deployment of L4S: If this 
concludes at some time, I guess we can expect ECT(0) behaviour to 
continue as-is, and we can expect use of ECT(1) for L4S to terminate, or 
be filtered to avoid L4S.

Have we thoughts on what would happen with SCE?
>
>> • entangled evaluation of L4S with TCP Prague (I see this badly in the threads ... From what I can tell, the public test Prague code doesn't yet meet all the Prague requirements in the L4S draft, and that's caused some explosion of emails.)
> Yes, sorry about my contributions to this problem.  I wasn't sure
> how to make the point about the level of confidence we can have in
> the safety properties of an L4S rollout (and how it relates to the
> likely impact of wg adoption decisions on external SDOs) without
> bringing up the examples from the TCP Prague testing.
>
> Maybe it would have been better just to point out that we don't yet
> know whether the safety requirements of L4S can be achieved, since
> we haven't yet seen running code that meets them, rather than
> introducing confusion by pointing to example tests of something
> that doesn't yet try to implement those requirements.
>
> The point is well-taken, both from you and from Greg's earlier
> message to that effect, and I'll try to be more clear on this
> distinction in the future.
>
> Best regards,
> Jake
>
>
Thanks for these thoughts,

Gorry