Standard Models User Guide 22 TCP Model User Guide

22 TCP Model User Guide

Transmission Control Protocol (TCP) is a widely used connection-oriented
transport layer protocol that provides reliable packet delivery over an unreliable
network. It is typically used with the Internet Protocol (IP) network layer protocol.
This document describes key features of the TCP model shipped as part of the
standard OPNET model library.

Model Features
The section provides a list of the main features available in the TCP standard
model:

• TCP model suite captures the following protocol behavior:

Table 22-1 TCP Model Features

Feature Description

Reliability Acknowledgments and retransmissions triggered by adaptively

calculated retransmission timers

Flow control Dynamic windowing of transmissions based on the availability

of buffering resources at receiving nodes

Resequencing Reordering of out-of-order segment arrivals

Connection Setup and Three-way handshake protocol used to establish connections

Termination and four-way exchange to close connections

Algorithms • Full implementation of slow-start congestion avoidance and

congestion control mechanism
• Silly Window Syndrome avoidance and Nagle’s algorithm
• Karn’s algorithm to avoid retransmission ambiguity problem
• Fast Retransmit and Fast Recovery
• Window Scaling
• Selective Acknowledgment
• Increased Initial Window Option
• Explicit Congestion Notification

Persistence Time-out Timer enabling sending node to send one-byte data segments
to receiving node with a very small window size to poll remote
socket

End of Table 22-1

Modeler/Release 10.0 STM-22-1

Standard Models User Guide 22 TCP Model User Guide

• TCP models are implemented based on information available from the

following sources:

Table 22-2 Reference Documents

RFC-793 Transmission Control Protocol

RFC-1122 Requirements for Internet Hosts -- Communication Layers

RFC-1323 TCP Extensions for High Performance

RFC-2018 TCP Selective Acknowledgement Options

RFC-2414 Increasing TCP’s Initial Window

RFC-2581 TCP Congestion Control

RFC-2582 The NewReno Modification to TCP’s Fast Recovery Algorithm

RFC-2988 Computing TCP’s Retransmission Timer

RFC-3168 The Addition of Explicit Congestion Notification (ECN) to IP

Textbook TCP/IP Illustrated Volume I - Stevens

Textbook TCP/IP Illustrated Volume II - Wright/Stevens

End of Table 22-2

• Detailed implementation of different TCP “flavors”: Tahoe, Reno, and New

Reno with SACK and Window Scaling extensions

• Ability to choose architecture-specific setting (e.g., Windows 3.5/ 4.0/2000,

Solaris 2.6/2.7, HPUX 10.xx/11.xx)

• Configurable parameters for window size, MSS, timer values,

acknowledgment schemes and extensions options: attributes for enabling
fast-retransmit, fast-recovery, window scaling, and/or selective
acknowledgment options

• Segment- and/or clock-based dataless acknowledgment generation scheme

• Explicit modeling of timers, retransmission algorithms, and adaptive

computation of RTOs using segment round-trip times

• The TCP standard model is designed to be used with the IP standard model;
however, it could also be modified for use with other network layer protocols

• API package for model developers to help interfacing with higher layer
processes

STM-22-2 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Model Attributes
Each node with TCP as one of its contained protocols, provides an attribute,
called “TCP Parameters”, to specify TCP configuration parameters. There are
several preset values available for this attribute to allow you to choose from
different TCP “flavors”:

Figure 22-1 TCP Parameters

Values for most of these settings have been referenced from the following URL:
http://www.psc.edu/networking/perf_tune.html

The “TCP Parameters” attribute itself consists of many sub-attributes (these can
be inspected by using the “Edit...” option for its value). Some of the important
TCP model attributes are:

• Maximum Segment Size: Defines the largest amount of data that will be
transmitted as one TCP segment. Choosing a good MSS value is important
because if MSS is small, network utilization may be low; on the contrary, if
MSS is large, it degrades performance as it results in creation of many IP
datagrams, which cannot be acknowledged or retransmitted independently.
Typically, this value should be set equal to the maximum size that the “MAC”
layer can handle, minus the size of TCP and IP headers. Setting this attribute
to “Auto-Assigned” automatically guarantees that it is configured optimally for
the data link layer over which TCP is operating.

