Scribd
Upload
149 views

Troubleshooting Latency by Capturing Traffic

This document discusses analyzing TCP performance issues using packet captures in Wireshark. It defines several TCP behaviors and terminology: 1. TCP Window Full occurs when a sender uses the full capacity of the TCP flow, limited by the recipient's receive window size. 2. TCP Zero Window occurs when a recipient's buffer fills and it closes its receive window, telling the sender to stop sending until the buffer clears. 3. TCP Retransmission happens when an ACK is not received within a timeout, causing the sender to resend unacknowledged packets. Duplicate ACKs can also trigger retransmissions.

Uploaded by

Prince Mishra
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
149 views

Troubleshooting Latency by Capturing Traffic

This document discusses analyzing TCP performance issues using packet captures in Wireshark. It defines several TCP behaviors and terminology: 1. TCP Window Full occurs when a sender uses the full capacity of the TCP flow, limited by the recipient's receive window size. 2. TCP Zero Window occurs when a recipient's buffer fills and it closes its receive window, telling the sender to stop sending until the buffer clears. 3. TCP Retransmission happens when an ACK is not received within a timeout, causing the sender to resend unacknowledged packets. Duplicate ACKs can also trigger retransmissions.

Uploaded by

Prince Mishra
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Troubleshooting Latency by Capturing Traffic

Description
When you use Wireshark to analyze a packet capture, it performs analysis on TCP connections and is able to flag
certain behaviors that can help understand TCP performance. Some of these correspond to specific TCP
messages as below

TCP Window Full

 TCP ZeroWindow
 TCP Retransmission (including variants)
 TCP Dup Ack

Terminology specific to TCP:

 Receive Window - also simply called the TCP window, this is advertised by a TCP receiver to its peer.
It is the window that is visible in the capture, and may be different in either direction in a connection. The
receive window is usually the size of the available receive buffer. TCP receivers can adjust the size of the
receive window by changing the window value in ACKs they transmit. 
 Send Window - technically the congestion window, this is an internal value in a TCP sender which
indicates the maximum amount of data it can send without receiving an acknowledgement. This is constantly
adjusted by the TCP Congestion Control algorithm, and on BIG-IP the maximum size is controlled by the Send
Buffer TCP profile option. This value cannot be observed in a capture; it can be inferred, if a sender stops
sending data even though the recipient's receive window is not full, but the actual value is never sent on the
network.
 Bytes In Flight - this is the term Wireshark uses to indicate the amount of unacknowledged data a TCP
sender has transmitted. It is always less than or equal to the recipient's receive window.

TCP Window Full: if a TCP sender transmits a packet which results in the number of unacknowledged bytes - or
bytes in flight - being the same as the recipient's receive window, this is called filling the window, and Wireshark
reports TCP Window Full.

When you see TCP Window Full flags, it usually means that the sender is using the full capacity of the TCP flow,
limited by the recipient's receive window. The network may have higher capacity. See below for more detail on
this.

TCP Zero Window: When a TCP receiver's buffer begins to fill, it can reduce its receive window. If it fills, it can
reduce the window to zero, which tells the TCP sender to stop sending. This is called "closing the window".
Typically this indicates that the network is delivering traffic faster than the receiver can process it.

When BIG-IP closes its receive window, it usually means that BIG-IP is receiving data faster than it can send it on
the peer flow. This is normal in situations where, for example, the server-side network is faster than the client-
side network, and there is a large transfer from the server to the client. BIG-IP buffers a certain amount of data
then closes its receive window when the proxy buffer reaches the configured high-water mark.

TCP Retransmission: When TCP sends a packet, it waits for an acknowledgment to confirm if the packets sent
by the sender are received by the receiving party. If the acknowledgment is not received within the timeout
interval (known as the retransmission timeout or RTO), the sender retransmits the packet.
Retransmissions can also be forced when a TCP sender receives duplicate ACKs.

Wireshark differentiates several categories of TCP retransmission; see the Wireshark TCP Analysis
documentation for more information.

TCP Duplicate / Selective Acknowledgments

Most packet analyzers will indicate a duplicate acknowledgment condition


when two ACK packets are detected with the same ACK numbers.

TCP Duplicate ACK: When a TCP receiver receives packets out of order, which it interprets as data loss, it sends
an ACK indicating the expected sequence number. After two duplicate ACKs, a TCP sender begins
retransmission. 

 Sending TCP sockets usually transmit data in a series. Rather than sending
one segment of data at a time and waiting for an acknowledgement,
transmitting stations will send several packets in succession. If one of these
packets in the stream goes missing, the receiving socket can indicate which
packet was lost using selective acknowledgments.

These allow the receiver to continue to acknowledge incoming data while


informing the sender of the missing packet(s) in the stream.

As shown above, selective acknowledgements will use the ACK number in


the TCP header to indicate which packet was lost. At the same time, in these
ACK packets, the receiver can use the SACK option in the TCP header to
show which packets have been successfully received after the point of loss.

The SACK option is a function that is advertised by each station at the


beginning of the TCP connection. Most network analyzers will flag these
packets as duplicate acknowledgements because the ACK number will stay
the same until the missing packet is retransmitted, filling the gap in the
sequence.

Typically, duplicate acknowledgements mean that one or more packets have


been lost in the stream and the connection is attempting to recover. They
are a common symptom of packet loss. In most cases, once the sender
receives three duplicate acknowledgments, it will immediately retransmit the
missing packet instead of waiting for a timer to expire. These are called fast
retransmissions.

Connections with more latency between client and server will typically have
more duplicate acknowledgement packets when a segment is lost. In high
latency connections, it is possible to observe several hundred duplicate
acknowledgements for a single lost packet.

Understanding RTT Impact on TCP Retransmissions

https://blog.catchpoint.com/2014/04/29/understanding-rtt-impact-on-
tcp-retransmissions/
https://www.isi.edu/nsnam/DIRECTED_RESEARCH/DR_HYUNAH/D-Research/fast-retransmit.html

You might also like