Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Sebastian Moeller <moeller0@gmx.de> Wed, 17 July 2019 22:40 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 C9E74120044 for <tsvwg@ietfa.amsl.com>; Wed, 17 Jul 2019 15:40:40 -0700 (PDT)
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 0AaJx0m7oIZZ for <tsvwg@ietfa.amsl.com>; Wed, 17 Jul 2019 15:40:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 204E71200F9 for <tsvwg@ietf.org>; Wed, 17 Jul 2019 15:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563403225; bh=cKvPEH44w5kqd7aB4Xiia8/m7d0JkPUNQJe4u8axfGY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=h/MgQeC2OAL/UUHyT7b0k92wnENPAsyB9g7ncuG7/pfF5rjPGwGqdfzFuQgyTODFZ /yQn/Ml2OfpdE9/quCesRIS3PMrijX5UvhXHIKPEKfwCiq8ZDyl58EaLgxXRch9tzi EEEi4ynBbmHRtMzFU/Sd9rCcs6uG2tvkL+ohf0rk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.190.246.243]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcnRD-1iCBKw32FL-00k8Nf; Thu, 18 Jul 2019 00:40:25 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <AM4PR07MB34592A10E2625C2C32B9893EB9F00@AM4PR07MB3459.eurprd07.prod.outlook.com>
Date: Thu, 18 Jul 2019 00:40:22 +0200
Cc: "Holland, Jake" <jholland@akamai.com>, Jonathan Morton <chromatix99@gmail.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6F05DD3-D276-4893-9B15-F48E3018A129@gmx.de>
References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <cc446538-cf23-4fd0-12df-7839ec6c04a2@bobbriscoe.net> <CAH8sseSPz3FoLWZNPEJcwb4xQNYk_FXb8VS5ec9oYwocHAHCBg@mail.gmail.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <D13294C4-105C-4F58-A762-6911A21A18C6@akamai.com> <CAH8sseSQaCbknok--hf=DgwzCs3OnnkKjPy5bdLgnzjq7-+c_w@mail.gmail.com> <ce4b1e2d-3bc8-265c-6bcd-5a26b4dd89e9@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <AM4PR07MB3459B1173917DAFBCEB25511B9FA0@AM4PR07MB3459.eurprd07.prod.outlook.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <AM4PR07MB345956F52D92759F24FFAA13B9F50@AM4PR07MB3459.eurprd07.prod.outlook.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <AM4PR07MB3459B471C4D7ADAE4CF713F3B9F60@AM4PR07MB3459.eurprd07.prod.outlook.com> <D231681B-1E57-44E1-992A-E8CC423926B6@akamai.com> <AM4PR07MB34592A10E2625C2C32B9893EB9F00@AM4PR07MB3459.eurprd07.prod.outlook.com>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:5vsz48WyuE5Bxqn/q0eWWx6UOY03a2F8CMP+jFb6euO6KZ0NJ+a a/0LwocQEeoPda+nH7D+uL4h0f+8l44LM8joIwLmIyRxq+f7vipLgU1S5scxiuRbnM/Fm6h b//yNE4pLOvM1PCBKl3wiZXU1Z2jNE7NH5MgRJkjC07pmQ0Vj5WiGiNTDBUpJebgdS3H0I9 EF5MNkAjvMSTskhupZq6w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2lLh0MdSyKo=:nLntIou0dV4eoybXFSiw+k 6T+L/Tnww6+D8SO69pyQV7JuIELju+METTOVPiwi3RcWVHLJeeXqTf6dp6Vfq0bNnD5rnYa1d GIkmyUToJ3XNog17i5UazCB05p3YpbZU7t1r1p5WCOru0TSr+OyjCdNVd0MjQOW7F7jsdRc63 VZKh9QSB/kXBftZQP74i322KRl+EUEbNjvZGcbJe/6gg5vsqo/vwsM1C4daruENMT9UG3m27v Z4MfUnm7fzj8MHi6IkrqMGNm//K5bAG9gs58AKY5YgOKoB0aWPw7LF0CJfaagvu6sbxCvHeGs 9lrBfP7K1z5dCoM7B39Bwup0kY1RMBvdi+UdqNcb5uaF8v5pGKnuYs7GQ9HCv39Vzp8UrMMSP bsuCgL4gqekZYh7tKBgEyHMIC1jplp52vyuyDgaT67sBQU/QvC/72ZFuS0NW12LoflswEcomb 2wvqrHZhcsO/aTMoSjMqIiIht2/JRV1QLZWDnIIZ5thUCrXGfbeCY9glAOxSK+JgGdBITQOs0 p1Y/UTwK1S0lJ8wJZ2sZ/wa/JnU5jty0iRCvFF6jGyn5VFnkqlefsrYkw69OyGQa7ziFeuIuJ 77VypQN/Y7kJnt9HLNkgwl5KTkMdJeHk6tbJ7n7ERBAu4lkiLWYITSuGDg81SSxmpvARcr0MK 5iTkmhBEjDrDW0htb3DXx6m8cFtYHNyLnzefTTDQlidF3vmXQ9F9Tns018KENXzc5SY76im9b wAhdsMC+XMQIFZ5GMrHZLfwmQ89/58hO44TZBFwc2sfg4uIvN3+Dba5T8kG0gqBTjRmFKSVDG 2kFD+OuWwdKZFwDdGTwk00RUz4jNKUW3238d1b7K+5BgOoIrg436+vO3Tr1ziY/Zh/MKBF085 ZxqAUT5L0MtkqJg6wKR0SblR3LGo4w53IuSvlX0nuWw5Ft02B2f55j8V2ftrqTmw2kPZOnYaW YxlCqxKx9zscwyZYDew9bi/dAsWuWZ1L+3fqqdtYYmchLPJ2ydYwo17JrOyLrpC26KkDcKWOJ PsFWUdCtaf9wafpgKQSqDAEJ1E4GMEKsnx/6XOdAckNPL3xX5XF2rMguqSgAqa7b99xzZBAoM uC0ljiXwDfP1IA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/x_pKN6KBDBAOodVfa4GdA2g8ZMw>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
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: Wed, 17 Jul 2019 22:40:41 -0000