Modeler/Release 10.0 STM-22-3

Standard Models User Guide 22 TCP Model User Guide

Figure 22-2 Setting Maximum Segment Size

For Ethernet Network:

• Maximum ACK Delay: Defines the longest time that a TCP connection
process waits to send an acknowledgment (ACK) after receiving data. Note
that TCP does not send an ACK the instant that it receives data. Instead, it
delays the ACK, hoping to have data going in the same direction as the ACK,
so the ACK can be sent along with the data (called ACK piggybacking).
This attribute can significantly influence end-to-end delay when a TCP
process is primarily receiving (and not both sending and receiving) data. This
is so because the TCP connection process waits for this timer to expire
before sending an ACK. Higher values generally result in higher application
response times. However, a low value may result in too many dataless
acknowledgments, adding to network load.
To determine this value, consult your system's configuration or examine a
network analyzer trace. Typically, this value is set to 200 msec, and the
ACKing procedure works in conjunction with the “Delayed ACK Mechanism”
attribute setting.

• Delayed ACK Mechanism: This attribute setting controls how the delayed
“dataless” acknowledgments are sent by the TCP connection process. The
two most common implementations are “Clock Based” (some UNIX
systems), wherein the dataless ACKs are generated at the expiration of the
maximum acknowledgment delay timer, and “Segment/Clock Based”
(Windows systems), wherein dataless ACKs are generated upon receipt of
every other received TCP segment or at the maximum delay timer expiration,
whichever happens first.

STM-22-4 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Figure 22-3 Delayed ACK Mechanism

• Receiver Buffer and Receive Buffer Usage Threshold: This is another

important parameter that the application delay is sensitive to. It effects the
TCP connection’s window size. Note that the window size is the amount of
buffer space available in the receive buffer. This parameter determines when
data should be transferred from the TCP's receive buffer to the application,
thereby allowing the receive window to open further. Values are expressed
as a fraction of the receive buffer size using a value between 0.0 and 1.0. In
general, higher values will result in higher response times for your application
(i.e., slower application).
As the receive buffer (RCV_BUFF) starts getting filled, the advertised
window starts decreasing, thus limiting the flow of traffic from the peer TCP
connection. A higher threshold setting will keep data in the receive buffer for
a longer duration, thereby causing increased delays. Since the threshold is
a fraction of the receive buffer, the effect of this setting is more observable at
smaller receive buffer sizes. A low value for this setting allows data from the
receive buffer to be transferred to the application more often; as a result, the
advertised window is always close to the full window.

Figure 22-4 Selecting a Size for Receive Buffer

This attribute is hard to determine exactly. Looking at your network

analyzer's trace output, examine how the receive window size varies each
time data is received by the host of interest. Your analyzer's output may show
this value as RWIN or a similar variable name. If the receive window remains
at or close to its maximum value each time data is received, then the
application layer is absorbing data from TCP quickly and you should use a
low number such as 0.0 or 0.1 for the usage threshold. Conversely, if the
receive window drops each time data is received, only to open up again after
several segments are obtained, then a higher value should be entered for the

Modeler/Release 10.0 STM-22-5

Standard Models User Guide 22 TCP Model User Guide

usage threshold. For example, if the maximum receive window is 16K bytes,
and the advertised receive window routinely drops to 8K bytes before moving
back to 16K bytes, a value of 0.5 would be appropriate for the usage
threshold. While many UNIX systems implement a value of 0.5 for this
parameter, Microsoft Windows systems are more accurately modeled with a
low value, such as 0.0. However, you should analyze actual trace output to
determine the value of this important parameter.

• Slow-Start Initial Count: Specifies the number of MSS-sized TCP

segments that will be sent upon slow-start. This also represents the value of
the initial congestion window (or “cwnd”). In most TCP implementations, it is
set to one MSS, indicating that every time TCP performs slow-start, it will
start with one segment as its initial window. RFC-2414 is an experimental
document that describes how critical it is to tune this value. It upper bounds
this initial window as:
min [4 * MSS, max (2 * MSS, 4380 bytes)]
Some newer Solaris implementations set the initial count to two. This helps
in reducing the overall end-to-end delay for data transfers, especially if the
data size stays within the slow-start threshold. OPNET models allow you to
choose from a list of possible values, including using the algorithm defined in
RFC-2414:

