1508 homework labs final

1508 Understanding TCP Model Internals and Interface

Understanding TCP Model Internals and Interface

Contents

Understanding TCP Model Internals and Interface...............................................................................1

Contents.............................................................................................................................................1

Lab 1: TCP Flavor Comparison.............................................................................................................3

Background........................................................................................................................................3

Objective............................................................................................................................................3

Network Model..................................................................................................................................4

Network Description..........................................................................................................................4

Main Configuration Steps..................................................................................................................4

Instructions........................................................................................................................................5

Examine Network Configuration...................................................................................................5

Configure TCP Tahoe on Hosts, Run the Simulation, and Collect Results..................................5

Configure TCP Tahoe on Hosts, Run the Simulation, and Collect Results..................................6

Configure TCP Reno on Hosts, Run the Simulation, and Collect Results....................................7

Configure TCP New Reno on Hosts, Run the Simulation, and Collect Results...........................8

Configure TCP SACK on Hosts, Run the Simulation, and Collect Results..................................9

Results Comparison.........................................................................................................................10

Lab 2: Modifying Slow-Start Mechanism to Improve Performance...................................................11

Background......................................................................................................................................11

Objective..........................................................................................................................................12

Network Model................................................................................................................................12

Network Description........................................................................................................................12

Main Configuration Steps................................................................................................................12

Instructions......................................................................................................................................13

Run Reference Scenario..............................................................................................................13

Implementation Steps..................................................................................................................13

Implement “Restart Window”.....................................................................................................14

Implementation Steps..................................................................................................................14

Lab 3: Interfacing with TCP................................................................................................................18

CONFIDENTIAL INFORMATION: DO NOT DISCLOSE, FORWARD, DISTRIBUTE, SHARE, OR MAKE COPIES OF THIS DOCUMENT IN WHOLE OR IN PART. © Copyright 2004 OPNET Technologies, Inc.

of 22


Background......................................................................................................................................18

Objective..........................................................................................................................................18

Generator and Node Models............................................................................................................18

Generator Model Description..........................................................................................................18

Main Configuration Steps................................................................................................................19

Instructions......................................................................................................................................20

Interfacing a Custom Traffic Source over TCP...........................................................................20

Summary..........................................................................................................................................22


of 22


Lab 1: 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 react 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

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.

For each of the modeled TCP flavors, we will examine:

Segment retransmission process (the order in which segments are retransmitted)


of 22

Dropped segments


The reason why segments get retransmitted – fast recovery vs. expiration of 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. The packet analyzer is used to drop selected segments and collect statistics.

Main Configuration Steps

1. Examine network configuration.

2. Configure TCP Tahoe on hosts, run the simulation, and collect results.

3. Configure TCP Reno on hosts, run the simulation, and collect results.

4. Configure TCP New Reno on hosts, run the simulation, and collect results.

5. Configure TCP SACK on hosts, run the simulation, and collect results.

6. Result comparison across scenarios.

Instructions

Examine Network Configuration

1. Start OPNET Modeler.


of 22


2. Open project 1508_lab1. Scenario Tahoe opens. This scenario has been fully configured for you.

3. Examine TCP configuration.

Sender and receiver have been configured identically. Open “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.

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.

5. Take note of 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


of 22


Configure TCP Tahoe on Hosts, Run the Simulation, and Collect Results

1. 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.

2. Run the simulation, then load statistics into the provided templates.

3. You should see the following results:

Sequence Numbers and ACK Numbers

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.

Results Analysis

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 for segment 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 sent. The ACK for segment 27 acknowledges segments up to 45. The sender then continues sending unsent data.

Notice that segments 29 and 30 were unnecessarily retransmitted and TCP Tahoe recovers from the packet lost without retransmission timeout expiration.


of 22

Retransmitted segments


Configure TCP Reno on Hosts, Run the Simulation, and Collect Results

1. Duplicate the Tahoe scenario and name it Reno.

