%
% x-kernel v3.3
%
% Copyright (c) 1996,1993,1991,1990  Arizona Board of Regents
%

\section{Ptcp}\label{Ptcp}

{\it Ptcp} is a graphical analysis tool used to analyze trace output
from {\xS} simulations. The ptcp can be used as follows.


Invoking the "ptcp" tool:
\begin{verbatim}
ptcp [arguments] <plot types> trace-filename
\end{verbatim}

plot types:
\begin{verbatim}
win
\end{verbatim}
Plot different windows (congestion, etc.)
\begin{verbatim}
rate
\end{verbatim}
Plot the sending rate.
\begin{verbatim}
vegas
\end{verbatim}
Plot Vegas information
\begin{verbatim}
rtt
\end{verbatim}
Plot RTT.
\begin{verbatim}
drtt
\end{verbatim}
Plot RTT differences.
\begin{verbatim}
seq
\end{verbatim}
Plot sequence numbers.

Args:
\begin{verbatim}
-t
\end{verbatim}
Starts graphs at time 0 (when the simulator started). The default is
to start graphing at the time the connection is opened.
\begin{verbatim}
-pn
\end{verbatim}
Create page information so postscript browsers, like ghostview,
can jump to any page.
\begin{verbatim}
-db=<file-name>
\end{verbatim}
To append file with data about the transfer. The entries are in ascii.
For further information refer to the database documentation
(to be written later).
\begin{verbatim}
-sid=<sid>
\end{verbatim}
Used to specify the session (connection) id when there were more than
one connection.
\begin{verbatim}
-xtime=<time>
\end{verbatim}
Time in ms covered by each graph. If the transfer lasts longer than
this time, more than one graph will be created.
\begin{verbatim}
-xtics=<time>
\end{verbatim}
Show tic marks in the time axis every <time> ms.
\begin{verbatim}
-xbeg=<time>
\end{verbatim}
Beginning time, in ms, of first plot.
\begin{verbatim}
-xend=<time>
\end{verbatim}
Ending time, in ms, of last plot. Xbeg and xend specify the time range
to plot.

\begin{verbatim}
-journal
\end{verbatim}
Create plots suitable for publication. The plots show less features.
\begin{verbatim}
-noEvents
\end{verbatim}
Don't show events such as packets with old acks, packets with
RST, SYN, FIN, timeout KEEP events, etc.
\begin{verbatim}
-journal=<#>
\end{verbatim}
Similar to -journal, except that it will create an encapsulated
postscript file of the right size to hold \# plots.
\begin{verbatim}
-header
\end{verbatim}
Insert header information at the beginning of the
file. One can run ptcp multiple times and have
each run's plot appended to the same file (see the
-a flag). The first time ptcp is ran it should have
the -header flag, the last time it is ran it should
have the -tail flag).
\begin{verbatim}
-tail
\end{verbatim}
Include necessary commands at the end of the
postscript file.
\begin{verbatim}
-allplot
\end{verbatim}
This flags is equivalent to the -header and -tail flags.

\begin{verbatim}
-a
\end{verbatim}
Append this plot to the default output file
(trace.ps) or to the file specified with the -o
argument.
\begin{verbatim}
-o <filename>
\end{verbatim}
Use filename as the output file containing the
postscript commands to do the plots.
\begin{verbatim}
-scale
\end{verbatim}

Scale the output by .8 in the y direction
\begin{verbatim}
-n <comment>
\end{verbatim}

Add the comment at the top of the 1st page.
\begin{verbatim}
-big
\end{verbatim}
Create big plots suitable for slides. The time
axis in each plot will only show 1/2 the time
specified with -xtime.
\begin{verbatim}
-maxRate=<rate>
\end{verbatim}
Set the y axis to maxRate when plotting the 
sending rate.
\begin{verbatim}
-rateTic=<#>
\end{verbatim}
Plot tic marks at multiples of \# when plotting 
sending rate.
\begin{verbatim}
-arn=<#>
\end{verbatim}
How many entries to use when doing running average
of sending rate.

