Subject: RE: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt]

From: [email-masked]
Date: Wed, 3 Apr 2002 16:57:27 +0300

Hi all!

	Please, see some comments below...

> > As Johnathan has not substantiate any of his statements 
> regarding the
> > exact procedure after several requests for explanation, I 
> propose that
> > you strike the following sentence and go with the modified 
> text above.
> > 
> 
> Well, so far I have not seen an overwhelming consensus for
> change... I will leave this to Scott and Allision to judge. I have
> submitted an -05 version with typo's fixed but this left the same
> i.e. not the above text that you commented on but the original.
> 
> I just don't see it as a problem Phil as convinced me 
> off-line that with
> a bit of sideways looking at it even the original wording will allow
> Michaels code...

	Why don't simply leaving things as they are and adding some note or something stating, for example: "Any other way of calculating the CRC that always leads to exactly the same result as the procedure stated above is also valid"?

	In my opinion, Brian made a good point. Especially when you are sending datagrams, you always know that those datagrams going to a specific association will always have the same port numbers, verification tag, and initial value of CRC (all 0s), i.e., same common header. Because of that, you can always skip the calculation of the CRC for the common header bytes since it will always lead to the same value (the only special cases are when the VT is not set to the "normal" value). When receiving a datagram, things are somehow more difficult to predict...

	So, in cases when you are only including one tiny chunk in the SCTP datagram (such as a SACK chunk without gaps or duplicate TSNs, for example, which in my opinion would be quite common), you would only need to calculate the CRC for the SACK bytes (20 bytes) instead of the whole datagram (32 bytes)... I don't know how much time this will save, but I don't see why you are not going to allow this as a legal practice...

	Comments?

	Thanks!

	BR Iván Arias Rodríguez

> R
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 
> _______________________________________________
> 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: Wed, 3 Apr 2002 10:36:26 -0800

Ivan,

The draft makes no statement about the packet being in contagious memory nor
that the calculation be done simultaneously across the entire packet.  It
provides only the sequence of the calculation.  Once you take that
perspective, then Michael Tuexen and Brian Bidulock's schemes can be done
without altering procedures described within this draft.

Doug

On April 3, 2002 5:57 AM Ivan Arias-Rodriguez
([email-masked]) wrote:
> 	Why don't simply leaving things as they are and adding some
> note or something stating, for example: "Any other way of
> calculating the CRC that always leads to exactly the same result
> as the procedure stated above is also valid"?
>
> 	In my opinion, Brian made a good point. Especially when you
> are sending datagrams, you always know that those datagrams going
> to a specific association will always have the same port numbers,
> verification tag, and initial value of CRC (all 0s), i.e., same
> common header. Because of that, you can always skip the
> calculation of the CRC for the common header bytes since it will
> always lead to the same value (the only special cases are when
> the VT is not set to the "normal" value). When receiving a
> datagram, things are somehow more difficult to predict...
>
> 	So, in cases when you are only including one tiny chunk in
> the SCTP datagram (such as a SACK chunk without gaps or duplicate
> TSNs, for example, which in my opinion would be quite common),
> you would only need to calculate the CRC for the SACK bytes (20
> bytes) instead of the whole datagram (32 bytes)... I don't know
> how much time this will save, but I don't see why you are not
> going to allow this as a legal practice...
>
> 	Comments?
>
> 	Thanks!
>
> 	BR Iván Arias Rodríguez
>
> > R
> > --
> > Randall R. Stewart

---

From: Jacob Heitz <[email-masked]>
Date: Wed, 03 Apr 2002 10:47:01 -0800

Douglas Otis wrote:
> The draft makes no statement about the packet being in contagious memory
                                                         ^^^^^^^^^^
Does this mean it has a virus ? :-)

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 3 Apr 2002 10:58:46 -0800

Jacob,

Opps, contiguous memory.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Apr 2002 13:07:31 -0600

Douglas,

Then why the objection to mathematically equivalent procedures?  If
the draft clearly stated your interpretation: that the MUST applies to
the "calculation" and not the "method," there would not be a problem.

On the contrary, others have expressed that this interpretation is
not true.  Which is it?  Can we clarify the text (perhaps with a note)
so that one interpretation can be taken.

--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: Wed, 3 Apr 2002 11:30:08 -0800

Brian,

Is it within the draft or Jonathan's statements you are objecting to?

The draft already indicates optional methods to calculate the CRC as
explanation with regard to initialization, as example.

The draft also indicates that the code is informative.  This leaves an
abstract calculation to be derived and implemented in whatever fashion
desired.  The draft also indicates there are many ways this can be done.
Beyond inventing a new algorithm, what is excluded by the draft?

Doug

On April 3, 2002 11:08 AM Brian F. G. Bidulock ([email-masked]) wrote:
> > The draft makes no statement about the packet being in
> > contiguous memory nor that the calculation be done simultaneously
> > across the entire packet.  It provides only the sequence of the
> > calculation.  Once you take that perspective, then Michael Tuexen
> > and Brian Bidulock's schemes can be done without altering procedures
> > described within this draft.
> >
> > Doug
> >

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Apr 2002 13:43:31 -0600

