Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE (Evolvability))

Sebastian Moeller <> Fri, 03 January 2020 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A08121200B7; Fri, 3 Jan 2020 08:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 RRpezgfLMYnb; Fri, 3 Jan 2020 08:37:53 -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 D51DC12008F; Fri, 3 Jan 2020 08:37:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1578069412; bh=oGEKooeNp5oJd6fzlXFaMRZObYR8Un64K8PpwUJ9mQ0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=jyKIw6OHTha/BJRNEay9zMKVQaprvGBgzAcmmyquNMqHbI2EK8YTtBG0ol/+/N5b8 Kt5Xqrz5aHU0hube91N/O14SxSi+zLmIIdIOMnEcr5V6PEtoIrHo/o+82jXc6WUrNg wTQjfEeW543RmB3i0jOsLrkh/ZdxmAS+BXx7Kvns=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MORAa-1j5VKU1nyQ-00Pqfz; Fri, 03 Jan 2020 17:36:52 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Fri, 03 Jan 2020 17:36:46 +0100
Cc: Ingemar Johansson S <>, "Black, David" <>, Bob Briscoe <>, Roland Bless <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:JQPEwpeyW9p5ZOQBBkA7eYwHFddC5lpWDX6ZQ7gEy9ysrYTbIxr +bH9OsnZ8mZ4ybktmQrKWiSaxiUJj3RQgLwpDIrlEoTixa2/zgFS6eCte6svfnzoJUEvRrK qU68WIVapBrb4B6TQn764LTX7lPP5LdtZ+A9j7XDwu8jChsVH/OZIEiUjuAMygHGRPkDU6T 7BQQFO0WDiXKnEoSrcMMg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:zdk7x1EMOdo=:QqqL/EX73AJxhrqqprSy9u IyJzzSpIwRK3lOlvSUqzMbCLCTLH5KZcNKGdysLDXEglCVJOjb3dvSuKcL7ndH4Yv0tj5a3LD N0cVvk3Z1zJNsVTMKgtEaj4pxVSu1v1/kid0x6Z3z/m0dnTVmkvmJnFjSZWFctsOOf/2uFJOg NiFLobZNyKSlhJv8DKXrpSi7rkqrh9mUu23ptzle9FYb/CgYAlZXAJ9QUrsFEIZ9HFGO/xsbn 3y0cQ+HGDpk64+sbVkXamj2DQ14dh/pc1GeEiXnslUEqyeq/EsKbB4CAJnJNKcJij8twJi/B0 lhCjqUHtAQvMHnTmC2WnfKJWb3iLFDeAu+VYS/3YECHi7PaTfdlgWZfCEvwQIPuflFEHdUzZj Eko+K44YtB5LjfcrdQkJX90FV38zYSezRsKy7626bOgGkY5IKLBCtHmWrh7nZ+WFSqyzOWkYL KyK7rPgjXiLeOtgdRZEpd+xH7FWyb9h/AMwLvDkt40ziW+Q1JRpSg7KfPlCKbjnlxCdaR25qo 3WRfWIpk13l5u6QdG0hxoPIO/UTcgyHOK4oP3ugFEcSqKyrtk82TitX2RECNEHkTMUHRQV0UX u0KtzPDemhopwDtwNo+/ZxUmXlMcAYvDDXwOP55OsD0CHI35fs/hue8kxGHE7NOv6L6OM7dsy zQvu2Nhhw1CBAURn0yjxt7XhYJeOyBtlfhK9fDLppIDPCyizIJIOzpm2JpKnRcmPf8JnDFP7e 2nQvETv70dN2LKOUww3FeNWS3KzqQUhRqT4dJT9x83VA4QJFXDrb3Jb5fGtpHeOrk5z0vUEIP dSBvehdxb6vPpaCMragmNwdOoo64B6EXPAUIWu4osXMW8wIzNJwASBz+WVqdEMqK6T9hAQ+FA 566Koz/0D+/CylLHpPieVVt6NUH7y0nOrDrxmEseIi8yZ94psPdP+REnbGBxqjDfUGjB8jx7u GWAHkK3zu6siougUqiTP4TV7eT6AFzn1YEMs2Dv7snChU6WCieFC1eluRW0elQ2kRmb2aJRvJ MDXSSISKRo3Bgvakjuxa/MKlfzl8fmUNSa5SE6Y1ER/JJgtVBPgo2j/bFsUByK4XEnp8Etp9D Oqzpch5+fxFoSZdVJz1W3XSIaed0T8rcuiS4xRgPTz2L0/F9g0N7GkF9UF4ZPII0hVyILHKaQ H1bvr6qM5in7RfSBFxuxaBPRTp1o/i8KF49D+fHd1WtZvUA9NjIHxltfyyB01l/KlO1GMpRu5 5uhpTll2epNBxoIYndnAGqs/c5C2DKkEFSrtG7gBlwbaaPDuykxc3HdyRByA=
Archived-At: <>
Subject: Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE (Evolvability))
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: Fri, 03 Jan 2020 16:37:56 -0000

