[Iccrg] IETF plenary: fast timescales

[Mikael Abrahamsson]

On Wed, 11 Aug 2010, Frank Kelly wrote:

> The above discussion is concerned with signalling congestion,
> and how fast end-systems can react, if they want to. How to align incentives 
> with congestion signals is of course the tricky issue that Bob is working on 
> - http://bobbriscoe.net/projects/refb/

To re-iterate what I said in Stockholm:

Devices are getting less and less buffers over time, not more. (re-)ECN 
relies on big buffers and WRED to signal congestion. Implementation of ECN 
(a 2001 standard) in major vendor core routers today is minimal (where the 
buffers are), I haven't seen it at all on switches that does policing 
only (and it makes little sense on a device with 1-5 ms of buffers).

Also, the best and easiest way (which is also net neutral) to solve 
congestion is to make sure that the heavy users either mark their packets 
as low priority (or it can be marked for them by means of having a 
different type of subscription) and queue accordingly, or by means of 
monthly caps (and having the user pay for extra credits which means 
congested links are financed).

If a core link (not the individual user access link) is congested, then 
the ISP is not doing its job. The real problem is to visualise this to the 
customer so they know and can switch providers. If they can't switch 
providers then this is a political problem and not something we can solve 
by technical means.

I'm from a market where 10/100 megabit/s ETTH is common (15-20 percent of 
the households have access to this service). Congestion is rare because 
bad performance is not tolerated by the end users and they switch 
providers. There are plenty of tools available to test bandwidth, and they 
work. People are not satisfied with badly performing ISPs so this is a 
problem of the past (it was "solved" 5-8 years ago).

So, my guess is that (re-)ECN, feedback, all of this, will get very 
limited usage on the actual Internet. I don't oppose the effort put into 
it, but I think it's misdirected. Time and effort would be better spent 
actually making it easier for the end user to see that congestion is going 
on, and act accordingly. This involves showing the classical congestion 
signals; variance in RTT and packet loss.

We have plenty of tools in the toolbox already, we have precedence/dscp 
markings, we have ECN and there has been plenty of mechanisms proposed the 
past 10 years, but what is still most in use is simple WFQ and WRED, all 
of these are at least 10 years old but they work.

We should work to remove congestion, not hide its impact. Congestion 
within the ISP means something is full and the ISP hasn't provisioned 
enough bandwidth to deliver the service it promised to the user. The only 
place congestion should happen is on customer access links.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se