[ih] TCP RTT Estimator

[Steve Crocker]

We tried to include a lightweight checksum in the original host-host
protocol.  (Later it was called the Network Control Protocol or NCP.  Same
protocol.)  The checksum was designed to be reasonably easy to compute.  It
was a 16-bit ones complement sum with one bit of rotation every thousand or
so bits.  (The rotation was intended to catch packets out of order, error
which we imagined might be possible but never occurred.)  Frank Heart
argued vehemently against it, saying it would make his network look slow.
I tried to push back and asked about the Host-IMP interface.  "As reliable
as your accumulator," he roared.

We removed the checkum from our design, a mistake I've rued ever since.
And, of course, it turned out there were indeed a few cases where it would
have made a difference.  As has been pointed out, there was a major memory
error in one of the IMPs that caused that IMP to look like it was zero
distance to every IMP.  But even before that error, when Lincoln Lab first
connected its host to its IMP, their hardware interface had a problem.
There was some crosstalk between the interface and the disk (or drum)
controller.  When the disk (or drum) was operating at the same time as the
Host-IMP interface, some bits got scrambled.  It apparently took them some
time to track down.  I think they would have found it faster if the
checksum had been part of the design.

Steve


On Fri, Apr 18, 2025 at 1:25 PM 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.
>
> Cheers,
> Andy
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Sent by a Verified

sender