Douglas,

I have been told differently by Randall and Johnathan on this
list.  They say that the algorithm must exactly follow the
procedure laid out in the draft to conform to the MUST.

The examples are informative and do not create or relax any
requirements, and may even be in error.

So, Randall, Jonhnathan, does the existing text permit me to
implement the caluclation "in whatever fashion desired" as
interpreted by Doug?

--brian

---

From: Phillip Conrad <[email-masked]>
Date: Wed, 03 Apr 2002 15:17:08 -0500

> > The draft makes no statement about the packet being in contagious memory

I suspect that Doug may have intended to say "contiguous" rather than 
"contagious".

Merriam-Webster's defines:
  contiguous: being in actual contact : touching along a boundary or at a point
  contagious: communicable by contact : CATCHING <contagious diseases>.

But you never know: those physicists and engineers are developing new types
of memory all the time.

On a more serious note, I've given this more thought and discussed it with
some folks.

All in all, unless there are NEW voices to the contrary, or NEW points
raised, I'm convinced that the issue raised by Brian (that the current text
unnecessarily/inappropriately constrains the implementor) while having
enough merit to warrant the discussion that has already taken place, does in
the end does not have enough merit to warrant any change in the current text.

The two important things that the draft needs to capture are that

(1) a checksum calculation MUST be done on incoming packets, and that

(2) the definition of this required checksum calculation is "CRC-32c over
the received packet, but with the checksum field in that packet replaced by
zeros."

I think the current language does this just fine.    The main objection to
the current language is that it inappropriately constrains the implementor.
For a brief time, I was persuaded by this argument, but I am no longer so
persuaded, and would suggest that the current language, unmodified, is fine.

 From what I've seen so far, reluctance to change the current language stems
from any or all of three reasons:

(1) the *particular* language to which Brian Bidulock objects was already
*previously* approved at every level of the IETF review process; as evidence
of this, see RFC2960, Section 8.3, pages 81-82, where the same language
appears, with the only difference being "CRC32c" instead of "Adler-32?.
This doesn't PROVE that the language is appropriate, since no-one would
claim that the IETF process is "infallible", but it does provide a strong
case that this language has already undergone significant review, and that
the rough consensus was "thumbs up".

(2) There is concern that changing the language may open up what is
currently perceived by some to be a water-tight document, to all kinds of
philistine and libertine practices such as "not computing the checksum at
all", or computing it on an off-board processor
or out-board motor, or in an off-shore betting establishment.

Personally, I'm not convinced that anything in the *current* language, or
for that matter any of the currently proposed alternatives, is going to have
much impact one way or the other on what an implementer does in regard to
"how" the checksum is calculated.      If it is really very important to
prohibit or discourage off-board processing of the checksum (and I'm now
convinced by Jonathan and others that perhaps we should) then I think we
should  *say that explicitly*.

Bottom line, these ARE internal implementation details, not visible on the
wire unless the hardware actually fails (unlike choosing explicitly to NOT
verify the checksum at all, which is easy to detect on the wire).   But, to
the extent that colleagues who are more knowledgeable about checksums (e.g.
Jonathan Stone) see this issue differently, I'm more than willing to defer
to their judgement about the power of the current language to discourage the
practice of "unsafe checksumming."

(3) The only counter-example of how one MIGHT want to compute the checksum
differently from the straightforward way described in the current draft is
the one in Michael Tuexen's ethereal code (previously posted on the list).
    However, on further consideration, I think this can be seen to be in
compliance with the current draft.    I'll leave the details of that to a
postscript.

All in all, unless there are NEW voices to the contrary, or NEW points
raised, I'm convinced that the issue raised by Brian (that the current text
unnecessarily/inappropriately constrains the implementor) while having
enough merit to warrant the discussion that has already taken place, does in
the end does not have enough merit to warrant any change in the current text.

Cheers,
Phill

PS: Two appendices...  first, how the current draft can permit Michael
Tuxen's code, and second, a few comments from Lewis Carroll that may be in
order here...

"1) Store the received CRC-32c value".

The value is most certainly stored by Michael's code (albeit in its original
place.)

"2) Replace the 32 bits of the Checksum field in the received SCTP packet
with all '0's and calculate a CRC-32c value of the whole received packet."

The word "replacement" here does not spell out whether it
is a physical movement of data, or whether it is a mathematical replacement.

The most straightforward interpretation  is a physical movement of data.
Michael's code, instead, does a mathematical replacement, by passing zeros
to the CRC32c function, bypassing the four bytes of the checksum field.

Also, note that "do X and do Y" doesn't necessarily mean "do X first, and do
Y second".   The replacement does not HAVE to PRECEDE the checksum
calculation; Michael's code integrates them into one step.   Perfectly fine.

