[e2e] Re: [Tsvwg] Really End-to-end or CRC vs everything
else?
David P. Reed
dpreed at reed.com
Thu May 24 12:33:32 PDT 2001
I don't want to get sucked into this too heavily, because I think it is a
small point.
Here's how I read the end-to-end argument's application in this case. The
protocol creates a layer that supports only those apps that need guarantee
data integrity from endpoint to endpoint. There is a choice whether to
provide it in the application ends or the SCTP ends, which are the same
machine (that is, SCTP is unlike SMTP in that it does not describe one hop
in a multiple hop scheme).
The application endpoints thus have an extremely high degree of certainty
that data is not corrupted between the checksum creation and decoding if
done at SCTP level, as long as the checksum is indeed done at the end-point
machines (big requirement in protocol definition, lest someone try to do it
down in some NIC).
crc32 is thought to be better at detecting errors than the alternative, and
can be computed at speeds that closely match traditional addition-based
checksums. So in designing a new protocol, I'd lean towards crc32.
But there are better alternatives that are in the same cost ballpark. For
example, it would be extremely useful to have the checksum block
"middleboxes" that might be introduced that spoof protocols so that they do
not provide true end-to-end checking of integrity. For that reason, I'd
suggest an MD5-based cryptographic hash code that is based on a shared
secret. This would make spoofing impossible, and assure the endpoints that
corruption didn't happen by badly designed spoofing boxes, and even bad actors.
Would putting such a thing in SCTP violate the end-to-end argument? I
don't think so, though it would make explicit the point that SCTP is
intended to be a protocol that preserves integrity between the two ends.
A somewhat more end-to-end design that enabled applications to completely
control the level of integrity would be to have the packet receiver call on
a function provided by the client app to compute the checksum. And have
the sending app call the same function. SCTP could then provide a
"recommended" checksum function as a default that would be, say, crc32 or
MD5. And clients could conveniently use that as a known standard of known
quality. Note that since checksums are validated at a different time than
data is released to the client app, this would require that the checksum
validation code be called at a different time than the data is released to
the app.
At 12:42 PM 5/24/01 -0500, Randall R. Stewart wrote:
>Actually:
>
>I must strongly dis-agree... this does not indicate
>his/their vote on this... the question is what is
>the acceptable trade off.. that is unanswered by
>the end2end argument...
>
>I will let Dr. Reed answer and not put
>words in his mouth, if he so wishes to voice an
>opinion...
>
>
>R
>
>
>Qiaobing Xie wrote:
> >
> > Randy,
> >
> > Based on the following sentence you quote from the end2end paper,
> >
> > "....It is probably not important to strive for a negligible error rate
> > at any point below the application level."
> >
> > you can probably add David Reed and his co-authors of that paper to your
> > "No, the cost is too high" camp :)
> >
> > -Qiaobing
> >
> > > So far I think I can sum up the folks in different camps:
> > > ******************************************************
> > > -----------------------------------------
> > > Yes, pay the price:
> > > -----------------------------------------
> > > Lloyd Wood
> > > La Monte Yarroll
> > > Doug Otis
> > > David Black
> > >
> > > ----------------------------------------
> > > No, the cost is to high:
> > > ----------------------------------------
> > > Qiaobing Xie
> > > Ran Atkinson
> > >
> > > -----------------------------------------
> > > No preference, as long as ONLY one is picked:
> > > -----------------------------------------
> > > Kacheong Poon
> > > Jonathan Woods
> > > Me
> > >
> > > -----------------------------------
> > > Not sure there is a problem:
> > > ------------------------------------
> > > Ian Rytina
> > > Shyamal Prasad
> > >
> > > ******************************************************
> > > Now, if I missed anyone OR have you down wrong please
> > > chime in here... my apologies ...
> > >
> > > If you would like to chime in ****PLEASE PLEASE do so!!!
> > > the more people that comment and add to the discussion
> > > the better*****
> > >
> > > As it stands, I don't see any consensus either way
> > > on this issue... except I would say the one item
> > > of consenus is that there is a problem :)
> > >
> > > Regards
> > >
> > > R
> > >
> > > >
> > > > The black boxers say that the application should be able to trust the
> > > > transport completely. The natural conclusion here is that we should
> > > > use the strongest digest protection we can get our hands on, CPU
> > > > cycles be damned.
> > > >
> > > > I don't think either side of the debate intends the conclusions I have
> > > > drawn above. I THINK we are debating CRC vs everything else. Is this
> > > > accurate?
> > > >
> > > > I've revealed my bias in previous messages, so let me bolster my side.
> > > >
> > > > Does anybody dispute the fact that CRC-32 gives the strongest
> > > > protection of any of the options we've examined? I THINK the only
> > > > remaining issue we care about is CPU and memory consumption.
> > > >
> > > > I was hoping to find you some real numbers, but instead I have
> > > > anecdotal data.
> > > >
> > > > Did you know that Fidonet used a CRC-32 to protect data? For those
> > > > who don't know, this is a store-and-forward network built during the
> > > > days when a fully loaded machine had a 12Mhz 8086 with 640K of RAM.
> > > >
> > > > Not small enough for you? How about Zmodem? It ran a real-time (for
> > > > 2400 baud links) CRC-32 on my TRS-80. That's a system with 48K of RAM
> > > > and a 2Mhz 8-bit CPU.
> > > >
> > > > If I were going to build a really cost-sensitive embedded device with
> > > > SCTP today, I would probably opt for Zilog's version of the Z80 that
> > > > includes a hardware CRC. The chip is very mature (over 10 years old),
> > > > has multiple second sources, and goes for under $1 in OEM quantities.
> > > > --
> > > > La Monte H.P. Yarroll Home: piggy at baqaqi.chi.il.us
> > > > If you remember nothing else: piggy at acm.org NIC Handle: LY
> > > > GPL - "Just give source a chance."
> > > >
> > > > _______________________________________________
> > > > tsvwg mailing list
> > > > tsvwg at ietf.org
> > > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > >
> > > --
> > > Randall R. Stewart
> > > randall at stewart.chicago.il.us or rrs at cisco.com
> > > 815-342-5222 (cell) 815-477-2127 (work)
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > tsvwg at ietf.org
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
>
>--
>Randall R. Stewart
>randall at stewart.chicago.il.us or rrs at cisco.com
>815-342-5222 (cell) 815-477-2127 (work)
- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html
More information about the end2end-interest
mailing list