An Analysis of TCP Congestion Control Mechanisms Using Wireshark.

An Analysis of TCP Congestion Control Mechanisms using Wireshark

Jayesh Naithani
SEIS 715 -‐ Spring 2011

Abstract

This paper contains detailed analysis of two Wireshark traces for investigating the behavior of TCP congestion control mechanisms. The paper
will analyze the following aspects:

x Basic slow start and congestion avoidance mechanisms
x Fast recovery: a variation of the TCP slow start mechanism that uses fast retransmit followed by congestion avoidance. A detailed
packet level analysis of areas within each trace indicating congestion issues will be performed.
x Receiver-‐advertised flow control mechanisms
x Throughput and round trip time of the connection

The traces captures are for file uploads to two remote social media sites www.blip.tv and www.youtube.com.
Overview
͞ĞĐŽŶƐĞƌǀĂƚŝǀĞŝŶǁŚĂƚǇŽƵĚŽ͕ďĞůŝďĞƌĂůŝŶǁŚĂƚǇŽƵĂĐĐĞƉƚĨƌŽŵŽƚŚĞƌƐ͘͟dŚŝƐŝƐƚhe Robustness
WƌŝŶĐŝƉůĞŽƌWŽƐƚĞů͛Ɛ>Ăǁ͕ŶĂŵĞĚĂĨƚĞƌ:ŽŶWŽƐƚĞůǁŚŽǁƌŽƚĞĂďŽƵƚŝƚŝŶĂŶĞĂƌůǇƐƉĞĐŝĨŝĐĂƚŝŽŶŽĨƚŚĞ
Transmission Control Protocol (TCP) [RFCϳϲϭ΁͘dW͛ƐƌŽďƵƐƚŶĞƐƐŝƐĂƌĞƐƵůƚŽĨits reactive behavior when
congestion occurs, and it then uses flow and congestion control mechanisms in order to reliably send
and re-‐transmit data from one end of the network to the other.

Flow control is a mechanism that prevents a sender from sending data amounts that will overwhelm the
ƌĞĐĞŝǀĞƌ͘dWĂĐŚŝĞǀĞƐƚŚŝƐƵƐŝŶŐƚŚĞƐůŝĚŝŶŐǁŝŶĚŽǁƉƌŽƚŽĐŽůǁŚĞƌĞƚŚĞƐĞŶĚĞƌ͛ƐǁŝŶĚŽǁŝƐŶĞǀĞƌůĂƌŐĞƌ
than the free space advertised by the receiver. Flow of data is controlled by the receiver sending
feedback to the sender. Congestion control is about preventing the sender from sending data that will
end up getting dropped by the network. Congestion control is controlled by the sender, and it uses a
congestion window and policy to avoid, detect, and alleviate congestion after it has occurred
[FOROUZAN].

This paper contains an analysis of congestion control mechanisms observed in two network traces
captured using Wireshark version 1.4.6. The traces capture file uploads to social media sites -‐
www.youtube.com and www.blip.tv. The files were uploaded from a laptop over a home wireless
connection. The focus of both analyses ŝƐƚŽŽďƐĞƌǀĞĂŶĚĚĞƐĐƌŝďĞdW͛ƐŐĞŶĞƌĂůĐŽŶŐĞƐƚŝŽŶƉŽůŝĐǇǁŚŝĐŚ
consists of four algorithms [RFC 2001]: Slow Start, Congestion Avoidance, Fast Transmit, and Fast
Recovery.
Analysis Method
A filter was applied to each trace to display only the TCP connection between the source and
destination. For each trace the three way handshake is analyzed to determine congestion control
information being negotiated at the time of connection establishment. Information gathered during the
handshake consists of the sender and receiver advertised Window Sizes (rwnd), Maximum Segment Size
(MSS), whether a Window Scale option (WS) is being used, and if the sender and receiver support
Selective Acknowledgement (SACK) options [RFC2018].

Then Wireshark analysis capabilities are used to gather information about Errors and Warning
information contained in the trace. The Warnings tab provides both summarized and specific packet
numbers where Fast Retransmission, Out-‐of-‐Order segments, Window Full Updates events have
occurred within the trace. The Notes tab provides information about packets where Retransmission and
Duplicate ACKs were detected.

Each of the traces revealed some packet loss, as indicated by Fast Retransmissions and Retransmission.
The packets that indicated Duplicate ACKs and Fast Retransmissions where analyzed to see how missing
segments information was provided and re-‐sent using TCP. Both traces indicated the use of TCP using
the Selective Acknowledgement algorithm to allow the sender to only re-‐transmit segments that were
dropped [RFC2018, RFC3782].

The analysis also makes use of Wireshark graphing capabilities to show round trip time for ACKs over
time (Round Trip Time Graph), transmission throughput using TCP sequence numbers (Throughput
Graph), sequence number versus time graphs that help to see if traffic is moving along without
interruption, packet loss, or long delays (Time-‐Sequence Graph -‐ Stevens/tcptrace). The IO Graph
capabilities are also used to show TCP information about Window Size, Bytes in flight, estimated RTT,
and areas in the trace where packet loss was detected. Trace Analysis #1 is more detailed, and makes
use of a number of charts to show congestion avoidance behavior. Trace Analysis #2 is more about the
analysis of the Fast Retransmit, a couple of new events (TCP Window Full, Window Scale factor) that
were captured in the trace. An unusual data transmission pattern was observed in the second trace as
well. There are short gaps in traffic flow between the sender and receiver which do not appear to be
related to network congestion or end-‐to-‐end flow control.
Trace Analysis #1

The first trace analysis is of a 153 MB video file upload to www.blip.tv over HTTP. The file was uploaded
from my home laptop over a wireless connection.

Source IP address: 192.168.1.104, Source TCP port: 53323
Destination IP address: 98.124.167.251, Destination TCP port: 80
Trace Summary
The trace analysis was performed using Wireshark Version 1.4.5, on laptop running Windows 7
Enterprise Edition.

The Wireshark Expert Info Composite window reveals the following information:

Errors: 1
-‐ 1 Malformed TDS -‐ Malformed Packet (Exception occurred)
Warnings: 366
-‐ 315 Fast Retransmissions
-‐ 47 Out-‐of-‐Order segments
-‐ 3 Previous segment lost
-‐ 1 Zero window
Notes: 5241
2


-‐ 4910 (35) Several Duplicate ACKs

-‐ 231 (1) Retransmissions suspected

The Packet Lengths statistics distribution window indicates that 59.73% of the packet lengths during the
file upload were between 1280-‐2559 (MSS = 1460).

The following Time-‐Sequence graph for the connection shows a reasonable slope, equal to the
maximum bandwidth from end-‐to-‐end.

Time-‐Sequence Graph for the connection duration

Three Way Handshake

Packets #801, #803, #804 show the three way handshake.
Packet #801
The source begins with a SYN containing a 32 bit sequence number 257939964 (relative sequence
number 0). The sender advertises a Window Size of 8192 bytes. There is no data sent in this segment -‐
Len is 0. The Maximum Segment Size (MSS) is 1460, and TCP SACK Permitted option is set to True. The
SACK Permitted option indicates that the sender can receive and interpret the SACK option. The MSS
ĚĞĨŝŶĞƐƚŚĞůĞŶŐƚŚŽĨĚĂƚĂƐĞŶƚŝŶĞĂĐŚƐĞŐŵĞŶƚ͘/ƚĂůƐŽŝƐƚŚĞŝŶŝƚŝĂůƐŝǌĞŽĨƚŚĞƐĞŶĚĞƌ͛ƐĐŽŶŐĞƐƚŝŽŶ
window (cwnd).
Packet #803
The receiver responds with a SYN-‐ACK, and sends frame with an independent sequence number
2334796346 (relative sequence number 0). It sends an increment of the sequence number received in
the last segment, in its Acknowledgement field (A), 257939965 (relative ack number 1). The
3


Acknowledgement numbeƌŝŶĨŽƌŵƐƚŚĞƌĞĐĞŝǀĞƌƚŚĂƚŝƚ͛ƐĚĂƚĂŚĂƐďĞĞŶƌĞĐĞŝǀĞĚĂŶĚƚŚĂƚŝƚĞǆƉĞĐƚƐƚŚĞ
next sequence number to start at A + x, where x is the number of octets that make up the data in this
ƐĞŐŵĞŶƚ͘dŚĞƌĞĐĞŝǀĞƌ͛ƐǁŝŶĚŽǁ;ƌǁŶĚͿƐŝǌĞŝƐϱϴϰϬďǇƚĞƐ;ŽƌϰƚŝŵĞƐƚŚĞMSS value).
Packet #804
The source receives the SYN-‐ACK segment, and sends an ACK segment containing the next sequence
number 2334796347 (relative ack number 1). The SYN sequence number is incremented by 1 to
257939965 (relative sequence number 1). The sender also defines the server window size, to 17520
ďǇƚĞƐ͘&ŽƌϭϬĂŶĚϭϬϬDďƉƐƚŚĞƌŶĞƚĐŽŶŶĞĐƚŝŽŶƐ͕ŽŶtŝŶĚŽǁƐϳƚŚĞƐĞŶĚĞƌ͛ƐƌĞĐĞŝǀĞǁŝŶĚŽǁŝƐƵƐƵĂůůǇ
set to 17,520 bytes (17 KB rounded up to 12 1460 byte segments) [TOMPB-‐2].
Slow Start and Congestion Avoidance

