Re: [tsvwg] L4S vs SCE

["Holland, Jake" <[e-mail]>]

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.


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.


> • 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