TCP header option: SACK-permitted (Selective Acknowledgments) negotiation

4
votes

I'm doing a research project, which needs to split tcp connection. so I have some pecular questions, which may happen in my development. The problem is understanding of TCP SACK-permitted negotiation. I read the RFC and can't find answer there.

For 3-way tcp handshake between two tcp programs: A and B. if A send a TCP SYN to B with SACK-permitted, will B surely respond a SYN/ACK packet with SACK-permitted? if B reply with a TCP SYN/ACK without SACK-permitted, does it mean

1) SACK-permmited is enabled only on A. A can selectively acknowledge tcp packets from A, but A can't selectively acknowledge tcp packets from B.

or

2) SACK-permmited is not enabled on both A and B

if A sends a TCP SYN to B without SACK-permitted, may B respond a SYN/ACK packet with SACK-permitted?

besides, why SACK-permitted is allowed or disallowed? it depends on the Operating system or kernel setting or something else? is it possible to control it? thanks!

1
networkingtcpnetwork-protocols

1 Answers

1
votes

The following should help you: TCP Selective Acknowledgements

To answer your question though (possible to control it), it all depends on "what you have control over." E.g., For Windows you CAN control it however, you have to ENABLE it. So if you're controlling both ends of the TCP session, the answer is yes. Obviously, if you don't control the other end, nothing you can do. So imagine you enable it on your end (controllable) but the destination (let's say a website) is not honoring SACKs, it ends up being a waste of time to an extent.

Most operating systems allow you to turn if off and on. On FreeBSD (my current desktop) it is on by default, in most variants of Linux, it too is on by default.