Once the connection is established, TCP starts slowly to determine the bandwidth of the connection and
to avoid overflowing the receiving host and other devices or links in the path.
Packet #805
A single packet of size 1023 is sent with the PSH flag set. The PSH flag indicates to the receiver that the
contents of the receive buffer should be immediately passed to the application layer.
Packet #806
Another DATA packet of size 1460 (MSS) is sent. At this point there are 2483 bytes of in flight or
unacknowledged data on the wire. I
Packet #807
The receiver acknowledges (ACK) data sent by the sender. A window size (rwnd) of 7161 is also
advertised by the receiver with this ACK.

When the connection was established, a congestion window (cwnd) of size 1 MSS (size 1460 bytes) is
initialized. Each time an ACK is received this congestion window is increased by 1 MSS. With ACK sent
with Packet #807, the congestion window size is increased by 1, i.e., cwnd = cwnd + 1 MSS, or 2 MSS =
2920 bytes.

In slow start, the sender can transmit up to the minimum of the value of the cwnd and the rwnd. This is
ƚŚĞůŽǁĞƌďŽƵŶĚŽĨƚŚĞƐĞŶĚĞƌ͛ƐdWǁŝŶĚŽǁƐŝǌĞ͘/ŶŽƚŚĞƌǁŽƌĚƐ͕ƚŚĞĂŵŽƵŶƚŽĨƵŶ-‐acknowledged data
will always be the minimum of the cwnd and rwnd size in bytes. In Frame #808, the sender sends DATA
of size 1460 bytes. At this point the unacknowledged data is 2920 bytes (2 * 1460), or equal to the value
of cwnd.
Packet #959
This pattern of sending DATA and receiving ACKs between the sender and receiver continues and at this
point there are 49152 bytes of un-‐ACKed data on the wire and the rwnd is 64240 bytes.