Figure 22-5 Selecting Slow-start Initial Count

• Protocol-specific Algorithms: The following algorithms are available in a

given TCP implementation:
— Fast retransmit
— Fast recovery
— Window scaling
— Selective ACKnowledgment
— Nagle’s algorithm
— Karn’s algorithm to avoid retransmission ambiguity
For description about these attributes, please refer to the attribute comments
by selecting the attribute of your choice and viewing the “Details”:

STM-22-6 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Figure 22-6 Enabling Fast Recovery

Available Statistics
To analyze TCP protocol performance, there are several statistics that can be
collected during simulation execution. The statistics can be collected on a
per-TCP connection, per-node or a global basis.

• Connection-based TCP statistics, grouped under the heading “TCP

Connection”, are useful for studying low-level TCP performance metrics (for
example, the “Congestion Window” maintained at each connection process
can be probed).

• Node-based (and global) statistics provide grouped information for all TCP
processes running in a node (and network) collectively. These are useful to
determine the total flow of traffic traversing through the TCP layer or the
average TCP layer delayed experienced by segments submitted by the
application processes.

Modeler/Release 10.0 STM-22-7

Standard Models User Guide 22 TCP Model User Guide

Figure 22-7 Selecting Statistics to Collect

During simulation execution, the different statistics grouped under “TCP

Connection” are annotated with information related to the connection for which
the statistics is being recorded:

Figure 22-8 Viewing Statistics

STM-22-8 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

The “View Results” option from the project work space provides a listing of
statistics that can be plotted -- each “TCP Connection”-related statistics
contains the “socket” information (i.e., local port, remote port, and remote
address) as shown below:

Figure 22-9 TCP Connection-related Statistics

Congestion Window Size (bytes) <Conn 1 [Ftp]: (Port 1024) <->

TCP Connection Information

Examples
An example project (called “TCP”) is shipped with the OPNET standard model
library. It highlights several features of the TCP model, including the different
algorithms modeled. The following graphs are from a simple network containing
one FTP traffic source sending 1MB file to a server. Different scenarios are

Modeler/Release 10.0 STM-22-9

Standard Models User Guide 22 TCP Model User Guide

modeled to monitor the effects of packet discarding by the network on

application response time and TCP’s congestion window. The effects of
enabling of Fast-Retransmit/Fast-Recovery algorithm is also shown in this
study.

Figure 22-10 Our Example Network

Application Traffic
Configuration Nodes

Workstation transferring Packet discarder Server supporting FTP

1 Mbyte to server. TCP dropping a packet service. It generates a
statistics are monitored during the congestion response when data
for this data transfer avoidance phase transfer completes

The results were obtained for the application layer response time and TCP
congestion window for three different simulations:

Figure 22-11 Sample Network Results

STM-22-10 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

The results show that the congestion window recovers fastest when the
Fast-Retransmit/Fast-Recovery algorithm are enabled (i.e., using a Reno
implementation) versus when they are disabled (i.e., when segment losses is
detected only upon retransmission time-out expiration). A dramatic
improvement in the application response time performance can also be seen as
a result of enabling Fast-Retransmit/Fast-Recovery algorithms under packet
drop conditions.

If you want to further understand TCP behavior and how it adapts as more and
more options are enabled/disabled, you can use the OPNET debugger (ODB)
and perform TCP model’s activity tracing using the command “ltrace tcp”. You
could also compare various statistics (e.g., Sent Sequence Segment Number
versus Received ACK Segment Number) or breakdown the statistics (e.g., TCP
Congestion Window) to get a better understanding of the results. For example,
if you examine the TCP Congestion Window statistic in the above example, you
can inspect how the Fast-Retransmit/Fast-Recovery works:

Figure 22-12 Effect of Fast-Retransmit/Fast-Recovery

Modeler/Release 10.0 STM-22-11

Standard Models User Guide 22 TCP Model User Guide

The following is a detailed analysis of the congestion window changes at

instances when Fast-Retransmit/Fast-Recovery features are activated:

