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.
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 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.
Underserved areas
There are some relevant topical areas where the PERT Knowledge Base is currently weak. For example:
- Wireless networks such as WLANs, but also mobile data networks such as GPRS/UMTS and CDMA
- VPNs and their performance implications
- The "multicore" trend and its implications on networking
Particular topics that need work
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 Specific
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.
Windows 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
Network 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.
Integrating performance-related information from other sources
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.
– Simon Leinen — 2009-07-29 — 2021-09-05