Understanding TCP/IP Model Internals and Interfaces

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


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? 

____________ 



2


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. 



3


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? _________________ 



4


• 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? 

1 st data segment 

2 nd data segment 

Sequence number 

Length 

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 

___________ 



5


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. 



6


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: 



7


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: 



8


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? ___________ 



9


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. 



10


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. 



11


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 



12


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 


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 



13


Instructions 


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. 



14


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. 



15


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. 



16


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: 



17


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. 



18


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: 





3. Why didn’t the congestion window change after retransmission? _______________________ 

______________ 




19




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. 



20


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? 

___________ 



21


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 



22


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. 



23


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 




To get an exact value, position your mouse in the desired region and read the tooltip for the Nearest 

Point: 



3. How did the server recover from packet loss, by using fast retransmit or timeout retransmission? 



24


___________ 



Examine Sequence number of forwarded and dropped segments graph to answer the following. 



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. 



25


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: 




To get an exact value, point the mouse to the desired point and read the tooltip. 





26



______________ 



Examine sequence number of forwarded and dropped segments graph to answer the following. 



7. When is the last segment sent? ___________ 


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. 



27


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: 



28




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? _______________________ 




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. 


Let us now compare the results across scenarios. 


1. Which TCP flavor had to use timeout retransmission to recover from loss? ___________ 


2. Which TCP flavor(s) retransmitted packets unnecessarily? ___________ 

3. Which TCP flavor did not have to retransmit at all? ___________ 



29




30


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. 



31


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. 



32


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 button) of 

the process to see the call to oms_pr_process_register (). 

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 



33


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 button) of the process model. The relevant lines are 

reproduced below. 

/***** 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. 



34


Coding Changes 

Make the Necessary Coding Changes to Handle a Packet from IP 

1. Open the function block (Code Blocks / Function Block or button) of the simple_mac 

process model. 

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; 



35


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. 



36


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. 


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. 



37


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: 



38


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. 



39


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. 



40


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. 



41


END OF LAB 3 



42


Lab 1 Answers: Tracing TCP Connection 


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? At time 101sec, 

event 125 

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 

1 st data segment 25250002 1460 

2 nd data segment 25251462 1460 



43


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? 7,300 Bytes or 5 

segments 

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 



44


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 



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. 



6. When is the last segment sent? About 1.2 sec 


1. Which flavor results in the lowest application response time? Reno with ECN 



45


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? Reno 

It had to wait for a timeout before resending the third dropped segment. 

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: 


2. What was the congestion window after the loss was detected? 536 Bytes 


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. 


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 




Fast recovery 

4. How many times was a slow start performed during the session lifetime? once 



7. When is the last segment sent? At about 1.2 sec 



46


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 


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 



47

Understanding TCP/IP Model Internals and Interfaces

Create successful ePaper yourself

Delete template?

Save as template?