[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything else?

[Christian Huitema]

> From: David P. Reed [mailto:dpreed at reed.com]
>
> >What is at stake here is whether we want a safety belt or an alarm
bell.
> 
> I would argue that the current TCP isn't a very good alarm bell,
because
> it
> doesn't detect too-smart-for-their-own-good, friendly "adversaries"
(such
> as NATs that recompute the entire checksum correctly after making
serious
> changes to the contents) that inadvertently weaken the detection.
>   Note that, if you really follow the e2e argument, this
> >is OK: the only way to be certain that the back-up went well is by
> >computing a strong checksum over the whole volume, not by trusting
TCP.
> 
> Indeed.  But then the IETF ought to spread the gospel to the folks who
are
> responsible for FTP and SMTP, for example.  These poor souls typically
> believe that TCP provides a *reliable* stream, where the word reliable
is
> implicitly defined as *perfect*.

As Vernon pointed out, this is exactly what SSL/TLS gives you: a strong
checksum on top of TCP. It is actually commonly used in the
"continuously running applications" that Julo mentioned in his message.
I would expect these applications to do something smart when the SSL/TLS
checksum fails.

> >In fact, it is all a matter of probabilities and arbitrations. The
> >transmission system should be good enough that the backup is OK most
of
> >the time, so that the e2e checksum (volume) only fails rarely, so
that
> >the cost of correction is acceptable...
> 
> I assume you mean by transmitting the whole file again.

That, or some form of divide and conquer. It is again a matter of
probabilities and arbitrations, whether or not you want to "optimize the
error cases."

-- Christian Huitema