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

Sebastian Moeller <moeller0@gmx.de> Fri, 03 January 2020 09:35 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2B1201A3; Fri, 3 Jan 2020 01:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhwXvUOR3aTn; Fri, 3 Jan 2020 01:34:58 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02244120180; Fri, 3 Jan 2020 01:34:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578044094; bh=eYVsFKaVGVwhRkLJ7c+JLspvYm9HN2HMhyeOOGYTEbc=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=DS20MOuSeOKfOyrLsARPASEpvXO3oIb0qIVborxanHcL3Pl2oVM1nlyUy+QF2e2Am rw0aOkPmjMAF/AMWduhfZAh3leN8GpEwRz4p8sAjmncHvSR7EXJGbI5ncBuKf0idih DWdqO9MY0QoUsX4THXIxSuwkeZXrPLA5pNg+L9x8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.22.54.225] ([80.187.115.94]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N4z6q-1jm3Eu3fHw-010xxI; Fri, 03 Jan 2020 10:28:29 +0100
Date: Fri, 03 Jan 2020 10:28:18 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <HE1PR07MB4425C5C29B3F53BD3B838DE1C2230@HE1PR07MB4425.eurprd07.prod.outlook.com>
References: <HE1PR07MB44253C4F00626C004E36D150C2200@HE1PR07MB4425.eurprd07.prod.outlook.com> <MN2PR19MB404592710685811AC2D255FE83200@MN2PR19MB4045.namprd19.prod.outlook.com> <HE1PR07MB4425C5C29B3F53BD3B838DE1C2230@HE1PR07MB4425.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "Black, David" <David.Black@dell.com>, Bob Briscoe <ietf@bobbriscoe.net>, Roland Bless <roland.bless@kit.edu>
CC: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <9D3452AD-8487-4937-B81C-6E0AC721D572@gmx.de>
X-Provags-ID: V03:K1:3xJdKUU+eLEhygVBgMyZqYBEMydu2y9hZZx7RYBPIbLZGt6VWXe CsEWZPuL388JIjIkVWV4c/968UwVMYUDeOAoSDjTKre8qOHcDySBAW+19pJbkw79430tapW ZvguPpuE8lW1Qxp5XEEbKdbJWrhEaRfug0sVT1U2Zwen26b2h095Li9bfP0s1D1BOymH6aE xdaAgcI23CI43ZDsbv0kA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:hhIQXmaPB1o=:4WUfx78DXUOkfVqtD6/nyT 2Cg7NAnR04LTNcZd/1m7/bwSiFXHO8b+5o8UAAh8bTENnRM+sXyQbNnbfSa2Awy03yvT/8Fnq Plifj0GuicSyzHOvg/vvIcePJLcZyNwvBj80LbE/2iTpUb3AeDRrwJ7OTx8M11FHy15TXL0Rd HEPpUs7KReIUx8H87jy+C2vytIYwIaa0ix9wBUPGPHtiKeqOMbDm+9VMMnpHygqnn4y02sCI5 xOaGK/RLVE3CdL88d8h0rsS7kVG/S0IUpFkp2QH0dnBZnRog2ubjzRAbd4EJqOwGhHMgSTK75 TYg5ZasYKOOlGs15D1jPiXJ9+vKYWxuwLdSxwRxpMpYnguUvBgEwx2CKRor7dzWSevXTRfJPS FHKyICde1oM8FvfKeZU2guBt8b+vPqHu9baO/l8+5SRQ7JO1xP+A7afTxtQwJgZINkXu0Q0r1 o2AcbRyGAtAxifcY11nZQ2M7IIdImOJOOjbWa7VDAlspA6KBkt1eDWzy2uCTcw2q3Ide1Xm8b HqzNdPjeWL+gi8Efj2Vm5CIJu1nIYr7NwMEkumOcgamn/XwhuncE/g0uIe1T3VaVsGrEMdAcc 3HZx0mtLd7LmD1mVrE5L+JPapA8zLSnKU4yITYdAUu/DfRIiZYBZ1ag9dkHOo7AoKFC30axRa 6W9eiv1LkNJalxRU/GZZlfc1vSW54FLwiz7EcxPEjjuNP/KwYcBYXNVecUEG/IeTpPHgs6j+c FkWZ75QduZlmR11g2nJC0eeNpFHQjyWWz10k/TDd6sEbGLzCLDh0s6PRlsn3ImQZR9Fd9Ja95 HCaNfHG+hLMsmen76QtvgPsQXenA+wkzXBbz6WRG4aGbGevg/zjJKHfOwRI9ljlfju4yecObv GOj06/gXOfUaYpstF8HDBXlMbpZEEhOM0qEG+8M2DBz21/alkGQ47Fs+1RCLcdTtrMIgjZd8/ sMMwpKgHck/WWmNILjNltkOoVOUk0Iha/kTvn0bK8YkB9wLdEHhuKdb9QhdHHYi7QMXHyLDmy ojShQa8ps/DnAZuwxtPXggB8j2kuCDV9GqgrkdvaflzBuMUm7R7RgB4TLH5isGvlNAheFHaNn crsGmSx2v7mVJfeLKuTnGeQBskZ2A+iPPB4hX0IKMPHMKN5Ud5V7oSjdaDkqSOToYfX3oYMHy fbIsXaa37I8VFibD6toyVjOb4unFk45ULDHPLuZn9EYRtEiqTNgHlDH4VV1WjKoHFRpjsi04x +x1Rz5bReUWpvQcd41nYsNIzi24o5kbQPiYyIQVkzd+Cjh6m7P2Ki1dI3VfA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mchcQMOxFKqitoecuHaSnsZcn-8>
Subject: Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S vs SCE (Evolvability))
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2020 09:35:02 -0000

