From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 lists.bufferbloat.net (Postfix) with ESMTPS id CC94B3BA8E; Tue, 19 Mar 2019 04:50:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1552985403; bh=NkJANHHbZrZ28alwDbRI0/3yLKl84stzqu6F1ftuGVU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=F4EomO24YnWwihXAG/e4ZzlXZWTzD2Eo20Ir/kmugfoxKENVxrx/PEeFndORxmEZx ViuVogydVLtbZ461gCvRrTcQP1RRKViFHuSVEQDPSeV6vB7zRNGRVOjRPKkI5N+tW3 Hqe6Jw/mgLFd+p5Krl7blQ40XVGdiuM1JDKgDDbA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.12.10] ([134.76.241.253]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcSWg-1ghFHQ3bHC-00jqxf; Tue, 19 Mar 2019 09:50:02 +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: Tue, 19 Mar 2019 09:50:01 +0100 Cc: "ecn-sane@lists.bufferbloat.net" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> <1552846034.909628287@apps.rackspace.com> To: Greg White X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:fa6LyLv2gvbPf3cqPsa7pc7Ua2ptgptKbiQlavQoT9O20WJZYt/ w0luJk3ybqzeKSjkw5h3evlGhw0p2dK8jqQ+vswV524KnZN6TYvfIgBqyNyv0pZNWHzR1XB kY6uilrUH2cuS3I3japiyKmDj+u/AhhVM3Q7ckdzvNnl7P+ca/aBWi5szDCQyJ8Z/JKX6Uh QnjiMA63aC/xuKI8RwGWw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:wg23Mq8UHlo=:BX78zba5YD7Z9iXV1vQxn/ NbOD4MxbcUQ63sc87Gk0/7fUoHHQzSX4DrfXhIvvpVVmp3Fq2RW3YwW/aMidHwxxR4rdmTvy8 tB9pNgRqLcMB7m9P8l2D4sFpzv/Aj086GzKljjTzfQQxbeSOEKtLobvK4OA1fTZFPmtF49Bw4 3yB+j8zX3ptkcGgaflobSt3FTSTNQ2buWsvgPU/rI7v+KHdXqjA9aNgs+SNv3I0fk+NWX16cD Jkq8QQDjEbIHsGAwrjlKanmnEhWw2VDHp4cLGX/h/nrUZRzNjPk632n4IfiNq5F0UuH9a4Dya aLdr5krkk+EN9ku4iTwSutEEmNGK1Rm4Cqvn+KasbOMBWilDkFeOFgsTgoLzOuTp+fHft9WLu JaIjaxKY0USzQL+lbnEDMOjU3dN8CaPykokO3SBVI3i3BzClx+X+a/n5p0zG0v+LkxUmgDgbH GhllRnPI2OFxapL5xpYP9RbvDtLNEizDt6oGMj/DHSQaj5omH3DXle/Z3NvAGBCtFXW988DyX URb+rPFdjzGT13u5srrXWmaVbFKUZpM+hod2u5MscRsqgPoHYYFnYto0BQ8Y40uFxRPEbK6Uq LXbMHXlVTBD+Xq1mI87qZ35dBknLr6/LhPLJ2lm30LLhm3t2s2Odp3bmHltYmVGRvVpMGpIeT 5qRft7vEa5CIbsGz+fpU4qz8KWcdBgNkDRAU3XMyxn4/2ETienka43AJKV/Oq0/eKLM7rZDFa nuEeHfJ7S7ILCNy1ArQt1dgsKWaSm8fKP+49xOQqLdZWYN1uzWTZmq4ZYLAEbJcm220vzc1RU INVGsms+W82dHCbO4RmkChFiHEXAbQ8viipsps1oTfGdPwPgsRSTtwVmxmlBZioYC4an2m7GN gRChXsDWvhYAOcxhsL9kMdyImqfkIfyQJJhEDdziJU/dSTBe0mGZMrdDQkmiMoKcnwTqEBsvG LPR58vwd2gQ== 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: Tue, 19 Mar 2019 08:50:10 -0000 > On Mar 19, 2019, at 05:44, Greg White wrote: > If I can boil this down for the people who are jumping into this = without reading the drafts: > =20 > =E2=80=A2 Both L4S and SCE are attempting to provide = congestion-controlled senders with better congestion signals so that = flows can achieve link capacity without buffering delay.=20 > =E2=80=A2 Both are proposing to use ECT(1) as part of the = mechanism, but to use it in different ways. SCE tries to encode information about the quantitative = congestion state of the marking AQM into ECT(1), while L4S tries to use = this as a general identifier of promised behavior as a receiver of CE = marks, or rather as an indication that flows marked ECT(1) will not = respond to CE marks as described in rfc3168. Which realistically means = any non-L4S AQM needs to learn quickly to drop ECT(1) packets instead of = marking them CE; that seems better controlled than waiting for a = fall-back to rfc3168-compliant CE response due to a heuristic based on = RTT variation. > =E2=80=A2 SCE=E2=80=99s usage of ECT(1) potentially allows an = automatic fallback to traditional Cubic behavior if the bottleneck link = is a single-queue classic-ECN AQM (do any of these exist?), whereas L4S = will need to detect such a condition via RTT measurement > =E2=80=A2 L4S=E2=80=99s usage of ECT(1) allows links to identify = new senders and take advantage of new sender features like reordering = tolerance that can further drive down latency in many common link = technologies. But L4S is incapable of _reliably_ classifying L4S flows/packets = as CE-marked packets default to L4S-treatment. This indicates to me, = that ECT(1) is not really suited as a reliable L4S identifier, what am I = missing?=20 This ambiguity leads to the question of the side-effects of this leaky = classification: what about re-ordering of CE-marked packets? I hope that = out of caution CE-marked packets will not be re-ordered as these are = very much not guaranteed to employ RACK. (And tangentially, how is a = link that desires more latitude for re-ordering going to deal with the = RACK requirement to keep the re-ordering windows <=3D 1 RTT, given that = RTTs over the internet differ from a few to dozens of ms. . Is there any = study showing how RACK and re-ordering actually interact in real-life?) = And how is it going to help a link in regards to re-ordering at all? It = has been argued, that links do not differentiate flows at all, and = assuming TCP traffic to coexist for a long time with (DC)TCP_Prague = traffic, how can a link actually allow more re-ordering than currently = tolerable without severely impacting the TCP flows? If it just transmits = all ECT(1) packets in its queue things will be a bit better than now, = but after the egress queue is emptied the link might still be stalled = until the re-transmit of ECT(0) and CE marked packets is finished, no? > =E2=80=A2 SCE will only work if the bottleneck link implements = fq. Some bottleneck network gear will not be able to implement fq or = will not implement it due to its undesirable side effects (see section 6 = of RFC 8290). > =E2=80=A2 L4S will work if the bottleneck link implements = *either* fq or dual queue. The proof ought to e in the pudding ;) is there data showing an = working L4S fq-AQM? > =20 > Beyond that, they are *very,very* similar. =20 > =20 > But, L4S has been demonstrated in real equipment and in simulation, = and leverages an existing congestion controller that is available in = Linux and Windows (with some tweaks). =20 As far as I can see the public git repository for TCP Prague is = only a few days old so how could that be "available in Linux and = Windows" right now, and one could similarly argue that it will only take = a few tweaks to teach cubic how to deal with SCE. So I have no pony in this race as I am outside of the field, but the L4S = RFCs seem to promise more than they=20 > SCE leverages a paragraph in a draft that describes a first guess = about how a congestion controller might work. > =20 > L4S has defined a congestion feedback mechanism so that these = congestion signals can get back to the sender. SCE offers that = =E2=80=9Cwe=E2=80=99ll propose something later=E2=80=9D. > =20 > BBR currently does not listen to explicit congestion signals, but it = could be updated to do so (for either SCE or L4S). > =20 > -Greg > =20 > =20 > From: Bloat on behalf of "David = P. Reed" > Date: Sunday, March 17, 2019 at 12:07 PM > To: Vint Cerf > Cc: bloat , = "ecn-sane@lists.bufferbloat.net" > Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] = Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 > =20 > Vint - > =20 > BBR is the end-to-end control logic that adjusts the source rate to = match the share of the bolttleneck link it should use. > =20 > It depends on getting reliable current congestion information via = packet drops and/or ECN. > =20 > So the proposal by these guys (not the cable guys) is an attempt to = improve the quality of the congestion signal inserted by the router with = the bottleneck outbound link. > =20 > THe cable guys are trying to get a "private" field in the IP header = for their own use. > =20 > =20 > -----Original Message----- > From: "Vint Cerf" > Sent: Saturday, March 16, 2019 5:57pm > To: "Holland, Jake" > Cc: "Mikael Abrahamsson" , "David P. Reed" = , "ecn-sane@lists.bufferbloat.net" = , "bloat" > Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] = Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 >=20 > where does BBR fit into all this? > v > =20 > On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake = wrote: >> On 2019-03-15, 11:37, "Mikael Abrahamsson" wrote: >> L4S has a much better possibility of actually getting deployment = into the=20 >> wider Internet packet-moving equipment than anything being talked = about=20 >> here. Same with PIE as opposed to FQ_CODEL. I know it's might not = be as=20 >> good, but it fits better into actual silicon and it's being = proposed by=20 >> people who actually have better channels into the people setting = hard=20 >> requirements. >>=20 >> I suggest you consider joining them instead of opposing them. >>=20 >>=20 >> Hi Mikael, >>=20 >> I agree it makes sense that fq_anything has issues when you're = talking >> about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE >> makes better sense there. >>=20 >> But fq_x makes great sense and provides real value for the uplink in = a >> home, small office, coffee shop, etc. (if you run the final rate = limit >> on the home side of the access link.) I'm thinking maybe there's a >> disconnect here driven by the different use cases for where AQMs can = go. >>=20 >> The thing is, each of these is the most likely congestion point at >> different times, and it's worthwhile for each of them to be able to >> AQM (and mark packets) under congestion. >>=20 >> One of the several things that bothers me with L4S is that I've seen >> precious little concern over interfering with the ability for another >> different AQM in-path to mark packets, and because it changes the >> semantics of CE, you can't have both working at the same time unless >> they both do L4S. >>=20 >> SCE needs a lot of details filled in, but it's so much cleaner that = it >> seems to me there's reasonably obvious answers to all (or almost all) = of >> those detail questions, and because the semantics are so much = cleaner, >> it's much easier to tell it's non-harmful. >>=20 >> >>=20 >> But as you also said so well in another thread, this is important. = ("The >> last unicorn", IIRC.) How much does it matter if there's a feature = that >> has value today, but only until RACK is widely deployed? If you were >> convinced RACK would roll out everywhere within 3 years and SCE would >> produce better results than L4S over the following 15 years, would = that >> change your mind? >>=20 >> It would for me, and that's why I'd like to see SCE explored before >> making a call. I think at its core, it provides the same thing L4S = does >> (a high-fidelity explicit congestion signal for the sender), but with >> much cleaner semantics that can be incrementally added to congestion >> controls that people are already using. >>=20 >> Granted, it still remains to be seen whether SCE in practice can = match >> the results of L4S, and L4S was here first. But it seems to me L4S = comes >> with some problems that have not yet been examined, and that are = nicely >> dodged by a SCE-based approach. >>=20 >> If L4S really is as good as they seem to think, I could imagine = getting >> behind it, but I don't think that's proven yet. I'm not certain, but >> all the comparative analyses I remember seeing have been from more or >> less the same team, and I'm not convinced they don't have some >> misaligned incentives of their own. >>=20 >> I understand a lot of work has gone into L4S, but this move to jump = it >> from interesting experiment to de-facto standard without a more = critical >> review that digs deeper into some of the potential deployment = problems >> has me concerned. >>=20 >> If it really does turn out to be good enough to be permanent, I'm not >> opposed to it, but I'm just not convinced that it's non-harmful, and = my >> default position is that the cleaner solution is going to be better = in >> the long run, if they can do the same job. >>=20 >> It's not that I want it to be a fight, but I do want to end up with = the >> best solution we can get. We only have the one internet. >>=20 >> Just my 2c. =20 >>=20 >> -Jake >>=20 >>=20 >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/ecn-sane >=20 > --=20 > New postal address: > Google > 1875 Explorer Street, 10th Floor > Reston, VA 20190 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat