Re: [tsvwg] L4S Issue #16 Discussion Paper: Fall-back on Classic ECN AQM

Sebastian Moeller <moeller0@gmx.de> Sun, 10 November 2019 14:26 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 F15DF1200B6; Sun, 10 Nov 2019 06:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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, URIBL_BLOCKED=0.001] autolearn=ham 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 LhNbug5L97In; Sun, 10 Nov 2019 06:26:44 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 921AE12004A; Sun, 10 Nov 2019 06:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573395957; bh=Mn7ie145d16Q8xEWBOkPL9bIHkiRYtGVsLlBaaqHlkk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:References:To; b=RK2vtE/MWJlbVx6UsSlAdJbEWifJzeiXjBiJDfl9qjjHJVG/l+29rVQQcpo5v3Gyc CdGwf8pKII99dqRQ0Ag/+IuyT28NjgUwMEVs2s/cgwTe50lDt1nHlug5xXmeq+iuec RExSIUXkjhfry1mj3/9dj6isAYGUmbLDecrWOpS8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.3.68.102]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MxUrx-1hffHY2MMz-00xqxH; Sun, 10 Nov 2019 15:25:57 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <b9f4d7e8-a5a4-84ae-dd75-35e3a73b4fa5@bobbriscoe.net>
Date: Sun, 10 Nov 2019 15:25:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4CB17E9-3845-41E7-9A74-47247EE67C6A@gmx.de>
References: <b9f4d7e8-a5a4-84ae-dd75-35e3a73b4fa5@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:BCIgumjW74V2CXn223V57GW+rJv6pm5bLMjH/J5KbZ7ii2PFlsm 1Vj9roHg5f9DpCabqGfoyICR6tqMCK1BbtxWHrZbKPQqaC/gnc5UuXfIXjun2TXTOfxoqyf jPTsMR4uA5QRXGdsP/KXqK/eDX5kP5EQc9iONBrsvsgKMr/D07oAZhtH8CCwNw5B4yPzmQ1 oOLlS5bQTh4EGFuG8HYKA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:6ZwF6li4FZM=:c1sGdx6QCoXkbLOkui50+c cGHot7eaoLdjhDwTr7AqQGSAJNNResP36unTwxa8W7WFghy34TpoB4CrCcnNvo2SbdMwUtEoj /18KSBQGqZ2Hn+tIJX27f4U9ifvB15JooyThSQOgSGQuYBdysQd93MUphNm8BcYp6xVYS6ztF 5gDw4SLq2PKoUy+Bls+l+5AoLDlhr74LA2ybXtrapsffC/AsfC3kptPPP64DbK4VNpEj5ufmI RH8NS2vQvKqXT9V06B/H8FUl0riVEvUfOnr1MrH3sws04ytsYCAgO660KOybysTv0jwYkqlmM QWNstuR65MXcqGglHOKWPgZG+3kRA9IiWC4iMkDUrvI8XSh0kcTchzFqoYgxmE/WH0YLWkI+c t7XCBSbGwq5wF1O5r5CfXBPtR8Fk2pfwM6yzlKXVxGP3IArKkTKD2URyjHeEFnFfT38QL/wtJ DRdIphiN6x8iQ2MrhPhGjA02CLy7Oq4pI33tS7bwel371JzuuunLBH9QLpA1DJ0fWgKYWirKT BxHv9vZ+hFXwN9gY/zp9HVZiX0ewrhOqAC9PPPR1jWNx85NtlN/lvsZ3eNbfbA8skyYF+49TK kO2ISb6Wy+MyoS6gr8Nrq3rNSx0/o8HcK29E4Na7BiLjMmVY3IFAbtNZ3fHoKS4D6PQIzIWn3 nbGnfjIaujJpTwV0fv91PhEpXrPHJx1+5vDtkx053JhuM6uVlfwZclpaNeMOGGnpn4mZKcl2S Op+ZqgzIb8MuZqnlGtSP+KzN507ArKs6P9Sa230dzd9cHDNUrX2XmC8ciHVJ5NtMdIuL9I6e5 bj+ftXSYYhUD1Z8ixPhbE1StngBLtByuV/nc6R66ID670sMZMzgGdbEjGCQ8jcnwnW2/nN40e kS0xDhy4tf+QHaT70C4nz2qV8r4uI+DhnLmnlQIT4j+yXcZH0BLLj5zydYLpCng4mnGP+/Oz2 iOrTmJZm7SQ8C2MlCT2HdPiNyVkv7ZfgVgiwuSWrRmvvSG6yLUoIvmRZRzbnQGzR/nE0ZwnuH s5O1VV0L5gD5m64KmrYKlg0ieH7rdREdZeTB36fySgYABj/MNlCe3HL+wejWYjS6udSp1ngc5 DIuoHeW11CzxWp+y9N131H9eFBffZjSQoY1mWZR9G/IWrtrxKkkz5+J6aAs3pO2lqGL+X/6hL Cb0qIDQO/ou4LUexecY8otzD3Ifqsk4Zz2/Pn6JpMU2dofH96j42C+pDdpOzv0QVuPiDLXsg4 XC/0m8MsQHuFIZ9zcbI7GjOgPJXTz+MW1VkSzUgNQKlER/Wm45boMyB+WtkU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qlZ-4c-A9ldErMMzUpJqDVv3UxM>
X-Mailman-Approved-At: Sun, 10 Nov 2019 17:15:50 -0800
Subject: Re: [tsvwg] L4S Issue #16 Discussion Paper: Fall-back on Classic ECN AQM
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: Sun, 10 Nov 2019 14:26:47 -0000