The value of the congestion window size is not something that can be obtained directly from a TCP
Wireshark trace. However, we can plot the amount of data that the sender has in flight using the IO
Graph feature. This can sometimes give a good indication of the cwnd size. When the amount of data
being sent reaches the size of the receive window, the slow start algorithm may no longer be in use and
flow of data is controlled by the receiver using the advertised window size [MSDN].

4


When congestion is encountered, as indicated in the trace by a fast retransmission, a congestion
ĂǀŽŝĚĂŶĐĞĂůŐŽƌŝƚŚŵŝƐƵƐĞĚƚŽƌĞĚƵĐĞƚŚĞƐĞŶĚĞƌ͛ƐǁŝŶĚŽǁƐŝǌĞ͕ĂŶĚƚŽŐƌŽǁŝƚďĂĐŬtowards the
ƌĞĐĞŝǀĞƌ͛ƐĂĚǀĞƌƚŝƐĞĚǁŝŶĚŽǁƐŝǌĞ͘ŽŶŐĞƐƚŝŽŶĂǀŽŝĚĂŶĐĞƌĞƋƵŝƌĞƐƚŚĂƚĂŶŽƚŚĞƌǀĂƌŝĂďůĞďĞŵĂŝŶƚĂŝŶĞĚ
called the slow start threshold or ssthresh. The initial value of ssthresh is arbitrarily high, and as much
as the largest possible advertised window size of 65535 bytes [RFC2001, RFC2581].

