Re: [tsvwg] L4S vs SCE

Sebastian Moeller <> Wed, 20 November 2019 14:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75F2D1208DA; Wed, 20 Nov 2019 06:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oA0vGyDjX6qj; Wed, 20 Nov 2019 06:19:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FDF0120896; Wed, 20 Nov 2019 06:19:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1574259531; bh=CGBnj+ln1LUcPX128EW7goohHGMzjzv/qRE9fihgKOg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=dyzY6Ux8E7WETpu6RR6k7R1T63GNpksJMhSNfsSaDfMaNa7o1CrjMUhoEdG917lXm 68XOZKA1CNpLpdmN663qGpKPwpsKkWvD3w7jfSmIaR/gG+dK8yN3F8RPtHaS33xmwG THir00pGIZDugh15tONC5KUguAANEBc+KiQ4Ewi4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1MtwZ4-1hhndP0cLU-00uFqF; Wed, 20 Nov 2019 15:18:51 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Wed, 20 Nov 2019 15:18:47 +0100
Cc: Ingemar Johansson S <>, Kyle Rose <>, G Fairhurst <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:Al5OLV8mvqjG+lPkZr4rUFuZf6C2/nQpugwYkCVQmbEwGypYMbN 2DbCetq2cwn0f7n+2W8PS+2gLbHeJkYJYj9kA5bAjWpMCKEVy7H0NG1Z0jBfh1Naok73jFL HibxxuWY05PFtyIwSidToT8+4ovD5tL8e0zCC8V9l7ZbpjLuv7AjqJtWBo9gqLTzgJ0P5lF edWGkf0CqcSUOLAxBlwHQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7zhC65BAFYc=:KaupS4nVzcyTe1qPUoWolG TnHNpRZyAgdVoc0gGrdcS7AHCb6GV9SJ7+npUOZuCKMZvuxoHZ6wUsXQLoaqIG/XrsRUgsvC5 +j7wGoyq57mIgI3I2m56UIHOsL/RuM4GBxgp8/cacaq223dDM2QFzgQR8BidpDUcxuA7jA6sv vsxkT7+RNg/rcbPd6XTN96FXpTlFFmeoiwIEg1I4wQv+3Sl9a/ymzeDNz72GmWiQ8RK3mLEoK ywTtmTHxn1vkEl27mqjmMs4LWqiDTKwpxEFRERoOlByoaLPRfxXbiRw19SnNZKwJrn6YoZ8FK 8LqjhpM+v9OoUGdA9MEa2DxU1XoCLM9tRBCxyxKK4ANIc8DtUDM4JjhMF0mrbjdrjvH0k1nzm NH4I4UNOGWUO34y6rzzqj1grlS63cta/eQKuGN9X5FW1EUULqdbYq0x9pW/axf6Ofk9tRRG+8 +T/7MQvJ4++hn5oGqDYXlGPBXxJpQYvGHXd7+TNsS2OzaQk/Yku+5SA4p1G9kuf3+xensuPid t397gLTgZzhcVvwAkSp/f4s/N5WZxG302b4ey+HSDbvIT/+CFv9EQ0xO7UOTeGr0uM49pAIna hM6TcIwjE898xK7nyXNksQjrj79tyQ8qNBbvOSoi43OkYRXDqNNmpa//uecB3IMEZsGVWgKqJ +eqv+eoNKymlZoh8ZUONSRCGVcHMnRYeFuDYfImBgg3s5i9pOAJqFv94deo+NJglZB89z3QlC G7JIVIOmmXll1FuENrECxJgWnm763WY/y8UlXFKj7myP10zNVNOFI5t9mqBX6zNwxW60PlEpV K3DpF5VlmYLE2bKqGCzS4pnTyoDvhnR4qRsBfQQr4AONREqdsP/itOwiWykyHwJGhZRSNKQ7R gkr4uGAVkIsOmNnVcwlcMU+sIUG+CtzaOyhrLtnyy1xGrx6BN6gQcvkP2wI4N5LVomdBDSXKH ve1DdZbny2hbdXncJJV97CXti2ygm+iGdmlVpBYakKRfia0rWifs7FoR5z7C606XwXFDXikEm WDESZzRGfT6my1h4VEibZNDLMlwRO2tgRJ5h0h5b6I8x4CLO1cGQO7CY6/vDPC0ihqwQk/g7S /I0HqWFCVefLCjhDBWYS/HEbd0lai28sW7JMkUPqCeVaf2TM4o9D02JnXoKEfqEzdIj3wGezP cykWs7srvfuribW1HYMwBJAfu/H98Y/NQFdWRAmauOYi3tyAgAdAzGC6JV8HvEIXxTIW2D/cZ 8I9Hkoec42xFrpEwHl0iJbMH7tApglItvOzdh9Mlx+z9LOnHpp0DsrVLlcts=
Archived-At: <>
Subject: Re: [tsvwg] L4S vs SCE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 14:19:03 -0000

Dear Koen, dear all,