Hi Ingmar,

On January 3, 2020 10:10:31 AM GMT+01:00, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> 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.

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 <David.Black@dell.com>
>> Sent: den 2 januari 2020 17:26
>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Bob
>Briscoe
>> <ietf@bobbriscoe.net>; Roland Bless <roland.bless@kit.edu>
>> Cc: De Schepper, Koen (Nokia - BE/Antwerp)
><koen.de_schepper@nokia-bell-
>> labs.com>; Kyle Rose <krose@krose.org>; tsvwg@ietf.org; tsvwg-
>> chairs@ietf.org; Black, David <David.Black@dell.com>
>> 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 <ingemar.s.johansson@ericsson.com>
>> > Sent: Thursday, January 2, 2020 5:13 AM
>> > To: Black, David; Bob Briscoe; Roland Bless
>> > Cc: De Schepper, Koen (Nokia - BE/Antwerp); Kyle Rose;
>tsvwg@ietf.org;
>> > tsvwg-chairs@ietf.org; 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 https://tools.ietf.org/html/rfc4301#section-5.1.2.1  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 <David.Black@dell.com>
>> > > Sent: den 2 januari 2020 00:32
>> > > To: Bob Briscoe <ietf@bobbriscoe.net>; Roland Bless
>> > <roland.bless@kit.edu>
>> > > Cc: De Schepper, Koen (Nokia - BE/Antwerp)
><koen.de_schepper@nokia-
>> > bell-
>> > > labs.com>; Ingemar Johansson S
><ingemar.s.johansson@ericsson.com>;
>> > Kyle
>> > > Rose <krose@krose.org>; tsvwg@ietf.org; tsvwg-chairs@ietf.org;
>> > > Black,
>> > David
>> > > <David.Black@dell.com>
>> > > 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 <ietf@bobbriscoe.net>
>> > > > Sent: Tuesday, December 31, 2019 6:11 PM
>> > > > To: Roland Bless
>> > > > Cc: De Schepper, Koen (Nokia - BE/Antwerp); Ingemar Johansson
>S;
>> > > > Kyle Rose; tsvwg@ietf.org; tsvwg-chairs@ietf.org
>> > > > Subject: Re: [tsvwg] L4S vs SCE (Evolvability)
>> > > >
>> > > >
>> > > > [EXTERNAL EMAIL]
>> > > >
>> > > > 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
>> > > > >>>> <https://protect2.fireeye.com/v1/url?k=10e7b9ba-4c6d6cbf-
>> > 10e7f921
>> > > > >>>> -861010bc36ff-2b3c729b7d8a378e&q=1&e=35be9991-3367-47d3-
>> > b023-
>> > > ed85
>> > > > >>>>
>> > >
>> > 01dddd52&u=http%3A%2F%2Fbobbriscoe.net%2Fprojects%2Flatency%2Fpe
>> > 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
>> > > > >>>>
><https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#s
>> > > > >>>> 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
>> > > > Briscoehttps://protect2.fireeye.com/v1/url?k=9834ac6d-c4be7968-
>> > 9834ecf
>> > > > 6-861010bc36ff-d256b2de1d12a128&q=1&e=35be9991-3367-47d3-b023-
>> > > ed8501dd
>> > > > dd52&u=http%3A%2F%2Fbobbriscoe.net%2F

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.