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

[julian_satran at il.ibm.com]

Christian,

But the point is that any protocol using in-stream check has to do it's own
recovery when TCP has already the whole recovery mechanism in place.
IPsec is offering a protection mechanism at a level that enables the stack
to
throw away offending packets. Should everybody wanting a decent data
integrity check use IPsec?  Perhaps - as in a year or two there will be no
substantial penalty in hardware for doing it.  But I don't feel like this
is the right answer.

Julo


"Christian Huitema" <huitema at windows.microsoft.com> on 12-06-2001 19:05:38

Please respond to "Christian Huitema" <huitema at windows.microsoft.com>

To:   "David P. Reed" <dpreed at reed.com>, "Douglas Otis"
      <dotis at sanlight.net>, "Jonathan Stone" <jonathan at DSG.Stanford.EDU>,
      "Craig Partridge" <craig at aland.bbn.com>
cc:   tsvwg at ietf.org, "end2end" <end2end-interest at postel.org>
Subject:  RE: [e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
      else?




> 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