This is at least partially the result of the reality of backhoes, trucks, and ships, and the different timescales on which these operate; and competence of the network operators is also an issue. Crystal balls are very hard to find, and accidents and acts of men and gods do happen.

So “SHOULD NOT happen” I can agree with; but it “DOES happen” is the reality of the Internet.

This means that the congestion that you cannot resolve by adding capacity will only happened at interconnects – which is something we are seeing right now and were seeing since the internet got more than one distinct network. Of course that made no sense to the academics so their solution was … Internet2 a network with no traffic and therefore no congestion.

If you are not accepting this as a premise you should stay away from the network design.

“Also, Alex, please understand that any operating system more recent than Windows XP can quite easily saturate and congest links of > 1Gbps (as they will do TCP window scaling). ”

I do not need to “understand it” – some of my customers saturate 10gig ports daily while pushing traffic to 1Gbit/sec or 100M/sec ports. Somehow none of them are having issues with the other connections dropping.

There should be no “congested core routers”. That is the solution to your problem. Even Cogent knows that. Yes. Cogent.

Even inside of a much more static network, you have a mesh of connections, and given the variability of traffic (and transient failures) and ISP cannot always provision successfully in advance (nor is it generally economic to do so). While the goal of a well run network may be to run uncongested as much as possible, without queue management, you will have poor latency any time your path crosses a congested router, not just at the connections between autonomous systems.

Also, Alex, please understand that any operating system more recent than Windows XP can quite easily saturate and congest links of > 1Gbps (as they will do TCP window scaling). Windows, however, has the additional default of shaping its traffic to remain below 100Mbps by default (on a *single* TCP connection).

We are moving into a world where congestion is “normal” for many operations at some point in the network path (primarily, but not necessarily at the edge of the network). In fact, we’ve been living in this congested world from the beginning; it is just with unbloated buffers, transport protocols can react as they were intended and the latency disaster we are now experiencing was primarily confined to congested core routers failing to run AQM. Now we see this latency problem everywhere, including on the hosts (as they too have bloated buffers, which they did not a decade ago).

The points of congestion are interconnects between the different networks where as a network operator I can control only one side and I’m speaking BGP to my peer.

When I did research in AQM, I noticed there were many algorithms out there. Mainly because anything you do will have an impact. The question is how big of an impact. RED was conceived as an initial almost empirical approach, where the piece wise linear function had absolutely no theoretical support except the one of being simple.

Based on this idea the RED worked, many researchers started to make modifications to improve its performance. You see however that something like Kelly/Gibbens VQ provides a first insight to marking instead of dropping, and it “works” with a simpler approach. Again the issue its not that it works, but how good is it and what computer processing requires. RED is simple, but it has nonlinearities that are hard to account for. ARED is just a modification to actively modify some of RED’s parameters.

On the other hand, you see for example PI or REM, with a little more theoretical background, but making the algorithms a bit more complex. You see that linear solutions such as REM are more stable, yet a bit slow. In fact, if you carefully read REM and AVQ you see both faced the same problems and while REM added the backlog into their algorithm to account for instabilities, AVQ didn’t reason why S-AVQ was later proposed.

I initially worked developing estimators of network parameters and modeling TCP. But noticed that accurate modeling requires too many parameters and estimators of such parameters are processor hungry.

Thus, my issue turned into using nonlinear systems that would act faster under extreme changing conditions, but reacted smoothly when the change in conditions weren’t significant. Therefore avoiding the speed/stability trade-offs of linear systems.

It certainly depends on what your goal is and what are you trading to achieve those goals. I broke the problem of AQM into three main parts: detection, mapping and marking. After RED proposed a Bernoulli like approach for marking, everyone gave marking for granted. And most people concentrate on the mapping scheme. For RED, the detection is performed using the EWMA filter, the mapping uses the piece-wise linear function and the marking uses the geometric/bernoulli like mechanism.

Using statistical theory, I found that a non-standard likelihood detector could dramatically improve the detection mechanism, and a Sigma Delta modulator could also improve the marking scheme in such way that the mapping mechanism wasn’t required to be processing intensive.

You can check a journal paper recently published “statistical approaches to congestion control in computer networks”, where I describe such blocks. The detector itself was proposed in another paper. But the main trade I gave was processing power. The algorithm is still complex compared to that one of the original RED.

Note that Cisco proposed an alternative WRED based on base-2 values and coefficients to make it easier to calculate and faster on switches. If you think about it, having a 48 1Gbps ports, and assuming worst case scenarios of 125 bytes per packet to make math simple, this means a rough 48 million of AQM operations per second. Having processor intensive AQMs translate those 48Mops into heavy work for the switches/routers. This, without taking into account using ECN and requiring to reassemble packets and re-calculating checksums (depending if the ECN is in the TCP or IP header of course).

ARED doesn’t seem to provide the performance improvement worth implementing it, which causes: 1. Impact on packet processing (and risk of bugs) 2. Scalability problems for large x-connects 3. Companies rather sell expensive cards to telcos, instead of providing them with improved software techniques.

That’s just a brief explanation of my perspective, but of course I’m willing to elaborate a bit further on it.

For ARED to be “interesting” it needs to be implemented and tried out. I suggest you implement a Linux queue discipline. As the driver debloating work already underway for Linux (see the bloat-devel mailing listshow, at some point over the next few months it will be time to move on to how to deal with routing queues. Simulation is one thing: trial by fire quite an another (and I don’t know if there has even been recent simulation of ARED; note Sally Floyd’s reasonably famous statement to the effect that a simulator can be used to show anything you like).

Note I don’t believe “one size fits all” is a likely outcome (pleasant as that might be if it turns out to be possible). We have a number of quite dramatically different environments where bloat is occurring, and it doesn’t follow in my mind that we’ll necessarily end up with a single solution. Beyond history having shown (and one of the the authors of RED 93 having said) that classic RED 93 isn’t really adequate, I take no position.

I do note that algorithms that primarily depend on output goodput, in my intuition, are most likely to succeed for wireless. The big challenge of wireless is the very large dynamic range and variability of goodput.

Please do make it a contender! We’re in a world of hurt.