Re: TCP "reliability"

[Jonathan Stone <jonathan@dsg.stanford.edu>]

In message <277DD60FB639D511AC0400B0D068B71E0709F5@corpmx14.us.dg.com>,
Black_David@emc.com writes:

>Careful - there are two meanings of the word reliability being confused
>here.
>
>(1) Data is delivered in the face of dropped packets.  TCP is definitely
>	reliable in this sense - all the data is delivered, in order, or the
>	connection closes.

Yep.

>(2) Data is correctly delivered in the face of corruption.  TCP's 16-bit
>	checksum falls short of a 32-bit CRC in its ability to detect
>	corruption, and hence TCP leaves something to be desired here.

David,

Can I quote that in my dissertation?

stricly, what you say is unquestionably true.  But I think you are
conflating two quite distinct properties here: 32-bit error-detecting
codes (EDCs) and the kinds of errors which a (32-bit) CRC guarantee to
catch, versus the errors which to which a transport-level error chehck
is, empirically, subjected.

It turns out that, on the best data we (I and Craig Partridge) have on
empirically-observed transport-level errors, CRCs are just not a whole
lot better than a 32-bit mod-M additive sum (where M ~= 2^32).

This is work in progress, so i cannot give a proper citation (best is
my nearly-complete dissertation).  OTOH, Julo Satran saw much of the
raw data at the recent framing/error-control meeting; i'd be very
happy to let Julo make a more impartial comment and see where that
goes.



>The word "integrity" is a better term for (2) to avoid confusion.

No argument there. The term "reliable transport" shoul,d perhaps, be
understood in contrast to the contatenated-x25-virtual-circuit model
which telcos were offering in serious competition to IP/TCP, once upon
a time.  (I think even Bob Braden would buy that.)