Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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):

  • 32-bit value to track what was transmitted
  • I don’t know of any special formula or requirement used to determine the starting sequence number; it’s a random number

Acknowledgement number (ACK):

  • 32-bit value to track to indicate what was received
  • The formula is simply Sequence + TCP Length = ACK, except during synchronization (SYN).

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:

 

Relative sequence numbers off:

 

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.

 

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.

 

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.

 

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.