Re: [tsvwg] L4S vs SCE

Roland Bless <> Wed, 20 November 2019 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05C1512004D; Wed, 20 Nov 2019 05:23:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yBzbi1dDT21r; Wed, 20 Nov 2019 05:23:02 -0800 (PST)
Received: from ( [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2A53120024; Wed, 20 Nov 2019 05:23:01 -0800 (PST)
Received: from [2a00:1398:2:4006:b99b:2cd1:6772:2d66] ( by with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1iXPwf-0005mk-8c; Wed, 20 Nov 2019 14:22:57 +0100
Received: from [IPv6:::1] (localhost []) by (Postfix) with ESMTPS id 8C70B4200E2; Wed, 20 Nov 2019 14:22:55 +0100 (CET)
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <>, Ingemar Johansson S <>, Kyle Rose <>
Cc: "" <>, "" <>
References: <> <> <> <> <> <> <> <> <>
From: Roland Bless <>
Openpgp: preference=signencrypt
Autocrypt:; prefer-encrypt=mutual; keydata= mQINBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABtChSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+iQJABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEuQINBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABiQIlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID: <>
Date: Wed, 20 Nov 2019 21:22:54 +0800
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060111 Thunderbird/1.5 Mnenhy/
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------ABA3E710A8AA5C3C9BF4CE95"
Content-Language: en-GB
X-ATIS-Timestamp: esmtpsa 1574256177.350921840
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 13:23:06 -0000


On 20.11.19 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.
> 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.
Yes, but as I also expressed my concerns w.r.t. the L4S codepoint
earlier, at the cost of binding this to a quite fixed set of L4S
behaviors and "burning" the last ECT codepoint. Personally, I like
concepts with a little bit more potential to be useful for future
development (evolvability) of congestion controls, e.g., BBRv2 and LoLa
could also benefit from an SCE-like marking...

Therefore, a compromise could be to define ECT(1) with "some congestion
experienced" semantics that could also be used for L4S.
In order to further disambiguate and use the particular L4S semantics of
Dual Queue AQM etc. one could use an additional DSCP as
L4S classifier: I currently don't see the need to follow the argument of
providing L4S orthogonal to DiffServ (and for me L4S is specifying a PHB).
In case L4S doesn't take off one can at least use the SCE semantics and
reassign the DSCP (or in case of success make it later orthogonal
to DiffServ). Due to the newly opened pool of DSCPs one may have a
chance of finding a DSCP that has a high probability of
getting through from end-to-end.

> 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).
> 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.
Achieving RTT fairness isn't easy, but the Fair Flow Balancing mechanism
of TCP LoLa is one
example of how one can achieve this...

> 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. 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.
I didn't see the adoption of L4S work at the BOF as an agreement to
accept everything as proposed rather than
an agreement to discuss and work on the issues, and to come up with a
potentially different solution as it has been
at the time of the BOF.


> 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 < <>>; G
> Fairhurst < <>>;
> <>; Ingemar Johansson S
> <
> <>>;
> <>; De Schepper, Koen (Koen)
> < <>>;
> <>
> *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