From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C34DD3B2A4 for ; Fri, 5 Jul 2019 04:26:12 -0400 (EDT) Received: by mail-lf1-x133.google.com with SMTP id q26so5771889lfc.3 for ; Fri, 05 Jul 2019 01:26:12 -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=F9Qonra/BntiqgEKM2pQ/lU8ytLv/9pb3w5+hj+4TRRFTNL8p6JBankNQC6OFtpqfK q4Oo67t5KoaI0HUzGNNQagQq7OyoFrEaUd6Yix6EXzAbZD6hd8H9a6vhUZV0FO4f6JWQ 0EhhhW2tW1QxjYDtGlZD2KNv4NdJThZvhoBy/DfbvPrHry26ogpoVIzgsrBTQZhWzdmk sqlQqTd4xQlfitwiV/SPOaaRlTcxNLj+WskEHAA8fH61OKgxYrk36OMfRMRhn6wlg3sg Y/S/B+p/OPPS9ne2FYFM9OPz/KgGM22DbN163vT1+llGqtnPpS3XDL15vPlNwsHnUx2P nvXg== X-Gm-Message-State: APjAAAX1kni169iPB3foucMbH4qCBiDpDwmMfyPkvidC9w2ku2BbcDqM c4cdQVJV4bV7RomC6L+fs94= 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 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)" , "ecn-sane@lists.bufferbloat.net" , "tsvwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <4aff6353-eb0d-b0b8-942d-9c92753f074e@bobbriscoe.net> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <5c58a2d1-0dfc-e0fa-398a-9e196615f04a@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 08:26:13 -0000 > On 4 Jul, 2019, at 8:54 pm, Bob Briscoe 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. > =E2=80=A2 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. > =E2=80=A2 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. > =E2=80=A2 If not, how does it work?=20 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. > =E2=80=A2 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. > =E2=80=A2 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. > =E2=80=A2 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? > =E2=80=A2 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