Fast Transmission with SACK TCP, and Retransmissions
Fast Retransmission with SACK TCP, Retransmission
Packet #961, #962, #963 (Duplicate ACK)

The TCP receiver sends a duplicate ACK to Packet #960. This indicates that an out-‐of-‐order segment has
arrived, and the sequence number expected is 102248 (Packet #914). After three ACKs for the same
sequence number are received (Packets #961 #962, #963), the send performs an immediate re-‐
transmission of the missing segment with Packet #964.

Here we also see that Selective Acknowledgements (SACKS) by the receiver are used to inform the
sender of data that has been received out-‐of-‐order ([SLE=105168, SRE=106628]). The beginning and end
of the blocks are indicated by SLE (Left Edge) and SRE (Right Edge )[RFC2883]. The sender then re-‐
transmits only the missing data segments.
5


Packet #963, #964 (Fast Retransmission)

The receiver informs the sender of an updated list of blocks that have arrived out of order.), i.e.,
[SLE=109548, SRE=112468], [SLE=105168, SRE=108088]. With the re-‐transmit of 1460 bytes in Packet
#964, the receiver indicates an updates to the list of blocks -‐ [SLE=109548, SRE=113928], [SLE=105168,
SRE=108088].

With Fast Re-‐transmit, TCP re-‐transmits the missing segments before the retransmission timer expires.
A fast re-‐transmission re-‐transmits the missing segment, and also sets the value for the slow start
threshold to be 0.5 * cwnd, and the new cwnd value to ssthresh + 3. For every subsequent duplicate
<͕ƚŚĞƐĞŶĚĞƌ͛ƐĐǁŶĚŝƐŝŶĐƌĞĂƐĞĚďǇϭƐĞŐŵĞŶƚ͘tŚĞŶĂŶĞǁ<ŝƐƌĞĐĞŝǀĞĚĐǁŶĚŝƐƐĞƚƚŽďĞƚŚĞ
ssthresh value and TCP resumes congestion avoidance.

TCP with Selective Acknowledgement (SACK) is an extension of the TCP Reno algorithm. So it does
retain the slow start and fast retransmit parts of RENO. And it works around some of the problems
faced by TCP Reno and TCP New Reno [RFC3782]. These problems are namely the detection of multiple
lost packets, and re-‐transmission of more than one lost packet per Round Trip Time (RTT).
Packet #972 (Enter Fast Recovery)

After the missing segment has been sent with Packet #964, the Fast Recovery algorithm controls the
transmission of a new data until the first non-‐duplicate ACK arrives.

Packets #914, #915, #918
Packet #966, #968 (Retransmission of segment in Packet #915)

We see a TCP Retransmission with these packets for Packet #915. This is because the sender did not
receive an acknowledgement for the data sent in Packet #915 before its Retransmission Timer expired.
6


A Retransmission Timer is started every time TCP sends a segment. It is the waiting time for an ACK for
the segment. If the time expires, the assumption is that the segment is lost. The RTO for segment being
retransmitted in Packet #966 was 0.053786 seconds.
Packet #968, #971, #973 (Retransmission of segment in Packet #918)
These packets indicate a TCP Retransmission for the segment in Packet #918. The RTO for segment sent
with Packet #968 was 0.058455 seconds.
Packet #997 -‐ #1102

These packets acknowledge the previously retransmitted packets.
Packet #1002 (First non-‐duplicate ACK, exit Fast Recovery, enter Congestion Avoidance)
Packet #1002 is a cumulative ACK, and acknowledges all pending packets. It contains an ACK for all
Packets up to Packet #959. With the arrival of a non-‐duplicate ACK, the congestion avoidance algorithm
is enforced by TCP. Congestion avoidance algorithm increases the Congestion Window additively
(Additive Increase/Multiplicative Decrease) instead of exponentially.
Traffic Flow, Throughput, and Round Trip Time

The following set of graphs provides a view of a section of the trace which includes the packets analyzed
in the previous section ʹ from Packets 801 through 186588.

The IO graph displays, over time, the TCP receiver advertised window size (black line), the number of
bytes in flight that have not been acknowledged (red line), the round trip time (RTT) for ACKs (green
line), and the areas where duplicate acknowledgements (purple dot) and fast retransmits (blue dot)
events occurred.

