This is a great way to detect non-tail losses, and should definitely be a part of TCP implementations. I hope this gets turned into an RFC and pushed through the standards process and widely deployed.<p>I do hesitate a bit about Google calling it a "new loss detection algorithm" and talking about how "the key innovation in RACK is to use a per-packet transmission timestamp." The same approach was previously described by Sprout in 2013, and I'd bet by a lot of other people before that. ("The assumption underlying this method is that while the network may reorder packets, it will not reorder two packets that were sent more than 10 ms apart. Thus, once the receiver actually gets a packet from the sender, it can mark all bytes (up to the sequence number of the first packet sent within 10 ms) as received or lost, and only keep track of more recent packets." <a href="https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final113.pdf" rel="nofollow">https://www.usenix.org/system/files/conference/nsdi13/nsdi13...</a>) The IRTF awarded this one of their Applied Networking Research Prizes that year, so it's not like it was totally just on the academic plane.<p>Which is not to say Google isn't making 90% of the important contribution by measuring and documenting how valuable this is in real life, defining and implementing it in the context of TCP, standardizing it, getting an RFC, etc. It's just not quite as new as the I-D seems to suggest.
"The main idea behind RACK is that if a packet has been delivered out of order, then the packets sent chronologically before that were either lost or reordered. This concept is not fundamentally different from [RFC5681][RFC3517][FACK]. But the key innovation in RACK is to use a per-packet transmission timestamp and widely deployed SACK options to conduct time-based inferences instead of inferring losses with packet or sequence counting approaches."<p>Conjecture: This, at scale, plus machine learning, might grant some insights (or at least variables that statistically strongly correlate to different conditions) about network segments that were previously not known or understood...
I feel like the days of "we hand-crafted this algorithm to solve this issue as well as we could" like this RFC are over.<p>Instead, simply give the issue to a neural network whose loss function is to find the best strategy for timing packets to minimize retransmissions and delay. Then train that on the real internet, and preload the resulting mini neural networks in operating systems.<p>For extra bonus points, implement the trainer too, so the networks behaviour can be auto-tweaked at runtime to improve performance based on local scenarios.