[Iccrg] congestion control and visability to the user

[Matt Mathis]

On Sun, Mar 28, 2010 at 9:03 PM, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> I participated in IETF75 which was my first and only IETF so far, and I've
> been trying to participate some via the mailing lists after that. I was in
> the ICCRG session and voiced concern regarding ECN, where it sounded there
> as people thought ECN was in wide use today, which it's not and there is
> nothing to suggest to me that it'll ever be. The core router world is more
> and more going to smaller buffers (< 50ms, often much lower than that) which
> makes WRED/ECN less and less usable.

Yea, we are all worried about ECN.    ECN capable routers are in wide
deployment, but nearly all have it turned off by default.

You are correct, at core speeds you never see significant queuing
(this was also mentioned at IETF 77).   However the Approximate Fair
Dropping (AFD) algorithm uses a shadow buffer in TCAM to approximate
WRED in virtual queues.  See: Rong Pan et al "Approximate fairness
through differential dropping", ACM CCR April 2003.  There are newer
papers but they were not published in the standard venues, so I don't
have clean citations for them.   Search for papers by Rong Pan that
start "Approximate Fair...".

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

Your statement was true for old stacks that have fixed size receiver
windows.   The new stacks autotune out to 4 or 8 MByte windows.
Unless you are on a transcontinental  GigE, every connection with
enough data will cause packet loss or queues somewhere in the network.
  Since all networks are at least slightly oversubscribed at most
levels, the potential exists for there to be congestion nearly
everywhere.   Between autotuning and p2p it is no longer possible to
avoid congestion in the core except by explicitly designing in
bottlenecks at midlevel interconnects, the network edges or somewhere
in between.

The problem is that AIMD congestion control does not work well enough
at these scales.   See my the talk that fell off of the ICCRG agenda:
http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf  (the
detailed argument is in the first set of backup slides).

> I therefore suggest that what
> is needed is to make is visable to the end user when core network congestion
> is occuring, and provide them means to try to fine what it causing it, so
> they can make an informed decision whether to complain to their service
> provider and might change providers.

You are off the mark here.  The problem is that the traditional "TCP
friendly" model does not implement anything that resembles any form of
fairness except under completely idealistic assumptions.  TCP has been
lame for 20+ years, such that we failed to notice that the Internet
does not have a real capacity sharing architecture.  Now that TCP is
mostly not lame, people are discovering that you do not want to share
the network with a well functioning bulk TCP transfer.  This has
actually been known in a theoretical sense for a long time (see RFC
2309), but was not often a problem until recently.

I didn't realize how bad it might be until I had a conversation with
my son, who mused that he liked his new PC because it was so quick on
the network.  However, whenever he is doing anything serious (he is a
web designer), everybody else on his home LAN starts to complain.

> In the TCP group I made the same suggestion, to standardize an interface
> into the TCP stack so as to make it visible to a statistics collection
> application on the computer so it can present network statistics to the end
> user. Also such speed limiting factors as "TCP window fully open" is
> interesting to know about, ie the speed is limited by RTT/window size.

See Web100.org and RFC 4898, which do all of the above and more.  They
are not out in stock operating systems quite yet....

> I believe today that the users too much see the Internet as a black box they
> have little or no visibility into, and this is where the IETF as a whole
> should put resources into fixing this situation. It should not be done by
> developing testing tools, but instead making the existing traffic able to
> report performance in a standardized way. I also think that any future work
> in congestion control/avoidance should include API etc for external
> applications in a meaningful way to extract this information and present it
> to the user. This might actually need a WG of its own, I don't know.

The network visibility was sort of the insight that lead to the IPPM
WG, some 15+ years ago.  It has proven to be a rather hard problem.

There has been lots of research proposing richer APIs  for managing
performance.  None have caught on.   This has also come up recently in
ICCRG, and will be discussed over the next several years I am sure.

I hope this helps,
--MM--