\begin{verbatim}
-maxWin=<#>
\end{verbatim}
Similar to -maxRate, but refers to window plot.
\begin{verbatim}
-winTic=<#>
\end{verbatim}
Similar to -rateTic, but refers to window plot.

Note: If using only 1 sid, then always use -sid=232
\newpage

\begin{figure}[ht]
\centering
\leavevmode\hbox{\epsfig{file=graphdesc2.ps,height=2.15in}}
\caption{TCP Windows Graph.}\label{graphdescx}
\end{figure} 

To assist the reader develop a better understanding of the graphs produced
by ptcp  and to gain a better insight of TCP's
behavior, we describe in detail one of these graphs. 
Figure~\ref{graphdescx} is a trace of Reno when there is other 
traffic through the a router.
The numbers in parenthesis refer to the type of line in the graph.

In general, output is allowed while the UNACK-COUNT~(4) (number of bytes
sent but not acknowledged) is less than the congestion window~(3)
and less than the send window~(2). The purpose of the congestion
window is to prevent substained congestion. The send window is used 
for flow control; it prevents data
from being sent when there is no buffer space availabe at the
receiver.

The threshold window~(1) is set to the maximum value (64KB) at the
beginning of the connection.  Soon after the connection is started,
both sides exchange information on the size of their respective 
receive buffers,
and the send window~(2) is set to the minimum of the sender's send
buffer size and the receiver's advertized window size. 

The congestion window~(3) increases exponentially while it is less
than the threshold window~(1). At 0.75 seconds, losses start to occur
(indicated by the tall vertical lines). More precisely, the vertical
lines represent segments that are later retransmited (usually because
they were lost). At around 1 second, a loss is detected after
receiving 3 duplicate ACKs and Reno's Fast Retransmit and Fast
Recovery mechanisms go into action.  The purpose of these mechanisms
is to detect losses before a retransmit timeout occurs, and to keep
the pipe full (we can think of a connection's path as a water pipe,
and our goal is to keep it full of water) while recovering 
from these losses.

The congestion window~(3) is set to the maximal allowed segment size
(for this connection) and the UNACK-COUNT is set to zero momentarily,
allowing the lost segment to be retransmitted.  The threshold
window~(1) is set to half the value that the congestion window had
before the losses (it is assumed that this is a safe level, that
losses won't occur at this window size).

The congestion window~(3) is also set to this value after
retransmitting the lost segment, but it increases with each duplicate
ACK (segments whose acknowledgement number is the same as previous
segments and carry no data or new window information).  Since the
receiver sends a duplicate ACK when it receives a segment that it
cannot acknowledge (because it has not received all previous data),
the reception of a duplicate ACK implies that a packet has left
the pipe. 

This implies that the congestion window~(3) will reach the 
UNACK-COUNT~(4) when half the data in transit has been received at the other
end.  From this point on, the reception of any duplicate ACKs will
allow a segment to be sent. This way the pipe can be kept full at half
the previous value (since losses occurred at the previous value, it is
assumed that the available bandwidth is now only half its previous
value). Earlier versions of TCP would begin the slow-start mechanism
when losses were detected. This implied that the pipe would almost
empty and then fill up again. Reno's mechanism allows it to stay
filled.

At around 1.2 seconds, a non-duplicate ACK is received, and the
congestion window~(3) is set to the value of the threshold window~(1).
The congestion window was temporarily inflated when duplicate ACKs
were received as a mechanism for keeping the pipe full. When a
non-duplicate ACK is received, the congestion window is reset to half
the value it had when losses occurred.

Since the congestion window~(3) is below the UNACK-COUNT~(4), no more
data can be sent. At 2 seconds, a retransmit timeout occurs (see black
circle on top), and data starts to flow again.  The congestion
window~(3) increases exponentially while it is below the threshold
window~(1).  A little before 2.5 seconds, a segment is sent that will
later be retransmitted.  Skipping to 3 seconds, we notice the
congestion window~(3) increasing linearly because it is above the
threshold window~(1).