How would the chart change with different implementations, or what is the assumption(s) regarding Reno that might not be true of other implementations?
Hi Kevin,
Thanks for your patience.
1) Get latest tool
Please download the latest version of the tool.
We just updated the TCP analysis tool extensively. The latest version of this tool can be found at
www.unleashnetworks.com/articles/tool-tcp-stream-analysis.html . The new version includes better handling of retransmission timeout and a new SSTHRESH chart. The old version was showing inaccurate congestion charts in a lot of cases.
2) TCP Reno for the Congestion Chart
We assume that the TCP implemented is \"plain reno\". The congestion control algorithms are as specified in RFC2581 \"TCP Congestion Control\"
www.faqs.org/rfcs/rfc2581.html. The retransmission timer must be calculated as per RFC2988 \"Computing TCPs Retransmission timer\"
www.faqs.org/rfcs/rfc2988.html
3) Assumptions about TCP Reno
In addition to the algorithms specified in (2), the tool makes the following assumptions.
- During the Fast Recovery phase (ie after a Fast Retransmit when 3 Dup Acks are received ), ssthresh is set to cwnd/2 instead of FlightSize/2. The side effect of this is the value of cwnd may in rare cases appear to be larger than it actually is during the FR phase. If the receiver advertised window (blue line) in the window chart is quite large, this assumption will not have any effect.
- The tool is extremely conservative about using samples for RTT calculation. This is partly because we always assume delayed acks are present.
- We assume both TCPs use delayed ACKs (ack once every two segments and do not delay beyond 500ms).
- b]The big one[/b We assume that 3 duplicate acks are used to trigger fast recovery. In other words, if we see 1 original ACK + 3 duplicates (i.e 4 identical ACKs in a row), we enter FR mode. This is what is specified in RFC2581 (Sec 3.2). The most notable violation of this is Windows 2000/XP/2003 clients and servers. Windows 2K/XP/2K3 enter FR when it sees 1+2 duplicates by default. See the Microsoft Article 224829
support.microsoft.com/default.aspx?scid=kb;EN-US;q224829
This could have a significant impact on the congestion chart! The TCP analysis tool will enter Fast Recovery only when it sees 1+3 dupacks, while in reality the MS Windows 2K/XP sender will enter FR after 1+2 dupacks. To work around this you have to change the following line (in the anastm.rb file)
from
[code:1]DUPACK_CNT=3 # num dup acks...[/code:1]
to (use for Microsoft Windows 2K/XP/2K3)
[code:1]DUPACK_CNT=2 # num dup acks...[/code:1]
To summarize, if your TCP sender is a windows box set DUPACK_CNT=2 in the anastm.rb script and you will get more accurate results.
4) NewReno and BIC-TCP
These are two other TCPs around. NewReno (Windows Vista) is used when SACKs are not available (most implementations do have SACKs!). We have not seen this tool in action with a NewReno implementation, but we expect that in the presence of multiple lost segments NewReno will scale up cwnd much more quickly than plain Reno. This chart may show a slower increase of cwnd.
BIC-TCP is used by many high speed LANs. BIC-TCP the slow start algorithm increases cwnd logarithmically instead of exponentially. This tool does not support this implementation.
Thanks,
Vivek
Unleash Networks
