...
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
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 documentingShould 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.
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.
...