SACK, no Shark

Poor application performance? When it seems your applications are ok but there is something wrong and user experience isn't good enough, look your network!! It could be something about Hot potato and could potato routing in your Autonomous System, or something about Elephants in your Long Fat Networks or even because you are not taking advantages of Multipath TCP. However, this time I don't want that you buy a shark but a SACK or Selective Acknowledgement.

SACK or TCP Selective Acknowledgement is a TCP option defined in RFC 2018 that allows to retransmit only lost segments when there are packets loss instead of retransmiting every packet from the last Acknowledgement. Therefore, we would have a slow and inefficient throughput without SACK because if we use the traditional cumulative acknowledgment scheme, it wouldn't never know what packets have been lost and as a result it could send all packets again.

Next, we can compare both schemes. When we have a cumulative acknowledgment scheme like the left picture (No SACK) and there are packets loss, we see ACK messages ask for lost segments without acknowledging received packets. However, SACK scheme, like the right picture, acknowledges received packets with TCP SACK option and asks for lost packets with ACK messages.

No SACK vs SACK

At first, it seems both schemes are the same but if there are multiple dropped segments and sender can't free up the network buffer, network throughput will be inefficient. In addition, with an extension to the selective acknowledgement (SACK) option for TCP called Duplicate-SACK or D-SACK and defined in RFC 2883, we'll have better network performance because sender can infer the order of packets received at the receiver and it can report duplicate segments.

Selective acknowledgement option is negotiate in the TCP hadnshake with Kind=4 and receiver and sender (both) must support this kind of communication, as we can see in the top picture. While when there are some dropped packet and it should be retransmited by sender, receiver asks them with Kind=5 saying which packets have been received successfully, as we can see in the down picture.

SACK Kind 4

SACK Kind 5

If we have a poor application performance, maybe the issue isn't in the development team but in the networking team, be sure your systems manage this kind of technologies because there are many others like EVN Trunk, Unicast Reverse Path Forwarding (URPF), Tribal Flood Network (TFN), etc and if your are not network engineer maybe you are not aware about it.

Regards my friends and remember, networking isn't plug and play.