# Analyzing TCP Performance in High Bit Error Rate Using Simulation and Modeling
## 5 Discussion and Interpretation of Results
### Congestion Avoidance  
The previous section explained that the file transfer needed a longer time because of the retransmission of the dropped packets. It also showed that the retransmission only accounts for a small amount of the additional time the file transfer needed in the scenario \(p_{drop}=1\%\) compared to the scenario \(p_{drop}=0\%\). This section focuses on the TCPcongestion avoidance mechanism and shows how the mechanism is responsible for the rest of the additional time needed in the scenario \(p_{drop}=1\%\).  
With segment (309), the server enters the congestion avoidance phase. RFC 5681 [6] defines two possibilities of fast expansion of _cvond_ for a TCP host. The first option is to expand _cvond_ by byte-acknowledged \(N\) or by one _MSS_.  
\[cvnd+=min(N,\ MSS) \tag{16}\]  
The second expansion option is:  
\[cvnd+=\frac{MSS\times MSS}{cvnd} \tag{17}\]  
Both formulas can be used by a TCP implementation. Table 9 shows the theoretical increase with a start value of three _MSS_ based on (17). The second column shows the results in bytes, and the third column shows results in the number of _MSS_.  
After 14 RTTs, the _cvond_ should again reach _rvond_ (8760 bytes or six MSS). The actual traffic capture shows a slightly different image. During 15 RTTs, the server keeps sending three segments, and the client replies with an ACK. Following that, the server sends nine times alternately four and five segments, which are acknowledged by the client. Then the server starts again by sending the full _rvond_ of six MSSs.  
Overall, the TCP connection in the _virtualized environment_ needs 27 RTTs to recover from one packet drop. In these 27 RTTs, only 98 segments are transmitted. With a _cvond_ equal to the _rvond_ (which would be the case without packet drops), the server would have sent 162 segments at the same time. Consequently, the server must transmit the other 64 segments later. The server transmits six segments per RTT. Accordingly, the server will need 10.67 RTTs or, based on an RTT of 0.04 s, 0.4268 s longer because of the one packet drop.  
In the scenario \(p_{drop}=1\%\), 68 segments should have been retransmitted. This adds up to 29.02 s, which is the additional time overhead required by the server to transfer the file to the client because of the packet drops. This is in the same range of time as the FTP download in the scenario \(p_{drop}=1\%\) (see Table 4) in the Riverbed simulation.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**RTT** & _Cvond_ (Bytes) & _Cvond_ (No. of _MSS_) \\ \hline
0 & 4380 & 3 \\ \hline
1 & 4867 & 3 \\ \hline
2 & 5305 & 3 \\ \hline
3 & 5707 & 3 \\ \hline
4 & 6080 & 4 \\ \hline
5 & 6431 & 4 \\ \hline
6 & 7762 & 4 \\ \hline
7 & 7077 & 4 \\ \hline
8 & 7379 & 5 \\ \hline
9 & 7667 & 5 \\ \hline
10 & 7945 & 5 \\ \hline
11 & 8214 & 5 \\ \hline
12 & 8473 & 5 \\ \hline
13 & 8725 & 5 \\ \hline
14 & 8969 & 6 \\ \hline \hline \end{tabular}
\end{table}
Table 9: _Cvond_ increased per RTT.  
Figure 3 shows that the server is not able to scale-up the congestion window because of the dropped packets. This indicates that the issue is not only related to the number of dropped packets, but it is also an important issue the way TCP handles packet drops and scales down the window.