IO Graph
7


Fast Retransmits coincide with a reduction in the number of unacknowledged bytes in flight. But not all
Fast Retransmits result in all bytes in flight being acknowledged, but only up to the bytes in the packet
that initiated the Fast Retransmission.

The Time-‐Sequence graph for the same period indicates there are gaps (circled in red) between
sequence numbers, indicating congestion in the network. These gaps also coincide with the Fast
Retransmission and Retransmission events in the trace.

Time-‐Sequence Graph

The Round Trip Time graph for ACKs indicates many dots that are clustered closer towards the x axis
indicating a consistent response time [TOMPB-‐2, CHAPT2-‐8], but there are a quite a few dots that are
steeply climbing towards the top. The dots circled in red are during the time the Fast Retransmits occur,
and show maximum length in RTT.

8


Round Trip Time Graph

Finally, the Throughput graph indicates time slots where nothing is being sent. Areas where Fast
Retransmission and Retransmission areas are circled in red, in both graphs.

Throughput Graph
9


Trace Analysis #2

This is a trace analysis of a 73 MB video file upload to www.youtube.com over HTTP. The file was
uploaded from my home laptop over a wireless connection.

Source IP address: 192.168.1.105, Source TCP port: 63870
Destination IP address: 192.168.1.105 Destination TCP port: 80

The most interesting things in this trace were the use of a Window Scale option by the receiver and
sender to allow support for larger receiver buffers on each end. The Wireshark trace also detected
several (21) TCP Window Full warning events and a few (4) suspect Fast Retransmits for the duration of
the transmission. A detailed analysis follows below.

Expert Info Composite View
Packet #26 (SYN)

The SYN from the source with relative sequence number 0 advertises a Window Size of 8192 bytes.
Data sent is 0. The Maximum Segment Size (MSS) is set to 1460. The TCP SACK Permitted option is set
to true to indicate the sender supports the SACK option. The SYN contains a Window Scale option of 2.
The sender is indicating it is prepared to do both send and receive window scaling [RFC2018].
Packet #36 (SYN-‐ACK)

The receiver sends back a <SYN,ACK> and advertises a window size of 5720 bytes. It also indicates it
supports the SACK option, and sends its own Window Scale option of 6. This essentially indicates that
the receiver supports a window size of 64 * the advertised window size. Scalable windows allow
multiple large packets to be pending in the receivers buffers and are used often in file transfer protocols.
Packet #37 (ACK)

The source receives the <SYN-‐ACK> segment, and sends an ACK segment containing the next relative
sequence number 1. The ƐĞŶĚĞƌĚĞĨŝŶĞƐŝƚ͛ƐƌĞĐĞŝǀĞǁŝŶĚŽǁƐŝǌĞƚŽďĞϭϳϱϮϬďǇƚĞƐ͘
Packet #243 (TCP Window Full)

Wireshark keeps track of the receivers sliding window. The TCP Window Full flag is being set here
because the payload data in the segment will completely fill the rĞĐĞŝǀĞƌ͛Ɛ received data buffer. The
10


number of bytes in flight is 64128. The last advertised window size by the receiver in Packet 240 was
64128.
Packet #13761, #13762, #13763 (TCP Dup ACK)

Three duplicate ACKs are sent by the receiver to indicate to the sender that an out-‐of-‐order segment has
arrived [SEIS715-‐WEEK5]. Selective Acknowledgement is used by the receiver to indicate the SACK block
which triggered the acknowledgements ([547388, 5475318]), in Packet #13761. This block also indicates
the list of duplicate packets, and informs the sender to only send the segment that is lost.

TCP with Selective Acknowledgement preserves the congestion control algorithms present in standard
TCP implementations (RFC 2581). When entering fast recovery following fast retransmit, the following
algorithm will be followed.

ssthresh = max(FlightSize/2, 2* MSS) // (1)

cwnd = ssthresh + 3 * MSS

For each additional dup ACK
cwnd = cwnd + MSS

Transmit a segment

When next ACK arrives that acknowledges new data
cwnd = ssthresh // value in (1)

Enter congestion avoidance phase

[RFC2581]
Packet #13764 (Fast Retransmission)

