Network Troubleshooting: TCP SACK Analysis

In my last article I explained why it's important to review your  IP MTU and TCP maximum segment size (MSS) values in network performance analysis. In this article, I will look at the TCP selective acknowledgement (SACK) option when network troubleshooting.

You may think there isn't much you can do when you have TCP retransmissions, but SACK can help reduce the number of packets retransmitted. It makes for a more efficient transmission algorithm, so it's important to check your traces to see if you are using SACK.

Before I explain the SACK option, let's quickly review TCP SEQ/ACK.

Sequence number (SEQ):

Acknowledgement number (ACK):

Here’s where you need to understand your network protocol analyzer of choice since many of them will display a value relative to the start of the session.

In the screenshots below I show you the difference between having relative sequence values enabled and disabled in Wireshark; the choice  is controlled via your TCP protocol preferences. Also notice in the screenshots that both ACK and SEQ are affected by this setting.

This can be an issue when you are trying to find the same packet in two different tools. It doesn’t matter if you are looking at a log or another trace file, having the same sequence number format is a big deal.

Relative sequence numbers on:

SACK-1.png

Relative sequence numbers off:

SACK-2.png

SACK numbers are a more efficient way of retransmitting lost packets. Traditionally, lost packets will result in a retransmission of lost and some received packets since the receiver can only tell the sender the last contiguous sequence number received. SACK will define a range of what was received.

In the diagram below you can see that packets 1 through 8 were transmitted, but 4 and 5 never arrived. Since both devices support SACK, the receiver can tell the sender exactly which segments were received.

SACK-3.png

For this to work properly, you need to ensure that SACK is permitted or configured for both devices by reviewing the TCP SYN packet. As you can see below, the client (first packet) supports it, but not the HTTP server (second packet). You can tell which is which by looking at the port numbers.

SACK-4.png

And when you encounter packet loss with SACK Permitted on both ends, you will see a reference to the Selective Left and Right Edge. These values will be shown as SLE and SRE.

SACK-5.png

The main point to keep in mind is that SACK will only help if you have a network that has a lot of retransmissions. For example, if you are on the same switch or LAN as your server and all is done correctly, SACK won’t help. Please don’t forget that these are just TCP options, so UDP-based applications will not benefit from SACK.