There is one condition where the congestion window size being small
can cause tcp retransmissions.
Normally a TCP stack will send an ACK immediately upon receiving two
full sized segments.
Some stacks vio9late this rule and implement so called "stretched
ACKs" where they change the rules
to only send an ACK upon receiving n (n >2) segments.
This can lead to a host sending two full sized segments to that
station, and then pausing since it might have filled its congestion
window of 2 full sized segments.
The sending host pauses waiting for an ACK, the receiving host
doesnt send an ACK immediately but instead does a Delayed ACK.
IF the delayed ACK timeout of the receiving host using stretched ACKs
is higher than the retransmission timeout of the sending host, then
the sending host will timeout first and do a TPC retransmission.
Stretched ACKs are a really stupid and clueless idea for this reason
since it breaks TCP.
Most sane stacks dont do stretched ACKs.
Also, you cant modify the congestion window size. This window size is
managed and updated dynamically inside the stack.
You can modify the maximum window size, but that is a completely
different window.
On Dec 22, 2007 12:52 AM, Feeny, Michael (GWM-CAI) <michael_feeny@xxxxxx> wrote:
>
>
>
>
> Hello.
>
> This may not be a Wireshark question – it is really a TCP question. To that
> end, if there is a good TCP forum to which I should post this, and similar
> questions, please let me know.
>
> Recently, there have been 2 occasions where colleagues have seen
> retransmissions occurring, and they have been blaming this on the TCP Window
> Size being too small, and want to increase it. My response is:
>
> - If the TCP Window size was too small, they would see conditions
> where the receiver's window size goes to zero (or very small), and the
> sender stops sending until a window update is received showing a bigger
> window size. They are NOT seeing this.
>
> - I cannot think of a scenario where a too-small TCP Window size would
> cause retransmissions. (Can anyone in this forum???)
>
>
>
> Can anyone comment on my assertions? And, can you point me to a good TCP
> forum?
>
> Thx much!
>
> Michael Feeny
>
> Merrill Lynch
> ________________________________
>
> This message w/attachments (message) may be privileged, confidential or
> proprietary, and if you are not an intended recipient, please notify the
> sender, do not use or share it and delete it. Unless specifically indicated,
> this message is not an offer to sell or a solicitation of any investment
> products or other financial product or service, an official confirmation of
> any transaction, or an official statement of Merrill Lynch. Subject to
> applicable law, Merrill Lynch may monitor, review and retain
> e-communications (EC) traveling through its networks/systems. The laws of
> the country of each sender/recipient may impact the handling of EC, and EC
> may be archived, supervised and produced in countries other than the country
> in which you are located. This message cannot be guaranteed to be secure or
> error-free. This message is subject to terms available at the following
> link: http://www.ml.com/e-communications_terms/. By messaging with Merrill
> Lynch you consent to the foregoing.
> ________________________________
>
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
>
