tcp.tex

柯老师网站上找到的

The {\tt Agent/TCP/FullTcp} object is a new addition to the suite of
TCP agents supported in the simulator and is still under development.
It is different from (and incompatible with) the other agents, but
does use some of the same architecture.
It differs from these agents in the following ways:
following ways:
\begin{itemize}\itemsep0pt
\item connections may be establised and town down
(SYN/FIN packets are exchanged)
\item bidirectional data transfer is supported
\item sequence numbers are in bytes rather than packets
\end{itemize}

The generation of SYN packets (and their ACKs) can be
of critical importance in trying to model real-world behavior
when using many very short data transfers.
This version of TCP currently defaults to sending
data on the 3rd segment of an initial 3-way handshake, a behavior
somewhat different than common real-world TCP implementations.
A ``typical'' TCP connection proceeds with an active opener
sending a SYN, the passive opener responding with a SYN+ACK,
the active opener responding with an ACK, and then some time later
sending the first segment with data (corresponding to the first
application write).
Thus, this version of TCP sends data at a time somewhat earlier
than typical implementations.
This TCP can also be configured to send data on the initial SYN
segment.
Future changes to FullTCP may include a modification to send the
first data segment later, and possibly to implement T/TCP functionality.

Currently FullTCP is only implemented with Reno congestion control,
but ultimately it should be available with the full range of
congestion control algorithms (e.g., Tahoe, SACK, Vegas, etc.).


\subsection{Simple Configuration}
\label{sec:simpleconfig}
Running an Full 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.

\paragraph{Creating the Agent}
\begin{program}
# {\cf set up connection (do not use "create-connection" method because }
# {\cf we need a handle on the sink object)}
set src [new Agent/TCP/FullTcp] \; create agent;
set sink [new Agent/TCP/FullTcp] \; create agent;
$ns_ attach-agent $node_(s1) $src \; bind src to node;
$ns_ attach-agent $node_(k1) $sink \; bind sink to node;
$src set fid_ 0   \; set flow ID field;
$sink set fid_ 0  \; set flow ID field;
$ns_ connect $src $sink \; active connection src to sink;

# {\cf set up TCP-level connections}
$sink listen \; will figure out who its peer is;
$src set window_ 100;
\end{program}

The creation of the FullTcp agent is similar to the other agents,
but the sink is placed in a listening state by the {\tt listen} method.
Because a handle to the receiving side is required in order to make
this call, the {\tt create-connection} call used above cannot be used.

\paragraph{Configuration Parameters}
The following configuration parameters are available through Tcl
for the FullTcp agent:
\begin{program}
Agent/TCP/FullTcp set segsperack_ 1 \; segs received before generating ACK;
Agent/TCP/FullTcp set segsize_ 536  \; segment size (MSS size for bulk xfers);
Agent/TCP/FullTcp set tcprexmtthresh_ 3 \; dupACKs thresh to trigger fast rexmt;
Agent/TCP/FullTcp set iss_ 0 \; initial send sequence number;
Agent/TCP/FullTcp set nodelay_ false \; disable sender-side Nagle algorithm;
Agent/TCP/FullTcp set data_on_syn_ false \; send data on initial SYN?;
Agent/TCP/FullTcp set dupseg_fix_ true \; avoid fast rxt due to dup segs+acks;
Agent/TCP/FullTcp set dupack_reset_ false \; reset dupACK ctr on !0 len data segs containing dup ACKs;
Agent/TCP/FullTcp set interval_ 0.1 \; as in TCP above, (100ms is non-std);
\end{program}

\section{Architecture and Internals}
\label{sec:tcparchitecture}

The base TCP agent (class {\tt Agent/TCP}) is constructed
as a collection of routines for sending packets, processing ACKs,
managing the send window, and handling timeouts.
Generally, each of these routines may be over-ridden by a
function with the same name in a derived class (this is how
many of the TCP sender variants are implemented).

\paragraph{The TCP header}
The TCP header is defined by the {\tt hdr\_tcp} structure
in the file \nsf{tcp.h}.
The base agent only makes use of the following subset of the fields:
\begin{program}
ts_     \* current time packet was sent from source */
ts_echo_ \* for ACKs: timestamp field from packet associated with this ACK */
seqno_ \* sequence number for this data segment or ACK (Note: overloading!) */
reason_ \* set by sender when (re)transmitting to trace reason for send */
\end{program}

