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.
Recommended For You
Businesses can make their organizations more secure while increasing employee productivity with fast, global wireless connectivity.
It’s no secret that as far as IT security goes, the healthcare space could be a whole lot better. How did things get so dire? And what can we do about it?
A basic, layered approach to DNS security can dramatically reduce the chances of DNS and BGP-related compromise. Here are three essential, preventative measures that organizations should implement.
The IIoT is here. Now it's time to make sure that security issues won't derail its value.
A security team with a broader view of issues can provide better plans and solutions to problems and the ability to react effectively and quickly in a security emergency.
By teaming up to address key technical and organizational issues, information and operational security teams can improve the resiliency and safety of their infrastructure systems.