Re: [Tsvwg] SCTP Checksum Change to the IESG

["Brian F. G. Bidulock" <[e-mail]>]

Douglas,

Upon reviewing the draft I agree with your statements.  The added text
makes the draft now presuppose to tell hardware as well as software
designers their business.  It might not be so bad if the recommended
approaches were the obvious best ones, but in both the software and
hardware cases, the strongly recommended and seemingly required
approach is suboptimal.  It further presumes to do this on the grounds
of past faulty hardware design.  I should think that it is obvious
that one would be wise not to purchase or deploy faulty hardware or
software.  No amount of "MUST" and "SHOULD" statements in the draft
will protect against faulty design or faulty implementation either in
software or hardware.  Either faulty hardware or faulty software is
even likely to deliver a faulty packet regardless of the checksum
algorithm.

I don't see a problem with recommending that a hardware assist
function deliver the information necessary to permit the software to
also do the calculation successfully.  But this is an operational
consideration and "MUST" language is IMO inappropriate here.  It is
the business of the hardware designer to either allow for a software
fix to poor hardware design, or not.  These are market issues, not
standardization or interoperability issues.

For software implementations, although the steps which would allow a
proper calculation have been detailed, the draft still does appear to
permit any other algorithm which yields the same result.  Rahter than
allowing software developers to generate optimal algorithms for their
software environment, it appears that the new draft wades into
restricting hardware assist designs also to sub-optimal approaches.

I think that your recommendation for hardware assist to deliver the
packet intact (with original checksum in place) appears to be the best
one for most circumstances and satisfies the objective of permitting
software to also perform the calculation.  It is as suboptimal to
require the hardware to replace the checksum when calculating as it is
to require software to modified a shared buffer.

If the editor of this draft could make the necessary changes to permit
software and hardware designers both to go about their business we
could finalize it and move forward.

I propose that the editor remove the restrictions on software and
hardware design, recommend that the hardware deliver the packet
intact, and only then advance the draft.  Othewise, the draft appears
to be clearly disputable on the grounds of technical error and plain
bad advice.

--brian

On Wed, 01 May 2002, Douglas Otis wrote:

> Scott,
> 
> While I agree with this sentiment, the introduction of a hardware
> implementation requirement is new text in conflict with previously raised
> concerns.  It appears Jonathan does not agree there is a need to allow
> implementations where the packet is not modified during the checking
> process.  This is a real problem.  This is true for hardware where an
> unmodified packet allows far greater software compatibility and should be
> the recommended approach.  I was happy with the draft prior to these last
> minute changes that appeared without review.  I was not the one twiddling.
> This is a wrong approach, if to standardize the hardware interface as is the
> intent of this language.
> 
> Presenting an unmodified packet would allow an Alder scheme to be introduced
> in software, as example, without any changes to existing code.  The same is
> equally true for a software CRC algorithm.  The scheme, as defined now, will
> require specialized code to handle such a situation.  The current
> recommendation is clumsy and wrong.  More generalized language would be
> acceptable such as- For hardware checking schemes, software MUST be able to
> confirm the integrity of the packet and not rely exclusively on a status
> bit.  An unmodified packet accomplishes this goal.  This added language has
> compounded an inappropriate algorithm interpretation.
> 
>  -Doug
> 
> On May 1, 2002 6:42 PM Scott Bradner ([e-mail]) wrote:
> >
> > the twiddeling with this document has gone on far far too long
> > at this point I do not see a reason to not have the IESG review this
> > version unless someone can show that it will not work
> >
> > someday we have to say that its good enough - and that day is now to me
> >
> > Scott
> >
> On May 1, 2002 6:34 PM Douglas Otis ([e-mail]) wrote:
> >
> > Scott,
> >
> > I see the hardware implementation notes added in
> > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpcsum-06.txt
> >
> > A check that 'logically' zeros content of the checksum field during a
> > checksum calculation and then compares the result to an unaltered field
> > is robust.  Passing an unaltered packet to a software stack provides
> > a complete diagnostic should there be a suspected problem with checksum
> > hardware and allows an unmodified software implementation to take over.
> > It is clumsy to alter the packet and then require a means to expose this
> > prior value.  Would it be possible to suggest presenting an unaltered
> > packet in the event of an error as an alternative?  Exposing the
> > unaltered CRC is common practice as a diagnostic.  The CRC field in the
> > header over a hidden zero value is an unusual case with respect to CRC.
> > Imposing a read/write/read operation on this field as opposed to just a
> > read is more prone to error and adds complexity within the circuit and
> > interface.
> >
> >  -Doug
> >
> > On May 1, 2002 5:51 AM Scott Bradner ([e-mail]) wrote:
> > >
> > >
> > > fyi - the revised version of the SCTP checksum chnage will be
> > > posted today as draft-ietf-tsvwg-sctpcsum-06.txt - this is the
> > > version that the IESG will consider for publication as a Proposed
> > > Standard RFC updating RFC 2960.
> > >
> > > Scott
> >
> 
> 
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[e-mail]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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