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

Jonathan Morton <chromatix99@gmail.com> Fri, 05 July 2019 08:26 UTC

Return-Path: <chromatix99@gmail.com>
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 A4AFF1200B2 for <tsvwg@ietfa.amsl.com>; Fri, 5 Jul 2019 01:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 YGnFnn0s8TGO for <tsvwg@ietfa.amsl.com>; Fri, 5 Jul 2019 01:26:16 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 6A416120128 for <tsvwg@ietf.org>; Fri, 5 Jul 2019 01:26:13 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id c19so144347lfm.10 for <tsvwg@ietf.org>; Fri, 05 Jul 2019 01:26:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f1b6UH4k/lRaPGLneO1rdRjIBYtnhRg7QvGsWRydu9w=; b=Fw8HIKW+iuWpUINuoxf+XvcBv7bBq5E0IPbWieKbYkXar+Nn07BvNvV6ChzF3o98hM UXAvCfIwuBRlNFeEKTBOp0JwRRGpH/TClCI1X4CiuNyTEFO+sJ7x1TnkpFhGzlPkJtHj rjpqghGALJTyFUge7jWdlHaZyWlcSdqIvOkvi6FuKQho3fr9a7fExkOs0xK+7MazBCyv hGMiY4tPqpE1S2jZcu9pyme+l+rXCbyBFnagG6Ct+g15L5G+JvwzuWUDtpo+ZQ1jCIMF Z7LlCasJXREe1azfygk78Ezq+IkXfKy+eBEjDRCe8LqyGDpDrPXF6j2i83klQ1LHfkGn IkpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f1b6UH4k/lRaPGLneO1rdRjIBYtnhRg7QvGsWRydu9w=; b=Fx+4dQ+LcsllMjdskTQ6PytbQccAovyfcOYACygLkRbeQ0fh/Oan4E4YNgBSUqrD6t ISm3l4xbxecAW2qmtEREsS+xHEPFTi8QgmwSVvXmq7mXzt9WJzCLCOZUg3sJeWwZCh6F bE04xBxNCJ4EbiiI9JRINc66I5OgRS6MKJe0Gl43NlT24ZnQvznHPqhMQrnVMbP3j6rB nnI30r4Dc5PTybXYcmz6rM4o5orE0bgSfod4H0xeFV6LEuPKsIhheG4gKHvQc9gUjQUE ahI2rnvsfnfZwTPh9d6fUFPPjCsCTJuN/OwGgaGSQj9+VXIM1Gij3rJg9hYZmIsNSOQ/ 5uoA==
X-Gm-Message-State: APjAAAXKWejFe9IXen+ZMyxhuNXsTChUusokAow033Rx4W0EngpjuDri AKTEe9fE1aorzx3CRF1wt+k=
X-Google-Smtp-Source: APXvYqxfOOb/FWMjLisGFf45xJ+etf4LUdBowGOpZ/cZQsFJHfMXWMFZxoU013AeE+J7eljGJ+Nl8g==
X-Received: by 2002:a19:c514:: with SMTP id w20mr639502lfe.182.1562315171719; Fri, 05 Jul 2019 01:26:11 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-232-91-nat-p.elisa-mobile.fi. [83.245.232.91]) by smtp.gmail.com with ESMTPSA id o8sm1636393ljh.100.2019.07.05.01.26.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 01:26:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <5c58a2d1-0dfc-e0fa-398a-9e196615f04a@bobbriscoe.net>
Date: Fri, 5 Jul 2019 11:26:09 +0300
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E15F260B-1BDA-4555-BCE8-D3FE4187025B@gmail.com>
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> <5c58a2d1-0dfc-e0fa-398a-9e196615f04a@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/wJ-X6miAJfmFhNvg8MvndTioQro>
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: Fri, 05 Jul 2019 08:26:18 -0000

> On 4 Jul, 2019, at 8:54 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:

> You are assuming that the one thing we haven't done yet (fall-back to TCP-friendly on detection of classic ECN) won't work, whereas all the problems you have not addressed yet with SCE will work.

This is whataboutism.  Please don't.

We have a complete end-to-end implementation of SCE, which not only works but is safe-by-design in today's Internet, as outlined not only in the I-Ds we submitted this week, but also below.

