TCP Window problem

[mikebw@bilow.bilow.uu.ids.net (Mike Bilow)]

I'm going to post my reply to the TCP-Group list, since I think this will be
instructive for everyone, and possibly even for someone who wants to fix the
problem in the source code.  :)

 k>     Let me make sure we're on the same page. You say that the window size 
 k> is always set by the information receiver. I assume that the NNTP Client 
 k> would be the information receiver... correct?

No, the TCP circuit is bilateral and has independently negotiated parameters in
each direction.  The idea of the window is that each side says, "When sending
me data, don't send more than x bytes to me before stopping and waiting for me
to send ACK."  This allows each side to limit the amount of data coming in when
receiving, and x in each direction can be negotiated differently.

 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.

 k> Finally... you said
 k> that you think I found a bug. A bug in JNOS or a bug in the RFC?

I mean a bug in NOS.  Heaven forbid that there should be a bug in the NNTP RFC.
 It was written by Brian Kantor.  :)

 k> It seems
 k> to me that even if JNOS sends 30K in MTU size buffers... it should/could
 k> free the MTU size buffer as soon as it's sent.

No, that's impossible.  When window bytes of data are sent, they have to be
retained by the sender until they are ACKed.  That's the whole point of window
in the first place: it's the amount of data that can be sent before ACK is
required.  If the ACK doesn't arrive, then the sender has to resend the data,
and it has to keep this in memory so that it can do so.

 k> OR does JNOS get a TCP 
 k> Window size buffer? Need to look at that. Anyway... I'd like to get this
 k> fixed. It's screwing up my NNTP code. Thanks.

It's really just a stupid bug.  Think of it as a kitchen in a restaurant.  You
generate an amount of garbage every day.  At the end of each day, you have a
garbage truck come and pick it up.  The garbage truck is "window" size.  It is
very important that you know how big the garbage truck is so that you don't
overfill it.  If you know that you have more than "window" garbage, you are
going to have to wait for the truck to come back and haul a second load.  The
TCP protocol has all sorts of elaborate negotiation to make sure that the
garbage truck is not overfilled.

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.

Does this make more sense now?

-- Mike