Figure 22-13 TCP Congestion Window Statistics

A more detailed analysis can also be performed by running a simulation in ODB

and tracing the TCP protocol behavior.

Frequently Asked Questions

Question: My simulation generated retransmission-related simulation log
messages like the one shown below. What should I do?

Answer: Please note that each TCP process specifies criteria limiting the time
for which retransmission of a segment is attempted. The limit is either in terms
of a maximum number of attempts or a time interval. Once this threshold is
reached, the TCP connection is aborted. Different thresholds exist for control
(e.g., SYN) versus data segments.

STM-22-12 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

The above simulation log results after a TCP process has made six
unsuccessful attempts to transmit the same segment. If you think your network
can recover from limits greater than the default values specified for this attribute,
change the default on the node models using the “Retransmission Threshold”
sub-attribute in the “TCP Parameters” attribute. Note that this threshold setting
is typically set to “Attempts Based” on Windows systems, and “Time Based” on
UNIX systems.

Figure 22-14 Transmission Thresholds Table

Question: I need to inspect the TCP packets present in the network; how can I
check the contents of each TCP packet?”

Answer: Each TCP segment contains a TCP header, options and data field.
When running the simulation under the control of ODB, you can use the “pkprint”
command to print the contents of a TCP segment. It shows detailed information
about the contents of the segment header, options, and contained payload
information:

Modeler/Release 10.0 STM-22-13

Standard Models User Guide 22 TCP Model User Guide

Figure 22-15 Pkprint of the Contents of a TCP Segment

Question: I would like to obtain information about all connections managed by

TCP -- is there a way to print this information?

Answer: Set the “TCP Connection Information” attribute to “Print” —this prints
a list of TCP connections running in the surrounding node. The list is printed in
the console from which OPNET was launched.

Figure 22-16 TCP Connection Information

Question: What is the difference between “TCP” Statistics and “TCP

Connection” Statistics?

Answer: The “TCP Connection” group contains per-connection statistics (i.e.,

these are recorded separately per TCP connection), whereas statistics under
“TCP” group represents TCP performance across all connections within a given
node for which this statistic is collected.

STM-22-14 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Model Architecture
The following sections have more relevance to model developers (e.g., OPNET
Modeler users). It discusses the topics necessary for understanding the internal
details and interfacing to the TCP model. The following diagram illustrates the
relevant portions of a typical node model where the TCP model resides:

Figure 22-17 Node Model with TCP

Each node intended to use TCP has a “tcp” module, which contains a dispatcher
process that spawns connection processes:

Table 22-3 TCP Model Processes

tcp_manager_v3 Represents the root process of the “tcp” module. It manages a
set of TCP connections by invoking the appropriate
tcp_conn_v3 process to handle the arriving requests

tcp_conn_v3 Represents the TCP connection (i.e., “socket”) process, which

manages one end of a single connection. It is spawned by the
tcp_manager_v3 process to manage activities related to an
individual connection

End of Table 22-3

Modeler/Release 10.0 STM-22-15

Standard Models User Guide 22 TCP Model User Guide

Each TCP connection (also called socket processes) is a structured information

exchange between two connection processes. The following diagram illustrates
the role of socket processes in the OPNET TCP model suite:

Figure 22-18 Socket Processes in the TCP Model

application application application application

socket1 socket2 socket2 socket1

TCP TCP
Virtual Connections

The socket processes are dynamically created and destroyed upon application
requests. Each socket process (tcp_conn_v3) contains the core logic for various
TCP protocol features. To illustrate the conformance to specified standards,
note that the implementation of the TCP connection process in OPNET exactly
resembles the specification in RFC-793:

STM-22-16 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Figure 22-19 RFC-793 Specification Compared to OPNET’s TCP Process Model

RFC-793’s TCP
Connection State
Transition Diagram

OPNET’s “tcp_conn_v3”
TCP Connection
Process Model

Modeler/Release 10.0 STM-22-17

Standard Models User Guide 22 TCP Model User Guide

Model Interfaces
The following sections discuss the topics necessary for interfacing with the TCP
model.

Packet Formats
The following packet format is used to represent a TCP segment:

Table 22-4 TCP Packet Format

tcp_seg_v2 Represents a TCP segment. Used by TCP to encapsulate
application data for transmission to the remote end of the
connection. It contains fields for source/destination port
identification, status flags (e.g., SYN, FIN) and several other
TCP-specific information fields

End of Table 22-4

Each TCP segment contains a TCP header, options and data field. This is
defined by the following TCP packet format (tcp_seg_v2). In the packet format
editor, it looks like this:

Figure 22-20 TCP Packet Format

You can refer to the descriptions provided for each packet field to get more
details about their importance.

STM-22-18 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

ICI Formats
The following table lists the interface control information (ICI) formats used in
the TCP model suite:

Table 22-5 TCP ICI Formats

ip_encap_ind_v4 The lower level (network layer) protocols forward packets to
TCP accompanied by this ICI. It contains information about the
source network and source node of the arriving packet.

ip_encap_req_v4 The TCP processes use this format to specify the destination
network and node information to the Network Layer. The ICI
always accompanies (installed with) a packet transfer.

tcp_command_v3 The application layer processes use this ICI format to identify
the target TCP connection, so that the commands they issue
can be dispatched to the correct connection process. The
same ICI should be used for all interactions with a particular
connection for the duration of the connection. ICI reuse
simplifies the TCP interface, since the connection parameters
can be preserved when the connection is first opened.

tcp_status_ind_v3 The TCP connection process uses this ICI to notify the
Application Layer processes of important events. The
connection creates this ICI, but does not destroy it; the
application is responsible for destroying it.

tcp_open_ind When an application opens a passive session with the server,

the TCP connection process uses this ICI to notify the
application that the passive session has been bound. The
application then sends TCP a request to create a new passibe
connection.

End of Table 22-5

TCP Commands and Indications

The interface between TCP and the application is based on commands issued
by the application to TCP and indications returned to the application from TCP.
The commands and indications are identified by symbolic constants defined in
the C header file tcp_api_v3.h (located in the <models>/std/include directory);
any applications that interact with TCP should refer to this file to obtain these
definitions.

Modeler/Release 10.0 STM-22-19

Standard Models User Guide 22 TCP Model User Guide

The following table lists the various commands used in the TCP model suite:

Table 22-6 TCP Command Descriptions

Command Description

OPEN The application issues an OPEN command to the TCP module

to open a new connection. There are two types of OPEN
commands: OPEN_ACTIVE, which causes a segment to be sent
to the remote socket, requesting that the connection be
established; and OPEN_PASSIVE, which causes the local
socket to wait for an establishment request (SYN) segment. The
command is issued by forcing a remote interrupt at the TCP
module, with the code argument set to either
TCPC_COMMAND_OPEN_ACTIVE or
TCPC_COMMAND_OPEN_PASSIVE. The interrupt should
typically be forced rather than scheduled so that the “return
value” in the command ICI can be examined to determine
whether the command was successful.

SEND The application issues a SEND command to the TCP module to

send a packet to the other end of an established connection. This
is performed by sending the data packet to the TCP module. If
the connection was opened with an OPEN_PASSIVE command,
and the address or port information for the remote socket has not
yet been specified, the SEND command (which must, in this
case, be accompanied by the missing remote socket
information) also acts as an OPEN_ACTIVE command.

RECEIVE The application issues a RECEIVE command to request data.

The application sends the TCP module a remote interrupt with
the code argument set to TCPC_COMMAND_RECEIVE. The
connection process will then forward the requested number of
packets as soon as they become available. The RECEIVE
command takes one argument, the number of packets
requested.

CLOSE The application issues a CLOSE command to the TCP module

to indicate that it has finished sending data and is ready for the
connection to close. This is performed by sending a remote
interrupt with the code argument set to
TCPC_COMMAND_CLOSE. The local socket (tcp_conn_v3
process) begins the connection teardown sequence when this
command is issued.

ABORT The application issues an ABORT command to abruptly drop the

connection without carrying out the normal teardown sequence.
The application sends a remote interrupt with the code argument
set to TCPC_COMMAND_ABORT.

End of Table 22-6

STM-22-20 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Indications take the form of remote interrupts or stream interrupts issued from
the TCP connection process to the application. All indications are
accompanied by an ICI of type tcp_status_ind_v3, described earlier.

