[Iccrg] congestion control and visability to the user

[Michael Welzl]

On Mar 30, 2010, at 5:59 PM, Mikael Abrahamsson wrote:

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

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.

The bandwidth may not be at that magnitude in today's residential
broadband links, but delays can easily have 100ms or more.


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

Tens of ms of RTT isn't much. I just wonder how you can make
a statement like "access links are always saturated (in your
neck of the woods)" when we're talking about the Internet,
not just Sweden, and you can't really know what's happening
beyond the scope of your ISP.


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

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.

Also, here:

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

we just agree.

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

Cheers,
Michael