[Iccrg] congestion control and visability to the user

[Mikael Abrahamsson]

On Mon, 29 Mar 2010, michawe at ifi.uio.no wrote:

> For a minute, assume that all users have an extremely
> well working congestion control mechanism, which would
> allow them to completely saturate their PE-CE links
> (from what Matt says, I gather that we're moving towards
> such a situation, as - I think - we should)

I don't understand your notion here, saturating PE-CE links is done all 
the time, but let's go on...

> Do you, then, assume that core network capacities have
> to match all this traffic, i.e. be up to N * PE-CE capacity
> when N is the number of customers?
> (I'm assuming an extremely inefficient net layout here  :)
> but I think you get my point)

No, statistical overbooking works extremely well. Day to day variations 
are less than 20% in all networks I've seen, and upgrading core links when 
their peak utilisation start to approach congestion (whatever ones policy 
might be) is quite easy if one just has a basic statistic set of 5 minute 
average usage of the links (mrtg).

For instance look here:

http://stats.autonomica.se/mrtg/14all.pl%3Fdir=Stockholm%252FGEB%252F.html

You'll see that ports have very similar usage patterns over time, and the 
total IX traffic:

http://stats.autonomica.se/mrtg/sums_max/All.html

is EXTREMELY easy to say approximately what'll happen over time. On a PE-P 
link with 500+ users behind it, even with this low number of users it's 
still quite easy to do statistical overbooking and not waste masses of 
unused bw or congest over time.

So just to re-iterate, ISPs congesting their cores are breaching their 
contracts with end customers, and IETF and more should NOT help them 
create an Internet that is sub-par with what we have today. There is no 
technical reason to congest the core, only economical and political (and 
perhaps out of incompetence/ignorance).

> I agree on that. Since you were in the Stockholm IETF,
> you must have seen my Ph.D. student Dragana's presentation,
> which addressed exactly that:
> http://www.ietf.org/proceedings/75/slides/iccrg-1/iccrg-1_files/v3_document.htm
> (it seems that her only diagram hasn't survived the conversion,
> but it should be understandable anyhow)

I agree that first and last hop should be the only congestion points.

Can't really say anything about XCP, apart from that if one wants it to be 
implemented in cheap devices, it needs to be easily implemented in 
silicon. Doing it with IP options seems hard? ECN sounds easier because 
it's in the same place of the header all the time.

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