[ih] Loss as a congestion signal [internet-history Digest, Vol 84, Issue 4]

[Noel Chiappa]

    > From: Craig Partridge <craig at aland.bbn.com>

    > I remember damaged packets.

I've been mildly racking my brain, and I just don't recall them being an issue
at MIT. I'm sure we had them, but I can only think they didn't pose a big
enough issue (performance-wise) that we noticed, and bothered to look into it.

Of course, we did always run with checksums on - in fact, we were so devoted
to the end-end principle that we even did a ring (the 10mbit/second one) that
didn't have a hardware checksum! Had we realized just how useless the TCP/UDP
checksum was... :-) (It did have a parity bit, but that was re-calculated at
every station - it was designed to find flaky links, not for data safety. I'm
not sure we ever bothered to collect statistics and look for flaky links,
though! Too many fish...)

    > the 1822 spec for ARPANET host connection had several variations, with
    > varying degress of CRCs 

IIRC, VDH and the VDH replacement, HDH (I think that was the name), had CRCs.
LH and DH (the two we used for all our machines at MIT) did not have a
checksum.

    > Then of course, there was SLIP -- which ran over dialup modem lines
    > with no CRC...

We ran an oddball serial line (leased line, but with asynchronous 9600 bps
modems :-) between MIT and Proteon; it implemented an idea Dave Reed had for
header compression. He noticed that sequential packets were mostly the same in
the header, so we kept a copy of the first 32 bytes of the previous packet,
and prepended a 32-bit vector, with a bit set in each to indicate that the
byte was the same, and only included the bytes that differed in the packet
sent over the line.

Of course, if the two ends got out of sync, things went south, so the format
included a one-byte (minimize line overhead) checksum; when the checksum
failed, a 'sync reset' was sent back to the other end, and the next packet
down the line was sent un-compressed.

But I don't recall that we ever looked at it to see how many packets we were
losing, etc, etc! In fact, looking at the code, it doesn't even seem to have
counted them (although it did print a log message when it lost sync). And it
also didn't count to see how much we were saving with the compression! Sigh!

	Noel