Read on Twitter
this problem has been driving me and @drance crazy for weeks and... well, i feel better about not being able to pin it down now https://twitter.com/Catfish_Man/status/1335421122947366912
ok this is pretty great - the corruption of packets is profound ... so profound that retries mean checksum collisions are getting through
i guess the logical questions then are "wouldn't someone notice a five-orders-of-magnitude increase in retries?" / "would the protocols even allow that number?" and the easy answer is "not if they're embedded in other working traffic"
a post-hoc note here: TCP generally uses a time-based retry window rather than a count-based retry window, which made sense when a limited number of packets could be transmitted in that time.
now you can exhaust the hash space (65,536 combinations) before you run out of time.
now you can exhaust the hash space (65,536 combinations) before you run out of time.
(TCP spec originated in 1974 and at the time Ethernet maxed out at ~3Mbps. One's Complement checksum used because CPUs were still mostly measured in KHz; perhaps 1-2MHz. Good thing IPv6 transition proved it's easy to shed legacy tech!)
