[Iccrg] congestion control and visability to the user

[michawe at ifi.uio.no]

> 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...

My notion was that it's not, usually, because of standard TCP
being "lame" (as Matt rightfully called it).

However, in this world of CUBIC in Linux, a growing number
of users with proper buffer sizing / window scaling, and,
above all, users (or their (P2P) applications) opening as
many connections as they need, I can imagine that what
you say is true.


>> 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).

Well of course economical reasons are there. Bandwidth
costs money. So, is all we're doing here with congestion
control only about:
1) managing fairness within the user's local networks, and
2) making the network operate even if ISPs don't investe
in enough core bandwidth, which apparently hardly ever
happens?

(plus making it robust for special scenarios, e.g. wireless
access, in the presence of failures, etc etc)

That might just be the case.


>> 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.

That was the only point here, really -


> 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.

XCP was really just an example. The point was that, given
that we can get a benefit from explicit feedback for
congestion control, it might be enough to do it on the
first and last hop, where doing it might actually be feasible.

Cheers,
Michael