Re: TCP Window problem

["Louis A. Mamakos" <louie@alter.net>]

>  k> It initiates the conversation
>  k> with the NNTP Server and says that it has a 30K TCP Window. The NNTP server
>  k> says OK to the clients connect request and responds with I have a 4K TCP 
>  k> Window. The NNTP server then starts sending TCP Window ( client ) size 
>  k> chunks of data that are MTU bytes in size. The NNTP Client will send stuff
>  k> in TCP Window ( server ) size chunks. This ok so far?
> 
> Yes, except that MTU has nothing to do with this except in terms of efficiency.
>  The window is the amount of data that can be sent without ACK.  The mss is the
> amount of data that can be sent in one IP datagram, not including the headers. 
> It is good practice to make window an integer multiple of mss.  MTU is the
> number of bytes that can be sent on an interface including the IP header, so
> you usually want mss no larger than MTU plus the size of the IP header (40
> bytes).  If mss is larger than this, you get IP datagrams fragmented at the
> interface level to fit in MTU.

It's usually not necessary to worry too much about making the window
some integer multiple of the MSS.  TCP will try really hard to not
send partial segments which not a whole MSS in length.  There is a
simple algorithm called Nagle's algorithm (after John Nagle) which
says that you while you have outstanding un-acked data, you won't send
a partial segment.

In practice, the TCP stack will conspire with the IP code to find out
what the MTU of the interface is.  Later versions of TCP can use Path
MTU discovery to adjust their MSS to prevent fragmentation.

> However, you have the opposite situation.  When the garbage truck arrives, it
> is so darned huge that there is no way you could ever actually fill it up,
> because you simply don't have that much garbage.  How do you handle this? 
> Well, the common sense thing would be to just throw in what you have and send
> the truck on its way mostly empty.  But, in fact, you decide to put the kitchen
> staff on overtime, working at a frenetic pace, to make enough garbage each day
> to fill the truck.  The TCP protocol doesn't really address this, because it is
> just so dumb that no one would expect you to do it.

This is actually what Nagle's algorithm does.  There's also another
bit of optimization you can do to control when you send ACKs to avoid
Silly Window Syndrome (SWS).  Here's the deal: you send a bunch of
data, and the other side receives and acks it.  But the process on the
remote system doesn't read any of the data, so TCP has to buffer it.
There is a finite limit to the amount of data it buffers, so to
control this, the remote TCP returns an offered window which is how
much data the TCP is willing to accept.

The optimization comes in here: when do you send an ACK?  If the
process reads one byte, do you then send a spontanous ACK advertising
a 1 byte window?  Probably not, because this can cause a stream of
"tiny" ACKs.  Generally, the TCP will only send an ACK when the window
opens by some moderate fraction of the maximum local received window
size, or some multiple of the MSS.

There's a lot of really subtle stuff in there, most of it discovered
the Hard Way.

Ask Phil to tell you about Karn's algorithm one day, probably the most
"real" contribution to the state of the art that Amateur Packet Radio
experimentation has made.

Louis A. Mamakos, WA3YMH                      louie@alter.net
Backbone Architecture & Engineering Guy       uunet!louie
AlterNet / UUNET Technologies, Inc.
3110 Fairview Park Drive., Suite 570          Voice: +1 703 204 8023
Falls Church, Va 22042                        Fax:   +1 703 204 8001