> I believe that using this to enable fine-grained congestion control would still rely on the semantics of the SCE style of signalling still. Correct?

Yes, although the fine detail of these semantics has changed since the first I-D in light of implementation experience.  I do suggest reading the new version.

> 	• Q1. Does SCE require per-flow scheduling?

SCE does not require per-flow scheduling.

It does work *better* with per-flow scheduling, but that's also true of most types of existing traffic.

> 		• If so, how do you expect it to be supported on L2 links, where not even the IP header is accessible, let alone L4?

While this question is moot, may I ask how you expect the ECN field to be used when the IP header is inaccessible?  I'm sure either DCTCP or SCE-like principles can be applied to an L2 flow, but it would not be through ECN per se.

> 		• If not, how does it work? 

In the first place, SCE flows work transparently with existing dumb and CE-marking infrastructure, and behave in an RFC-3168 compliant manner in that case.  So no special preparations in the network are required merely to allow SCE endpoints to be deployed safely.  We consider this one of SCE's key advantages over L4S.

We have now implemented and at least briefly tested a way to mark SCE in a single-queue bottleneck while retaining fairness versus non-SCE traffic.  It requires only an adjustment to a detail of the way SCE marking is done at that node - that is, altering the relationship between CE and SCE marking - and does not increase implementation complexity even there.  The tradeoff is that SCE's benefit is diluted because SCE flows may receive unnecessary CE marks, but it does achieve fairness (for example) between plain Reno and Reno-SCE.

You might wish to read the submitted draft outlining our initial test results.  They do in fact focus on single-queue behaviour, both with single flows and with two similar or dissimilar flows competing, and should thus answer additional questions you may have on this topic.  We are still refining this, of course.

> 	• Q2. How do you address the lack of ECT(1) feedback in TCP, given no-one is implementing the AccECN TCP option? And even if they did, do you have measurements on how few middleboxes / proxies, etc will allow traversal?

Our experimental reference implementation uses the former NS bit in the TCP header as an ESCE feedback mechanism.  NS is unused because Nonce Sum was never deployed, but because Nonce Sum was specified in an RFC, we expect it will traverse the Internet quite well.  Additionally, the reuse of NS in another role also associated with ECT(1) seems poetic.  Controlled tests over public Internet paths, as well as more extensively in lab conditions, have been carried out successfully.

Disruption of either SCE or ESCE signals is tolerated by design, because in extremis SCE flows still respond to CE marks and packet drops appropriately for effective congestion control.

We expect to publish an I-D covering the above shortly.

Cursory examination of QUIC indicates that it already has a mechanism specified for detailed ECN feedback, and naturally this can also support SCE.

> 	• Q3. How do you address all the tunnel decapsulators that will black-hole ECT(1) marking of the outer? Do you have measurements of how much of a blockage to progress this will be?

I imagine a blackhole of ECT(1) would also be problematic for L4S.  I would consider such tunnels RFC-ignorant (ie. buggy) because ECT(1) is expressly permitted by RFC-3168 in the same circumstances where ECT(0) is.  We have not encountered any such problems ourselves.

In any case, the precise effects will depend on the nature of the blackhole.  If they change ECT(1) to ECT(0) or Not-ECT, then SCE flows will not receive SCE information and will therefore behave like RFC-3168 flows do.  If the affected packets are dropped, then TCP should be able to recover from that.

> 	• Q4. How do you address the interaction of the two timescale dynamics in the SCE congestion control?

Which two timescale dynamics are you referring to?

> 	• Q5. Can out-of-order tolerance be relaxed on links supporting SCE? (not a problem as such, but a lack of one of L4S's advantages)

We consider that aspect of L2 link design to be orthogonal to SCE.  Most transports currently deployed should be able to cope with microsecond-level reordering on multi-millisecond Internet paths without triggering unnecessary retransmissions.

> {Note 1}: Implementation complexity is only a small part of the objections to FQ.

We are still waiting for a good explanation of these objections.  So far, we are aware only of the well-known vulnerability to "gaming" by employing more flows than necessary - but we also have defences against that, which we plan to add to a future version of the LFQ draft.  These defences are semantically similar to the dual host-flow fairness currently deployed in Cake, but with a more hardware-friendly algorithm.

 - Jonathan Morton