Re: [tsvwg] L4S vs SCE

Roland Bless <roland.bless@kit.edu> Fri, 22 November 2019 02:32 UTC

Return-Path: <roland.bless@kit.edu>
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 73FB5120836; Thu, 21 Nov 2019 18:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ghIaTqeQEXVL; Thu, 21 Nov 2019 18:32:27 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 65EF012012A; Thu, 21 Nov 2019 18:32:27 -0800 (PST)
Received: from [2a00:1398:2:4006:ad44:c71d:77f7:4385] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1iXykA-0006Vs-Sr; Fri, 22 Nov 2019 03:32:22 +0100
Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id BDCC0420097; Fri, 22 Nov 2019 03:32:20 +0100 (CET)
To: Bob Briscoe <ietf@bobbriscoe.net>
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@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <1ed5e25f-d105-8866-99fb-5fce181bbbbe@kit.edu> <5d36ceb0-d03f-6fee-c7ea-e803fbfa606f@bobbriscoe.net>
From: Roland Bless <roland.bless@kit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=roland.bless@kit.edu; 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: <151fd71f-bdc5-a140-104f-e924a2b7dc16@kit.edu>
Date: Fri, 22 Nov 2019 10:32:18 +0800
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
In-Reply-To: <5d36ceb0-d03f-6fee-c7ea-e803fbfa606f@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1574389942.945056013
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WpYiVI2WHK80ZtZP0EFGo2rS8Jc>
Subject: Re: [tsvwg] L4S vs SCE
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, 22 Nov 2019 02:32:30 -0000

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...
>>>>
> 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.
The SCE markings can be used independently whether you have multiple
queues or just a single queue. If one leaves the coupling aside the
algorithm for marking will probably not differ so much from what is
proposed in L4S.

>>> 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.

>>> other than massively constraining future evolution of CCs, especially
>>> real-time ones? See Per-Flow Scheduling and the End-to-End Argument
>>> <http://bobbriscoe.net/projects/latency/per-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?

>>   > The key thing here is the wording of the Prague requirements
>>> <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#section-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.

> 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.

Roland