[Iccrg] congestion control and visability to the user

[Woundy, Richard]

Mikael,

I'll provide my perspective on why I think ECN and congestion exposure
is still worthwhile.

> Apart from the access, the ISP should never congest and thus should
never be dropping packets. Core Network congestion is not something
"natural", it means the ISP is not doing its job properly.

My ISP perspective is that congestion can happen anywhere, but there are
parts of the network that are more likely to experience congestion than
others. The access network is most likely to experience congestion (with
'self' congestion happening more often than 'shared' congestion). Next
most likely would be congestion on the backbone interconnects. Least
likely (and a fairly rare occurrence) would be internal backbone links;
this probably happens when "the ISP is not doing its job properly" or
when there are multiple catastrophic link or routing failures. Even
Google has been guilty of this once or twice.

In an earlier email, you seemed to suggest that interconnects are easy
to manage from a capacity point of view, and you point to
<http://stats.autonomica.se/mrtg/14all.pl%3Fdir=Stockholm%252FGEB%252F.h
tml> as justification. I looked at the Microsoft graph, especially the
'yearly' graph at the bottom,
<http://stats.autonomica.se/perl/14all.pl?log=stockholm.geb.194>. It
appears that in October 2009, traffic quadrupled in just a few days. Do
you know why?

I've seen cases in which a change on the content/application provider
side will cause a significant change (100%+) in traffic on one or more
interconnect links. Consider tunneling traffic as a perfect example.

There is also another consideration for private interconnects -- both
ISPs have to coordinate on a capacity upgrade. Many times, the upgrade
is a higher priority to one ISP than the other. But one ISP can't expand
private interconnect capacity alone. :)

> I'm against the notion that core network congestion is something that
should be focused on handling by some kind of "make core routers aware
of flows so end users get fair access to bw in the core".

For me, "making core routers aware of flows" is not a goal. I didn't
think that was required for either ECN or congestion exposure in core
routers. (Some folks are talking about adding policers to the core, but
that is separate equipment and a different decision from my
perspective.)

Some ISPs are running (W)RED in their cores today. Are you saying they
should turn it off, and vendors should drop support? And why?

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

I don't want that either. I don't think that is the goal of most
participants, either.

-- Rich

-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On
Behalf Of Mikael Abrahamsson
Sent: Tuesday, March 30, 2010 10:47 PM
To: Michael Welzl
Cc: iccrg at cs.ucl.ac.uk; Matt Mathis
Subject: Re: [Iccrg] congestion control and visability to the user

On Tue, 30 Mar 2010, Michael Welzl wrote:

> Whether access links are always saturated or not. Sorry if just
> throwing in the RFC 3649 reference was confusing, I meant it
> as a point to illustrate TCP's growing problem with a growing BDP.

I'm still confused. First we were talking about congestion at the core
as 
an unavoidable natural way of things, now all of a sudden we're talking 
about something else. I'm all for enabling TCP and other protocols to 
properly utilize access links, I'm against the notion that core network 
congestion is something that should be focused on handling by some kind
of 
"make core routers aware of flows so end users get fair access to bw in 
the core".

> Sorry, we're at cross-purposes here. My point was that improving 
> congestion control functionality in end hosts still makes sense, and
we 
> just seem to agree here.

Yes.

> So what exactly is the technical development that you consider 
> pointless?

The core thing.

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

_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg