Re: [tsvwg] L4S vs SCE

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more in-line.

> On Nov 20, 2019, at 11:04, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> Please see inline , an answer to the question that is to some extent to directed me personally 

	[SM] I want to apologize to you, I did not intend to offend with this question, nor did I want to drag you and Koen into this. I merely cited you as I assume that both of you have a better feel about your respective fields/industries interest in L4S than I do.


> 
> /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.

	[SM] Well, I am trying to discuss "contingency planing" here, by necessity that includes potential retraction of the experiment, no? I am also happy to talk about the opposite contingency here unconditional success; where should I send the bottle of Champagne to for the deserved celebrations? ;)

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

	[SM] I duly note that 3GPP is not committed yet, but is it fair to claim that inside 3GPP thee is an interest in L4S' goals and/or techniques? My question is about the feasibility to roll-back L4S (under the pessimistic assumption that this is deemed required) in the light of potential uptake into industry standards and roll-out into a potentially high number of network elements (think base stations, CMTSs, ...). 

Best Regards
	Sebastian


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