Cell Relay Archive

[Jim Jackson <jj@scs.leeds.ac.uk>]

On Mon, 24 Apr 1995, Fahad A Hoymany wrote:

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

Other problems exist at the TCP buffering stage to do with TCPs MSS 
calculation from the network MTU etc. With widely differing send and rcv 
buffers sizes pathological behaviour can be seen. An excellant over view
of the problem (and a good tutorial on the workings of modern TCPs) is in 
a paper "How a Large ATM MTU causes deadlocks in TCP data transfers" by 
Moldeklov and Gunningberg. Not sure where it was published, but the copy 
I was sent by one of the authors is at

  ftp://scs.leeds.ac.uk/atm/doc/tcp-deadlock.ps

There are situations when using NODELAY dramatically improves performance!

Jim Jackson
Leeds ATM Lan Pilot