🚀 go-pugleaf

"Randy S." wrote:
> 
> > > 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.

That's the first time I've seen it described that way.  That
would eliminate one of the benefits of the sliding window.
i.e. retransmitting only from the first unack'd packet. 
According to this description, you'd have to send the entire
block of data again

  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.

Here's what it says in "Internetworking with TCP/IP vol 1,
Douglas Commer (1991). pg 176.

"Technically, the number of packets that can be
unacknowledged at any given time is constrained by the
window size and is limited to a small fixed number.  For
example, in a sliding widnow protocol with a window size 8,
the sender is permitted to transmit 8 packets before it
receives an acknowledgement.

As Figure 12.3 shows, once the sender receivesan
acknowledgement for the first packet inside the window, it
"slides" the window along and sends the next packet.  The
window continues to slide as long as acknowledgements are
received."

Later in the chapter he explains that TCP/IP uses sequence
numbers, not packet numbers in the sliding window.  Until
your message, I had never (to my knowledge) read about
waiting for the entire window to be sent before acking.


-- 
Replies sent via e-mail to this address will be promptly
ignored.
To reply, replace everything to the left of "@" with
"james.knott".