Hi Bob,


firstly, thanks for finally starting on tackling this issue of teaching L4S-style senders to peacefully coexist with AQMs employing RFC3168 ECN marking.


Secondly, I reserve judgment until you post real data under adversarial to worst-case conditions, the core of issue #16 is not the lack of ideas, but the lack of a real-world implementation that has survived and done the right thing in a number of tests.


Thirdly, I really wonder wether the incentives are properly aligned on this. I would very much prefer if you, if only for the sake of developing your detector, switch from assuming L4S until RFC3168 is proven to assume RFC3168 and switch to L4S-style once enough evidence was accumulated to justify this step (from then on you reverse again and try to collect evidence for RFC3168 for a potential switch back).  As it stands you seem to aim for limiting false positive RFC3168 judgements, while on the principle of "first, do no harm" you should minimize false negatives as well. 


A few more detailed comments:

"Any transition should be suppressed for a number of RTTs after the onset of CE marking, both to allow the connection to stabilize and because aggressive competition for bandwidth is not a great concern with short flows."

There is an obvious conflict here, to get a reliable estimate of whether a path seems limited by a RFC3168-compliant AQM or by a L4S style you require a fair number of data samples, but at the same time you also want to quickly correct ant AQM-type misjudgments to avoid the interference between the ECN response the AQM expects and the response the sender exhibits, to minimize the temporal effect on the AQMs queue. 

"Therefore, relative to overall convergence time, it will be insignificant if a flow takes a couple of dozen rounds to work out whether it should be converging to an L4S or to a classic target."

I could live with that IF all flows start RFC3168-compliant, then they can take as long as they want to switch to L4S style, in the reverse direction we are discussing here however that seems to be sub-optimal. As it stands this, you seem to give yourself leeway to mis classify a RFC3168-limited path for multiple seconds under congestion, this seems quite generous to L4S, too generous for my taste. Given that reasonably low latency networking is already possible with the existing internet and normal traffic I see very little slack to cut for L4S mis classifications (especially since all of this is rooted in L4S re-defining the meaning of CE, IMHO you can do this, but then you need to "eat" all the cost incurred by that decision).


"In that case, a large classic response to a CE-mark could under-utilize the link until cwnd returned. So a small scalable response would be more appropriate."

That seems misguided, unless TCP Prague operates on a L4S-limited path it should behave like a normal TCP flow, and that pretty much implies a multiplicative decrease on CE mark or drop.
I get it you want any advantage for L4S-style flows you can get, but honestly this looks like trying too hard to me.



There is quite some slack in this heuristic and I think this comes from a notion that the goal of that heuristic is to post-hoc "reluctantly" change from L4S-ECN response to RFC3168-ECN response. Personally I would be happier to see the test logic reversed, start in RFC3168-compliant mode and only enable the L4S-ECN response after an RFC3168-ECN has beed ruled out with sufficient certainty. Remember, you argue that dctcp style ECN response is too aggressive to be inflicted onto the internet without proper isolation and now you seem to argue that strict isolation can be replaced by a much looser heuristic.


Best Regards
	Sebastian



> On Nov 5, 2019, at 10:48, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> tsvwg, iccrg and tcpm folks,
> 
> I've published a discussion paper giving rationale and pseudocode for an algorithm we are implementing and evaluating in TCP Prague.
>     TCP Prague Fall-back on Detection of a Classic ECN AQM
> 
> I'd appreciate any immediate concerns with whether it looks feasible and/or any scenarios where you think it's likely not to work well.
> 
> 
> There's three main components: passive, active and base RTT adjustment. 
> Only the first may be necessary, or possibly only the second.
> 
> We'll publish evaluation results as soon as we have them.
> 
> Apologies for not posting as an Internet Draft, but 
> a) I find LaTeX quicker and more readable esp. for plots; 
> b) many patent offices consider arXiv (but not Internet Drafts) as strong as journal publication
> 
> For the avoidance of doubt, I have filed no IPR on this.
> 
> Cheers
> 
> 
> 
> Bob
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/