[ih] TCP RTT Estimator

[Jack Haverty]

John - you're right, the TCP checksum covers the header and "text".   I 
was thinking of the checksum in the IP header.   The Cerf/Kahn 1974 
paper has checksums in various places, but I don't recall how they were 
implemented before TCP and IP had been split apart.

At the time there was a lot of debate about the "End-to-end" issues in 
The Internet.  One of the issues I brought up was the "End-Middle" 
scenarios.   As a datagram flowed through devices, some of the 
information in headers was "consumed" by devices in the "middle", e.g., 
gateways which relied on data in IP header fields and options.  Other 
information was "produced" by devices along the way and added to the 
datagram, e.g., the addresses added into "record route" options or new 
datagrams sent such as Source Quench.

Each of those information flows, from producer to consumer(s), was 
subject to errors, but there was no mechanism to provide error 
detection, correction, or source authentication for all those flows of 
information that occurred whenever a datagram was sent.   There were 
more "ends" than the obvious two involved in the communication.  That 
was another issue put on the long-term to-do list.

This was not just a characteristic of TCP/IP.   The same thing happens 
even today in email headers, as you can see by looking at the raw 
headers in emails like this one.

Jack

On 4/18/25 11:14, John Day wrote:
> Correct me if I am wrong, but I thought the TCP checksum covered the entire TCP packet plus the pseudo-header.
>
> The IP checksum only covered the IP header plus the pseudo-header.
>
> Am I wrong?
>
> John
>
>> On Apr 18, 2025, at 14:00, Jack Haverty via Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>> Memory errors caused at least some ARPANET crashes, but I suspect few people outside of BBN knew such details.  But memory errors could affect any part of the data.  The checksums in TCP only covered some parts of the headers.   If they were designed to protect against memory problems, shouldn't they have covered the entire datagrams?
>>
>> Subsequently, changes to the TCP/IP architecture made checksums even less potent, when devices along the path through the Internet started recalculating checksums.  Mechanisms such as NAT, for example.
>>
>> So I still can't recall why checksums were included in TCP...
>>
>> Jack
>>
>> On 4/18/25 10:30, Craig Partridge wrote:
>>>
>>> On Fri, Apr 18, 2025 at 11:25 AM Andrew G. Malis via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>
>>>     Jack,
>>>
>>>     > Thinking back, I can't recall the reason for including checksums
>>>     in TCP
>>>     at all.
>>>
>>>     It was primarily to catch memory errors, which were a real thing
>>>     back in
>>>     the core memory days. Errors during transmission were generally
>>>     caught by
>>>     the lower layers.
>>>
>>>
>>> Memory errors are back.... I'm on a team that has caught them in disk caches :-(
>>> Craig
>>>
>>>
>>> -- 
>>> *****
>>> Craig Partridge's email account for professional society activities and mailing lists.
>> -- 
>> 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/561bdfd4/attachment.asc>