Table 22-7 TCP Indication Descriptions

TCP Indication Description

SEG_FWD The connection process forwards packets to the applications

when data requested by the application becomes available, or
when unrequested urgent data is received.

ESTAB The connection process uses a remote interrupt to indicate

connection establishment to the application. The status
attribute in the accompanying ICI is set to TCPC_IND_ESTAB.

CLOSED The connection process forwards a CLOSED indication to the

application layer at the end of the standard teardown
sequence. This relies on a remote interrupt with the status
attribute in the accompanying ICI set to TCPC_IND_CLOSED.

ABORTED The connection process an ABORTED indication to the

application to indicate an unexpected connection teardown.
The application is notified through a remote interrupt with the
status attribute in the accompanying ICI set to
TCPC_IND_ABORTED.

SEG_FWD The connection process forwards packets to the applications

when data requested by the application becomes available, or
when unrequested urgent data is received.

End of Table 22-7

Application Layer Interfacing

The following diagram illustrates the relevant portions of a typical application
layer process model which interfaces with the TCP model:

Figure 22-21 Typical Application Layer Process Model

Modeler/Release 10.0 STM-22-21

Standard Models User Guide 22 TCP Model User Guide

You can use one of two methods to create the application–to–TCP interface:
either directly, by using remote interrupts; or by using the TCP API. Unless you
are accustomed to creating this interface directly, you will probably find the API
method simpler.

• Issuing Commands Using Remote Interrupts: commands take the form of

remote interrupts or stream interrupts issued by the application to the TCP
manager process, which is the root process of the TCP module. All
commands must be accompanied by an ICI of type tcp_command_v3,
described earlier.

• Issuing Commands Using the TCP API: The TCP API is a set of functions
that hide many of the details involved in issuing commands. To use these
functions, declare the external source file tcp_api.ex.c; then include
tcp_api.h in the header block of the application-layer process:

Figure 22-22 Selecting External Files to Include

Each application module must first register itself with TCP using the function
tcp_app_register(); this returns a handle that the application uses as a
parameter in subsequent function calls. Dynamic processes within a single
application layer module can make copies of this handle to use in function calls
instead of re-registering.

The following table describes the mains functions available from this package:

Table 22-8 TCP API Package Description (Part 1 of 3)

ApiT_Tcp_App_Handle tcp_app_register (Objid app_module_id)

Purpose Registers application layer with the API package

Arguments Object ID of the module containing the application process

Return Value Handle containing connection information needed on all subsequent

calls to the API

STM-22-22 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Table 22-8 TCP API Package Description (Part 2 of 3)

int tcp_api_next_avl_port_get (ApiT_Tcp_App_Handle tcp_hndl)

Purpose Returns the next available port on the TCP layer for use by the
calling application

Arguments Handle returned from call to tcp_app_register()

Return Value The next available port number

int tcp_connection_open (ApiT_Tcp_App_Handle* tcp_hndle_ptr, IpT_Address

remote_address, int remote_port, int local_port, int command, int ip_tos)

Purpose Open a TCP connection between the host and a remote host

Arguments Pointer to the handle returned from a call to tcp_app_register()

IP address of the remote host (ignored if command is

TCPC_COMMAND_OPEN_PASSIVE)

Port on the local host

Either TCPC_COMMAND_OPEN_PASSIVE or
TCPC_COMMAND_OPEN_ACTIVE, depending on the desired
connection type

Value in the range 0–7 indicating desired setting as the precedence

field in the IP datagram header

Return Value ID of the TCP connection

void tcp_appl_name_from_rem_port_get (GnaT_App remote_port, char* appl_name)

Purpose Copies the application name (“Ftp”, “E-mail”, etc.) corresponding to

the remote port specified

Arguments Enumerated value indicating the application remote port

Pointer to a destination buffer that will store the application name.

This buffer must be large enough to hold the application string

Return Value None

void tcp_data_send (ApiT_Tcp_App_Handle tcp_hndl, Packet* data_pkptr)

Purpose Send data packets over the connection once it is established

Arguments Handle returned from call to tcp_app_register()

Pointer to the packet the application wishes to send

