Re: [tcpm] draft-eggert-tcpm-historicize-00

[Joe Touch <[e-mail]>]

[e-mail] wrote:
>>From the abstract of Stone's SIGCOMM paper:
> 
> Traces of Internet packets from the past two years show that between 1 packet
> in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where
> link-level CRCs should catch all but 1 in 4 billion errors.
> [..] Much of our time has been spent negotiating access to data.
> 
> s/*can*/*was observed to over two years in the wild*.

See Section 4.3.

End hosts that compute bad TCP checksums, or alter packets after the checksums
are validated aren't fixed by adding another checksum they can incorrectly
implement.

The only errors that appear to be happening due to paths were due to a faulty
router. Those errors were single bit errors, likely in memory of the router (as
per their observation, Sec 4.3.4). I.e., the authors believe the router was
accepting a valid CRC in, modifying the packet, and transmitting one with a
(different) valid CRC out. The end receiver thus saw a packet with a valid CRC
but would have seen an invalid TCP checksum.

Their methodology captured packets at the link layer, (Sec 3.1):

"For each complete packet, the software calculates
the checksum and if the checksum fails, the entire packet
is saved."

Later they note how they find out of the segment was faulty due to a
retransmission without the fault:

"If the IP datagram contains a TCP segment, the capture
program records what bytes were in the segment (on the as-
sumption that the sequence numbers are correct!) and then
looks for valid retransmissions of those bytes."

The do not seek, nor did they find in the wild, a single packet where the CRC
was valid and the TCP checksum was valid, but the packet had changed in
contents. That could have been attempted (perhaps with greater computational
power), but was not.

Joe