Hi, I have a question about the behaviour of Slow Start when ACKs come
back from the receiver are accumaltive. In Kurose & Ross pg 269 they
say the congestion window is opened for each ACK by the size of the MSS
for each ACK. In the case of an ACK coming back that is accumative does
the same behaviour hold? If an ACK is for multiple segments that are
larger than the MSS will the openning of the CongWindow still only be a
single MSS?

Thanks

niclane@oakcom.co.nz wrote:
> Hi, I have a question about the behaviour of Slow Start when ACKs
> come back from the receiver are accumaltive. In Kurose & Ross pg 269
> they say the congestion window is opened for each ACK by the size of
> the MSS for each ACK. In the case of an ACK coming back that is
> accumative does the same behaviour hold? If an ACK is for multiple
> segments that are larger than the MSS will the openning of the
> CongWindow still only be a single MSS?

I suspect it depends entirely on the TCP stack, but in general, one
was supposed to be allowed to open the congestion window by one
segment for every segment known to have left the network. There is
also a reasonably recent (in RFC if not Internet time development
called "apropriate byte counting" that suggests some things to change.

That the RFC's discuss congestion windows in terms of byte counts
rather than packets seems to be an unfortuneate consequence of most
stacks in existance around the time of VJ's first work only knowing
how many bytes they had outstanding and not number of packets...

The "ABC" RFC was written to address issues where stacks would
increase their byte-based cwnd by one MSS for every ACK. That
suggests such stacks were/are common. That RFC was concerned more
with avoiding a situation where a malicious receiver might send
"sub-MSS ACKs" to induce a sender to open their cwnd faster than
the authors believed apropriate.

As for stacks which "stretch/avoid/cumulate" ACKs with which I have
familiarity, when the receivers presume the sender is in slow-start,
they try to send ACK's with sufficient frequency to allow them to open
their byte-based cnwd's without undue delay. Most RFC authors do not
seem to like the idea of stretched or avoided ACKs, worrying more
about "burstiness" than the observation that in this day of ChecKsum
Offloading NICs, Copy Avoidance and TSO/LargeSend those ACKs are a
rather non-trivial chunk of the CPU overhead in a bulk transfer. A
chaque un son gout I suppose.

rick jones

But then I'm not all that fond of resetting the cwnd on idle
either... it feels like belt, suspependers and a pants-upholding
assistant all at the same time

--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...