[ih] TCP RTT Estimator
John Day
jeanjour at comcast.net
Sun Apr 13 04:57:04 PDT 2025
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. ;-)
That said, the Transport Layer does require a different error code than the Data Link Layer. They operate over very different scopes and the Link Layers can be different requiring different error detection choices across the network. The Data Link Layer is protecting against data corruption in the Physical Layer so needs to be relatively strong and largely determined by the characteristics of the media, i.e., for copper, burst errors are common; but for fiber single bit errors are more likely.
The primary purpose at Transport is loss due to congestion and rare memory errors during relaying. Of course, lost messages are handled by retransmissions and memory error tend to be single bit errors, so a different error code is required.
Too long to go into here but if the Link Layer is flaky (like wireless), then it needs to be enhanced to meet the minimal requirements of the error rate expected by Transport, which since there are several of them, it has to be much less.
John
> On Apr 13, 2025, at 06:41, Dave Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
>
> On 4/12/2025 7:00 PM, Greg Skinner via Internet-history wrote:
>> There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion. These two problems call for distinctly different solutions. In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.
>
> I never worked on the development of TCP or its constituent components. Just an innocent bystander, curious to watch things developing. I think Jon Postel was still at UCLA and therefore stuck with me as an office-mate, which also meant he was usually my source of technical explanations for me.
>
> I was shocked to see how simplistic (and weak) the TCP checksum was. (Since I was just learning about such components, I of course assumed that the strongest possible data integrity mechanisms were always essential.)
>
> Similarly, given the considerable network distances data traveled, I was skeptical that the TCP retransmission mechanism would suffice if there were serious problems.
>
> Jon suggested that a) more robust data integrity was a lot more expensive, and b) TCP's mechanisms were meant for occasional and major problems.
>
> He said that any transit section with chronic issues needed to have its own, underlying and more-robust mechanisms, to bring its reliability and throughput up to an acceptable level.
>
> d/
>
> --
> Dave Crocker
>
> Brandenburg InternetWorking
> bbiw.net
> bluesky: @dcrocker.bsky.social
> mast: @dcrocker at mastodon.social
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
More information about the Internet-history
mailing list