Re: [aqm] Draining queues

[[e-mail]]

Joe's right, at least historically: Once upon a time, one of the problems the "receive window" was thought to solve was operating systems that had very, very long response times and expensive process switching, so there was some benefit for the endpoints in "batching" up lots of data before sending and before receiving.
 
One way to think of this is that the bulk of the queueing delay on an end-to-end basis was spent with the packets sitting in operating system buffers, so one could optimize cost of process switching and/or deal with time quanta on the order of 50-100 msec. in the endpoint schedulers.  It was especially true in the days when the dominant content was "character-at-a-time" remote logins and the user could type much faster than the remote system could echo.
 
Such systems may still exist - multiprocessing systems where processors are kind of slow, memory is relatively free, etc.
 
I've never been sure that making TCP's design include these endpoint-buffering features was a good idea, since it encouraged managing the end-to-end flow with an incredibly slow and variable control response.
 
Put this kind of buffering in the layer above TCP, at least in a logical sense, by not counting these buffers as part of the "window".  Then you never end up letting the TCP window get big just because the recipient needs buffering to cover for its weak process scheduler. It's a *transmission* control protocol, not an Operating Systems workload scheduling protocol.
 
-----Original Message-----
From: "Joe Touch" <[e-mail]>
Sent: Wednesday, March 20, 2013 12:40pm
To: "Scheffenegger, Richard" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "John Leslie" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [aqm] Draining queues




On 3/20/2013 9:31 AM, Scheffenegger, Richard wrote:
> ECN by itself is only part of the solution (and there are discussion to
> achieve more accurate ECN feedback in TCP, for a number of reasons), ECN
> can not live without a proper AQM, and a responsive (!) transport protocol

Don't forget a decent scheduler and polling-based processing too; 
latency reduction is a systems issue, not just a networking one.

Joe