1508
Understanding TCP/IP Model
Internals and Interfaces
CONFIDENTIAL — RESTRICTED ACCESS:
This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
1508 Understanding TCP/IP Model Internals and Interfaces
Lab 1: Tracing TCP Connection
Background
•
TCP uses a 3-way handshake to open connections
•
TCP performs a slow start at the beginning of connection
•
TCP uses a 4-way handshake to close connections
Objective
Our goal is to observe the typical lifecycle of a TCP session. We will use OPNET Debugger (ODB)
to help us trace and understand TCP behavior. We are interested in seeing how the TCP model
•
establishes a connection
•
sends data during slow start
•
terminates connections
Network Model
Network Description
The workstation (“client”) downloads a 5,000-byte file from the “server” node. The traffic is sent
over Ethernet with MTU set to 1,500 Bytes.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
1
1508 Understanding TCP/IP Model Internals and Interfaces
Main Steps
•
Examine network configuration
•
Enable ODB while running simulation
•
Examine 3-way handshake
•
Examine slow start
•
Examine connection termination
•
Print connection state (homework)
•
Print packet content (homework)
Instructions
Examine Network Configuration
1. Start OPNET Modeler.
2. Open project 1508_lab1. Scenario FTP_5000_byte_download opens. This scenario has been
fully configured for you.
Examine TCP configuration
Both client and server are running on Windows 2000. Check that TCP Parameters attribute on
both is set to Windows 2000. Please contact one of the TAs if you do not know how to do
this.
Examine server settings
3. What is the Slow Start Initial Count (MSS)?
__________
4. How many TCP segments will be sent after the connection is established?
__________
5. What is the TCP Maximum Segment Size?
__________
Hint 1: By using the Auto-assigned symbol, we are asking TCP to calculate TCP MSS based on
the MTU of the lower layer, which is Ethernet. Ethernet MTU is 1,500 Bytes.
Hint 2: The size of the TCP header is 20 bytes, and the size of the IP header is 20 bytes.
Examine application configuration:
Client is downloading data from the server.
6. Verify that the file size is 5,000 Bytes. This is set on the Application Configuration object, in
attribute Application Definitions->File Transfer - 5000 Bytes -> Description -> FTP -> File
Size (bytes).
7. How many TCP data segments will be used to send 5,000 bytes if there is no retransmission?
____________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
2
1508 Understanding TCP/IP Model Internals and Interfaces
Examine 3-Way Handshake
Run the Simulation in ODB
1. Click on Configure/Run DES button.
If you do not see the dialog box shown in the screenshot below, click on “Detailed…” to bring it
up.
2. Configure the simulation to run in the ODB.
a. Ensure that Use OPNET Simulation Debugger (ODB) is checked as shown below:
b. Click on the Run button. OPNET Debugger Simulation Console comes up.
c. If you do not see the simulation console in the upper right pane, click on “Console” tab so it
appears.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
3
1508 Understanding TCP/IP Model Internals and Interfaces
3. Set a trace on TCP
a. To set a trace on TCP, type ltrace tcp in the ODB prompt as shown on the above picture and
press Enter.
b. To continue the simulation, click on the Continue button.
c. The simulation now continues and prints TCP-related information.
4. Examine the 3-way handshake. First, scroll up to the first event that gets printed. You can see
that the server opens a connection at time 0.
•
Is this a passive or active connection? How do you know?
_________________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
4
1508 Understanding TCP/IP Model Internals and Interfaces
•
What is the local port number used by the server?
•
At what event did the client’s TCP process receive an OPEN request from the application?
_________________
_________________
5. What are the sequence numbers of the segments comprising 3-way handshake?
a. First segment:
____________
b. Second segment:
____________
c. Third segment:
____________
6. Were any options set in the SYN packets? _________________________________________
Hint: See trace at events 125 and 146.
Examine Slow Start
1. Server’s TCP process then sends its first application data at event 230.
a. How many segments are sent out at the beginning?
___________
b. How is this related to the Slow Start Initial Count from step 3 of the Examine Network
Configuration section?
___________
c. What are the sequence numbers and data length of the first 2 segments?
Sequence number
Length
1st data segment
2nd data segment
2. What should be the ACK number acknowledging the second segment sent from client?
___________
3. Is this the same as the ACK number sent at event 276?
___________
4. How many more segments did the server send before closing a connection?
___________
5. How many bytes of data did the server send?
___________
6. What was the actual Maximum Segment Size?
___________
7. Is the number of segments sent by the server the same as the one you predicted in step 7 of
Examine Network Configuration section?
___________
Examine Connection Termination
1. Which side starts the connection termination process?
hint: look for FIN segments
___________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
5
1508 Understanding TCP/IP Model Internals and Interfaces
2. At what event did the other side send a FIN segment?
___________
3. At what event was the connection finally closed on the client?
___________
4. At what event was the connection finally closed on the server?
___________
5. Click on Close to close the Simulation Execution window.
END OF LAB 1
Examine Congestion Window (Homework Lab)
We want to determine the final congestion window on the server side before the session was closed.
In step 4 above, we hope you determined that the connection was finally closed at event 458.
Let’s run the simulation again, stop the simulation just before this event and print the congestion
window.
Recall that congestion window is printed from the diagnostic block of tcp_conn_v3.pr.m, so in order
to print the state we will need to get the process model ID of tcp_conn_v3.pr.m on the server.
1. Run the simulation in the ODB again following steps 1-2 from the section Run the Simulation
in ODB above. Again, click on the Console tab if you do not see the console.
2. Stop the simulation at event 458:
a. Type evstop 458 in the simulation console window and press the Enter key. This will set a
breakpoint to stop the simulation before event 458 is executed.
b. Type cont in the simulation console window and press the Enter key to run the simulation
until the above breakpoint is reached. Alternatively, you may click on the Continue button.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
6
1508 Understanding TCP/IP Model Internals and Interfaces
3. Get the process ID of the TCP process models on the server.
a. The simulation has been stopped before an interrupt is delivered to the TCP module on the
server. Locate tcp module on the server in the upper left pane:
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
7
1508 Understanding TCP/IP Model Internals and Interfaces
b. tcp_conn_v3 process model is a child process of the tcp_manager_v3 process model. Expand
tcp module (click on + sign) and tcp_manager process (click on + sign) to get a list of TCP
connection process models on the node:
4. What is the process ID of the active TCP process on server?
___________
5. Type prodiag 53 in the Simulation Console to get connection state information just before the
session is closed. You should see the following output:
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
8
1508 Understanding TCP/IP Model Internals and Interfaces
6. At what state is the connection?
___________
7. What is the size of congestion window? (Hint: cwnd variable is used to store the congestion
window)
___________
8. Is there any unsent data in the send or retransmission buffer?
___________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
9
1508 Understanding TCP/IP Model Internals and Interfaces
9. Type cont in the Simulation Execution window or click on the Continue button to let the
simulation complete.
10. Click on Close to close the Simulation Execution window.
Examine Packet Content (Homework Lab)
Client received ACK of SYN (as well as a SYN) at event 172. Let us examine its content.
1. Run the simulation again, and stop it before event 172 is executed, by typing the following in the
Simulation Execution console:
evstop 172
cont
2. You can see that TCP is about to receive a packet with ID = 3. Print the packet content.
a. Click on the Packet Content tab in the lower right pane of the Simulation Execution window
and specify Packet ID as 3. Press the Enter key.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
10
1508 Understanding TCP/IP Model Internals and Interfaces
b. The packet content is printed in the same pane:
3. What is the ACK number carried in the header of this segment?
____________
4. Does the segment contain any data?
____________
5. Are there any flags set in the TCP header?
____________
6. What TCP options does the segment contain?
____________
7. Type cont to complete the simulation. Close all the windows. Close the project.
Summary
You have seen how OPNET Debugger can help you understand the model behavior.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
11
1508 Understanding TCP/IP Model Internals and Interfaces
Lab 2: TCP Flavor Comparison
Background
TCP detects a packet loss when:
•
Retransmission timer expires, or
•
n-th duplicate acknowledgement is received for the connection.
TCP flavors differ in how they respond to packet loss. While all TCP implementations reset the
congestion window after retransmission timeout expiration to one maximum segment size (MSS),
they may proceed differently after duplicate ACKs are received. The missing segment is always
resent immediately, but transmission of new or unacknowledged data depends on the selected flavor.
We will compare the following flavors:
•
Tahoe—Fast retransmit followed by slow start
•
Reno—Fast retransmit followed by fast recovery
•
New Reno—Similar to Reno, but does not halve congestion window multiple times during
recovery process
•
Selective acknowledgement (SACK)—Selective retransmission based on received selective
acknowledgements
•
Reno with Explicit Congestion Notification (ECN) – similar to Reno, but has ability to
process congestion notification from network upon which it performs fast recovery
Objective
We will study TCP behavior after three segments are dropped from the same window of data. The
following graph shows the sequence numbers of sent and dropped segments.
Dropped
segments
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
12
1508 Understanding TCP/IP Model Internals and Interfaces
For each of the modeled TCP flavors, we will examine:
•
Segment retransmission process (the order in which segments are retransmitted)
•
The reason why segments get retransmitted—fast recovery vs. expiration of retransmission
timeout timer
•
Congestion window after drops
We will compare:
•
Application response time
Network Model
Network Description
The workstation downloads a 30,000-byte file from the server. TCP Maximum Segment Size is 536
Bytes. The packet analyzer is used to drop selected segments and collect statistics.
Main Configuration Steps
•
Examine network configuration
•
Configure TCP Reno on hosts, run the simulation, collect and analyze results
•
Configure TCP SACK on hosts, run the simulation, collect and analyze results
•
Run simulation for TCP Tahoe, TCP New Reno and TCP Reno with ECN
•
Compare response time across scenarios
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
13
1508 Understanding TCP/IP Model Internals and Interfaces
Instructions
Examine Network Configuration
The basic configuration is the same across all scenarios. We will be only changing the TCP flavor.
1. Start OPNET Modeler.
2. Open project 1508_lab2; scenario Reno opens. This scenario has been fully configured for you.
3. Examine TCP configuration.
Workstation and server have been configured identically. Open the TCP Parameters attribute
on one of them, and check the following:
a. Receive Buffer is set to 65,535 bytes. Since this value is greater than the size of transmitted
file, the size of the TCP receive buffer will never prevent data from being sent.
b. Maximum ACK Delay is 0.001 sec. This will cause ACKs to be sent almost immediately
after receiving a segment.
c. Maximum Segment Size is set to 536 bytes.
This also implies that congestion window will be increasing in increments of 536 Bytes.
d. Slow-Start Initial Count (MSS) is set to 2 segments.
4. Examine packet analyzer configuration.
The TCP Packet Analyzer node can be used to selectively drop segments and to introduce
additional network delay to the segment. Segments to be dropped are identified by their order
(e.g., first segment, second…) In this lab, three segments (23, 27, and 28) are dropped by the
analyzer_svr_wkstn node.
a. Edit attribute on analyzer_svr_wkstn and observe the following configuration for Segment
Discard List.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
14
1508 Understanding TCP/IP Model Internals and Interfaces
5. Select “DES->Choose Individual Statistics” to open the Choose Results window. Take note of
the selected TCP statistics. We will collect:
•
Application response time
•
Size of TCP congestion window on server
•
Sequence number of dropped and forwarded segments on the traffic analyzer
a. Right-click in the project editor and select
Choose Individual DES Statistics to see the selected statistics.
b. Expand Node Statistics and then TCP Connection.
c. Click on Congestion Window Size (bytes) to see the details.
d. Ensure that the Collection mode is All values.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
15
1508 Understanding TCP/IP Model Internals and Interfaces
Configure TCP Reno on Hosts, Run the Simulation, and Collect Results
1. TCP Reno supports fast retransmission and fast recovery.
a. Fast Recovery has been already enabled on both the workstation and the server by setting
TCP -> TCP Parameters -> Fast Recovery to Reno:
2. Run the simulation.
a. Click on the Configure/Run Discrete Event Simulation (DES) button.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
16
1508 Understanding TCP/IP Model Internals and Interfaces
b. Click Run.
c. When the simulation is completed, click Close to dismiss the simulation window.
3. Load statistics into the provided templates.
There are two statistics that we will analyze further:
•
TCP Congestion Window Size collected on the server
•
Sequence Numbers of TCP Segments that were
o forwarded by packet analyzer
o dropped by the analyzer
The panels for the above statistics have been already created for you.
a. Display the provided templates by clicking on the Hide/Show Graph Panels button.
Two panels should appear.
b. Select “DES->Panel Operations->Reload Data Into All Panels” to reload the panels.
4. You will get the following results:
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
17
1508 Understanding TCP/IP Model Internals and Interfaces
Results Analysis
Congestion Window
Examine TCP Connection.Congestion Window Size (bytes) graph to answer the following.
To get an exact value, position your mouse in the desired region, and read the tooltip for the Nearest
Point:
1. What was the congestion window size before the packet loss was detected?
___________
2. What did the congestion window size value change to after detecting packet loss? _________
3. Why did the congestion window keep increasing after the loss was detected? ___________
4. Why did the congestion window stay flat for a large period?
___________
5. How did the server recover from packet loss—using fast retransmit or timeout retransmission?
______________
6. How many times was a slow start performed during the session lifetime?
___________
Retransmission Pattern
Examine sequence number of forwarded and dropped segments graph to answer the following.
To get an exact value, position your mouse in the desired region and read the tooltip for the Nearest
Point.
7. How many segments were retransmitted?
___________
8. Were any segments retransmitted unnecessarily?
___________
9. When was the last segment sent?
___________
Detailed Analysis (Homework)
The size of the congestion window just before fast retransmission was 12,864 bytes. The congestion
window after fast retransmission is reset to
12,864 / 2 + 3 * MSS = 6,432 + 3 * 536 = 8, 040
Note: In this calculation, when the congestion window is halved, it is rounded down to an integral
multiple of the MSS. In this example, 12,864 is 24 * 536, the result of the division is also an integral
multiple of the MSS. If the window had been 23 * 536 = 12,328, then the result would be 11.5 *
536 = 6,164, which must be rounded down to 11 * 536 = 5,895.
The sender then continues receiving more duplicate ACKs and increases its congestion window by
one MSS for each ACK. At time 1.086 seconds, the ACK for retransmitted segment 23 takes the
server out of fast recovery and the congestion window is set to half of the pre-fast retransmission
value. The sender then receives 3 duplicate ACKs for segment 26 and resends segment 27 using the
fast retransmission algorithm. However, because the server does not receive more ACKs, its
congestion window could not increase further. To be able to send more data, it has to wait for the
retransmission timer to expire. This increases application response time considerably.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
18
1508 Understanding TCP/IP Model Internals and Interfaces
Configure TCP SACK on Hosts, Run the Simulation, and Collect Results
1. Select Scenarios -> Switch to Scenario to switch to scenario SACK.
2. TCP SACK supports fast retransmission and fast recovery.
TCP SACK has been enabled and Fast Recovery has been set to Reno on both the workstation
and the server:
3. Repeat steps 2 through 3 from page 16 to run the simulation, and load results into templates. You
should see the following results:
Results Analysis
Congestion Window
1. What was the congestion window size before the packet loss was detected?
___________
2. What did the congestion window size value change to after detecting packet loss? _________
3. Why didn’t the congestion window change after retransmission? _______________________
______________
Retransmission Pattern
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
19
1508 Understanding TCP/IP Model Internals and Interfaces
4. How many segments were retransmitted?
___________
5. Were any segments retransmitted unnecessarily?
___________
6. When is the last segment sent?
___________
Detailed Analysis (Homework)
Similar to the flavors we have already examined, TCP SACK retransmits segment 23 using the fast
retransmit algorithm. However, it uses a different approach to determine when and which packets are
sent out during fast recovery. It calculates the amount of in-flight data based on selective
acknowledgements that it has received. Data can be sent only if the amount of outstanding data is
lower than the size of the congestion window. Because it has information about which segments
were received, it is able to resend only missing segments and then continue with transmission of
unsent data.
Run Simulation for TCP Tahoe, TCP New Reno and TCP Reno with ECN Support
1. Select Scenarios -> Manage Scenario.
2. Set “Results” to “collect” for Tahoe, new Reno and ECN scenarios.
3. Click OK to run the simulations.
4. Click Close after simulation completes.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
20
1508 Understanding TCP/IP Model Internals and Interfaces
Comparison across Scenarios
Let us now compare the results across scenarios.
Application Statistics
Examine Client FTP.Download Response Time statistics available on a graph in the last scenario.
Repeat step 3 from page 17.
1. Which flavor results in the lowest application response time?
___________
2. Which two flavors tie for second place in application response time?
___________
3. Which flavor results in the highest response time and why?
___________
__________________________________________________________________________
4. Why do you think TCP Reno with ECN support outperformed all other TCP flavors?
__________________________________________________________________________
5. Why do you think TCP Reno performed worse than TCP Tahoe, which does not use fast
recovery?
___________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
21
1508 Understanding TCP/IP Model Internals and Interfaces
Summary
We have seen how packets are retransmitted and the congestion window is calculated depending on
a selected TCP flavor.
We can observe that TCP Reno with ECN support outperforms TCP SACK and New Reno, while
Reno has the worst response time for this case. Moreover, Reno is even “slower” than Tahoe. This
may be surprising, because Reno was designed as an improvement over Tahoe. However, this is
because Reno is optimized for networks with a small packet discard ratio, whereas we presented a
case in which multiple packets were dropped from the same window of data. The reason that TCP
Reno with ECN support offers the best response time is that in this case no packets are actually
dropped.
Note:
For a comparison, we have also executed simulations in which only one segment is dropped
(segment 23). In this case, Reno should perform better than Tahoe. That this is indeed the case can
be seen from the graph below.
END OF LAB 2
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
22
1508 Understanding TCP/IP Model Internals and Interfaces
Homework Lab 2
In this lab you will finish our analysis of the selected TCP flavors and compare their response to
three packet drops from the same window of data.
Main Steps
•
Analyze TCP Tahoe behavior
•
Analyze TCP New Reno behavior
•
Analyze TCP Reno with ECN support behavior.
•
Compare response time across scenarios.
Analyze TCP Tahoe
2. Select Scenarios -> Switch to Scenario to switch to scenario Tahoe.
3. TCP Tahoe supports fast retransmission and resets the congestion window to one MSS after
segment retransmission. Check that Fast Retransmission is enabled and Fast Recovery is
disabled. Your TCP settings on the workstation and server are shown below.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
23
1508 Understanding TCP/IP Model Internals and Interfaces
3. Repeat steps 2 through 3 from page 16 to run the simulation, and load results into templates.
You should see the following results:
Retransmitted
segments
Results Analysis
Congestion Window
Examine TCP Connection.Congestion Window Size (bytes) graph to answer the following.
To get an exact value, position your mouse in the desired region and read the tooltip for the Nearest
Point:
1. What was the congestion window size before the packet loss was detected?
___________
2. What did the congestion window size value change to after detecting packet loss? _________
3. How did the server recover from packet loss, by using fast retransmit or timeout retransmission?
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
24
1508 Understanding TCP/IP Model Internals and Interfaces
___________
4. How many times was a slow start performed during the session lifetime?
___________
Retransmission Pattern
Examine Sequence number of forwarded and dropped segments graph to answer the following.
5. How many segments were retransmitted?
___________
6. Were any segments retransmitted unnecessarily?
___________
7. When was the last segment sent?
___________
Detailed Analysis
Sequence Numbers and ACK Numbers
Note: Segments are identified by their segment sequence numbers (e.g., segment 1, 2…) In the
following text, the term “ACK for segment X” means that segment X has been received successfully
and the next expected segment is segment X + 1.
The server retransmits segment 23 after it has received a third duplicate ACK and set its congestion
window to one MSS. After the client receives the retransmitted segment, it also processes the
previously received segments 24, 25, and 26 and sends an ACK acknowledging segments 23 through
26. This allows the receiver to increase its congestion window to 2 and resend segments 27 and 28.
The ACK for segment 27 increases the server’s congestion window to 3 and segments 29 and 30 can
be resent. The ACK for segment 28 acknowledges all segments up through segment 46 (which has
sequence number 24,121). (These segments had been sent before the server received the third
duplicate ACK and cut the congestion window.) The server then continues sending unsent data, but
with the reduced congestion window.
Notice that segments 29 and 30 were unnecessarily retransmitted, and TCP Tahoe recovers from the
packet lost without retransmission timeout expiration.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
25
1508 Understanding TCP/IP Model Internals and Interfaces
Analyze TCP New Reno
4. Select Scenarios -> Switch to Scenario to switch to scenario New_Reno.
5. TCP New Reno supports fast retransmission and fast recovery. However, contrary to TCP Reno,
it halves the congestion window only once during recovery process.
a. Fast Recovery has been already enabled on both the workstation and the server by setting
TCP Parameters->Fast Recovery to New Reno:
3. Repeat steps 2 through 3 from page 16 to run the simulation, and load results into templates. You
should see the following results:
Results Analysis
Congestion Window
Examine TCP Connection.Congestion Window Size (bytes) graph to answer the following.
To get an exact value, point the mouse to the desired point and read the tooltip.
1. What was the congestion window size before the packet loss was detected?
___________
2. What did the congestion window size value change to after detecting packet loss? _________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
26
1508 Understanding TCP/IP Model Internals and Interfaces
3. How did the server recover from packet loss, by using fast retransmit or timeout retransmission?
______________
4. How many times was a slow start performed during the session lifetime?
___________
Retransmission Pattern
Examine sequence number of forwarded and dropped segments graph to answer the following.
5. How many segments were retransmitted?
___________
6. Were any segments retransmitted unnecessarily?
___________
7. When is the last segment sent?
___________
Detailed Analysis
The size of the congestion window just before fast retransmission was 12,328 bytes. After fast
retransmission, the congestion window is reset to
12,864 / 2 + 3 * MSS = 6,432 + 3 * 536 = 8, 040
Note: In this calculation, when the congestion window is halved, it is rounded down to an integral
multiple of the MSS. In this example, 12,864 is 24 * 536, the result of the division is also an integral
multiple of the MSS. If the window had been 23 * 536 = 12,328, then the result would be 11.5 *
536 = 6,164, which must be rounded down to 11 * 536 = 5,895.
Note: 12,328/2 is rounded down to the increments of MSS, rather than to the actual value (6,164).
The process then continues receiving more duplicate ACKs and increases its congestion window by
one MSS for each received ACK. Unlike in Reno, the ACK for the retransmitted segment 23 does
not take New Reno out of the recovery process. New Reno will keep increasing its congestion
window for each received ACK until the ACK for the last segment sent before retransmission is
received (which is segment 46). When the client receives the retransmitted segment 28, then it will
send an acknowledgement for all the outstanding segments. When the sender gets this
acknowledgement, fast recovery ends, and the sender enters slow start.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
27
1508 Understanding TCP/IP Model Internals and Interfaces
Analyze TCP Reno with Explicit Congestion Notification
1. Select Scenarios -> Switch to Scenario to switch to scenario ECN.
2. Make sure that ECN has been enabled on both the sender and the receiver:
3.
Open the attributes window for the analyzer_svr_wkstn node. Notice that the packet dropper
was configured to mark packets rather than drop them:
4. Repeat the steps 2 and 3 from page 16 to load results into templates. You should see the
following results:
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
28
1508 Understanding TCP/IP Model Internals and Interfaces
Results Analysis
Congestion Window
1. What was the congestion window size before the congestion was detected?
___________
2. After congestion was detected, what was the new size of the congestion window? _________
3. Did the traffic analyzer drop any segments?
_______________________
Retransmission Pattern
4. How many segments were retransmitted?
___________
Detailed Analysis
Notice that the packet analyzer did not drop any segments, but the sender reacted to the congestion
notification by decreasing the congestion window. It did not have to retransmit the segment though,
because the segment was received by the client.
Comparison across Scenarios
Let us now compare the results across scenarios.
Congestion Window
1. Which TCP flavor had to use timeout retransmission to recover from loss?
___________
Retransmission Pattern
2. Which TCP flavor(s) retransmitted packets unnecessarily?
___________
3. Which TCP flavor did not have to retransmit at all?
___________
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
29
1508 Understanding TCP/IP Model Internals and Interfaces
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
30
1508 Understanding TCP/IP Model Internals and Interfaces
Lab 3: Interfacing a Custom Lower Layer to IP
Overview
The OPNET IP model has an open API that allows any custom MAC layer to interface with IP. In
this lab you will interface a simple MAC layer to IP. Any lower layer interfacing with IP must
perform the following four steps.
•
Address assignment
•
Process Registry
•
Handle packets coming from IP
•
Handle packets coming in from the network
Objectives
•
Interface the simple_mac MAC model to IP
•
Use a test network to verify proper operation
Instructions
The simple_mac Process
The simple_mac process provides a custom lower layer which can be interfaced with the IP
layer. This process will be used throughout this lab.
1. Open the process model simple_mac present in the C:\op_models directory.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
31
1508 Understanding TCP/IP Model Internals and Interfaces
Initialization: Address Assignment
Each MAC process in the network must have a unique integer address. This address may be
manually assigned via an attribute or programmatically generated. The simple_mac process uses the
OPNET auto-addressing package called oms_aa to assign addresses. This package is capable of
assigning unique integer addresses to all or some of the nodes in the network. More information
about this package is available in the session material of 1528–Accelerating Model Development
with OPNET’s Model Support Libraries. The address must be assigned before proceeding to the
next step (process registry).
Initialization: Process Registry
In this step, the MAC process must publish its address in the model-wide process registry so that the
ARP module in each node can learn the MAC address. This information is later used to translate IP
addresses to MAC addresses.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
32
1508 Understanding TCP/IP Model Internals and Interfaces
The MAC process must set the following two attributes:
Attribute Name
Attribute Type
Attribute Value
“protocol”
OMSC_PR_STRING
“mac”
“address”
OMSC_PR_INT64
MAC address
The MAC process must publish these attributes by the third interrupt, because the ARP process
performs discovery in the fourth interrupt.
In the simple_mac process, this registry is occurring in the function
simple_mac_oms_process_register (), which is called from the exit execs of the
Register state. You can look at the function block (Code Blocks / Function Block or
the process to see the call to oms_pr_process_register ().
button) of
Handling a Packet from IP
Handling a packet from IP involves the following steps:
•
Identify an IP packet
•
Determine the destination MAC address to which the packet needs to be sent
•
Encapsulate the IP datagram in a MAC packet with the appropriate header
•
Send the MAC packet to the transmitter
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
33
1508 Understanding TCP/IP Model Internals and Interfaces
Identifying an IP Packet
When the simple_mac process model receives a stream interrupt, it needs to decide whether the
packet is from the ARP layer or from the receiver. This is done based on the input stream index.
Refer to the transition macros PACKET_FROM_IP and PACKET_FROM_NTWK defined in the Header
block (Code Blocks / Header Block or
reproduced below.
button) of the process model. The relevant lines are
/***** Transition Macros
******/
#define PACKET_FROM_IP
(in_strm == SMC_IN_STRM_INDEX_FROM_ARP)
#define PACKET_FROM_NTWK (in_strm == SMC_IN_STRM_INDEX_FROM_RCV)
/* Macro corresponding to stream indices
*/
#define SMC_OUT_STRM_INDEX_TO_ARP
0
#define SMC_OUT_STRM_INDEX_TO_XMT
1
#define SMC_IN_STRM_INDEX_FROM_ARP
0
#define SMC_IN_STRM_INDEX_FROM_RCV
1
Note: The stream indices do not have to be hard-coded like this. Instead the MAC process can
perform a graph walk at initialization and determine these values and store them as state variables.
This approach was not used for this lab for the sake of simplicity.
Determining the Destination MAC Address
Every packet from the ARP layer will have an ICI of type ip_mac_req associated with the stream
interrupt. The destination address of the packet will be specified in the dest_addr field of the ICI.
Note:
•
Since the ARP module reuses the ICI, the MAC layer SHOULD NOT destroy the ICI after
handling the packet.
•
For broadcast packets, the dest_addr field will be set to IPC_PHYS_ADDR_BROADCAST.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
34
1508 Understanding TCP/IP Model Internals and Interfaces
Coding Changes
Make the Necessary Coding Changes to Handle a Packet from IP
1. Open the function block (Code Blocks / Function Block or
process model.
button) of the simple_mac
2. Scroll down to the simple_mac_packet_from_ip_handle function (line 105).
3. Edit the function as follows. (Lines to be added are in bold).
FIN (simple_mac_packet_from_ip_handle (ip_pkptr));
/* Get the ici associated with the interrupt. The
/* destination address of the packet will be specified
/* in the ici.
arp_ici_ptr = op_intrpt_ici ();
*/
*/
*/
/* Get the destination address from the ici.
*/
op_ici_attr_get_int32 (arp_ici_ptr, "dest_addr", &dest_addr);
/* Print a trace Message
*/
if (SMC_LTRACE_ACTIVE)
{
sprintf (msg, "Destination Address: %d", dest_addr);
op_prg_odb_print_major ("Received a Packet from IP",
msg, OPC_NIL);
}
/* Create the MAC Packet.
mac_pkptr = op_pk_create_fmt ("simple_mac");
*/
/* Set the source and dest addresses in the packet
*/
op_pk_nfd_set_int32 (mac_pkptr, "source address", my_address);
op_pk_nfd_set_int32 (mac_pkptr, "dest address", dest_addr);
/* Encapsulate the IP Datagram in the MAC Packet
op_pk_nfd_set_pkt (mac_pkptr, "data", ip_pkptr);
*/
/* Send the packet out to the transmitter.
op_pk_send (mac_pkptr, SMC_OUT_STRM_INDEX_TO_XMT);
*/
FOUT;
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
35
1508 Understanding TCP/IP Model Internals and Interfaces
Sending a Packet to IP
The MAC process receives a packet from the network, it decapsulates the IP packet from the MAC
packet and sends it to the ARP module. No ICIs are involved here. In the simple_mac process model
this is performed in the function simple_mac_packet_from_ntwk_handle (no need to
make any coding changes):
FIN (simple_mac_packet_from_ntwk_handle (mac_pkptr));
/* Decapsulate the IP datagram from the packet.
op_pk_nfd_get (mac_pkptr, "data", &ip_pkptr);
*/
/* Print a trace Message
if (SMC_LTRACE_ACTIVE)
{
/* Get the source address from the packet
op_pk_nfd_get (mac_pkptr, "source address",
&source_address);
*/
*/
sprintf (msg, "Source Address: %d", source_address);
op_prg_odb_print_major ("Received a Packet from the”
“Network", msg, OPC_NIL);
}
/* Send the packet to the higher layer.
op_pk_send (ip_pkptr, SMC_OUT_STRM_INDEX_TO_ARP);
*/
/* Destroy the MAC packet.
op_pk_destroy (mac_pkptr);
*/
FOUT;
Save and Compile the Process Model
1. Save and compile the process model.
2. If you are having problems in compilation, you may
a. Close the simple_mac process model.
b. Open the simple_mac_ref process model.
c. Save it as simple_mac.
d. Recompile.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
36
1508 Understanding TCP/IP Model Internals and Interfaces
Test the Network
Open the Test Project
We will now use a simple network to verify that the MAC layer is working correctly.
1. Open the project 1508_lab_3. If you did not make the coding changes to the simple_mac
process model, you may use the 1508_lab_3_Ref project.
The project should open up in the scenario named simple_ping_network.
Network Description
The network consists of two nodes of type simple_mac_wkstn connected to each other. A ping
demand has also been configured from wkstn_1 to wkstn_2. The MAC and the IP addresses on both
the nodes are set to Auto Assigned. The simulation IP auto-addressing package works with custom
wireline MAC layers also. Shown below are the attributes for the wkstn_1 and wkstn_2 nodes
which effect IP addressing. These attributes can be accessed by right-clicking on the node and
selecting Edit Attributes.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
37
1508 Understanding TCP/IP Model Internals and Interfaces
Run the Simulation in ODB
1. Click on the Configure / Run Discrete Event Simulation action button.
2. In the treeview on the left, go to Execution / OPNET Debugger.
3. Check the Use OPNET Simulation Debugger (ODB) checkbox in the right panel.
4. Click Run.
When the simulation starts you will see a single Simulation Execution window open. Inside this
window, three tabs are defined: the Console tab provides an interface for the ODB commands
and output, the Progress tab displays information about the overall simulation progress, and the
Model tab allows the user an interactive view of the network where nodes can easily be selected
for graphical debugging.
5. Select the Console tab so further debugging can be accomplished on this scenario.
Inspect Trace Messages
We will run the simulation with a trace on the label simple_mac so that we can see the debug
messages printed out by the simple_mac process model.
1. In the ODB console (the ODB> box), enter the following commands:
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
38
1508 Understanding TCP/IP Model Internals and Interfaces
a. tstop 105 (and then Enter). This command sets a breakpoint for 105 seconds. Our
ping traffic starts at 100 seconds, so this is a good place to stop.
b. ltrace simple_mac (and then Enter). This command enables trace for the label
simple_mac.
c. cont (and then Enter). This command executes the simulation until a breakpoint.
Examine the trace messages.
2. Complete the simulation.
a. cont (and then Enter).
3. Close the simulation window once the simulation has finished.
Ping Results
The record route option was enabled for the ping demand. An output table entry is created
corresponding to each successful ping demand. Verify that there is an entry corresponding to the
ping demand.
Verify Ping Results
1. Click on the View Results action button (or right-click in the project workspace and select
View Results) to open up the view results dialog box.
2. In the window that opens, click on the DES Run (1) Table tab.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
39
1508 Understanding TCP/IP Model Internals and Interfaces
3. Select the Ping Report from the left treeview and click Show.
Note that the ping demand was successful.
Larger Network Scenario
The project also contains a second scenario named Larger_Network that consists of several
simple_mac and ppp_wkstns connected using routers. Ping demands have been configured between
many nodes.
Switch to the Scenario Named Larger_Network
1. Select Scenarios / Switch to Scenario / Larger_Network.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
40
1508 Understanding TCP/IP Model Internals and Interfaces
Run the Simulation
1. Select DES / Run Discrete Event Simulation.
2. After the simulation completes, click Close.
Verify Ping Results
1. Click on the View Results action button
to open up the view result dialog box.
2. Click on the DES Run (1) Table tab.
Note that there are Ping Reports corresponding to all the ping demands in the network.
This shows that IP can route between different interface types.
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
41
1508 Understanding TCP/IP Model Internals and Interfaces
END OF LAB 3
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
42
1508 Understanding TCP/IP Model Internals and Interfaces
Lab 1 Answers: Tracing TCP Connection
Examine Network Configuration
3. What is the Slow Start Initial Count (MSS)?
2
4. How many TCP segments will be sent after the connection is established?
2
5. What is the Maximum Segment Size?
1460 Bytes
6. Estimate how many TCP data segments will be used to send 5,000 Bytes?
4
Examine 3-Way Handshake
4. Scroll up to the first event that gets printed. You can see that the server opens a connection at
time 0.
a. Is this a passive or active connection?
Passive
b. What is the local port number used by the server?
20
c. When did the client receive an OPEN request from the application?
event 125
At time 101sec,
5. What are the sequence numbers of the packets comprising 3-way handshake?
a. First segment:
25250000
b. Second segment:
25250001
c. Third segment:
25250001
6. Were any options set in the SYN packets?
Yes, MSS and SACK-Permitted
Examine Slow Start
1. Server’s TCP process then sends its first application data.
a. How many segments are sent out at the beginning?
2
b. How is this related to the Slow Start Initial Count from step 3b of the Examine Network
Configuration section?
It is equal.
c. What are the sequence numbers and data length of the first 2 segments?
Sequence number
Length
1st data segment
25250002
1460
2nd data segment
25251462
1460
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
43
1508 Understanding TCP/IP Model Internals and Interfaces
2. What should be the ACK number of the next segment sent from client?
25252922
3. Is this the same as the ACK number sent at event 260?
Yes.
4. How many more segments did the server send before closing a connection?
2
5. How many bytes of data did the server send?
5008
6. What was the actual Maximum Segment Size?
1460
7. Is the number of segments sent by the server the same as you predicted ?
It should be 4
Examine Connection Termination
1. Which side starts the connection termination process?
server
2. When did client send a FIN segment?
At event 400
3. When was the connection finally closed on the client?
At event 461
4. When was the connection finally closed on the server?
At event 463
Examine Congestion Window (Homework Lab)
4. What is the process ID of the active TCP process on server?
53
6. What state is the connection at?
TIME_WAIT
7. What is the size of the congestion window?
segments
7,300 Bytes or 5
8. Is there any unsent data in the send or retransmission buffer?
No, send buffer size is 0
Examine Packet Content (Homework Lab)
3. What is the ACK number of this segment?
25250001
4. Does it contain any data?
No
5. Are there any flags set in the TCP header?
Yes, SYN and ACK flags
6. What options does it contain?
MSS, SACK-Permitted
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
44
1508 Understanding TCP/IP Model Internals and Interfaces
Lab 2 Answers: TCP Flavor Comparison
TCP Reno:
1. What was the congestion window before the packet loss was detected?
12,864 Bytes
2. What was the congestion window after the loss was detected?
8,040 Bytes
3. Why did the congestion window keep increasing after the loss was detected?
This is due to the arrival of duplicate ACKs.
4. Why did the congestion window stay flat for a large period?
Sender could not send new data, it had to wait for a retransmission timer to expire
Note: You can typically conclude this whenever you see a large gap when no data is sent.
5. How did the server recover from packet loss – using fast retransmit or timeout retransmission?
Retransmission timeout expiration
6. How many times was a slow start performed during the session lifetime?
Twice – when the session started and when the timer expired.
7. How many segments were retransmitted?
3
8. Were any segments retransmitted unnecessarily?
No
9. When is the last segment sent?
At about 2.6 seconds
TCP SACK
1. What was the congestion window before the packet loss was detected?
12,864 Bytes
2. What was the congestion window after the loss was detected?
6,432 Bytes
3. Why did not congestion window change after retransmission?
TCP SACK does not use congestion window to decide when to send a packet during fast
recovery. It has its own algorithm that uses an estimation of how much data is outstanding.
4. How many segments were retransmitted?
3
5. Were any segments retransmitted unnecessarily?
No
6. When is the last segment sent?
About 1.2 sec
Comparison across Scenarios
1. Which flavor results in the lowest application response time?
Reno with ECN
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
45
1508 Understanding TCP/IP Model Internals and Interfaces
2. Which two flavors tie for second place in application response time?
TCP SACK, New Reno
3. What flavor resulted in the highest response time and why?
It had to wait for a timeout before resending the third dropped segment.
Reno
4. Why do you think TCP Reno with ECN support outperformed all other TCP flavors?
It did not have to retransmit any segment.
5. Why do you think TCP Reno performed worse than TCP Tahoe, which does not use fast
recovery?
It had to wait for retransmission timer expiration.
TCP Tahoe:
1. What was the congestion window before the packet loss was detected?
12,864 Bytes
2. What was the congestion window after the loss was detected?
536 Bytes
3. How did the server recover from packet loss, by using fast retransmit or timeout retransmission?
Using fast recovery
4. How many times was a slow start performed during the session lifetime?
Slow start was performed twice – when the session opened and when the packet drop was
detected.
5. How many segments were retransmitted?
5
6. Were any segments retransmitted unnecessarily?
Yes, 2 of them
7. When is the last segment sent?
At about 1.4 sec
TCP New Reno
1. What was the congestion window before the packet loss was detected?
12,864 Bytes
2. What was the congestion window after the loss was detected?
8,040 Bytes
3. How did the server recover from packet loss, by using fast retransmit or timeout retransmission?
Fast recovery
4. How many times was a slow start performed during the session lifetime?
once
5. How many segments were retransmitted?
3
6. Were any segments retransmitted unnecessarily?
No
7. When is the last segment sent?
At about 1.2 sec
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
46
1508 Understanding TCP/IP Model Internals and Interfaces
TCP Reno with ECN Support
1. What was the congestion window size before the congestion was detected?
12,328 Bytes
2. After congestion was detected, what was the new size of the congestion window? 5,896 Bytes
3. Did the traffic analyzer drop any segments?
No
4. How many segments were retransmitted?
None
Comparison across Scenarios
1. Which TCP flavor had to use timeout retransmission to recover from loss?
Reno
2. Which TCP flavor(s) retransmitted packets unnecessarily?
Tahoe
3. Which TCP flavor did not have to retransmit at all?
Reno with ECN
CONFIDENTIAL – RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc.
© 2010 OPNET Technologies, Inc.
47