Cell Relay Archive

[fahad@cs.pitt.edu (Fahad A Hoymany)]

On (Mon, 24 Apr 1995 16:32:07 GMT) Craig Partridge at (craigp@world.std.com) wrote:

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

 .... stuff deleted .....

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

 Craig,

   I agree with your description but I don't think the sender window has
   anything to do with the receiver's window.  That is, there is no 
   negotiation to determine the window size, every end advertises its own
   window.  So, it is very common to see a sender's window of 4KB and a 
   receiever's window of 2KB.  There is no problem here.

   The problem with the window size goes right down to the length of the
   window field in the TCP header.  Currently this is a 16-bit field, which
   means that you cannot advertise a window of size larger than 64KB! The
   trick used in some TCP implementation is to scale this field by using
   a scale factor stored in the options field.  So, you get as large as
   2**30 bytes, which is enough to support any high-speed links.

'hope that helps

Fahad