tcp.tex

柯老师网站上找到的

\chapter{TCP Agents}
\label{sec:tcpAgents}

This section describes the operation of the TCP agents in \ns.
There are two major types of TCP agents: one-way agents
and a two-way agent.
One-way agents are further subdivided into a set of TCP senders
(which obey different congestion and error control techniques)
and receivers (``sinks'').
The two-way agent is symmetric in the sense that it represents
both a sender and receiver.
It is still under development.

The files described in this section are too numerous to enumerate here.
Basically it covers most files matching the regular expression
\nsf{tcp*.\{cc, h\}}.

The one-way TCP sending agents currently supported are:
\begin{itemize}\itemsep0pt
        \item Agent/TCP - a ``tahoe'' TCP sender
        \item Agent/TCP/Reno - a ``Reno'' TCP sender
        \item Agent/TCP/NewReno - Reno with a modification
        \item Agent/TCP/Sack1 - TCP with selective repeat (follows RFC2018)
        \item Agent/TCP/Vegas - TCP Vegas
        \item Agent/TCP/Fack - Reno TCP with ``forward acknowledgment''
\end{itemize}
The one-way TCP receiving agents currently supported are:
\begin{itemize}\itemsep0pt
        \item Agent/TCPSink - TCP sink with one ACK per packet
        \item Agent/TCPSink/DelAck - TCP sink with configurable delay per ACK
        \item Agent/TCPSink/Sack1 - selective ACK sink (follows RFC2018)
        \item Agent/TCPSink/Sack1/DelAck - Sack1 with DelAck
\end{itemize}
The two-way experimental sender currently supports only a Reno form of TCP:
\begin{itemize}
        \item Agent/TCP/FullTcp
\end{itemize}

The section comprises three parts:
the first part is a simple overview and example of configuring
the base TCP send/sink agents (the sink requires no configuration).
The second part describes the internals of the base send agent,
and last part is a description of the extensions
for the other types of agents that have been included in the
simulator.

\section{One-Way TCP Senders}
\label{sec:oneWayTcp}

The simulator supports several versions of an abstracted TCP sender.
These objects attempt to capture the essence of the TCP congestion
and error control behaviors, but are not intended to be faithful
replicas of real-world TCP implementations.
They do not contain a dynamic window advertisement, they do segment
number and ACK number computations entirely in packet units,
there is no SYN/FIN connection establishment/teardown, and no
data is ever transferred (e.g. no checksums or urgent data).

\subsection{The Base TCP Sender (Tahoe TCP)}
\label{sec:tahoetcp}

The ``Tahoe'' TCP agent \code{Agent/TCP} performs congestion
control and round-trip-time estimation
in a way similar to the version of TCP released with the
4.3BSD ``Tahoe'' UN'X system release from UC Berkeley.
The congestion window is increased by one packet per new ACK received
during slow-start (when $cwnd\_ < ssthresh\_$) and is increased
by $\frac{1}{cwnd\_}$ for each new ACK received during congestion avoidance
(when $cwnd\_ \geq ssthresh\_$).

\paragraph{Responses to Congestion}
Tahoe TCP assumes a packet has been lost (due to congestion)
when it observes {\tt NUMDUPACKS} (defined in \code{tcp.h}, currently 3)
duplicate ACKs, or when a retransmission timer expires.
In either case, Tahoe TCP reacts by setting {\tt ssthresh\_} to half
of the current window size (the minimum of {\tt cwnd\_} and {\tt window\_})
or 2, whichever is larger.
It then initializes {\tt cwnd\_} back to the value of
{\tt windowInit\_}.  This will typically cause the TCP to
enter slow-start.

\paragraph{Round-Trip Time Estimation and RTO Timeout Selection}
Four variables are used to estimate the round-trip time and
set the retransmission timer: {\tt rtt\_, srtt\_, rttvar\_, tcpTick\_,
and backoff\_}.
TCP initializes rttvar to $3/tcpTick\_$ and backoff to 1.
When any future retransmission timer is set, it's timeout
is set to the current time plus $\max(bt(a+4v+1), 64)$ seconds,
where $b$ is the current backoff value, $t$ is the value of tcpTick,
$a$ is the value of srtt, and $v$ is the value of rttvar.

