Re: [Tsvwg] SCTP Checksum Change to the IESG

[Randall Stewart <[e-mail]>]

Jonathan:

I don't know if you are still on tsvwg list or not.. so I
will send this directly to you.. since it is your question
to answer..

What do you think?

R

Qiaobing Xie wrote:
> 
> Hi, all,
> 
> I am one of those who hate to see another delay of this draft, but I do
> think Doug has a valid point. Before taking on flames, let me clarify
> that I do understand the intention of those notes to hw designers - the
> purpose is to demand hw designers to build only CRC hw implementations
> whose results are verifiable by software.
> 
> Let's say we have no problem with this intention itself, but the current
> text does not exactly fulfill this intention. To illustrate Doug's
> point, let's see the following example.
> 
>        outputs to sw       result verifiable?     compliant to draft?
> -----------------------------------------------------------------------
> hw #1: GO/NO-GO flag             No                    No
> 
> hw #2: both initial              Yes                   Yes
>        value and computed
>        value
> 
> hw #3: GO/NO-GO flag             Yes                   No!!
>        and unaltered
>        packet
> 
> Here is the question: why hw #3 is outlawed by the current text while
> its results are clearly verifiable by software?
> 
> -Qiaobing
> 
> Douglas Otis wrote:
> >
> > Randall,
> >
> > This is a rather clear statement that demands (by using the word MUST) both
> > the initial value and the hardware computed checksum value.  This
> > requirement reflects expectations of a particular implementation that-
> >
> >  1) should not be the recommended approach
> >  2) should not form the basis of a MUST requirement
> >
> > It means a hardware solution that passes the packet unaltered and sets a
> > status bit within the descriptor would not meet the requirements of this
> > draft.  This noncompliant implementation would however allow software to
> > inspect the integrity of the hardware check and interoperate with all other
> > implementations without harm whatsoever.  The recommendation is wrong as is
> > this MUST provide statement.  If someone suspects a hardware problem or
> > wishes for a complete end-to-end solution, not altering the packet by
> > hardware should be the recommended implementation.  This however would not
> > comply with this draft without also providing a means of exchanging the
> > hardware result?  The current recommendation would provide a zeroed checksum
> > field and two odd places to look for the checksum values (computed and
> > original).  Software would then require many versions of checking schemes
> > for each hardware device rather than just the current scheme.  : (
> >
> >  -Doug
> >
> > On May 2, 2002 7:13 AM Randall Stewart ([e-mail])
> > wrote:
> > >
> > > Douglas Otis wrote:
> > > >
> > > >  "An implementation using hardware assist is encouraged to follow the
> > > >   exact procedure specified above.  Whatever implementation strategy
> > > >   an implementation chooses, it MUST arrange to provide both the
> > > >   initial value of the checksum field, and the value computed for the
> > > >   SCTP checksum, to the software stack."
> > > >
> > >
> > > Doug the only requirement above is that the hardware must let the
> > > software see both the initial value in the checksum field .. i.e.
> > > what came off the wire AND the value computed by the hardware..
> > >
> > > I think what Jonathan was after here is so that you don't get a
> > > GO/NO-GO from the hardware..
> > >
> > > This does NOT discourage you from doing non-alter techniques to
> > > the data packet.. since by non altering the packet you are letting
> > > the software see the value off the wire..
> > >
> > > I don't understand your objection.. the wording lets you do
> > > what you want and just recommends a specific implementation...
> > >
> > > R
> > >
> > > --
> > > Randall R. Stewart
> > > [e-mail] 815-342-5222 (cell phone)
> > >
> >
> > _______________________________________________
> > tsvwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall R. Stewart
[e-mail] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg