Subject: RE: [Tsvwg] SCTP Checksum Change to the IESG

From: Tuexen Michael <[email-masked]>
Date: Thu, 2 May 2002 14:04:11 +0200

Dear all,

see my comments below.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CC SE 7    E-mail: [email-masked]

> -----Original Message-----
> From:	Scott  Bradner [SMTP:[email-masked]]
> Sent:	Thursday, May 02, 2002 1:23 PM
> To:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: [Tsvwg] SCTP Checksum Change to the IESG
> 
> I disagree
> 
> if others think that Doug has a point that is important enough to
> delay this document even longer please speak up - if there is not
> support it is time to move on - if there is support (and more than 
> one or two people) then we will delay yet again
> 
> Scott
> 
> ---
> From [email-masked]  Thu May  2 04:13:18 2002
> From: [email-masked]
> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Subject: RE: [Tsvwg] SCTP Checksum Change to the IESG
> Date: Thu, 2 May 2002 11:06:13 +0300
> Thread-Topic: [Tsvwg] SCTP Checksum Change to the IESG
> Thread-Index: AcHxpjxIGhC9zygQSfGHzxp8oSdOagACb13Q
> To: <[email-masked]>, <[email-masked]>
> X-OriginalArrivalTime: 02 May 2002 08:06:14.0189 (UTC) FILETIME=[3A8C35D0:01C1F1B0]
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18023
> Sender: [email-masked]
> Errors-To: [email-masked]
> X-Mailman-Version: 1.0
> Precedence: bulk
> List-Id: Transport Area Working Group <tsvwg.ietf.org>
> X-BeenThere: [email-masked]
> 
> Hi Scott & Doug,
> 
> I think that we need to get this over & done with it.  If this is as
> important as Doug thinks it is (so I am willing to say it may be),
> then lets just put it to a working group 'vote' - have both 
> propsosed texts & have the WG decide which is appropriate.
> 
> best regards,
> john
> 
> > 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.
	[Tuexen Michael]  I agree with Doug that you may want
	to computer the CRC in hardware without changing the
	packet in memory and provide to the software the unmodified 
	packet and the hardware computed CRC separately. The sofware
	then makes the coparision.
	I do NOT see that this preocedure is forbidden in the ID.
	The verification routine on page 3 talks about Store and Replace.
	Only the implementation note on page 4 taks about modifying the
	packet. But it starts with "One recommended implementation strategy
	is" which does NOT require it. 
	The added text in this ID is helpful for the reader and it is 
	also agreed (up to now) by all comments on the list that it is
	a good thing that the software can do the computation again to
	verify the harware and/or work around some hardware problems.
	Summary:
	In my opinion the procedure described by Doug is not forbidden by
	the ID, so I see no reason why to delay the ID any further. 
>  > 
> > 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.
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 2 May 2002 06:02:04 -0700

Michael,

 "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."

This does not allow the freedom you suggested.  If the packet is presented
as unaltered, why mandate presentation of the hardware calculated value?
Software inspection of hardware status does *not* necessitate this
calculated value and yet it is now a MUST.  To be compliant with this,
hardware MUST present a clumsy and unneeded calculated value regardless of
the implementation.  Only where the packet is modified, would both prior and
hardware calculated values be needed and yet the draft demands this as a
result of this new requirement.  This is in violation of Scott's RFC 2119.

"6 Guidance in the use of these Imperatives

  Imperatives of the type defined in this memo must be used with care
  and sparingly.  In particular, they MUST only be used where it is
  actually required for interoperation or to limit behavior which has
  potential for causing harm (e.g., limiting retransmisssions)  For
  example, they must not be used to try to impose a particular method
  on implementors where the method is not required for
  interoperability."

Change this paragraph to read:

 "For hardware checking schemes, software SHOULD be able to confirm
  integrity of the packet and not rely exclusively on a status bit.
  An unmodified packet accomplishes this goal."

 -Doug

On May 2, 2002 5:04 AM Michael Tuxen ([email-masked]) wrote:
> > On May 2, 2002 4:13 AM John Loughney ([email-masked]) wrote:
> >
> > Hi Scott & Doug,
> >
> > > 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.

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 08:03:33 -0500