"3) Verify that the calculated CRC-32c value is the same as the received
CRC-32c value. If not, the receiver MUST treat the packet as an invalid SCTP
packet. "    Actually, Michael's code doesn't spell out how this is done,
but presumably, the value returned at the end would be compared to the value
that is *still* stored in place in the packet buffer.  So, again, no problems.

A little quote from "Through the Looking Glass" by Lewis Caroll may be in
order here.

>`I don't know what you mean by "glory,"' Alice said.
>
>   Humpty Dumpty smiled contemptuously.  `Of course you don't--
>till I tell you.  I meant "there's a nice knock-down argument for
>you!"'
>
>   `But "glory" doesn't mean "a nice knock-down argument,"' Alice
>objected.
>
>   `When _I_ use a word,' Humpty Dumpty said in rather a scornful
>tone, `it means just what I choose it to mean--neither more nor
>less.'
>
>   `The question is,' said Alice, `whether you CAN make words mean
>so many different things.'
>
>   `The question is,' said Humpty Dumpty, `which is to be master--
>that's all.'

More such fun available at: http://www.textlibrary.com/download/thru-loo.txt

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Apr 2002 16:04:35 -0600

Phillip,

Please see comments below...

> the rough consensus was "thumbs up".

Unfortunately it is not the same language.  RFC 2960 says:

"    When an SCTP packet is received, the receiver MUST first check the
"    Adler-32 checksum:
" 
"    1) Store the received Adler-32 checksum value aside,
" 
"    2) Replace the 32 bits of the checksum field in the received SCTP
"       packet with all '0's and calculate an Adler-32 checksum value of
"       the whole received packet.  And,
" 
"    3) Verify that the calculated Adler-32 checksum is the same as the
"       received Adler-32 checksum.  If not, the receiver MUST treat the
"       packet as an invalid SCTP packet.
" 
"    The default procedure for handling invalid SCTP packets is to
"    silently discard them.

CSUM-04 says:

"    When an SCTP packet is received, the receiver MUST first perform the 
"    following: 
"     
"    1) Store the received CRC-32c value, 
"     
"    2) Replace the 32 bits of the Checksum field in the received SCTP packet 
"       with all '0's and calculate a CRC-32c value of the whole received 
"       packet.  And, 
"     
"    3) Verify that the calculated CRC-32c value is the same as the received 
"       CRC-32c value.  If not, the receiver MUST treat the packet as an 
"       invalid SCTP packet. 
"     
"    The default procedure for handling invalid SCTP packets is to silently 
"    discard them. 

If we change:

"    When an SCTP packet is received, the receiver MUST first perform the 
"    following: 

to

"    When an SCTP packet is received, the receiver MUST first check the
"    CRC-32c checksum:

and make the CSUM text match the RFC 2960 text, I would have no problem.
This difference is one says that the check must be performed, the other
says how it must be performed.

> practice of "unsafe checksumming."

After reading the introduction, I would question that knowledge.

> compliance with the current draft.    I'll leave the details of that to a

You have overlooked my two counterexamples: precalculating the SCTP
common header checksum on a per-association basis as a more efficient
starting point for the calculation, and the Van Jacobson 30-line send
approach of performing partial checksums on data while copying from the
user.  As CRC-32c is division, it can be performed as a series of partial
divisions which are later put together when the packet is bundled.  This
is done for TCP where software checksums are performed all the time.
To see how the approach is done, see any BSD NET4 based implementation
of TCP.

> the end does not have enough merit to warrant any change in the current text.

I agree: please do not change the text over RFC 2960: this means that
the text in the draft needs to be changed back from:

 <    When an SCTP packet is received, the receiver MUST first perform the 
 <    following: 

to read:

 >    When an SCTP packet is received, the receiver MUST first check the
 >    CRC-32c checksum:

--brian

> is a physical movement of data, or whether it is a mathematical replacement.

Johnathan objected to "mathematical equivalents".

> calculation; Michael's code integrates them into one step.   Perfectly fine.

Johnathan (and Randall) objected to reordering of the procedure.

> A little quote from "Through the Looking Glass" by Lewis Caroll may be in

Lewis Caroll was a mathematician and logician, and probably a poor
engineer.

--brian

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 3 Apr 2002 15:08:53 -0800

Phillip,

I think you will find defining where transport CRC is preformed to be
problematic.  As we pursue ever higher throughputs, it is interesting to
note next generation IO solutions replace PCI by emulation with serial
packets also protected by CRC.  Although it would be impossible to trust
equipment beyond your control as would be the case with a MAN or WAN
environment, the quality of local equipment is within your control.
Interfaces where errors go unchecked is being removed in newer designs.

There is no protection from a stray cosmic ray from flipping a bit.  A bit
error in hardware may have greater ramifications but as there is never a
time where the CPU is not dependent upon a great deal of hardware.
Positioning the algorithm closer to the CPU may have advantages but these
advantages may be reduced by a more complex system that has greater
opportunity to go astray.

Doug