Cell Relay Archive

[jkay@isis.com (Jon Kay)]

In article <D7JsLK.78y@world.std.com> craigp@world.std.com (Craig Partridge) writes:
> craigp@world.std.com (Craig Partridge) stated:
> In general, if you care about throughput, you should always ask for
> the largest possible window size, since TCP will dynamically adapt if
> the link cannot handle that much data.  (Using the Jacobson work mentioned
> in other postings).

I have recently been forced to the realization that this is not true.
When I was still a student, I recommended use of a window size as
large as 256k to users of 'netconfig'.  I don't think it's a BAD
recommendation...just a tad naive.

Let's say you set your socket buffer to 256k and, through a miracle of
TCP dynamics, the TCP window size actually reaches that size in normal
use and you have that much outstanding data.  If this conversation is
traveling over Ethernet (remember, chances are it is), any packet that
you write can experience a delay of up to 200 milliseconds before it
makes it to the network.  200 milliseconds is an absolute eternity in
networking terms, awful performance.  If the app has any interactivity
at all, the user will feel this as outright unresponsiveness.

Usually, of course, it makes no difference.  Most apps don't burst
that much, and you're probably going to overrun the interface queue
before you reach that point anyway (though even the ifq would allow
you to buffer up 60 ms of data, which is noticeable if not
disastrous).

							Jon