Comments below

>         the ID, so I see no reason why to delay the ID any further.

Michael:

I agree with you 100%. The wording for the hardware references
does NOT require you do it this way.. it just suggests an
implementation strategy.. it does NOT require it.

On top of that we did exactly what Brian wanted and returned
the wording of RFC2960..

I see no reason why this document should not move forward.

R
--
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 09:12:46 -0500

>   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

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 02 May 2002 11:13:04 -0400

>I see no reason why this document should not move forward.

Perhaps the word "recommended" in the sentence:

"One recommended implementation strategy is ...."

is too strong. Simply delete the word "recommended".

>R

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 May 2002 10:06:42 -0500

Randall,

	"Any implementation using hardware assists for checksum computation
	 MUST make the final CRC value available to the software portion of
	 the stack. ..."

This would appear to preclude non-altering technique for hardware assist.
If one computes the checksum at all, one "MUST" provide both the original
and computed values.  I think that this is the basis of the objection.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ 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 ¦

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 2 May 2002 10:01:11 -0700

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 12:19:25 -0500

"Michael A. Ramalho" wrote:
\
Michael:

Last time I looked "recommended" is NOT a key word and can
be ignored. Correct me if I am wrong but recommending something
does NOT REQUIRE that you do it..

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 12:25:25 -0500

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

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 2 May 2002 11:25:12 -0700

Randall,

See comments interspersed -

> back i.e. the computed value and the value in the data.

Yes.

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

Yes, I would like to provide an unaltered packet and a status bit.  This
draft prohibits this approach.

> debug what is going wrong...

One can audit hardware any number of ways without inflicting extra data on
the operational interface and should be completely left to the implementor.
The size of a descriptor cache will be impacted by a requirement of included
computed values.  These may not be computer systems but rather small and
constrained state machines pumping out packets.  Not altering the packet is
safer, faster, and a less complex means of providing an identical level of
software checking capabilities.  An address glitch during the 'recommended'
Read/Write/Read operation may induce a 64 bit packet error!  The MUST
requirement is in violation of RFC 2119!  The recommendation is bad advice
unless you wish to see slower hardware and a proliferation of checking
software needed for each device!

May I ask a few questions?

What is deduced from differing CRC results beyond what can be discerned from
an unaltered packet and a status bit?

Either the hardware works or it doesn't.  If it doesn't...

An unaltered packet and a status bit allows the software to confirm the
integrity of the hardware using existing routines.

Why require new checking routines tailored for specific hardware?

 -Doug

> > 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-
> >
> > 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
> >
> > > >  "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."
> > > >
> > >

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 02 May 2002 14:30:51 -0400

>does NOT REQUIRE that you do it..

Of course. I *never* inferred that it REQUIRED that you do something.
Your reply seems to infer that *I* thought "recommended" meant "required".
(I have this English language parsing problem with you sometimes).

 >is too strong. Simply delete the word "recommended".

My suggestion was simply that if it (the "recommended" word) causes
people to think/believe/interpret a more strong belief in the
recommendation than the "recommended" in the sentence was
meant to convey ... what exactly is the problem with simply
deleting the word "recommended"? Clearly *you* do not believe that
it conveys something that is required.

It seemed like the easiest fix to me (i.e., "One implementation
strategy is ... ").

When an adjective or adverb does not add value (i.e., information)
one SHOULD always consider deleting it ;).

Michael Ramalho

---

From: Scott Bradner <[email-masked]>
Date: Thu, 2 May 2002 14:35:00 -0400 (EDT)

> one SHOULD always consider deleting it ;).

it seems to me that it does add value - this is one way that
is knnown to meet the requirements - that is stronger than saying 
by the way, here is a way to do this

Scott

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 13:59:37 -0500

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,
> >

---

From: Randall Stewart <[email-masked]>
Date: Thu, 02 May 2002 13:56:42 -0500

Michael:

I think the point is moot.. it is NOT the recommended 
approach but the fact that you can't pass a bit instead
of a word back.. See my recent email to Doug and his
response..

R

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 02 May 2002 13:35:35 -0500

Hi, all,

-Qiaobing