Not really. You'd only get that many corrupt packets if you have a Gbps of traffic flowing; but as soon as you start detectably corrupting 99.999% of packets, TCP throughput is going to drop dramatically and so you'll have fewer packets available to corrupt.
Still not something to ignore, but not nearly as bad as the author indicates.
It's totally routine to see much higher network wide packet loss rates higher than 1%. The most I can remember was >15% sustained for weeks, for a few Gbps of real life traffic in a mobile network. ("Real life" as in hundreds of thousands of normal users, with the traffic coming directly from whatever servers they were actually accessing).
A study was done on the Performance of CRCs on Real Data. CRC16 as used for TCP has real biases. "In one dramatic case, 0.01% of the check values appeared nearly 15% of the time"
This can be equally frustrating, as now you have to trace the entire path from switch to switch and try and figure out what cable/fibre is bad, and you see error counters increase on multiple interfaces.
Source: Broadcom documentation
My experience is with the Nexus platform from Cisco, pure layer 2.
Only if your network is corrupting every packet!
Data corruption is a serious problem, but it doesn't help the discussion if you wildly over-estimate its occurrence.
Did the server (both source and destination) in question both/all have ECC-protected memory? Hopefully that's a foregone conclusion but that's another big opportunity for errors.
1. IPv6 completely removes the checksum you used to have in IPv4. So, now there is just the Ethernet FCS, and the TCP checksums. You should use IPv6. If you're not using IPv6, you're only hurting yourself, and the rest of the internet.
2. Just transport everything over SSL, please. With AES-NI, the overhead for encrypting data is so tiny, that it's easier just to let someone else solve this problem.
This post has pushed me to finally getting checksums in.
ZFS checksumming has served me well..
If you mean "it's not checksumming data not represented in the filesystem, like unpartitioned sectors", well, no one cares about that data, right?
See this post from Jeff Bonwick: https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data
Basically, the filesystem isn't the end point, and thus simply isn't positioned to really provide "end-to-end" protection.
Also, ZFS only has it's claims to data integrity if you use ECC memory.
BTW, anything running on top of the machine is going to be vulnerable to your example, i.e. if you have a program that checksums something, and then writes it to disk, there is opportunity for corruption while it's reading the data to checksum it.