Round-trip time samples arrive with new ACKs.
The RTT sample is computed as the difference between the current
time and a ``time echo'' field in the ACK packet.
When the first sample is taken, its value is used as the initial
value for {\tt srtt\_}.  Half the first sample is used as the initial
value for {\tt rttvar\_}.
For subsequent samples, the values are updated as follows:

\[ srtt = \frac{7}{8} \times srtt + \frac{1}{8} \times sample \]
\[ rttvar = \frac{3}{4} \times rttvar + \frac{1}{4} \times |sample-srtt| \]

\subsection{Configuration}
\label{sec:tcp-config}

Running an TCP simulation requires
creating and configuring the agent,
attaching an application-level data source (a traffic generator), and
starting the agent and the traffic generator.

\subsection{Simple Configuration}

\paragraph{Creating the Agent}
\begin{program}
set ns [new Simulator]                  \; preamble initialization;
set node1 [$ns node]                     \; agent to reside on this node;
set node2 [$ns node]                     \; agent to reside on this node;

{\bfseries{}set tcp1 [$ns create-connection TCP $node1 TCPSink $node2 42]}
$tcp  set window_ 50                   \; configure the TCP agent;

{\bfseries{}set ftp1 [new Application/FTP]}
{\bfseries{}$ftp1 attach-agent $tcp1}

$ns at 0.0 "$ftp start"
\end{program}
This example illustrates the use of the simulator built-in
function {\tt create-connection}.
The arguments to this function are: the source agent to create,
the source node, the target agent to create, the target node, and
the flow ID to be used on the connection.
The function operates by creating the two agents, setting the
flow ID fields in the agents, attaching the source and target agents
to their respective nodes, and finally connecting the agents
(i.e. setting appropriate source and destination addresses and ports).
The return value of the function is the name of the source agent created.

