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:

Basic slow start and congestion avoidance mechanisms

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.

Receiver-‐advertised flow control mechanisms

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 he Robustness

Transmission Control Protocol (TCP) [RFC 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

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 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].

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.youtube.com/










http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/


2

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

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/

http://www.blip.tv/


3

-‐ 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


4

Acknowledgement numbenext sequence number to start at A + x, where x is the number of octets that make up the data in this

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

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

-‐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].


5

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.


6

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

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.


7

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


8

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.


9

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


10

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


11

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.


12

IO Flow

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

Time-‐Sequence Graph for the connection


13

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


14

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. tical and graphing capabilities were used to observe the traffic flow, throughput, and areas where congestion events were observed.

References http://tools.ietf.org/txt/rfc761.txt (10

January 1980) [RFC2001] W

http://tools.ietf.org/txt/rfc2001.txt, (January 1997) [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanhttp://www.ietf.org/rfc/rfc2018.txt (October 1996)

http://tools.ietf.org/txt/rfc2581.txt, (April 1999)

http://www.ietf.org/rfc/rfc2883.txt (July 2000) [RFC3782] S. Floyd, T. Henderson, A. Gurtov,

http://www.ietf.org/rfc/rfc3782.txt, (April 2004) [FOROUZAN (2010) [SEIS715-‐ -‐

http://msdn.microsoft.com/en-‐us/library/ms818965.aspx [CHAPT2-‐Duplicate ACKs, ACK Lost Segment and Out-‐of-‐http://sharkfest.wireshark.org/sharkfest.08/T2-‐8_Chappell_Trace-‐File-‐Analysis_Loss.pdf (2 April 2008) [TOMPB-‐http://sharkfest.wireshark.org/sharkfest.10/B-‐2_TompkinsAnalyzing%20TCPIP%20Networks%20with%20Wireshark.pdf

http://tools.ietf.org/pdf/rfc761.pdf












http://www.google.com/url?q=http%3A%2F%2Ftools.ietf.org%2Ftxt%2Frfc2001.txt&sa=D&sntz=1&usg=AFQjCNE6d8qwCEwSbVTuuSoC2DIixX_QLA













http://www.ietf.org/rfc/rfc2018.txt













http://tools.ietf.org/txt/rfc2001.txt







































http://msdn.microsoft.com/en-us/library/ms818965.aspx

http://msdn.microsoft.com/en-us/library/ms818965.aspx

http://sharkfest.wireshark.org/sharkfest.08/T2-8_Chappell_Trace-File-Analysis_Loss.pdf























http://www.google.com/url?q=http%3A%2F%2Fsharkfest.wireshark.org%2Fsharkfest.10%2FB-2_Tompkins%2520Analyzing%2520TCPIP%2520Networks%2520with%2520Wireshark.pdf&sa=D&sntz=1&usg=AFQjCNFeCBM6N7bzsqE4wzBE2Jv78jT6HQ














http://sharkfest.wireshark.org/sharkfest.10/B-2_Tompkins%20Analyzing%20TCPIP%20Networks%20with%20Wireshark.pdf










an analysis of tcp congestion control mechanisms using wireshark

Documents