Dear Koen,


> On Jul 10, 2019, at 11:00, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:
[...]
>>> Are you saying that even if a scalable FQ can be implemented in high-volume aggregated links at the same cost and difficulty as dualq, there's a reason not to use FQ?
> 
> FQ for "per-user" isolation in access equipment has clearly an extra cost, not? If we need to implement FQ "per-flow" on top, we need 2 levels of FQ (per-user and per-user-flow, so from thousands to millions of queues). Also, I haven’t seen DC switches coming with an FQ AQM...

	I believe there is work available demonstrating that a) millions of concurrently active flows might be overly pessimistic (even for peering routers) and b) IMHO it is far from settled that these bid transit/peering routers will employ any of the the schemes we are cooking up here. For b) I argue that both L4S "linear" CE-marking and SCE linear ECT(1) marking will give a clear signal of overload that an big ISP might not want to explicitly tell its customers...

> 
>>> Is there a use case where it's necessary to avoid strict isolation if strict isolation can be accomplished as cheaply?
> 
> Even if as cheaply, as long as there is no reliable flow identification, it clearly has side effects. Many homeworkers are using a VPN tunnel, which is only one flow encapsulating maybe dozens.

	Fair enough, but why do you see a problem of treating this multiplexed flow as different from any other flow, after all it was the end-points conscious decision to masquerade as a single flow so why assume special treatment; it is not that intermediate hops have any insight into the multiplexing, so why expect them to cater for this?

> Drop and ECN (if implemented correctly) are tunnel agnostic.

	Exactly, and that is true for each identified flow as well, so fq does not diminish this, but rather builds on top of it.


> Also how flows are identified might evolve (new transport protocols, encapsulations, ...?).

	You are jesting surely, new protocols? We are in this kefuffle, because you claim that a new protocol to signal linear CE-marking response to be made of unobtaininum so you want to abuse an underused EVN code point as a classifier. If new protocols are an option, just bite the bullet and give tcp-reno a new protocol number and use this for your L4S classifier; problem solved in a nice and clean fashion.

> Also if strict flow isolation could be done correctly, it has additional issues related to missed scheduling opportunities,

	Please elaborate, how an intermediate hop would know about the desires of the endpoints here. As far as I can tell such hops have their own ideas about optimal scheduling that they will enforce independent of the what the endpoints deem optimal (by ncessity as most endpoints will desire highest priority for their packets).

[...]

>>> Anyway, to me this discussion is about the tradeoffs between the 2 proposals.  It seems to me SCE has some safety advantages that should not be thrown away lightly, 
> 
> I appreciate the efforts of trying to improve L4S, but nobody working on L4S for years now see a way that SCE can work on a non-FQ system.

	That is a rather peculiar argument, especially given that both you and Bob, major forces in the L4S approach, seemm to have philosophical issues with fq?

> For me (and I think many others) it is a no-go to only support FQ. Unfortunately we only have half a bit free, 

	??? Again you elaborately state the options in the L4S RFC and just converge on the one which is most convenient, but also not the best match for your requirements.

> and we need to choose how to use it. Would you choose for the existing ECN switches that cannot be upgraded (are there any?) or for all future non-FQ systems.
> 
>>> so if the performance can be made equivalent, it would be good to know about it before committing the codepoint.
> 
> The performance in FQ is clearly equivalent, but for a common-Q behavior, only L4S can work.
> As far as I understood the SCE-LFQ proposal is actually a slower FQ implementation (an FQ in DualQ disguise 😉), so I think not really a better alternative than pure FQ. Also its single AQM on the bulk queue will undo any isolation, as a coupled AQM is stronger than any scheduler, including FQ.

	But how would the bulk queue actually care, being dedicated to bulk flows? This basically just uses a single codel instance for all flows in the bulk queue, exactly the situation codel was designed for, if I recall correctly. Sure this will run into problems with unrepsonsive flows, but not any more than DualQ with or without  queue protection (you can steer misbehaving flows into the the "classic" queue, but this will just change which flows will suffer most of the collateral damage of that unresponsive flow, IMHO).


Best Regards
	Sebastian Moeller