Return Value None

void tcp_receive_command_send (ApiT_Tcp_App_Handle tcp_hndl, int receive_count)

Modeler/Release 10.0 STM-22-23

Standard Models User Guide 22 TCP Model User Guide

Table 22-8 TCP API Package Description (Part 3 of 3)

Purpose Indicate to the TCP layer that the application is prepared to receive
one or more packets from the remote host

Arguments Handle returned from call to tcp_app_register()

Maximum number of additional packets the application is willing to

accept (i.e., in addition to the sum of all unfulfilled receive requests
already issued)

Return Value None

ApiT_Tcp_App_Handle tcp_intf_hndl_copy (ApiT_Tcp_App_Handle tcp_hndl)

Purpose Returns the original data handle passed as the parameter tcp_hndl.
This allows the application calling this function to copy the handle’s
data values into a new variable

Arguments Handle returned from call to tcp_app_register()

Return Value The same handle as the parameter tcp_hndl

void tcp_connection_close (ApiT_Tcp_App_Handle tcp_hndl)

Purpose Close the connection after all data has been sent

Arguments Handle returned from call to tcp_app_register()

Return Value None

void tcp_connection_abort (ApiT_Tcp_App_Handle tcp_hndl)

Purpose Terminate the connection early. This may be necessary due the
application layer requirements

Arguments Handle returned from call to tcp_app_register()

Return Value None

void tcp_api_fatal_error (char* msg_str)

Purpose Copies the error message referenced by msg_str* to standard

output and terminates the simulation

Arguments Pointer to a string buffer containing the appropriate error message

Return Value None

End of Table 22-8

STM-22-24 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

Debugging/Simulation Tracing
The TCP model provides several simulation run-time tracing and debugging
features. These include labeled traces and diagnostic block code execution
when simulation is run under the control of OPNET simulation debugger (ODB).

The following table lists the various label traces that can be used while
understanding the behavior of the TCP models:

Table 22-9 TCP Label Traces

tcp Prints all protocol-specific information tracked by the TCP
model. This includes sending connection open requests, data
transfer, retransmissions, ACK handling, connection close, etc.
This trace prints information across all managed connections

tcp_extensions Prints information related to TCP extensions modeling -- Fast

Retransmit/Fast Recovery, Selective ACKnowledgments, and
Window Scaling across all managed connections

tcp_retransmissions Prints information related to TCP retransmissions. This trace

comes in handy when you want to accurately determine the
event at which a retransmission occurs to understand the
subsequent actions taken by TCP

tcp_conn_id_<n> This trace can be used to print all protocol-specific information

for the TCP process with connection identifier <n>. Every TCP
connection in OPNET is assigned a connection identifier -- this
identifier can be determined by setting the “TCP Connection
Information” model attribute to “Print”

End of Table 22-9

Modeler/Release 10.0 STM-22-25

Standard Models User Guide 22 TCP Model User Guide

The following section illustrates how you can navigate through the different
debugging/tracing features available in the TCP model. It assumes that you
have enabled the “debug” option for a simulation containing TCP elements:

Figure 22-23 OPNET Simulation Debugger

TCP “passive”
Connection Open

TCP “active”
Connection Open

You can track the exact state of a TCP connection by using the following steps:

• Determine the list of “tcp” modules. For the object (i.e., node) of interest,
determine the object ID of the “tcp” module

• Find a list of processes running within that module: You will notice that there
is always one “tcp_manager_v3” and one or more “tcp_conn_v3” processes
running under this module

• For the connection process of interest, print the diagnostic block contents.

STM-22-26 Modeler/Release 10.0

Standard Models User Guide 22 TCP Model User Guide

The following example shows how to obtain the above-mentioned information.

Figure 22-24 Debugger Output

TCP’s diagnostic block

provides information about
the current timers, “cwnd”
size, segment buffers, etc.

A special label “tcp_ooo_list” is available within the context of the diagnostic

block to print information about segments that are received out-of-order

Figure 22-25 Out-of-order List

Out-of-order
Received Segment List

Modeler/Release 10.0 STM-22-27

Standard Models User Guide 22 TCP Model User Guide

STM-22-28 Modeler/Release 10.0