The PERT Knowledge Base is a Wiki, so it can be edited by anyone after a simple registration procedure. Here are a few suggestions for further developing the site's contents. If you want to contribute, consider working on some of these suggested improvements. And if you have other suggestions, feel free to add them here.
Friendlier start page
The main entry page is currently a large collection of keywords. This allows to jump quickly to a specific topic, but is probably not the friendliest way for a newcomer to become familiar with the site. It is also not very attractive in that it doesn't change frequently (at least not visibly).
Suggestions for how the start page could look are welcome! Feel free to create sample entry pages as new topics so that people can look at your ideas.
More case stories
It would be great to have more stories about actual PERT cases. The idea is that when a PERT has finished an interesting case - whether successfully or not - they would contribute a writeup for the use of the community. These "case stories" should include a description of the problem, how it was approached by the PERT (possibly including false starts), how it was resolved, and some kind of conclusion explaining what was learned.
The PertCaseHistories PERT Case Histories topic contains the summaries of many (all) issues handled by the "centralized" GN2 PERT during its lifetime between 2005 and 2007. I'm sure that other PERTs (as well as people doing similar work without calling themselves "PERT" :-) have similar stories to contribute. The existing "case histories" could possibly be presented in a more user-friendly way as well. For example by adding keywords per case (e.g. "TCP", "throughput", "packet loss"...), and by grouping related cases.
...
Particular topics that need work
"tcp-thin"
A new feature in the Linux kernel: http://www.mjmwired.net/kernel/Documentation/networking/tcp-thin.txt. The goal seems to be to protect low-rate TCP connections with only the occasional packet from horrible performance when one of these few packets is lost.
BsdOSSpecific
Should be updated, preferably by someone with actual experience with such systems. In particular, the TCP socket buffer tuning hints from MacOSXOSSpecific probably work as-is on *BSD. Someone should check that, and either copy/paste the Mac instructions over to the BSD topic, or unify them somehow else.
New ECN Semantics (e.g. DC-TCP)
The original ECN proposals assumed that ECN signals would be sent infrequently, similar to packet-loss "signals" in prior times. Later on, proposals such as Microsoft's Data Center TCP suggested to use more fine-grained congestion signals, by marking increasing percentages of packets with ECN bits as congestion increases. BBRv2 assumes this "DC-TCP-like" form of ECN, and proposals like L4S (see below) and SCE (Some Congestion Experienced) do as well.
L4S (Low Latency, Low Loss, Scalable Throughput)
We already reference a couple of Internet-Drafts in various topics.
Anycast
This was mostly used either specifically for DNS, in particular for higher-level (e.g. Root/TLD) nameservers, or within individual administrative domains. Lately it has become more widely used, for example in CDNs. SIGCOMM 2021 had two papers about it. SWITCH has an "interesting" (in the Chinese-curse sense of the word) story about an issue with such a CDN and ECMP that might be worth documenting.
Linux OS SpecificLinuxOSSpecific
The TCP_CONGESTION setsockopt() socket option should be documented. It is available in Linux and possibly also in FreeBSD. It allows to select the TCP congestion-control algorithm on a per-connection basis. The current Linux-specific tuning instructions only talk about setting this globally.
WindowsOSSpecificWindows OS Specific
Maybe this should be split into pre- and post-Vista topics, because the TCP stack in Vista (and Windows 7, and Windows Server 2008 etc.) is different enough from that in Windows XP and earlier. A few specific topics that should be talked about:
- Receive-side scaling: This is Microsoft's name for a feature that allows an interrupt handler to dispatch incoming packets to multiple (logical) processors. Similar to what Solaris does with "multi-tasking" adapters such as the Neptune, but without the need for hardware support. The feature makes sure that packets for the same flow are handled on the same processor. See http://blogs.msdn.com/wndp/archive/2006/05/05/Winhec-blog-tcpip-2.aspx
- Document how auto-scaling is configured, and why some people turn it off (because it can cause TCP Window Scaling to be activated, which exposes brokenness in EvilMiddleBoxes), and how Vista SP2 changes this. See http://www.kombitz.com/2007/02/14/vista-auto-tuning/, http://www.talktalkmembers.com/forums/showthread.php?p=248939, http://social.technet.microsoft.com/Forums/en-US/itprovistasp/thread/570652e5-438d-46a7-8302-00f84c430eea
NetworkBufferSizingNetwork Buffer Sizing
This topic should be updated regularly as the scientific discussion advances. ACM SIGCOMM CCR 39/2 (April 2009) has a new article, Perspectives on Router Buffer Sizing: Recent Results and Open Problems, by Arun Vishwanath, Vijay Sivaraman, and Marina Thottan, which contains an excellent survey of the area.
...
On various mailing lists, or while surfing the Web, or when reading scientific publications, we often encounter work that is related to the information in the PERT Knowledge Base. Maybe it would be suitable for integration into an existing topic, or deserve a new topic. In other cases it would make a nice "further reading" topic at some point. If you encounter such pieces of information, consider leaving them in the following list as a reminder to yourself and others that this might be worth adding (somehow) to the PERT Knowledge Base.
– Main.SimonLeinen — 21 Jul 2009 - 02 Jul 2011 Simon Leinen — 2009-07-29 — 2021-09-05