From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 C10783B29E; Sat, 16 Mar 2019 18:09:48 -0400 (EDT) Received: from [192.168.42.220] ([77.182.103.198]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MZ8fw-1hJW3z25Lo-00Kxxy; Sat, 16 Mar 2019 23:09:39 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> Date: Sat, 16 Mar 2019 23:09:35 +0100 Cc: Mikael Abrahamsson , "David P. Reed" , "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> To: "Holland, Jake" X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:fEaN39Id9BkUREbOPBIkBD63zSBHkiK6IeDvF7nz7jLowavdfHp 4ypDoAUH/9H+uuaOacEqe8ZQAsSkCGhUJW9g3boSmVbSZJpRAveMk4FaoU+5LhP815w4uPT o6i10XOpmm3KX2b9Os+SQxKncwv+Za+jAQ0QwyqYYgXjpzkvMP9g4tBo/by07TT/HYc0dWd lmM+6K3Dqy5ABEpgrMaew== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QT3qbY29WPQ=:of+5lE/k1UXfIDkMQ87t9y /eoD0nrnUmHGnht87qkpk9MRvpCYq8huH0FREymw2dSbmLTMWNxn7nuVN/zR7Tdul7VHm1cDC c5Xv7EecboyXvEGM2Fu1elY/Xiovj6uZ3yrb3IH32853qe1qlVomzps1lXuXKPH8FSEwnJeUx mCoqGfSCxPW4tCIKjGnnbP4ZyBakU15qjP2fe/2Lcyetu/ab1g02kKKcQY4NRUZ631E0JN1Po BmYO+NkZ9sU14N0L5vcVTnaYfUu4EiZeX1h+Dpy12mQMN5Qeh+17F2bmOFsfnQ2bW8BuIf3S4 cW23q+SKT3CoX//SkfC8DxhzDNu1HOtHLQRnCpegagzTsOjeBXHq9NYYBLWpLwyL5Jhr4k+dv K+3n19EHyHQizCzworBD/+y/l/v/e0ZD9c3qryjy0hjxSnIg5u9Aqcuwnp5M9cE+q2qLDi6Dl JVtATh16VH3tpWHjTov+FmL8YUpGSS36ERL4+Cfcmb2ll9m7YCt+GjX+fOebnBTo6cwsNe6aG 6nqtXbcCgpEepL2c5rm0/UMbX6S9aBdVmta5Z7svXQ+LOY5Rk6AdJZGeQTAwLU/WyFID+yT9I t9qhXncIP+IErwAOwy3Nyk7epbysOzhcpZdtq+4hfr7FUn74+epNOzq0g/8L4D+6yfHAIc5to 0kO/fcMJB3vuXE/Orxgkd6GbMkukusAG4OQi6hybbfSJzw276Ie0UXa+eM+VJypeaC1hK5YTX LiwnmV8AMDqu/z3Sj8rTMO1jD5dDdWSxMmV7zM9maV4MBEG4V3gmEPpu04vB2UH4AWTen6uL6 OSSiuywH5Arj+wO23ayNuQ3iK7B1jX498nFJ0lQ7J3MvZMpt5D/2VsL0Tz5jPQ0we4Atn4VkS ZzYlc4dSqnxtl48BJ8q8HcY9nwvXA3771bTmT8InCFHL36cLbUwWwoiIrvMNm2h36J3Bwj5NU wHQlNzMLJ4Q== Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 22:09:49 -0000 > On Mar 16, 2019, at 22:38, Holland, Jake wrote: >=20 > 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. Except PIE is not mandatory there, DOCSIS3.1 made PIE mandatory = on the CPE or customer modems, CMTS AQM was I believe recommended. >=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. The relevant section from = https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06: "A.1.4. Fall back to Reno-friendly congestion control on classic ECN bottlenecks Description: A scalable congestion control needs to react to ECN marking from a non-L4S but ECN-capable bottleneck in a way that will coexist with a TCP Reno congestion control [RFC5681]. Motivation: Similarly to the requirement in Appendix A.1.3, this requirement is a safety condition to ensure a scalable congestion control behaves properly when it builds a queue at a network bottleneck that has not been upgraded to support L4S. On detecting classic ECN marking (see below), a scalable congestion control will need to fall back to classic congestion control behaviour. If it does not comply with this requirement it could starve classic traffic. It would take time for endpoints to distinguish classic and L4S ECN marking. An increase in queuing delay or in delay variation would be a tell-tale sign, but it is not yet clear where a line would be drawn between the two behaviours. It might be possible to cache what was learned about the path to help subsequent attempts to detect the type of marking." In short L4S has not seem to have solved this problem yet except for = identifying it. IMHO this is a clear reason not to to re-use ECT(1) outside of ECN = signaling. >=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. IMHO the beauty of the simple SCE proposal is that it simply = supplies information a rational flow could/should react on purely by = self interest, but ignoring it should do no harm, assuming the = assumption holds that ECT(1) safely traverses the internet. >=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