Re: [tsvwg] L4S vs SCE

Sebastian Moeller <moeller0@gmx.de> Thu, 21 November 2019 07:33 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 1BA45120980; Wed, 20 Nov 2019 23:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 x1tfxupm57pr; Wed, 20 Nov 2019 23:33:03 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2843B12097B; Wed, 20 Nov 2019 23:33:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574321571; bh=F/zVH2bER2Wu4tfiAtjD38LSfC0bkZRKUpMBrJpIDCU=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=aUE7H6O6DORSXG9gwuFl/73mky6U8D4w9stDwr+rZ7HTpk1A7tBoAjIwlSd8AyafO sxq2a2U7IdYq+mZwE35Kqyaf1BGasFg+yNX8VuxkDHEHzTqgxakH3bVGpccWFxiRad XX2ILc4QGwxZxZzXxuCWFLylxqmj5tmHfBlFIS2A=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.133.114.36] ([80.187.114.53]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MacOW-1i0H5F1Gos-00cCal; Thu, 21 Nov 2019 08:32:51 +0100
Date: Thu, 21 Nov 2019 08:32:44 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <716AA405-6C3D-4AF5-9C7A-FEEC8A988CF4@cablelabs.com>
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> <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net> <357abfd2-2d93-b4cf-355a-71a2def32b15@gmx.at> <E175102C-CD01-40B3-9807-3DE0C2DB8277@heistp.net> <9d6c1ce4-d192-d016-8418-c26a09e25517@gmx.at> <716AA405-6C3D-4AF5-9C7A-FEEC8A988CF4@cablelabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: tsvwg@ietf.org, Greg White <g.white@CableLabs.com>, "Scheffenegger, Richard" <rs.ietf@gmx.at>, Pete Heist <pete@heistp.net>
CC: Roland Bless <roland.bless@kit.edu>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <6803E804-6F4F-4811-97CE-3DA058896AE0@gmx.de>
X-Provags-ID: V03:K1:cs1MPRhcurjfxmBxUJ1VW0pfYqNRJ7yIcwIZrY887fgP9Fvzeym mSFw3l2Yn7lAaH+M+l+2dYXd7yWdUYwc9ehE+WlT4D2VdjcgBFdq8etlidrDFLZK8PYCMz/ VIgnMqceBbGxnqno3e3vTbtRGlJ6gFNtf0soQpldtdxVdA4FJE5Aus8KaGUWB8Fpm04Trts m5cWF7xjDnl1U/POpz1Jg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mC5F4UxhHJk=:MxIrP+zKJNowUyO+iPbPeB o00KVsIUFlPXWLirJhu97lHVzWMz/xY/5rhb3Y4zXs/Bux1enTPfEvWxR/IOKzy0wScmnBDAu Zj+uazfOsTQyf94D1RGU1D2rXAevuZ0rEQ5tYUC4pPNLna9nX5503qVnrdr7Nc4/bhlWopzIE KL2brT9TjYiFr8avUDo0i/cL5vJaHpxJX6ZUyl94tZq9q4x0nciyOeEIRBfTFCGfb75JuL5go SSSKoIuYunXeVENvgqze8pcTvwMtn7ebVMqB2huNNfR22E71MNJ9IEPoKxesKcAq2jmjl/46e 3F3I4a5N4I1Mmtrb2RGQr3VkW8XE5/tFuwOuNF16DLNoSArYpRyT3m7LH/IdRWbpo2nrnA6X1 wJwtRXZQ0HoCrexkW49oLksmG7jmZXA8x7Xhghdd58kck8S9o1xkyQ33bCJ9WDOfBrtYOvHvt 5Oh1gMHgy8msBbiagSTy6PidTED7qlKEf7I9+WZcgbhmiFpiQCNLxduV0lfvw+TjyIFH3Rdl9 rUGH+1mExdVGSUadqK1naUADyInXkM3PHdcZwMWHXDIb7eoN91JbzwChZxiY3TDgNUWijGqdn Q+YhtQUVdzf4t55Nh1EeiGHELmSxSFkx9unQMqYetiVZRggbY4XSPZc3kHBIFi9v6SE/XkzxZ I/vC+ItQAsrxvhawW3lKdNLhBDbhCLFjCA/xfwSTGNF/XyjtEWyQz4fALd7p8o+0aWRBSJFrM GFt7Be4+0UPCQgMGsk/7LxL9kXxGjsAcvx8fhsGKQG/dukKRhU7P4OlZDt5vCr4qZhaJkId0V /I6mVNMmGthLzbDiZdLBxr0GTOpKTyR937f1CfJlFQxIzMmMqR9hBTeHAYv8zauNDNl+5HFD8 FOwm0WRIHe+evf1X4B7bnYsWsMzypyJaLQ1dX/abKpylAntTp9+ihABNr72j70hgHJXxmLhAR M6UuYSpHL9VKbHl/TtAwbbDGceNOUUDiPdxGOLwfURiI18PaDFO7afS4Yrnsxc6HhDxo537o1 13bWq3gQ48SvtZc99v5a7mOx5GXvB1aHO2v7CjYy/TMBZeAtWIs6kl7BFV9hFkQmnuiCLxt3n yxdk+wyRtHkBinCDg0FkxgkBSvOb0hi3Fs1HdUrnEIACW0dGOudCLhVEaAROdv8THrFpKw9b2 LzJwB45sMbDj2NLXvc8lZQBoLjPB7rBu0ZcFf4gRRyPQKdcpG+wZmjJVG5t0wmcV2ddknADDc krcAKkRfwMuRRb/iNSJyHdFfkTdXG9inCEO5auRV+3YYQ6bE4LIZ1Mm/x1Uc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_GPR-QqNjfWj7ipuQhg_3vgm9e4>
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: Thu, 21 Nov 2019 07:33:06 -0000

Hi Greg,

More below.

On November 21, 2019 12:14:11 AM GMT+01:00, Greg White <g.white@CableLabs.com> wrote:
>It seems that a component of this debate revolves around whether FQ is
>a good solution or not

         [SM] The only party that keeps bringing up fq consistently seems to be the L4S proponents. In the context of the dual queue coupled AQM this is just a sreawman argument IMHO that distracts from the core of the issue. Tht being that implicitly everyone reading the L4S drafts will expect equitable sharing between the two traffic classes L4S divides the world into. In a sense a two class fair sharing system is one solution for the issue, as would be a strict priority scheduler that limits L4S traffic to 50% of the bandwidth (look, no fq). I even had a look at dualq's pseudocode and identified two toggles that most likely would allow to improve the worst case sharing behavior, potentially into a range that seems acceptable at least for the experiential roll-out. Not even exploring these options does not strike me as productive.


>
>In my view, FQ provides a very nice benefit (flow isolation) which, if
>it were to be implemented in *every* bottleneck in the Internet, would
>allow for unfettered innovation around congestion control.  

         [SM] I guess we agree that the most likely bottleneck for most users, is going to be the internet access link, so fixing those for users interested in low latency seems to be a more modest, but reachable goal.


 It also
>enforces fairness, which could be a blessing, or it could be a "don’t
>care" or it could be a curse, depending on the situation (and it has
>been argued that it weakens the end-to-end principle).  


         [SM] Well to recap the L4S approach of anything goes suffers from the issue that without an oracle scheduler divining the relative importance of active flows will not do the optimal thing either, but at the cost of allowing way more "catastrophic" sharing behavior, as evidenced in the results of sharing over DualQ at short RTTs. And to add insult to injury, opening multiple parallel flows to "trick" an fq aqm will also glresult in a higher bandwidth share in L4S, the only difference being that L4S did not try to make any guarantees in the first place....

Finally, it
>introduces complexity concerns that likely prevent it from actually
>being implemented in *every* bottleneck in the Internet.

[SM] How about we start with good enough and aim for the most relevant bottlenecks first instead of constructing an argument of the kind that shows that perfection seems unachievable and hence rejects the idea of even trying.


>
>The question around the SCE signal vs the L4S signal, in my view, is
>mainly around the question:  Does the IETF want to select a signal that
>forces all bottlenecks to implement FQ (if they want to participate in
>high-fidelity congestion signaling), or does it want to select a signal
>that allows the bottleneck implementer to choose between TWO options
>(FQ or DualQ).   

        [SM] It seems clear that the actual marking strategy of SCE and L4S are similar enough, that a unified method should exist to satisfy both camps, the goal in the end is a 1/p Control Loop. The issue about mutual exclusiveness of the two solutions really only comes from the side-effects of trying to change the semantics of the ECN codepoints', either subtly (SCE) or massively (L4S).
IMHO it seems worth revisiting the ECT(1) as classifier decision, but I fear that I do not represent the majority view in this.



>
>I assume that FQ will nearly always give better per-flow-fairness than
>DualQ (just like it has always done better in that regard as compared
>to single queue systems.

         [SM] I agree, based on actually testing vodel versus fq_codel and cake on my Home-Link. I repeat though, that that issue really only isxrelevant for the sharing in each of L4S two queues. The sharing between these queues should be equitable independent on the guarantees inside each queue. IMHO that inter-queue sharing behavior is the sticking point.

With L4S, anyone can use FQ to get
>near-perfect fairness if that is what they think is most important (and
>they can participate in high-fidelity congestion signaling).  

[SM] Under the assumption that person is in control of the actual bottleneck, sure, but e.g. DOCSIS seems to plan to roll out L4S on the CMTS and I severely doubt all ISPs will give the user control over it's activation...


So, the
>argument that L4S is broken because DualQ doesn't provide the same
>precise fairness as FQ is not a convincing one.  

         [SM] I agree, the reason why it is broken is not that it is not FQ, but that it does not achieve the engineering goal of strictly separating the two traffic types. And in all fairness the "coupled" in dual queue coupled AQM and the L4S' team philosophical objections against fairness indicate to me that we are talking about a conscious design decision and notvsimplyvtge inability to come up with a strict and equitable sharing system.


>
>Where I think SCE fails is that it is not available to any link that
>doesn't implement FQ, whether that is by choice or by necessity.  

         [SM] SCE is a marking strategy pure and simple. I see no insurmountable obstacle in combining the backward compatible SCE marking strategy with a better classifier to give L4S queueing to selected traffic.


I
>don't believe that the IETF should use the last IP codepoint for a
>signaling mechanism that can *only* work in FQ.

        [SM] Again I agree, but luckily that is simply not true, tack on a better identifier for L4S style senders and you are off to the races....

Sebastian


P.S.: If it appears that I am repeating my arguments than I admit that to be true, but so are Greg's.



>
>-Greg
>
>
>
>On 11/21/19, 5:36 AM, "tsvwg on behalf of Scheffenegger, Richard"
><tsvwg-bounces@ietf.org on behalf of rs.ietf@gmx.at> wrote:
>
>    
>    
>    Am 20.11.2019 um 21:53 schrieb Pete Heist:
>    >
>>> On Nov 21, 2019, at 4:28 AM, Scheffenegger, Richard <rs.ietf@gmx.at>
>wrote:
>    >>
>    >> Hi Pete,
>    >>
>    >> Am 20.11.2019 um 21:20 schrieb Pete Heist:
>>>> allowing alternatives to be explored without a risk-benefit
>analysis.
>    >>
>    >> A basic risk-benefit analysis should always be done. Even benign
>    >> optimizations can change the dynamics of a CC.
>    >
>> Good point, but the additional risks that a second congestion signal
>adds should only be reduced performance that doesn’t impact other
>flows.
>    >
>    > :)
>    >
>    
>  There have been proposals over the years, to utilize the absence of a
>   congestion signal as another signal, to speed up with session-start.
>    
>I know that Bob has also been looking into this as a thought, to use
>the
> absence (or lower than expected steady-state) feedback of a low-impact
>  congestion signal as a new mechanism to speed up slow-start or adjust
>maximum burst sizes. and there are similar approaches in the literature
>    (but most were never brought in front of the IETF).
>    
>The addition of a secondary congestion signal also introduces the
>signal
>    "absence of secondary congestion signal" (provided you can affirm
>    yourself, that this secondary mechanism is actually working on the
>   bottleneck). Misuse of such a "1-x" signal could impact other flows.
>    
>But don't get me wrong - I am very much in favor to a new signal; in my
>    opinion, there are valid point in favor and against both of the two
>    current proposals, which can not be easily combined.
>    
> However, perhaps a more in-depth analysis would show, that linking SCE
>    and L4S queues behind each other (in any order, and any number of
>    queues, only some of which become the bottleneck at a time), is not
>catastrophically problematic. I haven't run any numbers on this though.
>    
>    
> From a 20km view, the marking strategies between both - broken down on
>an individual flow - seem to be fairly similar. Both appear to be using
>  instantaneous queue depth (sojorn time) without any smoothing of that
>  signal at the bottleneck. One stated of with a step function profile,
>    while the other with a slope. Form my understanding, both marking
>    strategies have found that some aspects of the other are beneficial
>    (deadband when the queue is fairly empty, and a more or less steep
> slope, ramping up to 1 well ahead of a full Q). One crucial difference
> is that one does lend itself to easily cope with 100G+ link speeds and
>very tight time and memory budget on silicon, while the other one lends
>    itself ideally more towards the edge of the current internet.
>    
> The main contention - from my observation - is the question if a DualQ
>  can be implemented without infringing certain IPR, and if it actually
>    meets the cited design goals. Or if classification and bandwidth
> allocation need to be an orthogonal means to prevent starvation of one
>or the other type of flow. Similar questions remain on the other side -
>is it possible to build an AQM that can be put on 200G / 400G switching
>chipsets and maintain the properties of (FQ_)Cake - especially when the
>    Q never holds more than one packet of a flow at any time.
>    
>The L4 feedback signal should be the least concern when designing a new
>CC mechanism (and AccECN would in principle support all the use cases
>of
>SCE - not necessarily particularly efficient per the latest draft where
>the TCP options need to be used; but we have had designs over the years
>   to match up with SCE needs much better, and could still tweak things
>there. Remember that when we started, we did think that ECT1 may become
>an additional congestion signal in its own right - but that design fell
>through in the WG. But there is nothing stopping the WG to revisit this
>    decision now, in light of new data.
>    
>  Remains the CC reaction, where I believe the base CC mechanism in L4S
> has had more in-depth reviews (dctcp) than SCE over the last ~9 years.
>    
>    Best regards,
>        Richard
>    
>