Cell Relay Archive

[craigp@world.std.com (Craig Partridge)]

I didn't see a post that explicitly answered Scott Weberg's questions
about TCP, so here's my take:

> But I still don't know what the "TCP window size" is - and how it is
> set.

Formally speaking, the "TCP window size" is the maximum amount of unacked
data that the sender can have outstanding.  So if the window size is W
and the last acked byte is A, the sender can send bytes A+1 through
A+W (TCP tracks bytes, not packets) but must then stop sending until
it hears an ack back from the receiver.

It affects throughput in the following way.  If the window size W is less
than 2*delay*bandwidth product between sender and receiver, TCP will
not fill the link.  The delay*bandwidth product is the transmission
delay from sender to receiver times the bandwidth of the channel.  So,
for instance, OC-3c (about 139 Mb/s after SONET and ATM overhead) across
a continent (say 60 ms of transit time) has a delay*bandwidth product of
139 * 0.060 = 8.3 Megabits or a little over 1 MB.  So if the window
size is less than 1 MB, a single TCP won't fill the link.

As several folks have noted the SOL_SNDBUF and SOL_RCVBUF options set
the window size options.  Critical here is that TCP negotiates the
window size at setup time and picks the MINIMUM of the sender's offered
window size (SNDBUF) and the receiver's max window size (RCVBUF).
So both sender and receiver must request a large enough window size.

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

The TCP_NODELAY option does not help, and in most situations will hurt,
since it allows TCP to send runt sized segments (rather than always
trying to send max sized segments, which is more efficient).

Craig
craig@bbn.com