Hi Ingemar,

more below in-line.

> On Jan 3, 2020, at 12:18, Ingemar Johansson S <> wrote:
> Hi
> Please see inline
> /Ingemar
>> -----Original Message-----
>> From: Sebastian Moeller <>
>> Sent: den 3 januari 2020 10:28
>> To: Ingemar Johansson S
>> <>; Black, David
>> <>; Bob Briscoe <>; Roland Bless
>> <>
>> Cc: Ingemar Johansson S <>; tsvwg-
>> Subject: Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE
>> (Evolvability))
>> Hi Ingmar,
>> On January 3, 2020 10:10:31 AM GMT+01:00, Ingemar Johansson S
>> <> wrote:
>>> Hi
>>> Yes I am aware that SCE works with RFC6040 tunnels, it does however
>>> seem to work well with RFC4301 ditto.
>>> Now I have no idea as regards to how large extent RFC4301 is deployed
>>> on the internet and whether this is a large problem for SCE or not. I
>>> notice however that RFC4301 is no problem for L4S.
>>        [SM] I beg to differ, L4S will not play nice with either a rfc3168 
>> or SCE-
>> capable AQM on a tunneled segment, as it will completely misinterpret the
>> received CE marks and will not respond appropriately with a sufficiently 
>> large
>> reduction of the congestion window*. The currently still preferred solution 
>> to
>> this issue, if I understand Bob correctly, is still to reason that such 
>> ECN-enabled
>> AQMs along tunneled path segments (which I understand to be always inside 
>> the
>> core of an AS as towards the edges packets get decapsulated) are rare enough
>> to allow completely ignoring them.
> [IJ] This is more of a concern with traditional loss/ECN based congestion 
> control algorithms like Reno, Cubic (and DCTCP).

	[SM] How so? As far as I can tell the failure mode is, that L4S flows will not yield to the rfc3168 AQMs CE marks in the way that the AQM expects/is designed for, thereby crowding out the 1/sqrt(p) flows and securing themselves the lion's share of the bandwidth (assuming the hop does not need to dip deep into dropping-instead-of-marking territory)). BBR, might bully over the AQM's signals, but I am not sure whether that actually is an improvement over the status quo (unless purely viewed from BBR's perspective), but that is a different kettle of fish.

> If one look more into the 
> future (and actually present) I see algorithms like BBRv2 that strive one BDP 
> queue and will therefore not strive to bloat the queues as much as the 
> forementioned CC algos.  It seems to me like there is incentive to go towards 
> more of these. And as you point out below there is work ongoing work by Bob 
> and others to add RFC3168 compatibility to TCP Prague.

	[SM] Which albeit quite belated is a welcome development. I am looking forward to the data demonstrating that approach working as intended and as required (I am especially interested to see how long this is going to take and whether it introduces a "latency-bolus" in the queue). But that still leaves all other transports the L4S folks envision classifying into the L4S-queue to worry about. Doing that for TCP Prague is only a first mile-stone, sure being proof of principle it might be an important mile stone, but if coexistence with the existing internet is of serious concern (which it should) it is only the beginning... 
	I consider this to be a side-effect/consequence of redefining what a CE-mark means, as the SCE proposal demonstrates that is not the only option to implement 1/p style signaling.

> Speaking of the SCE capable AQMs, how much does it take to make them L4S 
> capable instead, an update of RFC8290 ?

	[SM] Note that RFC8290 is not really SCE capable to begin with (how could it, it predates the SCE drafts considerably). Be that as it may, IMHO it would take a) as a precondition a robust and reliable indicator of how a flow will respond to congestion signaling, 1/p or 1/sqrt(p), unfortunately ECT(1) is neither robust nor reliable*, and b) a consensus that overloading the ECN CE-codepoint with two semantic different meanings is reliable, robust (and safe for the rest of the network). 
	The more relevant question for me is what it would take to remedy these two obvious issues in the L4S design... and what would it take in addition to start tackling the failure of the dual queue coupled AQM to do the one thing is was intended/designed for reliably and robustly. 

