Article proposal: TCP window scaling, timestamps and selective acknowledgments

Team Workflows Fedora Magazine
1

The Linux TCP stack has a myriad of sysctl tuneables by which its behaviour can be changed.
There are a various blog posts/articles that recommend to disable some TCP extensions, notably timestamps and/or selective acknowledgments (SACK) for various “performance tuning” or “security” reasons. However, there is little to no reason anymore to do this. The motivation is to debunk a few myths about these features.

The article would be structured similar to this:

  1. TCP Window scaling
  • Problem its solving
  • how this works
  1. TCP time stamps
  • problem its solving
  • how things work when feature is not available/off
  • difference of net.ipv4.tcp_timestamps=1 vs. “=2”
  1. Selective Acknowledgments
  • problem its solving
  • how this works at a high level
  • how its releated to Window scaling
  • problems that may occur when this feature is off
  1. Summary
1 Like
2

+1

I rarely mess with anything that low-level myself, but I’ve seen complaints about TCP and corrupt TCP stacks on occasion. For example, the “Known Limitations” section of wireguard.com has some wording about TCP being terrible. I’d be curious to know more about these sort of problems.

3

Hello @strlen,
Welcome to the community discussion forum.
+1 on the article idea, I would welcome some clarity around this topic.

4

Accepted! I’ve created a Taiga card for this article: https://teams.fedoraproject.org/project/asamalik-fedora-magazine/us/217

5

@strlen Can you please log in to Taiga (link in previous comment) so I can add you to the board?

6

I’ve logged in to taiga, thanks for creating the card.

7

And I’ve just added you!

8

Great idea.

Does hardware matter? Does this affect laptops more than PCs with network cards?
Does it have anything to do with “tuned”?

9

No, this has nothing to do with hardware or software of any kind. There are a bunch of (older) blog posts that make claims that are not true (or not true anymore), thus the clarification. It might make sense to write another article later that covers other/different aspects of tcp or tcp related network offloads such as (tcp) segmentation offload. I will think about it, let me know if you have a particular (related) topic you might want covered.