Re: [tsvwg] L4S vs SCE

[Ingemar Johansson S <[e-mail]>]

Hi
Please see inline , an answer to the question that is to some extent to directed me personally 

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 20 november 2019 09:32
> To: G Fairhurst <[e-mail]>
> Cc: Holland, Jake <[e-mail]>; [e-mail];
> Ingemar Johansson S <[e-mail]>; tsvwg-
> [e-mail]; De Schepper, Koen (Koen)
> <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] L4S vs SCE
> 
> Hi Gory,
> 
> new question below.
> 
> > On Nov 20, 2019, at 05:03, G Fairhurst <[e-mail]> wrote:
> >
> > 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.
> 
> 	[SM] According to Koen:
> "I don't expect many large real world service/application providers to use the
> basic reference Prague implementation anyway. They will have their own
> version ready, eager to deploy low latency applications and to test and check
> if they are sufficiently complying to the Prague requirements."
> 
> And according to Ingemar:
> "I have argued (rightly or wrongly) about the connection to work in 3GPP,
> admittedly so far only proposed work. Others have pointed out work related
> to WiFi and DOCSIS, how much should this weight in here ?"
> 
> It seems like the industry is ready to adopt L4S rather quickly.
> 
> 
> 	How do you expect an industry/commercial roll-out of L4S
> technology to behave, if the L4S experiment should terminated without
> adoption as a standard track RFC? Are they supposed to phase-out using
> ECT(1) as well, or is it understood that deployed L4S instances continue using
> L4S methods?

[IJ] The premise would be that L4S is declared a failure. I doubt that anybody has a good enough crystal ball to predict what happens. First it is necessary to come to the conclusion that L4S is a failure and I would argue that we are not yet there and I don't currently see that coming. Before that possible event I don't see it meaningful to speculate.
This reminds me of a question the late Ingvar Kamprad, the founder of IKEA, got when an IKEA warehouse was opened in northern Sweden, something that he was very engaged in personally : "How long are you going to support it financially?" was the question. His answer was "Well.. let us open the warehouse first..".. I can add that the parking lot outside IKEA in Haparanda, Sweden is most often jam-packed.
And.. as regards to 3GPP adoption, it must be understood that 3GPP has not yet adopted L4S, I certainly hope that it will go that way and I try to do all that I can to make that happen, but alike IETF, 3GPP is a collection of minds with differing preferences and goals.


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