Best Regards

*) Which flow does a CE-marked packet belong to a L4S-capable or an rfc3168-compatible one?

>> Best Regards
>>         Sebastian
>> *) I realize that there is finally some on-going research work on rfc3168-
>> compatibility in TCP Prague, but I have seen no data yet indicating that the
>> proposed scheme triggers fast enough (or even at all). I reserve judgement 
>> until I
>> see the data.
>>> /Ingemar
>>>> -----Original Message-----
>>>> From: Black, David <>
>>>> Sent: den 2 januari 2020 17:26
>>>> To: Ingemar Johansson S <>; Bob
>>> Briscoe
>>>> <>; Roland Bless <>
>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp)
>>> <koen.de_schepper@nokia-bell-
>>>>>; Kyle Rose <>;; tsvwg-
>>>>; Black, David <>
>>>> Subject: RE: RFC 4301 on ECN codepoints (was RE: [tsvwg] L4S vs SCE
>>>> (Evolvability))
>>>> See RFC 6040, which updates this area of RFC 4301.
>>>> In addition, see  draft-ietf-tsvwg-rfc6040update-shim and
>>>> draft-ietf-tsvwg-ecn-
>>>> encap-guidelines, both of which apply RFC 6040 to additional
>>>> encapsulations/tunnels ... and both of which are on Bob Briscoe's
>>> "round
>>>> tuit"
>>>> list to write better fragmentation text (what's currently in both
>>> drafts
>>>> does not
>>>> comply with RFC 3168's fragmentation provisions, hence has to be
>>> changed).
>>>> Thanks, --David
>>>>> -----Original Message-----
>>>>> From: Ingemar Johansson S <>
>>>>> Sent: Thursday, January 2, 2020 5:13 AM
>>>>> To: Black, David; Bob Briscoe; Roland Bless
>>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp); Kyle Rose;
>>>>>; Ingemar Johansson S
>>>>> Subject: RFC 4301 on ECN codepoints (was RE: [tsvwg] L4S vs SCE
>>>>> (Evolvability))
>>>>> Hi
>>>>> I put my question in a separate thread to avoid messing up the
>>>>> original thread.
>>>>> I read in  the
>>>>> following
>>>>>      (6) If the ECN field in the inner header is set to ECT(0) or
>>>>>          ECT(1), where ECT is ECN-Capable Transport (ECT), and if
>>> the
>>>>>          ECN field in the outer header is set to Congestion
>>> Experienced
>>>>>          (CE), then set the ECN field in the inner header to CE;
>>>>>          otherwise, make no change to the ECN field in the inner
>>>>>          header.  (The IPv4 checksum changes when the ECN
>>> changes.)
>>>>> So, if we have an SCE flow that is tunneled:
>>>>> 1) At the tunnel ingress, the ECN bits are copied to the outer
>>> header.
>>>>> 2) Somewhere along the tunneled path an SCE compatible AQM remarks
>>>>> from ECT '10' to SCE '01'.
>>>>> 3) At tunnel egress, given rule #6 above, I understand that the
>>> inner
>>>>> header will still be ECT '10'.
>>>>> In order words, the SCE congestion marks along the tunneled
>>> interface
>>>>> become ignored and the queue will grow until packets are either CE
>>>>> marked, or dropped.
>>>>> Is this a correct interpretation ?
>>>>> /Ingemar
>>>>>> -----Original Message-----
>>>>>> From: Black, David <>
>>>>>> Sent: den 2 januari 2020 00:32
>>>>>> To: Bob Briscoe <>; Roland Bless
>>>>> <>
>>>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp)
>>> <koen.de_schepper@nokia-
>>>>> bell-
>>>>>>>; Ingemar Johansson S
>>> <>;
>>>>> Kyle
>>>>>> Rose <>;;;
>>>>>> Black,
>>>>> David
>>>>>> <>
>>>>>> Subject: RE: [tsvwg] L4S vs SCE (Evolvability)
>>>>>> Bob,
>>>>>> (posting as an individual)
>>>>>> The assertion that SCE traffic will "starve" is just plain wrong
>>> in
>>>>>> the following ...
>>>>>>>> The SCE markings can be used independently whether you have
>>>>> multiple
>>>>>>>> queues or just a single queue.
>>>>>>> [BB] This seems to be the opposite of reality. Perhaps you've
>>> used
>>>>>>> the word 'can' because you think it might be possible. But
>>> there's
>>>>>>> good reason to doubt that. As follows...
>>>>>>> Packets from non-SCE and from SCE senders are indistinguishable
>>> by
>>>>>>> just looking at them. So, if there's a single queue, they have
>>> to
>>>>>>> be mixed together in it {Note 1}. But a single queue can only
>>> have
>>>>>>> one length.
>>>>>>> Any transports that don't understand SCE drive the single queue
>>> to
>>>>>>> a deeper operating point (defined by CE or drop).
>>>>>> The reasoning appears to be sound up to this point, but the next
>>>>>> sentence does not follow from the above:
>>>>>>> This overruns the SCE
>>>>>>> operating point, and causes SCE marking to approach 100% {Note
>>> 2}.
>>>>>>> Then those transports that do understand SCE will starve.
>>>>>> Actually, it causes both SCE and non-SCE senders to operate at
>>> that
>>>>> "deeper
>>>>>> operating point (defined by CE or drop)" because SCE traffic has
>>> an
>>>>>> RFC-3168-
>>>>>> like response to CE marks, and the usual reaction to drops.  The
>>>>>> result is a deeper queue than would have resulted in the absence
>>> of
>>>>>> non-SCE traffic,
>>>>> but
>>>>>> the result is definitely *not* starvation.
>>>>>> Thanks, --David
>>>>>>> -----Original Message-----
>>>>>>> From: Bob Briscoe <>
>>>>>>> Sent: Tuesday, December 31, 2019 6:11 PM
>>>>>>> To: Roland Bless
>>>>>>> Cc: De Schepper, Koen (Nokia - BE/Antwerp); Ingemar Johansson
>>> S;
>>>>>>> Kyle Rose;;
>>>>>>> Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
>>>>>>> Roland,
>>>>>>> As I just said, I noticed that Koen's useful response snipped
>>> some
>>>>>>> of your responses about evolvability that I ought to have
>>> addressed.
>>>>>>> Sorry, you'll need to reload state from November...
>>>>>>> On 22/11/2019 02:32, Roland Bless wrote:
>>>>>>>> Hi Bob,
>>>>>>>> see inline.
>>>>>>>> On 21.11.19 at 15:44 Bob Briscoe wrote:
>>>>>>>>> Roland,
>>>>>>>>> I'm not getting it....
>>>>>>>>> On 21/11/2019 09:32, Roland Bless wrote:
>>>>>>>>>> Hi Bob,
>>>>>>>>>> see inline.
>>>>>>>>>> On 21.11.19 at 19:34 Bob Briscoe wrote:
>>>>>>>>>>> On 20/11/2019 21:22, Roland Bless wrote:
>>>>>>>>>>>> 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...
>>>>>>> [BB] BBRv2 has not used SCE, but it has used L4S marking. And
>>> the
>>>>>>> authors of the LoLa draft have not used SCE but they have
>>> merged
>>>>>>> with the NQB draft, so that they can work with L4S as well. So
>>>>>>> perhaps your belief that SCE is "more evolvable" is just that -
>>> a
>>>>>>> belief.
>>>>>>>>> This last sentence... please really spell it out what you
>>> could
>>>>>>>>> possibly be meaning here. What has made you suddenly think
>>> this
>>>>>>>>> particular marking scheme has got magical properties that
>>>>>>>>> bestow evolvability? I'm serious, if you can't explain why
>>>>>>>>> you've said a sentence like this, it implies you are under
>>> the
>>>>>>>>> spell of some cult or fad.
>>>>>>>> Not sure what you are trying to indicate by your last
>>> sentence,
>>>>>>>> but sure, I can elaborate a bit on my last sentence.
>>>>>>>> I find it architecturally cleaner to have an additional ECN
>>>>>>>> codepoint used for indicating "SCE" rather than (ab)using it
>>> as
>>>>>>>> classifier for the dualQ AQM.
>>>>>>> [BB] I just forked another thread 'ECN as a classifier' to
>>> address
>>>>>>> that assertion.
>>>>>>>> The SCE markings can be used independently whether you have
>>>>> multiple
>>>>>>>> queues or just a single queue.
>>>>>>> [BB] This seems to be the opposite of reality. Perhaps you've
>>> used
>>>>>>> the word 'can' because you think it might be possible. But
>>> there's
>>>>>>> good reason to doubt that. As follows...
>>>>>>> Packets from non-SCE and from SCE senders are indistinguishable
>>> by
>>>>>>> just looking at them. So, if there's a single queue, they have
>>> to
>>>>>>> be mixed together in it {Note 1}. But a single queue can only
>>> have
>>>>>>> one length.
>>>>>>> Any transports that don't understand SCE drive the single queue
>>> to
>>>>>>> a deeper operating point (defined by CE or drop). This overruns
>>>>>>> the SCE operating point, and causes SCE marking to approach
>>> 100% {Note
>>>> 2}.
>>>>>>> Then those transports that do understand SCE will starve.
>>>>>>> In contrast, L4S works in dual queues or multiple queues (where
>>>>>>> 'works'
>>>>>>> means it gives very low latency without losing utilization).
>>>>>>> Also, there is considerable scope for evolvability with both:
>>>>>>> * the dualQ is a framework that is intended to encompass
>>> different
>>>>>>> AQMs in future.
>>>>>>> * and there is considerable scope for developing the ways FQ
>>> uses L4S.
>>>>>>> {Note 1}: Unless L4 identifiers are used to separate out
>>>>>>> microflows, and identify low latency flows by their behaviour.
>>> But
>>>>>>> then it's not really a single queue, unless you make it look
>>> like
>>>>>>> a single queue, but still treat it like multiple queues, as in
>>>>>>> LFQ. However, schemes like LFQ are "single-queue" in name only.
>>>>>>> They still have all the downsides of multiple queues.
>>>>>>> {Note 2}: Unless the SCE operating point is hardly any
>>> shallower
>>>>>>> than that for CE, in which case SCE gives hardly any
>>> improvement.
>>>>>>>> If one leaves the coupling aside the algorithm for marking
>>> will
>>>>>>>> probably not differ so much from what is proposed in L4S.
>>>>>>> [BB] You still haven't explained (rather than asserted a
>>> belief)
>>>>>>> why the choice between SCE and L4S has anything to do with
>>>>>>> evolvability.
>>>>>>>>>>> My whole purpose in solving the problem of deploying
>>> scalable
>>>>>>>>>>> CCs
>>>>>>> over
>>>>>>>>>>> the Internet was to re-juvenate evolution (to widen the
>>> range
>>>>>>>>>>> of applications that could be supported by different
>>>>>>>>>>> transport behaviours, particularly for real-time with low
>>>>>>>>>>> latency and high throughput at the same time). One of the
>>>>>>>>>>> main things that has stopped CCs evolving so
>>>>>>> far
>>>>>>>>>>> is the need for friendliness with the Reno behaviour that
>>> was
>>>>>>>>>>> not scaling over the years.
>>>>>>>>>> FWIW, our delay-based approach has deployment problems at
>>> the
>>>>>>>>>> other end of the spectrum: it gets suppressed by loss-based
>>> CCs...
>>>>>>>>>> (and we don't want to sacrifice our low delay goal).
>>>>>>>>>>> If SCE is primarily supported in FQ AQMs, that will
>>> constrain
>>>>>>>>>>> flows to be capped at the rate that FQ gives them. How is
>>>>>>>>>>> that doing anything
>>>>>>>>>> I was solely referring to the marking behavior of SCE, not
>>> a
>>>>>>>>>> particular implementation based on FQ-AQMs.
>>>>>>>>> This implies you believe all that silliness about a
>>> shallower
>>>>>>>>> SCE threshold not starving an SCE flow in a single queue,
>>>>>>>>> because it makes SCE flows not want to use the queue.
>>>>>>>> I do not understand what you are saying here.
>>>>>>> [BB] I've now explained this above (after "But there's good
>>> reason
>>>>>>> to doubt that...").
>>>>>>> The silliness I'm referring to is the statement by Jonathan M
>>> in
>>>>>>> his tsvwg talk at IETF-106 that CNQ is backward compatible with
>>>>>>> RFC3168 traffic, because its performance for SCE traffic when
>>>>>>> mixed with 3168 is bad enough that it discourages use of SCE
>>> alongside
>>>> 3168.
>>>>>>>>>>> other than massively constraining future evolution of CCs,
>>>>>>>>>>> especially real-time ones? See Per-Flow Scheduling and the
>>>>>>>>>>> End-to-End
>>>>>>> Argument
>>>>>>>>>>> <
>>>>> 10e7f921
>>>>>>>>>>> -861010bc36ff-2b3c729b7d8a378e&q=1&e=35be9991-3367-47d3-
>>>>> b023-
>>>>>> ed85
>> 01dddd52&
>>>>> r
>>>>>>>>>>> -flow_tr.pdf>. I don't
>>>>>>> need
>>>>>>>>>>> to tell you that the e2e argument is all about giving end
>>>>>>>>>>> systems the power to innovate without permission.
>>>>>>>>>>> Anyway, what are you imagining would stop CCs evolving
>>>>>>>>>>> alongside
>>>>>>> other
>>>>>>>>>>> scalable CCs? In much the same way CCs have always
>>> evolved.
>>>>>>>>>>> With L4S
>>>>>>> you
>>>>>>>>>>> have a clean slate that seems just like a FIFO with a
>>> shallow
>>>>>>>>>>> ECN-only immediate AQM. And other flows are causing you
>>>>>>>>>>> hardly any delay and
>>>>>>> very
>>>>>>>>>>> rarely any loss. Think of all the things you can do with
>>>>>>>>>>> that. Go evolve, Roland!
>>>>>>>>>> I already said that the Dual Queue AQM is nice, but comes
>>> with
>>>>>>>>>> the problem due to its built-in dropping law. Other CCs may
>>>>>>>>>> react differently and BBR was one example of newer CCs that
>>>>>>>>>> did not work in the L4S
>>>>>>> queue
>>>>>>>>>> without further adaptation.
>>>>>>>>> The built in dropping law is for the old traffic
>>> ('pre-evolved'
>>>>>>>>> if you
>>>>>>>>> like) that doesn't respond to anything else but loss. That's
>>>>>>>>> what drop-based AQMs were for - to fool Reno etc into
>>> thinking
>>>>>>>>> they had hit the buffers, so to speak.
>>>>>>>> Yes, I understand that. But what happens if the classic
>>> traffic
>>>>>>>> once vanishes and we only have low-delay congestion control
>>> and
>>>>>>>> want to re-use the "second" queue for other purposes, e.g.,
>>>>>>>> using it for flows that do not use loss-based CC?
>>>>>>> [BB] Let me repeat back the question, 'cos it seems rather odd,
>>> so
>>>>>>> perhaps I've misunderstood.
>>>>>>> You want me to assume that the classic behaviour of repeatedly
>>>>>>> seeking out more capacity until loss occurs doesn't exist on
>>> the
>>>>>>> Internet any more. There's only low-delay CC, by which I think
>>> you
>>>>>>> mean CC based on L4S ECN (but I'm not sure that's your
>>> meaning).
>>>>>>> Then, it sounds like everything would be working well. So why
>>> do
>>>>>>> you want to re-use the "second" queue for other purposes?
>>> Nothing
>>>>>>> is wasted if you don't use it. It has no capacity associated
>>> with it.
>>>>>>> it's just some lines of code sitting there in case packets
>>> appear
>>>>>>> from a classic
>>>>>> CC.
>>>>>>>>>>> The key thing here is the wording of the Prague
>>>>>>>>>> requirements
>>> <
>>>>>>>>>>> ection-
>>>>> 4>.
>>>>>>>>>>> We have a session in the 'Prague' side-meeting tomorrow to
>>>>>>>>>>> review
>>>>>>> them
>>>>>>>>>>> (and I encourage this on this list too).
>>>>>>>>>>> Later down the line, if the L4S experiment is successful,
>>>>>>>>>>> there will be an opportunity to review these requirements
>>> if
>>>>>>>>>>> a standards track doc replaces the experimental (it is
>>> easier
>>>>>>>>>>> to relax CC requirements than tighten them). So, for the
>>> expt
>>>>>>>>>>> track, the requirements are designed to protect competing
>>>>>>>>>>> flows from harm in a tighter way than you might find in
>>> RFC5033
>>>>>>>>>>> or
>>>> similar.
>>>>>>>>>>> Nonetheless, even the 1/p isn't tightly spec'd, quoting:
>>>>>>>>>>>     The inverse proportionality requirement above is
>>> worded
>>>>>>>>>>>     as a 'SHOULD' rather than a 'MUST' to allow
>>> reasonable
>>>>>>>>>>> flexibility
>>>>>>>>>>>     when defining these specifications.
>>>>>>>>>> Yes, but something has to be implemented (in hardware) and
>>>>>>>>>> therefore
>>>>>>> it
>>>>>>>>>> is fixed for some time and it should be consistent along a
>>>>>>>>>> path, so I don't see a viable path for evolvement of this
>>> coupling
>>>>>>>>>> law...
>>>>>>>>> Why does the coupling law need to evolve? It's a
>>> relationship
>>>>>>>>> between something invariant (scalable) and the past (which
>>> is
>>>>>>>>> over, by definition, so it's not going to change now).
>>>>>>>> See above, probably we want to put something into queue which
>>> is
>>>>>>>> using a non-loss-based congestion control and/or we need to
>>>>>>>> change the (1/p,1/p^2) marking.
>>>>>>> [BB] The queue doesn't induce loss, the CC does. The queue
>>> isn't
>>>>>>> 1/p or
>>>>>>> 1/p^2 or whatever, the different CCs are. So, if a CC is using
>>> the
>>>>>>> C queue without inducing any loss (e.g. a delay-based CC might
>>> be
>>>>>>> able to keep the queue under the AQM's target delay), then the
>>>>>>> coupling won't couple any marking across to the L queue.
>>>>>>> But I can't imagine why a delay-based CC that can keep the
>>> queue
>>>>>>> below the target of the AQM would want to classify itself into
>>> a
>>>>>>> queue designed for CCs that need to induce a decent queue (in
>>>>>>> order to maintain full utilization), given such queue-inducing
>>>>>>> traffic might start up at any time.
>>>>>>>>> If you want to evolve, you select what's best for you -
>>>>>>>>> probably the nice clean L4S ECN queue. I still don't get
>>> what
>>>>>>>>> sort of evolution you can't do? Evolvability isn't about a
>>>>>>>>> researcher being able to do what they'd like.
>>>>>>>> I also don't understand it in this way, but investigating
>>>>>>>> invariables and degrees of freedom prudently may enable or
>>>>>>>> facilitate deployment of new stuff. If that new stuff cannot
>>> be
>>>>>>>> deployed it never gets a chance of being weeded out later
>>> either.
>>>>>>> [BB] If you have something specific in mind, please say it.
>>> This
>>>>>>> is all getting rather abstract.
>>>>>>> This does make me want to question your notion of evolvability.
>>>>>>> Usually, when we make sure the Internet supports evolvability,
>>> we
>>>>>>> mean evolvability of new applications. We don't mean the
>>> ability
>>>>>>> for researchers to come up with different ways to solve
>>> problems
>>>>>>> that are already solved. There seems to be a hint of a
>>> complaint
>>>>>>> in your emails that L4S doesn't leave room for researchers to
>>>>>>> solve the same problem differently. That sort of evolvability
>>> is
>>>>>>> rather a luxury isn't it? If one approach solves an enduring
>>>>>>> problem with the Internet, it would be rather churlish to say
>>> "No,
>>>>>>> we can't use this solution, because it might preclude some
>>> ideas
>>>>>>> that might lead to other solutions to the same problem in the
>>> future,
>>>>>>> but
>>>> we're not sure."
>>>>>>> Having said that, I hope I (and Koen) have shown that L4S still
>>>>>>> leaves scope for complementary delay-based CCs, not to mention
>>>>>>> scope for different AQMs and for different FQ-based solutions.
>>>>>>> Regards
>>>>>>> Bob
>>>>>>>> Roland
>>>>>>> --
>>>>> __________________________________________________________
>>>>>>> ______
>>>>>>> Bob
>>>>>>> Briscoe
>>>>> 9834ecf
>>>>>>> 6-861010bc36ff-d256b2de1d12a128&q=1&e=35be9991-3367-47d3-
>> b023-
>>>>>> ed8501dd
>>>>>>> dd52&
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.