22.11.2014 Views

Understanding TCP/IP Model Internals and Interfaces

Understanding TCP/IP Model Internals and Interfaces

Understanding TCP/IP Model Internals and Interfaces

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

1508 <strong>Underst<strong>and</strong>ing</strong> <strong>TCP</strong>/<strong>IP</strong> <strong>Model</strong> <strong>Internals</strong> <strong>and</strong> <strong>Interfaces</strong><br />

Results Analysis<br />

Congestion Window<br />

Examine <strong>TCP</strong> Connection.Congestion Window Size (bytes) graph to answer the following.<br />

To get an exact value, position your mouse in the desired region, <strong>and</strong> read the tooltip for the Nearest<br />

Point:<br />

1. What was the congestion window size before the packet loss was detected? ___________<br />

2. What did the congestion window size value change to after detecting packet loss? _________<br />

3. Why did the congestion window keep increasing after the loss was detected? ___________<br />

4. Why did the congestion window stay flat for a large period? ___________<br />

5. How did the server recover from packet loss—using fast retransmit or timeout retransmission?<br />

______________<br />

6. How many times was a slow start performed during the session lifetime? ___________<br />

Retransmission Pattern<br />

Examine sequence number of forwarded <strong>and</strong> dropped segments graph to answer the following.<br />

To get an exact value, position your mouse in the desired region <strong>and</strong> read the tooltip for the Nearest<br />

Point.<br />

7. How many segments were retransmitted? ___________<br />

8. Were any segments retransmitted unnecessarily? ___________<br />

9. When was the last segment sent? ___________<br />

Detailed Analysis (Homework)<br />

The size of the congestion window just before fast retransmission was 12,864 bytes. The congestion<br />

window after fast retransmission is reset to<br />

12,864 / 2 + 3 * MSS = 6,432 + 3 * 536 = 8, 040<br />

Note: In this calculation, when the congestion window is halved, it is rounded down to an integral<br />

multiple of the MSS. In this example, 12,864 is 24 * 536, the result of the division is also an integral<br />

multiple of the MSS. If the window had been 23 * 536 = 12,328, then the result would be 11.5 *<br />

536 = 6,164, which must be rounded down to 11 * 536 = 5,895.<br />

The sender then continues receiving more duplicate ACKs <strong>and</strong> increases its congestion window by<br />

one MSS for each ACK. At time 1.086 seconds, the ACK for retransmitted segment 23 takes the<br />

server out of fast recovery <strong>and</strong> the congestion window is set to half of the pre-fast retransmission<br />

value. The sender then receives 3 duplicate ACKs for segment 26 <strong>and</strong> resends segment 27 using the<br />

fast retransmission algorithm. However, because the server does not receive more ACKs, its<br />

congestion window could not increase further. To be able to send more data, it has to wait for the<br />

retransmission timer to expire. This increases application response time considerably.<br />

CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.<br />

© 2010 OPNET Technologies, Inc.<br />

18

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!