\paragraph{TCP Data Source}
The TCP agent does not generate any application data on its own;
instead, the simulation user can connect any traffic generation
module to the TCP agent to generate data.
Two applications are commonly used for TCP: FTP and Telnet.
FTP represents a bulk data transfer of large size, and telnet chooses
its transfer sizes randomly from tcplib (see the file
\code{tcplib-telnet.cc}.
Details on configuring these application source objects are in
Section~\ref{sec:simapps}.

\subsection{Other Configuration Parameters}
\label{sec:other-tcp-config}

In addition to the \code{window_} parameter listed above,
the TCP agent supports additional configuration variables.
Each of the variables described in this subsection is
both a class variable and an instance variable.
Changing the class variable changes the default value
for all agents that are created subsequently.
Changing the instance variable of a particular agent
only affects the values used by that agent.
For example,
\begin{program}
  Agent/TCP set window_ 100     \; Changes the class variable;
  $tcp set window_ 2.0          \; Changes window_ for the $tcp object only;
\end{program}

The default parameters for each TCP agent are:
\begin{program}
Agent/TCP set window_   20              \; max bound on window size;
Agent/TCP set windowInit_ 1             \; initial/reset value of cwnd;
Agent/TCP set windowOption_ 1           \; cong avoid algorithm (1: standard);
Agent/TCP set windowConstant_ 4         \; used only when windowOption != 1;
Agent/TCP set windowThresh_ 0.002       \; used in computing averaged window;
Agent/TCP set overhead_ 0               \; !=0 adds random time between sends;
Agent/TCP set ecn_ 0                    \; TCP should react to ecn bit ;
Agent/TCP set packetSize_ 1000          \; packet size used by sender (bytes);
Agent/TCP set bugFix_ true              \; see explanation;
Agent/TCP set slow_start_restart_ true  \; see explanation;
Agent/TCP set tcpTick_ 0.1              \; timer granulatiry in sec (.1 is NONSTANDARD);
Agent/TCP set maxrto_ 64                \; bound on RTO (seconds);
Agent/TCP set dupacks_ 0                \; duplicate ACK counter;
Agent/TCP set ack_ 0                    \; highest ACK received;
Agent/TCP set cwnd_ 0                   \; congestion window (packets);
Agent/TCP set awnd_ 0                   \; averaged cwnd (experimental);
Agent/TCP set ssthresh_ 0               \; slow-stat threshold (packets);
Agent/TCP set rtt_ 0                    \; rtt sample;
Agent/TCP set srtt_ 0                   \; smoothed (averaged) rtt;
Agent/TCP set rttvar_ 0                 \; mean deviation of rtt samples;
Agent/TCP set backoff_ 0                \; current RTO backoff factor;
Agent/TCP set maxseq_ 0                 \; max (packet) seq number sent;
\end{program}

For many simulations, few of the configuration parameters are likely
to require modification.
The more commonly modified parameters include: {\tt window\_} and
{\tt packetSize\_}.
The first of these bounds the window TCP uses, and is considered
to play the role of the receiver's advertised window in real-world
TCP (although it remains constant).
The packet size essentially functions like the MSS size in real-world
TCP.
Changes to these parameters can have a profound effect on the behavior
of TCP.
Generally, those TCPs with larger packet sizes, bigger windows, and
smaller round trip times (a result of the topology and congestion) are
more agressive in acquiring network bandwidth.

\subsection{Other One-Way TCP Senders}

\paragraph{Reno TCP}
The Reno TCP agent is very similar to the Tahoe TCP agent,
except it also includes {\em fast recovery}, where the current
congestion window is ``inflated'' by the number of duplicate ACKs
the TCP sender has received before receiving a new ACK.
A ``new ACK'' refers to any ACK with a value higher than the higest
seen so far.
In addition, the Reno TCP agent does not return to slow-start during
a fast retransmit.
Rather, it reduces sets the congestion window to half the current
window and resets {\tt ssthresh\_} to match this value.

\paragraph{NewReno TCP}
This agent is based on the Reno TCP agent, but which modifies the
action taken when receiving new ACKS.
In order to exit fast recovery, the sender must receive an ACK for the
highest sequence number sent.
Thus, new ``partial ACKs'' (those which represent new ACKs but do not
represent an ACK for all outstanding data) do not deflate the window
(and possibly lead to a stall, characteristic of Reno).

\paragraph{Vegas TCP}
This agent implements ``Vegas'' TCP (\cite{Brak94:TCP,Brak94a:TCP}).
It was contributed by Ted Kuo.

\paragraph{Sack TCP}
This agent implements selective repeat, based on selective ACKs provided
by the receiver.
It follows the ACK scheme described in \cite{rfc2018}, and was developed
with Matt Mathis and Jamshid Mahdavi.

\paragraph{Fack TCP}
This agent implements ``forward ACK'' TCP, a modification of Sack
TCP described in \cite{Math96:Forward}.

\section{TCP Receivers (sinks)}

The TCP senders described above represent one-way data senders.
They must peer with a ``TCP sink'' object.

\subsection{The Base TCP Sink}

The base TCP sink object ({\tt Agent/TCPSink})
is responsible for returning ACKs to
a peer TCP source object.
It generates one ACK per packet received.
The size of the ACKs may be configured.
The creation and configuration of the TCP sink object
is generally performed automatically by a library
call (see {\tt create-connection} above).

\paragraph{configuration parameters}
\begin{program}
        Agent/TCPSink set packetSize_ 40
\end{program}

\subsection{Delayed-ACK TCP Sink}

A delayed-ACK sink object ({\tt Agent/Agent/TCPSink/DelAck}) is available
for simulating a TCP receiver that ACKs less than once per packet received.
This object contains a bound variable {\tt interval\_} which gives the
number of seconds to wait between ACKs.
The delayed ACK sink implements an agressive ACK policy whereby
only ACKs for in-order packets are delayed.
Out-of-order packets cause immediate ACK generation.

\paragraph{configuration parameters}
\begin{program}
        Agent/TCPSink/DelAck set interval_ 100ms
\end{program}

\subsection{Sack TCP Sink}

The selective-acknowledgment TCP sink ({\tt Agent/TCPSink/Sack1}) implements
SACK generation modeled after the description of SACK in RFC 2018.
This object includes a bound variable {\tt maxSackBlocks\_} which gives
the maximum number of blocks of information in an ACK available for
holding SACK information.
The default value for this variable is 3, in accordance with the expected
use of SACK with RTTM (see RFC 2018, section 3).
Delayed and selective ACKs together are implemented by
an object of type {\tt Agent/TCPSink/Sack1/DelAck}.

\paragraph{configuration parameters}
\begin{program}
        Agent/TCPSink set maxSackBlocks_ 3
\end{program}

\section{Two-Way TCP Agents (FullTcp)}
\label{sec:fulltcp}