[Iccrg] congestion control and visability to the user

Mikael Abrahamsson swmike at swm.pp.se
Mon Mar 29 02:03:31 BST 2010


Hello.

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.

It also shows that whatever is invented that involves changing things in 
routers takes 5+ years, if ever, to get implemented. It also means that 
really long core network delays due to congestion is also going away, 
we'll see packet losses straight away. In the ETTH space where cheap and 
small L2 switches are often used, there also quite small buffers are used 
(often < 5ms).

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

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.

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.

Thoughts?

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



More information about the Iccrg mailing list