# Analyzing TCP Performance in High Bit Error Rate Using Simulation and Modeling
## 5 Discussion and Interpretation of Results
### Packet Drop and Retransmission  
Figure 10 shows the packet exchange for the scenario \(p_{drop}=1\%\) around the first packet loss until the packet is retransmitted. The graph is based on traffic captured in the _virtualized network environment_, used to verify the results, and not on the Riverbed simulation. It was captured on the client-side. Therefore, the packet order on the server side does not necessarily represent the correct sequence.  
In Figure 10, the numbers on the left-hand side are timestamps in seconds. Numbers on the left-hand side in round brackets are frame numbers as they were recorded. Numbers on the right-hand side in square brackets count the segments sent without an ACK received, and in curly brackets are the numbers of ACKs received for the same sequence number.  
Before the first segment was lost, the server reached the receiver's advertised window (_rwnd_) of 8760 bytes (six segments' of 1460 bytes) with a slow start. The server was sending six segments when the fifth segment (between 292 and 293) was dropped. The client immediately replied with an ACK (294) as defined in RFC 5681 [6]. Because the FTP client did not have a chance to read the data from the TCP receiving buffer (289-292), the client set the receiving window to 2920 bytes. Shortly after, the FTP clients read the data and the client sent a TCP window adjustment (295) to open the window again.  
After receiving the ACK (294), the server sent another four segments to the client and filled the window with six segments 1-6. The first three segments 3 to 5 were sent almost at the same time. The figure might be a bit misleading here. For easier reading, the figure has been stretched to avoid overlapping arrows. Many packets were sent almost simultaneously. The packets sent from the server and the client crossed each other somewhere between the two systems.  
Because the client was missing the segment with sequence number 321,201, the client kept sending ACKs for sequence numbers 1-4. When the server received the fourth ACK (or the third duplicated ACK), it went into fast retransmission [6] and retransmitted the segment (303). Again, the figure might be misleading. The third duplicated ACK was received by the server around 2.468 (sent time plus half of RTT), and the packet was retransmitted around 2.473 (arrival time minus half RTT).  
When the next (new) ACK (305) was received, the congestion window (_cwnd_) was set to slow start threshold (sstthresh). In this case, it is set to three _MSS_ or 4380 bytes. The server then sent two additional segments (306, 307) and the client acknowledged them (308).  
Between the first segment (280) arriving at the client and the last segment (307) arriving at the client, 0.132977 s passed, which is roughly three RTTs (0.042 s). During this period, 12 segments were sent to the client. Without a packet drop, 18 packets would have been sent to the client (three times the full window size) at the same time. In other words, each packet drop led to a delay of one RTT. This is exactly what anyone unfamiliar with TCP would expect. Unfortunately, it does not account for all the additional delays observed in the scenario \(p_{drop}=1\%\).