🚀 go-pugleaf

> > You have to look at typical data streams.  The MAX ratio of data packet to Ack is 23:1,
> > because an Ack is 64 bytes and a max size Ethernet Packet is 1500 bytes, and of course
> > you'll average significantly less than that..  It doesn't matter anyways, because the TCP
> > receive window is set to send Acks based on the number of bytes received, not the number
> > of packets.
>
> 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.

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

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

--

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.

Randy S.