Craig Partridge wrote:
OK, on to what people are seeing today. This shows that 1 in every 121 file transfers FTP delivers a file that, when you do the md5 sum, turns out not to match the original (note there are multiple possible reasons, but TCP checksum is a strong candidate).
That's unreasonable because most errors are detected by datalink layer checksum and almost all remaining errors are detected by transport layer checksum, which should have been the reason why transport checksum need not be so strong.
Anecdotally, folks are reporting some middlebox vendors are not updating the TCP checksum but rather letting the outbound interface simply recompute the entire checksum -- which means that if the TCP segment gets damaged during middlebox handling, the middlebox will slap a valid checksum on bad data.
That should be the real problem to make transport checksum not to work end to end. Thus, your proposal to have stronger checksum can not prevent file corruptions. So, we should make middlebox vendors to update checksum incrementally or, check the original checksum just before sending a packet with the original header (not applicable if payload is also modified). Masataka Ohta PS This is a old problem documented in the original paper on the E2E principle. https://dl.acm.org/doi/pdf/10.1145/357401.357402 2.2 A Too-Real Example One gateway computer developed a transient error: while copying data from an input to an output buffer a byte pair was interchanged, with a frequency of about one such interchange in every million bytes passed.