\paragraph{Functions for Sending Data}
Note that generally the sending TCP never actually sends
data (it only sets the packet size).

{\bf send\_much(force, reason, maxburst)} - this function
attempts to send as many packets as the current sent window allows.
It also keeps track of how many packets it has sent, and limits to the
total to {\em maxburst}. \\
The function {\tt output(seqno, reason)} sends one packet
with the given sequence number and updates the maximum sent sequence
number variable ({\tt maxseq\_}) to hold the given sequence number if
it is the greatest sent so far.
This function also assigns the various fields in the TCP
header (sequence number, timestamp, reason for transmission).
This function also sets a retransmission timer if one is not already
pending.

\paragraph{Functions for Window Management}

The usable send window at any time is given by the function {\bf window()}.
It returns the minimum of the congestion window and the variable {\tt wnd\_},
which represents the receiver's advertised window.

{\bf opencwnd()} - this function opens the congestion window.  It is invoked
when a new ACK arrives.
When in slow-start, the function merely increments {\tt cwnd\_} by each
ACK received.
When in congestion avoidance, the standard configuration increments {\tt cwnd\_}
by its reciprocal.
Other window growth options are supported during congestion avoidance,
but they are experimental (and not documented; contact Sally Floyd for
details).

{\bf closecwnd(int how)} - this function reduces the congestion window. It
may be invoked in several ways: when entering fast retransmit, due to
a timer expiration, or due to a congestion notification (ECN bit set).
Its argument {\tt how} indicates how the congestion window should
be reduced.  The value {\bf 0} is used for retransmission timeouts and
fast retransmit in Tahoe TCP.  It typically causes the TCP to enter
slow-start and reduce {\tt ssthresh\_} to half the current window.
The value {\bf 1} is used by Reno TCP for implementing fast recovery
(which avoids returning to slow-start).
The value {\bf 2} is used for reducing the window due to an ECN indication.
It resets the congestion window to its initial value (usually causing
slow-start), but does not alter {\tt ssthresh\_}.

\paragraph{Functions for Processing ACKs}

{\bf recv()} - this function is the main reception path for ACKs.
Note that because only one direction of data flow is in use, this function
should only ever be invoked with a pure ACK packet (i.e. no data).
The function stores the timestamp from the ACK in {\tt ts\_peer\_}, and
checks for the presence of the ECN bit (reducing the send window if
appropriate).
If the ACK is a new ACK, it calls {\bf newack()}, and otherwise
checks to see if it is a duplicate of the last ACK seen.
If so, it enters fast retransmit by closing the window, resetting the
retransmission timer, and sending a packet by calling {\tt send\_much}.

{\bf newack()} - this function processes a ``new'' ACK (one that contains
an ACK number higher than any seen so far).
The function sets a new retransmission timer by calling {\bf newtimer()},
updates the RTT estimation by calling {\bf rtt\_update}, and updates
the highest and last ACK variables.

\paragraph{Functions for Managing the Retransmission Timer}

These functions serve two purposes: estimating the round-trip time
and setting the actual retransmission timer.
{\bf rtt\_init} - this function initializes {\tt srtt\_} and {\tt rtt\_}
to zero, sets {\tt rttvar\_} to $3/tcp\_tick\_$, and sets the backoff
multiplier to one.

{\bf rtt\_timeout} - this function gives the timeout value in seconds that
should be used to schedule the next retransmission timer.
It computes this based on the current estimates of the mean and deviation
of the round-trip time.  In addition, it implements Karn's
exponential timer backoff for multiple consecutive retransmission timeouts.

{\bf rtt\_update} - this function takes as argument the measured RTT
and averages it in to the running mean and deviation estimators
according to the description above.
Note that {\tt t\_srtt\_} and {\tt t\_rttvar} are both
stored in fixed-point (integers).
They have 3 and 2 bits, respectively, to the right of the binary
point.

{\bf reset\_rtx\_timer} -  This function is invoked during fast retransmit
or during a timeout.
It sets a retransmission timer
by calling {\tt set\_rtx\_timer} and if invoked by a timeout also calls
{\tt rtt\_backoff}.

{\bf rtt\_backoff} - this function backs off the retransmission timer
(by doubling it).

{\bf newtimer} - this function called only when a new ACK arrives.
If the sender's left window edge is beyond the ACK, then
{\tt set\_rtx\_timer} is called, otherwise if a retransmission timer
is pending it is cancelled.

