🚀 go-pugleaf

Packetboy wrote:
> > Not true, Randy.  You will generally see TCP send 1 ACK for every 2
> > packets received (this is a general recommendation in the RFC that most
> > stacks follow).  If the
> > incoming stream is REAL fast there may be less, but for ADSL I'd think
> > it would always be 1:2.

"Randy S." wrote:
> 
> Ok, I've always thought what you're saying was correct, but the reference books I have been
> looking at recently seem to say differently.  From the Cisco Internetworking Technologies
> Handbook, Second edition, pg 447:
> 
> "In TCP the receiver specifies the current window size in every packet.  Because TCP provides a
> byte-stream connection, window sizes are expressed in bytes.  This means that window is the
> number of data bytes that the sender is allowed to send before waiting for an acknowledgement.
> Initial window sizes are indicated at connection setup but might vary throughout the data
> transfer to provide flow control.  A window size of zero, for instance, means "Send no data."

Yes, this is a correct statement...you are just mis-interpreting it.

Window size controls how much *DATA* a SENDER is allowed to send (before
requiring RECEIPT of an ACK).
Receive window size has no direct bearing on when the RECEIVER actually
SENDS the ACKs...this a different part of the RFC.

(which for the life of me I can't find...and you made me look).

> 
> In a TCP sliding-window operation, for example, the sender might have a sequence of bytes to
> send (numbered 1 to 10) to a receiver who has a window size of five.  The sender then would
> place a window around the first five bytes and transmit them together.  It would then wait for
> an acknowledgment.  The receiver would respond with an ACK=6, indicating that it has received
> bytes 1 to 5 and is expecting byte 6 next.  In the same packet, the receiver would indicate
> that its window size is 5.  The sender then would move the sliding window five bytes to the
> right and transmit bytes 6 to 10.  The receiver would respond with an ACK=11, indicating that
> it is expecting sequenced byte 11 next.  In this packet, the receiver might indicate that its
> window size is 0 (because, for example, its internal buffers are full).  At this point, the
> sender cannot send any more bytes until the receiver sends another packet with a window size
> greater than 0."
> 
In reality the window "slides" in 2-segment increments.
> 
> Nowhere can I find a reference to a situation where ACKs are tied to the number of packets.  I
> could easily be missing something here, or it could be that some other rule applies that is not
> directly tied to TCP.

W. Stevens, TCP/IP Illustrated.

I can't find the specific RFC where this is described (although I know
it is discussed by Nagle in his RFC).