[Iccrg] congestion control and visability to the user

[Mikael Abrahamsson]

On Tue, 30 Mar 2010, Michael Welzl wrote:

> How can you be so sure? The longer the delay, and the greater
> the bandwidth, the harder it gets for standard TCP to saturate the
> bottleneck. See the abstract of RFC 3649 (2nd paragraph), which
> lays it out quite nicely - what do you think of this, is it unrealistic,
> or wrong in your opinion?

I don't get it. First people here are talking about their residential 
broadband and I answer to that, next I get a reference to a 10 gigabit/s 
transfer in single session and ask if I think that is true. What problem 
are we discussing really?

> Surely, like everyone else I know, you have once downloaded
> something from some sever somewhere on the net
> at much less than your internet connection's speed - then, how do
> you know where the bottleneck comes from - is it a slow access
> link of the server, or the server itself being slow, or TCP not
> saturating the bottleneck (wherever it is) well? How would you know?

Because I work for an ISP and I have a pretty good idea about what's going 
on. In my local "ecosystem" I regularily saturate my 100 megbait/s 
residential connection by communicating with other hosts in Sweden. This 
is with tens of ms of RTT. I've had to implement fair-queue and all on my 
connection because with FIFO I get 100-200ms buffering and I'm not 
interested in that affecting my SSH/web sessions.

> There's nothing expensive to an ISP about changing congestion control 
> functionality in end hosts.

No, but it'll be quicker.

> There's nothing expensive to a vendor of an ADSL modem about
> changing congestion control functionality in end hosts.

No, but it'll be quicker.

I don't see end host congestion control functionality working well around 
FIFO buffering with 200ms max buffer, at least not anywhere near what can 
be done in the unit actuallly duing the buffering.

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