From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 1700D3CB37 for ; Mon, 5 Aug 2019 11:56:12 -0400 (EDT) Received: by mail-lj1-x22a.google.com with SMTP id z28so25499951ljn.4 for ; Mon, 05 Aug 2019 08:56:11 -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=rCj3KubLzhyBvmt3m5sij9iCGDCmzKAOYbcx3Ijy/UE=; b=AuIcf2wP+i/uHF5LelV+I/CBg3bGbnkbEvCMFzmJ6yvBCevWde6CIgC9GV/1bAWbqN BjSMZUiFQphluXFLgS5i68BB/QYpSx1DPOu6n4KDNsT54DCtSAqPUPh2m3k+HTOMPo7V T5YBugS6ZuL/EOdeS6yMQrk+S1MPAGg+na8O4hDM9M5Q3PcoePWAv6OwVapiAnUD0Bh4 AxspfGoVmC/JpGYvPL+7XZt2leN4ivqHY1Ufyi6939CrUpiEGB9jmPeL/r6BCugJvszK IhyqXhffkA1aYI0IkvGLCbKx1m1EBHc8M0eLe8FPNvs52Slsc/brvSxtsEHnn5VBvwmZ iZsQ== 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=rCj3KubLzhyBvmt3m5sij9iCGDCmzKAOYbcx3Ijy/UE=; b=DBlBdPunOlUR8E1gIwEMeAVS1TjIvCh2tF1p1JZd/9cQP5228LdbguoMRXHQxKVCMs vAb9tMqbftSwPKMewEk81HiuaDAPm2vBqINopBQHgBPEjGK6T4iEVCoReoPxG0d9VXyg 2J6/fp/3Puq2LydPMZnZ9RkBpTZyYOpCUoTMZioSOL752TPs5fah6UG7Ug3DR/TEPxK/ Jsbjmy+vippgb681YgPApOL1LzQ1rSXvbE0UTVo88mwICCr7bI1DAXK8W/Dbss1fSNyJ RgCm2MDmzwyB03abgr4k7tNPIsHW9ED0hqzQYZydnc6UzQB4TN8lfJC5kGRyemww7/Gp 7gLg== X-Gm-Message-State: APjAAAVn3/TYbXKRpDT6rXa83rPWoVNWIQnpW6x0RgOX/5ju3moQfrBp 53+UfGkeFvNrChFqBp8F9LU= X-Google-Smtp-Source: APXvYqxQ0VHCvqunvmjjNc+SKehKFC0fho1tzHhaRQRnsPvpvdeEd2JYVTER9d3b1NKKdpo9NgDGfA== X-Received: by 2002:a2e:9a13:: with SMTP id o19mr80649345lji.102.1565020570932; Mon, 05 Aug 2019 08:56:10 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-193-nat-p.elisa-mobile.fi. [83.245.237.193]) by smtp.gmail.com with ESMTPSA id g12sm868113lfc.96.2019.08.05.08.55.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 08:56:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Mon, 5 Aug 2019 18:55:36 +0300 Cc: tcpm@ietf.org, ecn-sane@lists.bufferbloat.net, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9D57C401-36FE-4D33-9C04-730BCD4A0122@gmail.com> References: <24f7b15a-129f-ca44-60e0-32c7d23eadf4@bobbriscoe.net> <0FD0931A-3035-4F65-BC91-E0267DF6537B@gmail.com> <0CD0C15C-2461-4B0E-AFD1-947BA6E6212B@gmail.com> To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Ecn-sane] [tsvwg] ECN CE that was ECT(0) incorrectly classified as L4S 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: Mon, 05 Aug 2019 15:56:12 -0000 > On 5 Aug, 2019, at 3:16 pm, = wrote: >=20 > As I said, no corner-case engineering. > In the market that I am aware of, there's a single regular bottleneck, = which is the consumer access or terminal. Let me explain one more time: this is *not* a corner case. This is = normal operation on today's Internet; faster core networks feed into = larger numbers of slower edge networks in several stages. If you = haven't noticed it yourself, that's fortunate for you - but that "single = regular bottleneck" is an illusory simplification, which only applies at = relatively long timescales. However, high-fidelity ECN markers *will* notice the difference, and the = resulting congestion signals will appear at the receiver and be fed back = to the sender. That represents an engineering problem for which either = a solution must be devised, or the fact that it is not a problem must be = established. At present, we're still working through the maths to = determine the boundaries of acceptable operation. It's even possible that conventional RFC-3168 AQMs notice it as well, = depending on their design. Codel, for example, is specifically designed = to ignore transient queuing (if it persists for less than one = 'interval', which is taken as an estimate of the RTT) and only act when = a persistent standing queue exists. And it's actually a very important problem when a dumb FIFO bottleneck = is immediately followed by a slightly narrower AQM bottleneck. In this = case the dumb FIFO dilutes the benefit of the AQM significantly, because = the AQM can't see that most of the queue exists in the upstream FIFO, = and even if it could, it cannot apply any intelligence to it. This is = the scenario Sebastian is most concerned about, and for which I have = tried to compensate in Cake with "ingress mode" shaping - because Cake = is specifically designed to be deployed into that topology. Most of the problem would go away if that dumb FIFO were merely replaced = by a simple AQM. This is a straightforward & deployable engineering = solution that has been known for many years, and yet almost nobody has = actually deployed it. I would urge you to do what you can on that = front; judging by your e-mail address, you probably have more influence = where it counts than I do. I repeat: this is normal operation on today's Internet. > If your technical standardization activities help to make using the = Internet more convenient in African countries without raising extra cost = or requiring extra skills, I'm sure that's a fair market. I know that = these countries are struggling to improve the services operated in their = networks. May I refer you to some useful work already done and widely deployed? = This is now the default in most Linux and Apple devices, and is also = available in FreeBSD. It is used by some of the better CPE devices as = part of "Advanced QoS" and "Airtime Fairness", eg. in the Netgear R7000. https://tools.ietf.org/html/rfc8289 https://tools.ietf.org/html/rfc8290 The problem is that it's not deployed at most of the actual bottlenecks, = which mainly exist in ISPs' equipment if the core networks are indeed = overprovisioned. If it was deployed, congestion on the Internet would = be a much easier problem than it is today. And this should be = especially applicable to less-developed areas of the Internet. All it takes is enough ISPs manning up, talking to their hardware = vendors, and saying: "We expect to have congestion = occasionally/frequently (delete as applicable). What AQM does your = hardware support, and how do we turn it on?" And if the answer is = negative, being prepared to take business to a competitor who does. The = technology exists; money talks. In the less developed parts of the world, one could easily jury rig an = AQM router together using a Raspberry Pi and a couple of USB Ethernet = dongles. With the latest Raspberry Pi 4, that would work for up to a = gigabit link; with older models, you can still handle 100Mbps. These = things are cheap enough to practically be disposable, and consume very = little power. If there's demand for that sort of thing, I and my = colleagues could probably arrange for a ready-made SD card image to be = built and published. Or you could standardise on a consumer CPE router and build a no-knobs = mesh-networking image for that. There's a bunch of groups who regularly = attend Battlemesh, who could help with that. Be prepared to change = models every few years as the old ones go out of production. - Jonathan Morton