RE: [Tsvwg] SCTP Checksum Change to the IESG

[[e-mail]]

Randall,

The draft says: "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."

That sure looks like a requirement to me. Not clear why it says that the
same thing is recommended in another place but I assume that attaching
SHOULD and MUST to the same item in different places means that it is a
MUST.

Secondly, you presume that the CRC checker produces the same value as a CRC
generator and as I have pointed out in my other emails the most common CRC
checker implementation in hardware does not.

I have another problem with the draft. In a number of places it talks about
zeroing out the checksum field to do CRC generation. This has no purpose
especially since the recommended method for generating the CRC is the SMD
(simultaneous multiply divide) method. This method does not run trailing
zeros through the CRC generator since the generator does the multiplication
by x^32 at the same time as it divides.

Regards,
Pat



-----Original Message-----
From: Randall Stewart [mailto:[e-mail]]
Sent: Thursday, May 02, 2002 10:25 AM
To: Douglas Otis
Cc: [e-mail]
Subject: Re: [Tsvwg] SCTP Checksum Change to the IESG


Doug:

Please lets be clear here and not confuse the recommended approach
... there is NO MUST attached to the "recommended approach"

What I read from you.. and I would like a short YES/NO if I read
you correct is:

You DON'T want to have to give the implementation two values
back i.e. the computed value and the value in the data.

Instead you would like to give as YES/NO back...



I don't see why you should object to this.. since it gives
a audit mechanism over the hardware.. and in fact passing
back the 32 bit value gives more info if you are trying to
debug what is going wrong... 

With modern architectures passing a 32 bit value back verses
passing a YES/NO bit really does not add anything cpu savings
wise... ... in fact it won't be to long and we will be saying
this about 64 bit values.. pretty wild when one things about it...

R


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

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