2. Enable “Fast Recovery” on the workstation and server by setting it to “Reno”. Make sure that your TCP settings on the workstation and server are as shown below.

3. Run the simulation, create templates from the existing graphs, and load results into them. You should see the following results:

Results Analysis

The size of the congestion window just before fast retransmission was 12,328 bytes. The congestion window after fast retransmission is reset to

12,328 / 2 + 3 * MSS = 6164 + 3 * 536 = 7772

The sender then continues receiving more duplicate ACKs and increases its congestion window by one MSS for each ACK. 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 27 and resends segment 28 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.


of 22


Configure TCP New Reno on Hosts, Run the Simulation, and Collect Results

1. Duplicate the Reno scenario and name it “New_Reno”

2. Enable New Reno fast recovery on both hosts by changing “Fast Recovery” to “New Reno”. Make sure that your TCP settings on the client and the server are as shown below.

3. Run the simulation, create templates from existing graphs and load results into them. You should see the following results:

Results 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,238 + 3 * MSS = 12,238 + 3 * 536 = 7727

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 45). However, by that time all segments have been sent and the congestion window never drops again. Increasing the congestion window will also allow the process to resend segments 27 and 28. Drops in the congestion window during the recovery process are due to partial ACKs (ACKs acknowledging new data). Partial ACKs decrease the congestion window by the amount of ACKed data.


of 22


Configure TCP SACK on Hosts, Run the Simulation, and Collect Results

1. Duplicate the New Reno scenario and name it “SACK”.

2. Set Fast Recovery back to “Reno” and enable “Selective Acknowledgements”. Make sure that your TCP settings on the workstation and server are as shown below.

3. Run the simulation, create templates from existing graphs, and load results into them. You should see the following results:

Results Analysis

Similar to the flavors we have already examined, 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.


of 22


Results Comparison

We have seen how packets are retransmitted and the congestion window is calculated depending on a selected flavor. The following graph shows FTP download time for selected flavors. To view the graph, compare results across the scenarios for “Client FTP->Download Response Time” on the workstation.

We can observe that SACK and New Reno have the best response time, 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.

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 1


of 22


Lab 2: Modifying Slow-Start Mechanism to Improve Performance

Background

When application data transfer is followed by an idle period larger than the size of the retransmission timeout, TCP resets its congestion window to one MSS. This behavior is illustrated in the graph below.

Resetting the congestion window to one MSS might be too conservative for networks with low packet loss. RFC 2451 defines an alternative approach for setting the congestion window:

[Jac88] recommends that a TCP use slow start to restart transmission after a relatively long idle period. Slow start serves to restart the ACK clock, just as it does at the beginning of a transfer. This mechanism has been widely deployed in the following manner. When TCP has not received a segment for more than one retransmission timeout, cwnd is reduced to the value of the restart window (RW) before retransmission begins.


of 22

Idle Period > Last RTOIdle Period > Last RTO


Objective

We will modify TCP performance for persistent application sessions by modifying the congestion window after idle periods. To do that, we will implement the “Restart Window” algorithm as defined in RFC 2451.

We will then compare the TCP congestion window and application response time for two scenarios:

Scenario 1. This is the baseline scenario. Congestion window is reset to one MSS.

Scenario 2. “Restart Window” is set to 4 * MSS.

Network Model

Network Description

The client node is transferring five 1-MB files from a server as part of a data transfer operation. There is an idle duration of 5 seconds between the file transfers. A custom application is used to generate the data.


1. Run the reference scenario and collect application response time and congestion window size.

2. Add a new attribute “Restart Window” and compare results with the baseline scenario.


of 22


Instructions

Run Reference Scenario

Implementation Steps

1. Run OPNET Modeler.

Open project 1508_lab2. Scenario “default_network” will show up as the first scenario.

Project “1508_lab2_ref” is also provided in case you simply want to follow along without actually performing this lab.

2. Run the simulation.

3. Load results.

