🚀 go-pugleaf

[POSTED TO comp.dcom.modems.cable; PLEASE REPLY THERE]

With all due respect, I think you're misinterpreting what you are
reading.  ACK's are cumulative, but in practice, Lawrence Baldwin is
essentially correct.  Here's a small sample FTP download with a very
large Receive Window (65535):

   02-03-2001 09:59:06.90 - Bytes Received         288231
   02-03-2001 09:59:06.90 - Bytes Transmittted     7948
   02-03-2001 09:59:06.90 - Frames Received        546
   02-03-2001 09:59:06.90 - Frames Transmitted     345

In <3A7C39C0.AC977793@ufl.edu>, "Randy S." <rswitt@ufl.edu> 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.

You're forgetting Header Compression.

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

-- 
Best regards,
John Navas     <http://navasgrp.home.att.net/>
     CABLE MODEM/DSL GUIDE:  <http://Cable-DSL.home.att.net/>