> On Nov 20, 2019, at 13:40, De Schepper, Koen (Nokia - BE/Antwerp) <> wrote:
> I agree with Ingemar. Related to the chances for failing: as history learned us, the only real world chance for failing would be that the technology would not be taken up in deployments. This whole codepoint conflict is mainly damaging/creating this deployment 'issue'. The other so called show stoppers are less of an issue for most people that worked on CCs. Blowing 'issues' (not yet implemented/integrated/tested code and bugs) out of proportion is not the way to go forward here.

	[SM] I take offense in that characterization. It is by now an accepted fact that the dual queue AQM/scheduler does not work as intended or expected from reading either the dualq or the L4S-arch draft, That is not an issue if CC algorithm or RTT dependence, if the isolation between the two queues would be as robust and reliable as one assumes from reading the two internet drafts, all RTT unfairness would do is distribute bandwidth unequally between different RTT flows in each of the two queues. That is very much not the reason for me to observe dual queue failing miserably, the failure mode is the leakage between the two queues. I just think that undesired behavior in one component is best fixed in that specific component instead of basically declaring the issue goes away once all CC are made more RTT-invariant. If that would be easy, I assume it would not be an issue any more anyways, but I predict it will not be completely fixable (short RTTs generate tighter control loops).

> To give an example:
> As mentioned in another thread already: the L4S codepoint, where there's a new queue and new CCs, creates a clean-slate opportunity. This is an opportunity to select new desired behavior.

	[SM] The precondition for that clean-slate is however that L4S and existing traffic are sufficiently isolated from another, and that isolation as currently implemented IMHO is not sufficient.

> One of these opportunities here is to make L4S_TCP less RTT dependent. There have been many working implementations for less RTT-dependent CCs in the past. One that is widely deployed is Cubic, which is doing this for getting more throughput for longer RTTs. The only reason why it didn’t fly for lower RTTs on the current Internet is that they would hurt themselves (get lower throughput, competing with Reno).

	[SM] Looking at the pfifo_fast results in Høiland-Jørgensen T, Hurtig P, Brunstrom A (2015) The Good, the Bad and the WiFi: Modern AQMs in a residential setting. Computer Networks 89:90–106. For Cubic/pfifo_fast (linux former default combination), I fail to see a strong indicator that cubic is RTT invariant or getting more thoughput at longer RTTs (except for the 10ms versus 50ms "hump"). What paper/data should I be looking at instead?

> As we are able to define a new independent behavior and the RTT dependence in L4S is taken serious (some even call it a show stopper) this is even a must do opportunity for L4S. It is all a matter of perspective: show-stopper <-> opportunity.

	[SM] I believe that working on more RTT independence is worth-while but no replacement for fixing the isolation system as it it is that equitable isolation from existing traffic that basically gives you the slate clean-"green field" development opportunity, no? 

> Let it be clear, I am not against adopting new ideas for implementation of congestions controls and AQMs, as long as they are not contesting with the code point and requirements that were selected and agreed on as part of the L4S BoF.

	[SM] Not claiming that it applies here, but "not contesting with the code point and requirements" basically rules out all substantial changed to L4S...

> I'm also not against the recent vibrant energy, interest and engagement of people, but I think we can better use this energy in making things work. As you noticed, we can use the help to speed things up on the open source part.

	[SM]... while at the same time requesting help for implementation and dealing with the consequences of said "code point and requirements".

Best Regards

> Regards,
> Koen.
> From: Ingemar Johansson S <> 
> Sent: Wednesday, November 20, 2019 11:50 AM
> To: Kyle Rose <>rg>; Ingemar Johansson S <>
> Cc: Sebastian Moeller <>de>; G Fairhurst <>uk>;;; De Schepper, Koen (Nokia - BE/Antwerp) <>om>;; Ingemar Johansson S <>
> Subject: RE: [tsvwg] L4S vs SCE
> Hi
> So given the imagined outcome that L4S fails.. two scenarios
> If other SDOs or developers don’t pick up L4S then things are quite simple I guess, just declare the L4S drafts as deprecated, or is there more to do ?
> But, if e.g. 3GPP somehow thinks that this is a good idea and adopts it.. Will the IETF send a message (LS?) to 3GPP with the message “please stop using L4S”, is this even a reasonable scenario?. After all, the fact that it is picked up by other SDOs, speaks against a failure ?
> /Ingemar
> From: Kyle Rose <> 
> Sent: den 20 november 2019 11:14
> To: Ingemar Johansson S <>
> Cc: Sebastian Moeller <>de>; G Fairhurst <>uk>;; Ingemar Johansson S <>om>;; De Schepper, Koen (Koen) <>om>;
> Subject: Re: [tsvwg] L4S vs SCE
> On Wed, Nov 20, 2019 at 6:04 PM Ingemar Johansson S <> wrote:
> >       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.
> I'm going to have to go ahead and disagree with you strongly here. Given the potential consequences of cleaning up after a failed experiment without a plan worked out beforehand, this blithe approach is simply not acceptable.
> In lots of cases, experiments are easy to terminate in an obvious way: for example, in one typical case, a code point can simply be abandoned, or (even better) a pollutable experimental code point returned to the available pool after some time. If that were the case here, it would not be difficult to enumerate a sequence of steps required to do so. It doesn't appear that's the case, however, so all the more reason to make sure we address this as part of the experiment setup.
> A launch escape system of the necessary complexity should be a requirement of any experimental deployment. In this case, that might circumscribe the scope of the experiment itself.
> Kyle