A template panel exists for “Application Response Time (sec)” and “TCP Congestion Window (bytes)” for the TCP connection. Load the data into templates.

Results Analysis

Notice that, after idle periods, TCP resets its congestion window to one MSS and continues with slow start.


of 22


Implement “Restart Window”

In the previous scenario, slow-start started at the same value—one MSS—for each connection. We are sure the pipe is empty, and can therefore be more aggressive. We will define a new TCP attribute called “Restart Window”. We will follow the steps below to add a new TCP attribute.

1. Define the attribute on the interface of TCP manager process.

2. Add a new field to the TcpT_Conn_Parameters data structure.

3. Read in the attribute from the manager process.

4. Modify TCP behavior to use the new attribute.

Implementation Steps

1. Add “Restart Window” as a configurable attribute.

a. Open the “tcp_manager_v3” process model.

b. From the “Interfaces” menu choose “Model Attributes”.

c. Select “TCP Parameters” and click “Edit Attributes”.

d. Scroll to the end and define a new attribute “Restart Window”.

e. Declare it as an integer and select “Edit Properties”.Click the “Load Public” button and choose “restart_window”. This will load an already defined attribute. If prompted to select range, set it as shown on the picture below.

f. Select “Private” to enable local editing and click “OK”.

g. The complete attribute definition is shown below.

Note that the new attribute is promoted to the node level automatically. You do not need to modify workstation and server node models. This is because the attribute was added to a compound attribute already defined on a node.


of 22


h. Move this newly defined attribute using the “Move Up” button and place it just below the “Slow-Start Initial Count” attribute.

i. Click the OK button to save the changes.

2. Add a new field to TCP parameters data structure

The “tcp_v3” header file defines a data structure “TcpT_Conn_Parameters” used to convey configured attribute parameters from the manager to the connection processes. You will add a new field to this data structure.

a. Choose File > Open, select “Header File C/C++, .h”, and select “tcp_v3”.

b. Add the variable “restart_window” of type integer to the TcpT_Conn_Parameters data structure, as follows:int restart_window;Save changes and close the file.

4. Read the configured attribute value

You will now modify the TCP code so that this new attribute is parsed and available to connection processes. The function that reads all configured attributes is tcp_mgr_tcp_params_parse(). You will add code to this function, so that the new attribute is read in.

a. Open the function block. Go to line 305 and add the following code to obtain the assigned value.

if (op_ima_obj_attr_get (tcp_parameter_objid, “Restart Window”,

&tcp_parameter_ptr->restart_window) == OPC_COMPCODE_FAILURE)

tcp_mgr_error (“Unable to get Restart Window attribute”);

b. Save changes to the function block and the “tcp_manager_v3” process model.


of 22


c. Compile the process model.

If the model does not compile, you can try using the “tcp_manager_v3_ref” process model. Save it as “tcp_manager_v3” and recompile.

5. Modify TCP behavior in the connection process

a. Open tcp_conn_v3.pr.m.

b. Change the assignment of congestion window (cwnd), so that instead of it being set as the initial window size, it is set as the value contained in the attribute we created in “tcp_manager_v3”.

The tcp_restart_window_size_set() function returns a value based on the attribute we created in the TCP manager process. This function has already been written for you. Uncomment it, so that it will be used. Go to end of the tcp_conn_v3.pr.m function block and remove “#if 0” and “#endif” from before and after tcp_restart_window_size_set(). This will uncomment the function. Also, remove the “#if 0” and “#endif” from the header block.

c. Replace the two instances of “cwnd = initial_window_size” on lines 3304 and 3194 with the following code:

3. Compile process model

We are done with our changes to tcp connection process. Instead of restarting the window, it should now use the new algorithm.

4. Restart window configuration

We will now configure the TCP process on the workstation to restart with the congestion window set to 4 MSS.

a. Open scenario “modified_restart_window”.

