[ih] TCP RTT Estimator

[Jack Haverty]

I can confirm that the computer resources for computing a checksum were 
definitely a concern with the machines of that era. Communications 
hardware, such as modems, could do robust checksums in hardware, but the 
checksums in TCP/IP were too complicated for that since only particular 
parts of datagrams were included in the calculations.

It was difficult enough to get a decent packets-per-second performance 
in gateways, and minimize overhead in host computers, without the 
additional work to do a "real" checksum.  So the rudimentary one (that 
IIRC was the same one we settled on at the first Bakeoff) was adequate 
for the moment.

In addition, we expected that, for DoD use, real-world deployment would 
utilize encryption, as was being done at the time on the ARPANET using 
PLIs.  See https://en.wikipedia.org/wiki/ARPANET_encryption_devices  
Military grade encryption was quite good as a checksum algorithm to 
catch all sorts of problems, including errors in transmission.

Thinking back, I can't recall the reason for including checksums in TCP 
at all.  Perhaps it was just there because it was standard practice to 
include some kind of mechanism to detect the expected transmission 
errors on circuits of the day.  Of course you had to have a checksum ... 
everyone else does.

Jack Haverty

On 4/17/25 11:58, touch--- via Internet-history wrote:
> AFAICT, the Internet checksum was basically a trade-off between an additional E2E check and the cost of implementing it in software.
>
> Link devices already had CRCs, but implemented in hardware, where bit-wise mixing is very fast. In software, the same function can require multiple opcodes per bit; the Internet checksum is one opcode per CPU word (1 per byte in the early days, fewer now), i.e., runs around 16-30x faster in software. Because the Internet assumes link layers can vary, there’s no easy way to assume all net devices implement the same CRC in hardware.
>
> This kind of speed difference gave rise to the misconception that *every* SW crypto/check alg was 10-50x faster in HW, which notably isn’t true for some hashes such as MD5.
>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Apr 17, 2025, at 11:34 AM, Leonard Kleinrock via Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>> Hi Dave,,
>> As I understood it, the CRC code was especially easy and powerful for detecting errors, but extremely complicated for correcting errors. I would’ve guessed that the error detection was indeed CRC (the BCH code).
>> Len
>>
>> Sent from my iPhone
>>
>>> On Apr 17, 2025, at 8:19 AM, David Finnigan via Internet-history<internet-history at elists.isoc.org>  wrote:
>>> On 13 Apr 2025 6:57 am, John Day via Internet-history wrote:
>>>> Sometime ago, (I think it was Jack Haverty) said that the TCP checksum
>>>> was a placeholder until they could consult someone to advise them on
>>>> what to use and it got lost in the shuffle.  ;-)
>>> Even RFC 791 [Sep 1981] states "experimental evidence indicates it [the checksum] is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience."
>>>
>>> -David Finnigan
>>> --
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250418/cda2af2a/attachment.asc>