Subject: [Tsvwg] RE: U-SCTP comments

From: [email-masked]
Date: Tue, 13 Mar 2001 14:35:53 +0200

> >         - Section 3.2.2: This is a little bit tricky. If 
> the sender of a
> > P-DATA sets the "Checksum Coverage" field exactly to the 
> value of Chunk
> > Length - 20, but the P-DATA contains some padding at the 
> end, should those
> > bytes (that would be set in theory to 0) be included in the Adler-32
> > checksum? The same questions comes if for example there are 
> 3 bytes of
> > padding at the end, and the Checksum Coverage is set to 
> Chunk Length - 19,
> > for example, should we include also the other 2 bytes of 
> padding in the
> > checksum?
> 
> Padding is never counted in the Chunk Length and is never 
> covered by the
> checksum. This is very clear in RFC2960 and U-SCTP makes no difference
> here. We can further clarify this by adding a note.

	:-O

	Excuse me Qiaobing, maybe I'm wrong but I couldn't find any place in
RFC 2960 that says that the paddings are not included in the checksum :-/...
Section 6.8 2) says:

   2) Calculate the Adler-32 checksum of the whole packet, including the
      SCTP common header and all the chunks.  Refer to appendix B for
      details of the Adler-32 algorithm.  And,

	Nothing about not including paddings... If you go to the appendix B,
you can read:

         while (read_buffer(buffer, length) != EOF) {
           adler = update_adler32(adler, buffer, length);
         }

	I guess that buffer is a byte array containing part of the datagram,
length is the length of that buffer, and read_buffer reads "length" bytes
from the datagram and stores them in "buffer"... It seems that we calculate
the checksum of a byte stream (in this case a SCTP datagram) step by step,
but everything, even the paddings are included (maybe the one for the last
chunk is not??!!).

	In any case, I haven't modified the Adler-32 checksum algorithm I
use in a long time, I include all the bytes of a datagram to calculate it
(including all the paddings), and it worked with some other implementations
during the bake off, so I guess that other people are doing it as I am...

	Comments?

	BR Iván Arias Rodriguez

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 13 Mar 2001 07:35:27 -0600

[email-masked] writes:
> > covered by the checksum. This is very clear in RFC2960 and U-SCTP
> > makes no difference here. We can further clarify this by adding a
> > note.
> 
> 	:-O
> 

I thought this came up at the bakeoff, but I can't find it in
draft-stewart-ong-sctpbakeoff-sigtran-01.txt.

There IS a section that clarifies that the padding bytes in the LAST
bundled chunk are not included in the length of the SCTP packet, so we
can infer that these should be excluded from the checksum.  Do the
extra zeros have any effect on the algorithm?

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 13 Mar 2001 12:30:14 -0600

> RFC 2960 that says that the paddings are not included in the checksum :-/...
...snip...

Sorry, my mistake. I meant to say that the paddings are not included in
the Chunk Length and RFC2960 states this clearly. And I agree with you
that the RFC2960 checksum does cover all the paddings in the middle of
the packet. As to the paddings in the LAST bundled chunk, we should
clarify it further (maybe we already have noted it down, Randy?).

Now let us go back to the P-DATA issue. My inclination is that we should
NOT include paddings. For example, with the following P-DATA chunk:

  +-------------------+
  | chunk header (20) |
  +-------------------+
  | user data (37)    |
  | paddings (3)      |
  +-------------------+

we will have Chunk Length = 20 + 37 = 57.

If the Checksum Coverage = 0, then only the header is covered, 
If the Checksum Coverage >= 37, then only the first 57 bytes (header +
user data) are covered. 

Comments?

-Qiaobing

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Wed, 14 Mar 2001 06:10:17 -0600

Qiaobing Xie <[email-masked]> writes:
> >         Excuse me Qiaobing, maybe I'm wrong but I couldn't find
> > any place in RFC 2960 that says that the paddings are not included
> > in the checksum :-/.. 
 .
> NOT include paddings. For example, with the following P-DATA chunk:

I agree.  If we are going to go to the trouble of parsing the whole
packet before checksumming, then there is no percentage in including
the padding bytes.

I'm a little concerned about parsing the packet based on data that has
not (yet) been confirmed by checksum.  At the very least it will
require some very careful thought.  Invalid chunk types and invalid
lengths are two problems that leap to mind.

Is there are fast way to detect packets with P-DATA chunks in them?
I'd really rather not pollute my checksum fast-path with them.

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 14 Mar 2001 15:02:07 -0600

...
> I'd really rather not pollute my checksum fast-path with them.

Both points are very valid. I will include them as open issues.

-Qiaobing