b. Right-click on the “workstation” node and choose Edit Attributes. Click and select “Edit…” for the “TCP Parameters” attribute. Click on the value for “Restart Window” and set it to “4 * Initial Window”. Click “OK” to save the changes.

c. Make the same changes to the “server” node.


of 22


5. Run the simulation.

6. Load data into the provided templates.

Results Analysis

You should see the following results:

In agreement with the design, congestion grows at a much faster rate with “Restart Window” set to four times the initial window. Application response time decreased when the restart window was set higher than one MSS.

END OF LAB 2

Lab 3: Interfacing with TCP

Background

OPNET provides an API package that can be used to interface your custom application model over TCP. The package contains functions that can be used to interact with TCP.

Objective

We assume that a custom application model has been created. The goal of this lab is to modify it so that it can be used over the standard TCP model. Moreover, the model should operate directly over TCP as seen on the client node model below.

Generator and Node Models


of 22


Generator Model Description

The generator will generate data with a configurable interarrival time and packet size. The application should start and end data transmission at a configurable time. The following picture shows the application model attributes.

The process model consists of four states:

Init state. Used to initialize the model and to read the configured attributes and store them.


of 22


Open state. The application process will transfer into this state at the configured “Start Time”. At that time, the application will request TCP to open a new TCP connection to the server.

Data state. Application sends and receives data. Segments are generated with configurable packet sizes and packet interarrival times. Data are sent to and received from TCP.

Release state. Connection is terminated. The process transfers into this state at the configured “End Time”. Application should then request TCP to terminate the connection.


1. Define attributes required for connection setup in the TCP client process.

2. Register with the TCP API.

3. Initiate TCP connection setup process.

4. Handle indications generated by the TCP process.

5. Send data such that TCP can associate it with a connection.

6. Close the connection.


of 22


Instructions

Interfacing a Custom Traffic Source over TCP

1. The IP addresses and ports of the source and destination identify a TCP connection.TCP connection is defined by source and destination IP addresses and ports. In order for TCP to establish a connection, it needs to have this information available. IP destination address and local and remote ports are configurable from the application. Open the application process model tcp_lab_gen, choose Interfaces > Model Interfaces, and notice the configurable parameters related to TCP session.

2. TCP client initialization

To be able to establish a connection, the application needs to register with TCP API first. tcp_app_register() is used for this purpose.

a. Open the enter executives of the INIT state and notice how this is performed.

3. TCP client connection setup

The application can start sending data to TCP only after TCP establishes a connection. Connection establishment request is sent using OPEN request as seen below.

a. Open the enter executives of the OPEN state and notice that the application uses the application handle obtained from the registration process (step 2 above).

The TCP process then creates a new connection and sends the SYN message.


of 22


4. Connection establishment indication

This indication is received after the TCP connection is fully established. It causes the application process to transfer to the DATA state.

5. Data transfer

Outgoing data

After the application packet is created, it is sent to TCP using tcp_data_send().

Incoming data

For TCP to send data to the application process, it first needs to receive a RECEIVE command from the application. This is done using tcp_receive_command_send().

6. Closing TCP connection

Once the data transfer has been completed, the application will transfer to RELEASE state. It should then send a CLOSE command to TCP to terminate the connection. tcp_connection_close() is used to do that.


of 22


7. Simulation execution

You can now create a simple network model to check that the data is sent and received by the new application. Such a model has already been created for you. Open the 1508_lab3 project and inspect the workstation and server settings and node models.

You can then run the simulation, collecting link throughput statistics, and check that the data is indeed exchanged between the two hosts.

Summary

1. Use of APIs significantly reduces the number of low-level details required to interface to the TCP layer.

2. The example “tcp_lab_gen” model can be used as a template to create custom application layer interfaces.

END OF LAB 3


of 22

1508 homework labs final

Documents

tcp reno

tcp tahoe

tcp sack

tcp behavior

tcp implementations

tcp new reno

connection tcp flavors

modeled tcp flavors