The sender does not wait for retransmission timer (RTO) to expire and sends only the missing segment
with SEQ number 5472580.
Packet #13765 (Enter Fast Recovery)

TCP enters fast recovery stage, until first non-‐duplicate ACK received.
Packet #13766 (Non-‐duplicate ACK, Enter Congestion Avoidance)

TCP enters congestion avoidance stage with the arrival of first non-‐duplicate ACK. This is a cumulative
acknowledgement for bytes sent up to Packet #13658. TCP begins Congestion Avoidance phase, and the
congestion window is increases linearly until congestion is detected or the maximum sending window
size is reached.
Traffic Flow, Throughput, and Round Trip Time

The IO Flow graph for Packets #26 through #30000 indicates the rwnd (black line), bytes in flight (red
line), ACCK RTT (green line), Fast Retransmits over time (blue dots), Window Full (purple). TCP with
SACK re-‐transmits allow the senders TCP to only send the packets that were dropped.
11


IO Flow
The Time-‐Sequence for the connection reveals an interesting step-‐ladder like pattern.

Time-‐Sequence Graph for the connection
12


A closer look into the areas of the graph where the sequence numbers are not increasing over time
indicates that there is very little traffic being sent from the sender. Looking over the trace does not
provide any indication of a problem in the transmission. However, the data in packets sent down from
the server show HTTP 404 (page not found) messages during these periods. Subsequently, the receiver
waits for a period of time before sending data. The connection at all times remained established.

404 Not Found
The following throughput graph further validates gaps in the transmission where there is very little
traffic going from the sender to the receiver.

Throughput Graph
13


Conclusion
The purpose of this project was to capture and analyze congestion control mechanisms observed in
Wireshark traces of file uploads to a couple of popular social media sites. Information exchanged during
TCP connection establishment was analyzed for each trace. A detailed analysis of sections of the traces
where packet loss was detected was performed and described in terms of the Fast Retransmit and Fast
Recovery algorithms for TCP Congestion Avoidance. tŝƌĞƐŚĂƌŬ͛ƐƐƚĂƚŝƐtical and graphing capabilities
were used to observe the traffic flow, throughput, and areas where congestion events were observed.
References
΀Z&ϳϲϭ΁͞K^dEZdZE^D/^^/KEKEdZK>WZKdKK>͟http://tools.ietf.org/txt/rfc761.txt (10
January 1980)

[RFC2001] W͘^ƚĞǀĞŶƐ͕͞dW^ůŽǁ^ƚĂƌƚ͕ŽŶŐĞƐƚŝŽŶǀŽŝĚĂŶĐĞ͕&ĂƐƚZĞƚƌĂŶƐŵŝƚ͕ĂŶĚ&ĂƐƚZĞĐŽǀĞƌǇ
ůŐŽƌŝƚŚŵƐ͕͟http://tools.ietf.org/txt/rfc2001.txt, (January 1997)

[RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. RomanŽǁ͕͞dW^ĞůĞĐƚŝǀĞĐŬŶŽǁůĞĚŐĞŵĞŶƚKƉƚŝŽŶƐ͕͟
http://www.ietf.org/rfc/rfc2018.txt (October 1996)

΀Z&Ϯϱϴϭ΁D͘ůůŵĂŶ͕s͘WĂǆƐŽŶ͕t͘^ƚĞǀĞŶƐ͕͞dWŽŶŐĞƐƚŝŽŶŽŶƚƌŽů͕͟
http://tools.ietf.org/txt/rfc2581.txt, (April 1999)

΀Z&Ϯϴϴϯ΁^͘&ůŽǇĚ͕:͘DĂŚĚĂǀŝ͕D͘DĂƚŚŝƐ͕D͘WŽĚŽůƐŬǇ͕͞ŶǆƚĞŶƐŝŽŶƚŽƚŚĞ^ĞůĞĐƚŝǀĞ
ĐŬŶŽǁůĞĚŐĞŵĞŶƚ;^<ͿKƉƚŝŽŶĨŽƌdW͕͟http://www.ietf.org/rfc/rfc2883.txt (July 2000)

[RFC3782] S. Floyd, T. Henderson, A. Gurtov, ͞dŚĞEĞǁZĞŶŽDŽĚŝĨŝĐĂƚŝŽŶƚŽdW͛Ɛ&ĂƐƚZĞĐŽǀĞƌǇ
ůŐŽƌŝƚŚŵ͕͟http://www.ietf.org/rfc/rfc3782.txt, (April 2004)

[FOROUZAN΁͘͘&ŽƌŽƵǌĂŶ͕͞dWͬ/WWƌŽƚŽĐŽů^ƵŝƚĞ͕ϰ͛ƚŚĚŝƚŝŽŶ͕͟DĐ'ƌĂǁ,ŝůů(2010)

[SEIS715-‐t<ϱ΁͘KĞůŬĞ͕͞^/^-‐ϳϭϱtĞĞŬϱ͗dƌĂŶƐŵŝƐƐŝŽŶŽŶƚƌŽůWƌŽƚŽĐŽů͟ůĞĐƚƵƌĞŶŽƚĞƐ͕;DĂǇϮϬϭϭͿ

΀D^E΁͞^ůŽǁƐƚĂƌƚĂŶĚŽŶŐĞƐƚŝŽŶǀŽŝĚĂŶĐĞůŐŽƌŝƚŚŵƐ͕͟http://msdn.microsoft.com/en-‐
us/library/ms818965.aspx

[CHAPT2-‐ϴ΁>͘ŚĂƉƉĞůů͕͞dƌĂĐĞ&ŝůĞŶĂůǇƐŝƐ͗WĂĐŬĞƚ>ŽƐƐ͕ZĞƚƌĂŶƐŵŝƐƐŝŽŶƐ͕&ĂƐƚZĞƚƌĂŶƐŵŝƐƐŝŽŶƐ͕
Duplicate ACKs, ACK Lost Segment and Out-‐of-‐KƌĚĞƌWĂĐŬĞƚƐ͕͟
http://sharkfest.wireshark.org/sharkfest.08/T2-‐8_Chappell_Trace-‐File-‐Analysis_Loss.pdf ͕^ŚĂƌŬĨĞƐƚ͚Ϭϴ͕
(2 April 2008)

[TOMPB-‐Ϯ΁Z͘dŽŵƉŬŝŶƐ͕͞ŶĂůǇǌŝŶŐdWͬ/WEĞƚǁŽƌŬƐǁŝƚŚtŝƌĞƐŚĂƌŬ͕͟
http://sharkfest.wireshark.org/sharkfest.10/B-‐
2_TompkinsAnalyzing%20TCPIP%20Networks%20with%20Wireshark.pdf͕^ŚĂƌŬĨĞƐƚ͚ϭϬ͕;ϭϰ:ƵŶĞϮϬϭϬͿ
14

An Analysis of TCP Congestion Control Mechanisms Using Wireshark.

Uploaded by

Copyright:

Available Formats

An Analysis of TCP Congestion Control Mechanisms Using Wireshark.

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Analysis of TCP Congestion Control Mechanisms Using Wireshark.

Uploaded by

Copyright:

Available Formats

An Analysis of TCP Congestion Control Mechanisms using Wireshark

Trace Analysis #1

-­‐ 4910 (35) Several Duplicate ACKs

Three Way Handshake

Slow Start and Congestion Avoidance

Fast Retransmission with SACK TCP, Retransmission

Packet #961, #962, #963 (Duplicate ACK)

Packet #963, #964 (Fast Retransmission)

Packet #972 (Enter Fast Recovery)

Packet #966, #968 (Retransmission of segment in Packet #915)

Packet #997 -­‐ #1102

Traffic Flow, Throughput, and Round Trip Time

Trace Analysis #2

Packet #26 (SYN)

Packet #36 (SYN-­‐ACK)

Packet #37 (ACK)

Packet #243 (TCP Window Full)

Packet #13761, #13762, #13763 (TCP Dup ACK)

Packet #13764 (Fast Retransmission)

Packet #13765 (Enter Fast Recovery)

Packet #13766 (Non-­‐duplicate ACK, Enter Congestion Avoidance)

Traffic Flow, Throughput, and Round Trip Time

You might also like

-‐ 4910 (35) Several Duplicate ACKs

Packet #997 -‐ #1102

Packet #36 (SYN-‐ACK)

Packet #13766 (Non-‐duplicate ACK, Enter Congestion Avoidance)