Ptcp is a graphical analysis tool used to analyze trace output from x-Sim simulations. The ptcp can be used as follows.
Invoking the "ptcp" tool:
ptcp [arguments] <plot types> trace-filename
plot types:
winPlot different windows (congestion, etc.)
ratePlot the sending rate.
vegasPlot Vegas information
rttPlot RTT.
drttPlot RTT differences.
seqPlot sequence numbers.
Args:
-tStarts graphs at time 0 (when the simulator started). The default is to start graphing at the time the connection is opened.
-pnCreate page information so postscript browsers, like ghostview, can jump to any page.
-db=<file-name>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).
-sid=<sid>Used to specify the session (connection) id when there were more than one connection.
-xtime=<time>Time in ms covered by each graph. If the transfer lasts longer than this time, more than one graph will be created.
-xtics=<time>Show tic marks in the time axis every <time> ms.
-xbeg=<time>Beginning time, in ms, of first plot.
-xend=<time>Ending time, in ms, of last plot. Xbeg and xend specify the time range to plot.
-journalCreate plots suitable for publication. The plots show less features.
-noEventsDon't show events such as packets with old acks, packets with RST, SYN, FIN, timeout KEEP events, etc.
-journal=<#>Similar to -journal, except that it will create an encapsulated postscript file of the right size to hold # plots.
-headerInsert 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).
-tailInclude necessary commands at the end of the postscript file.
-allplotThis flags is equivalent to the -header and -tail flags.
-aAppend this plot to the default output file (trace.ps) or to the file specified with the -o argument.
-o <filename>Use filename as the output file containing the postscript commands to do the plots.
-scale
Scale the output by .8 in the y direction
-n <comment>
Add the comment at the top of the 1st page.
-bigCreate big plots suitable for slides. The time axis in each plot will only show 1/2 the time specified with -xtime.
-maxRate=<rate>Set the y axis to maxRate when plotting the sending rate.
-rateTic=<#>Plot tic marks at multiples of # when plotting sending rate.
-arn=<#>How many entries to use when doing running average of sending rate.
-maxWin=<#>Similar to -maxRate, but refers to window plot.
-winTic=<#>Similar to -rateTic, but refers to window plot.
Note: If using only 1 sid, then always use -sid=232
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 7 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).
