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.
- [tsvwg] RFC 4301 on ECN codepoints (was RE: L4S v… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Black, David
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Jonathan Morton
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Sebastian Moeller
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Sebastian Moeller
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Jonathan Morton
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Sebastian Moeller
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Bob Briscoe
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Sebastian Moeller
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… alex.burr@ealdwulf.org.uk
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Sebastian Moeller
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Ingemar Johansson S
- Re: [tsvwg] RFC 4301 on ECN codepoints (was RE: L… Sebastian Moeller