\section{Tracing TCP Dynamics}
\label{sec:traceTcpdyn}

The behavior of TCP is often observed by constructing a
sequence number-vs-time plot.
Typically, a trace is performed by enabling tracing on a link
over which the TCP packets will pass.
Two trace methods are supported: the default one (used for tracing
TCP agents), and an extension used only for FullTcP.

\section{One-Way Trace TCP Trace Dynamics}
\label{sec:trace1WayTcpdyn}

TCP packets generated by one of the one-way TCP agents and destined for
a TCP sink agent
passing over a traced link (see section~\ref{chap:trace})
will generate a trace file lines of the form:
\begin{verbatim}
+ 0.94176 2 3 tcp 1000 ------ 0 0.0 3.0 25 40
+ 0.94276 2 3 tcp 1000 ------ 0 0.0 3.0 26 41
d 0.94276 2 3 tcp 1000 ------ 0 0.0 3.0 26 41
+ 0.95072 2 0 ack 40 ------ 0 3.0 0.0 14 29
- 0.95072 2 0 ack 40 ------ 0 3.0 0.0 14 29
- 0.95176 2 3 tcp 1000 ------ 0 0.0 3.0 21 36
+ 0.95176 2 3 tcp 1000 ------ 0 0.0 3.0 27 42
\end{verbatim}
The exact format of this trace file is given in section~\ref{sec:traceformat}.
When tracing TCP, packets of type {\sf tcp} or {\sf ack} are relevant.
Their type, size, sequence number (ack number for ack packets),
and arrival/depart/drop time are given by field positions
5, 6, 11, and 2, respectively.
The {\sf +} indicates a packet arrival, {\sf d} a drop, and {\sf -} a
departure.
A number of scripts process this file to produce graphical output or
statistical summaries (see,  for example, \nsf{test-suite.tcl}, the
{\tt finish} procedure.

\section{One-Way Trace TCP Trace Dynamics}
\label{sec:tcpdyn}

TCP packets generated by FullTcp and
passing over a traced link contain additional information not displayed
by default using the regular trace object.
By enabling the flag {\tt show\_tcphdr\_} on the trace object
(see section~ref{sec:traceformat}), 3 additional header fields are
written to the trace file: ack number, tcp-specific flags, and header length.


\section{Commands at a glance}
\label{sec:tcpcommand}

The following is a list of commands used to setup/manipulate TCP flows
for simulations:
\begin{flushleft}
\code{set tcp0 [new Agent/TCP]}\\
This creates an instance of a TCP agent. There are several flavors of
TCP-sender and TCP-receiver (or sink) agent currently implemented in ns.
TCP-senders currently available are:
Agent/TCP, Agent/TCP/Reno, Agent/TCP/NewReno, Agent/TCP/Sack1, Agent/TCP/Vegas,
Agent/TCP/Fack. \\
TCP-receivers currently available are:
Agent/TCPSink, Agent/TCPSink/DelAck, Agent/TCPSink/Sack1,
Agent/TCPSink/Sack1/DelAck.\\
There is also a two-way implementation of tcp called Agent/TCP/FullTcp. For
details on the different TCP flavors see earlier sections of this chapter.


Configuration parameters for TCP flows maybe set as follows:\\
\code{$tcp set window_ <wnd-size>}\\
For all possible configuration parameters available for TCP see section
\ref{sec:other-tcp-config}. The default configuration values can also be
found in \ns/tcl/lib/ns-default.tcl.


Following is an example of a simple TCP connection setup:
\begin{program}
set tcp [new Agent/TCP] \; create tcp agent;
$ns_ attach-agent $node_(s1) $tcp \; bind src to node;
$tcp set fid_ 0   \; set flow ID field;
set ftp [new Application/FTP]   \; create ftp traffic;
$ftp attach-agent $tcp  \; bind ftp traffic to tcp agent;
set sink [new Agent/TCPSink] \; create tcpsink agent;
$ns_ attach-agent $node_(k1) $sink \; bind sink to node;
$sink set fid_ 0  \; set flow ID field;
$ns_ connect $src $sink \; active connection src to sink;
$ns_ at $start-time "$ftp start"  \; start ftp flow;
\end{program}

For an example of setting up a full-tcp connection see section
\ref{sec:simpleconfig}.

\end{flushleft}

\endinput