From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 2EDD93BA8E; Fri, 15 Mar 2019 10:44:15 -0400 (EDT) Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lu8Ri-1gwSNf1jTq-011UWi; Fri, 15 Mar 2019 15:44:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 15 Mar 2019 15:44:10 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , bloat , ecn-sane@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:T+1rYLTrLQ7EsP/riWszbf2gV/+BpQMEnrfu9ag0sU2g0VOcE7f Im6a5k9FzJyOrDJiGnWfzp97qkdVbDzMLqnuew8jrZCf+4Xrmvcr5IuX0BiNn5roSOJwix9 GjqrxL9fqbcozWg/gatQMxYH+B+V4cEE4ntPlMM/Kb2ZDJ/z2nX6i4+6XvsqsbpDe+VPAml HIEPsTqSEpxw2Yb+KPnXw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Hd5e9n6XbDs=:WSbH3FOH5PAyugLGGxKNHs arZtxryRkENfApRoVF8RbqVrcxdvjZCVAJaCVW0gadzAkFvkzRacxIfKIAj2jsy5bAU1vRuv0 ODBwSNs0tffC6eAk0IaKnIP3JjQyvE1Sk3b7FMk65YZ8urSxNWhWy5xEenXfLNw7GJ/4WChaO DcoCZ1rXrARzue30DSIcXP1uFx1Vf02SYStgm2nuHf6bQF/GYTJ7d2k72C4cJedC7QZwZSugl +16c0dW5b0BQncqy9u8np7HM6znB4GGn2+NYH8Sz6wfZGXBd+Ym7tFOZDN0hNLzWZV2RuTB7l M+hJufY7RCJSszq/S5Vv//4iWIC3b1xvhP2r2OCpEm/P9PGB/M1WscEacoQScNp3xwMScdPHv bSusr6jKWlh2H5F8EP/Ttk46H9YCHe9QxhtXpFrk0umuWmi6deFvEB7hB8jQesTRKN7dUh6Uy VdpqR4B908pF60SB+3zEjZvapRQ0xLlBT86mnlbUr96NOs+FyjmYTLU18I5eT9pPQCo/zIDwH PNYlslhCDtHZRjaDIMrlcp+iUoUR9faSQnp6Y/turKZkqB3TyQhzfv1VRzUmVtBupssPTRdca xjZep4KlyTwK6tDphkTrxxLfZeEugShj52wqxMky9yyRNnkBXT5aAXBPDsHjGs/CO5nA7LYoU 2jp0gW4pLPhqGqYlT4NEUGXnuxPCF8KqWhe5kmLJH9bwTanDzmG1bHeXic2UFp75Te0+Z24AL Ue16Ynl7PKOtrqWBBwlbKaXepzVYJVl921c6ZLiNzf0Ro54pboDccHVbLZnf2DHcAWHMj6Qam yC1uI4zk4o5V5EAPFPBgmCZ7h9zzkKggjIwMsH/z+lKF9s31yFRMHwLrNEaueGlhC2hpDacnM KZYpsVUjPHXyOf9noWlZC9A8MF06BD51Ewq7jv1ImGRF0Cr78AUdGxDMHmOsvxlwNquBRJH7c ORsyMdJjsQQ== Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 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, 15 Mar 2019 14:44:15 -0000 Hi Jonathan, > On Mar 15, 2019, at 15:27, Jonathan Morton = wrote: >=20 >> On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller = wrote: >>=20 >> That said, having read through the L4S architecture description and = the related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the = conclusion, that this is a mess. >>=20 >> The L4S project proposes a really wide-ranging change of basically = the internet (but allow a concurrent operation with legacy probably to = cater to the fact that an internet-wide flag-day seems daunting to = organize). But then they chicken out when figuring out how to = differentiate between their new and the old by proposing to use = ECT(1)=E2=80=A6 >=20 > I think I would be less annoyed by L4S if it proposed to assign a DSCP = or three to identify its traffic. In fact, I'd be interested to hear a = defence of why DSCP identification of L4S flows was *not* adopted. I = suspect it would revolve around the widespread practice of re-marking = DSCPs by ISPs, which renders DSCP too unreliable for L4S' purposes. https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05 contains a = discussion of the alternatives, specifically to your point it argues: "Appendix B. Alternative Identifiers [...] B.2. ECN Plus a Diffserv Codepoint (DSCP) Definition: For packets with a defined DSCP, all codepoints of the ECN field (except Not-ECT) would signify alternative L4S semantics to those for classic ECN [RFC3168], specifically: * The L4S DSCP would signifiy that the packet came from an L4S- capable sender; * ECT(0) and ECT(1) would both signify that the packet was travelling between transport endpoints that were both ECN- capable; * CE would signify that the packet had been marked by an AQM implementing the L4S service. Use of a DSCP is the only approach for alternative ECN semantics given as an example in [RFC4774]. However, it was perhaps considered more for controlled environments than new end-to-end services; Cons: Consumes DSCP pairs: A DSCP is obviously not orthogonal to Diffserv. Therefore, wherever the L4S service is applied to multiple Diffserv scheduling behaviours, it would be necessary to replace each DSCP with a pair of DSCPs. Uses critical lower-layer header space: The resulting increased number of DSCPs might be hard to support for some lower layer technologies, e.g. 802.1p and MPLS both offer only 3-bits for a maximum of 8 traffic class identifiers. Although L4S should reduce and possibly remove the need for some DSCPs intended for differentiated queuing delay, it will not remove the need for Diffserv entirely, because Diffserv is also used to allocate bandwidth, e.g. by prioritising some classes of traffic over others when traffic exceeds available capacity. Not end-to-end (host-network): Very few networks honour a DSCP set by a host. Typically a network will zero (bleach) the Diffserv field from all hosts. Sometimes networks will attempt to identify applications by some form of packet inspection and, based on network policy, they will set the DSCP considered appropriate for the identified application. Network-based application identification might use some combination of protocol ID, port numbers(s), application layer protocol headers, IP address(es), VLAN ID(s) and even packet timing. Not end-to-end (network-network): Very few networks honour a DSCP received from a neighbouring network. Typically a network will zero (bleach) the Diffserv field from all neighbouring networks at an interconnection point. Sometimes bilateral arrangements are made between networks, such that the receiving network remarks some DSCPs to those it uses for roughly equivalent services. The likelihood that a DSCP will be bleached or ignored depends on the type of DSCP: Local-use DSCP: These tend to be used to implement application- specific network policies, but a bilateral arrangement to remark certain DSCPs is often applied to DSCPs in the local-use range simply because it is easier not to change all of a network's internal configurations when a new arrangement is made with a neighbour; Global-use DSCP: These do not tend to be honoured across network interconnections more than local-use DSCPs. However, if two networks decide to honour certain of each other's DSCPs, the reconfiguration is a little easier if both of their globally recognised services are already represented by the relevant global-use DSCPs. Note that today a global-use DSCP gives little more assurance of end-to-end service than a local-use DSCP. In future the global-use range might give more assurance of end-to-end service than local-use, but it is unlikely that either assurance will be high, particularly given the hosts are included in the end-to-end path. Not all tunnels: Diffserv codepoints are often not propagated to the outer header when a packet is encapsulated by a tunnel header. DSCPs are propagated to the outer of uniform mode tunnels, but not pipe mode [RFC2983], and pipe mode is fairly common. ECN hard in some lower layers:: Because this approach uses both the Diffserv and ECN fields, an AQM wil only work at a lower layer if both can be supported. If individual network operators wished to deploy an AQM at a lower layer, they would usually propagate an IP Diffserv codepoint to the lower layer, using for example IEEE 802.1p. However, the ECN capability is harder to propagate down to lower layers because few lower layers support it. Pros: Could migrate to e2e: If all usage of classic ECN migrates to usage of L4S, the DSCP would become redundant, and the ECN capability alone could eventually identify L4S packets without the interconnection problems of Diffserv detailed above, and without having permanently consumed more than one codepoint in the IP header. Although the DSCP does not generally function as an end- to-end identifier (see above), it could be used initially by individual ISPs to introduce the L4S service for their own locally generated traffic;" In essence, they do not want to deal with the diffserv mess under the = end-to-end perspective and making it reliable. >=20 > But using the ECN field for this purpose is *also* unreliable, because = it is *intended* to be altered on route (in prescribed ways). In = particular, both ECT codepoints can be replaced by CE, erasing the = distinction between them when it comes to choosing which half of a "dual = queue" AQM to pass it through. I'm not convinced they've spent very = much of the past several years thinking about that. There is also a discussion of this in Appendix B. Alternative = Identifiers, which I will not copy here ;) >=20 > Fortunately, L4S flows should work with flow-isolating AQMs (including = Cake) without modifying the latter, and without needing to specifically = identify which flows are L4S or otherwise. That really says more about = the robustness of proper flow isolation than anything else. But = Codel-type AQMs don't provide the ideal ECN signal for L4S (and nor do = RED-type AQMs without specific tuning for L4S), and any single-queue AQM = is going to end up with L4S flows outcompeting standard ones quite = seriously. Except L$S flows are required to "degrade" to classic congestion = contro once they have proof of not being handled by a l4s aware AQM, = like real packet drops or ECT(0) + CE... >=20 > Since very little "big iron" hardware supports flow-isolating AQM so = far, that puts a damper on any "incremental deployment" argument to be = made for L4S, even if they claim their dual-queue AQM is easier to = implement at high link rates than full flow isolation. The fact is that = either dual-queue or flow-isolation is required in middleboxes *before* = endpoint deployment of L4S can begin. Sure, the argument there seems to be that the typical bottleneck = seems to be the access link and there the ISP who could controll this = might have an interest of making that happen. In that light the = involvement of cablelabs actually seems like a good thing, except for = the part were they presumably took development underground/out of = sight... >=20 > SCE explicitly avoids these problems, as both SCE-aware endpoints and = SCE-aware middleboxes can safely be deployed without waiting for each = other. Work remains on figuring out precisely how SCE information = should be produced and consumed, and verifying that the resulting system = behaves as intended when fully deployed - but its interaction with = existing deployed hardware and software is explicitly defined to be = benign. Sure, I am confident that should SCE prevail here, L4S would = find uses for SCE, but that still faces the same roll-out issue... Best Regards Sebastian >=20 > - Jonathan Morton >=20