Hi all,
I was wondering why such a simple checksum algorithm is implemented in
TCP. I suppose, it's because of the slow CPU performance many years ago.
This algorithm looks so unreliable to me that it even can't protect
against some pretty simple errors, which (I suppose) also could occur
randomly (but obviously very seldomly in practice).
In RFC 1122 I've read that the TCP checksum MUST (the usual caps lock
problem...) be implemented:
...
4.2.2.7 TCP Checksum: RFC-793 Section 3.1
Unlike the UDP checksum (see Section 4.1.3.4), the TCP checksum is
never optional. The sender MUST generate it and the receiver MUST check it.
...
So I'm wondering why it MUST be calulated:
is it necessary to implement a checksum in TCP because reliability at
layer 2 is insufficient in practice? I see only two possible answers to
this question:
1) yes - than it's a very old reliability bug and should be fixed,
because sooner or later the TCP checksum won't catch a random error
pattern in a segment. (should it be fixed by always using an alternate
TCP checksum option, i.e. a MD5 hash? Or by improving layer 2
reliability in hardware?) [btw, netstat -sp tcp shows me that there
sometimes are TCP checksum errors - 23 errors in 9 days on a slow DSL link]
2) no - so why not skip TCP checksum calculation at all? (at least for
incoming seqments this wouldn't break a thing besides the RFC itself).
I know that some new NICs do checksum calculation in hardware for
performance reasons, but this has nothing to do with the actual problem
(if there even is a necessity to calculate a checksum at transport layer).
Please correct me if my assumptions or conclusions are wrong.
regards,
Andreas
