Re: [tcpm] [tsvwg] [Ecn-sane] ECN CE that was ECT(0) incorrectly classified as L4S

[Jonathan Morton <[e-mail]>]

> On 5 Aug, 2019, at 3:16 pm, <[e-mail]> <[e-mail]> wrote:
> 
> 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