Subject: RE: [Tsvwg] RE: U-SCTP comments

From: [email-masked]
Date: Tue, 13 Mar 2001 15:49:37 +0200

See my comments below...

> -----Original Message-----
> From: ext La Monte Henry Piggy Yarroll [mailto:[email-masked]]
> Sent: 13. March 2001 15:35
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] RE: U-SCTP comments 
> 
> 
> [email-masked] writes:
> > > 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...
> 
> 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?

	Well... that is not exactly what we are talking about I guess... I
think that what was stated during the bake off was that the padding of the
last parameter of a chunk wasn't included in the length of that chunk (but
all the rest were included)... I don't remember anything about if the last
padding of the last chunk is included or not in the SCTP packet, since there
isn't any Datagram Length value, just and addition of several Chunk Length
values...

	The extra 0s at the end really change the value of the checksum...
And as I said before, my checksum algorithm was compatible with some other
guy's ones in the bake off (actually all the ones I worked with), so I guess
they were doing the same... I don't see the point of excluding the padding
in the checksum, since in my opinion it doesn't do anything but complicating
more the algorithm, since then you have to parse first the datagram and then
calculating the checksum, and maybe if the checksum is invalid, you can't
even parse the datagram...

	I'm with you if you say that if there is a corruption in one padding
byte, then the whole datagram could be valid and you wouldn't need to
discard it... But I guess that the probability of receiving a corrupted
datagram is low, and even lower is the probability of having that corruption
in one padding byte... I think it is not worthy having extra computation in
every single incoming datagram just to avoid that possibility... you are
going to spend more time skipping padding bytes than if you simply include
them...

	I would appreciate any comments... Thanks!

	BR Iván Arias Rodríguez

	PS: In any case, maybe I'm clumsy but I have looked for any mention
about this in the RFC 2960 and I haven't found any...

---

From: [email-masked]
Date: Wed, 14 Mar 2001 11:13:10 +0200

> >         Excuse me Qiaobing, maybe I'm wrong but I couldn't 
> find any place in
> ...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?).

	I don't know if there is already any decision about this issue, but
I would vote for including the padding of the last chunk also inside the
checksum, so you don't have to parse the datagram before calculating the
checksum... I don't know how people do this, but in my implementation I
receive a bunch of bytes, I calculate the Adler checksum out of those bytes,
and then (if the checksum is valid) I convert those bytes into my own
structures... Summarizing, it would take more time to skip the padding of
the last chunk, just to avoid including up to 3 bytes in every datagram...

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

	Since once you support the P-DATA chunks you have always to look
first inside the datagram previous to the checksum calculation, I would
support Qiaobing's proposal here.

> -Qiaobing

	BR Iván Arias Rodríguez

---

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

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

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

-Qiaobing

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Fri, 16 Mar 2001 15:46:45 +0200

Hi all!

	See below...

> > > ["La Monte Henry Piggy Yarroll" <[email-masked]> wrote:]
> > 	What about using with them the same restriction as with 
> COOKIE ECHO
> > and COOKIE ACK? I will propose that in case a datagram 
> carries any P-DATA,
> > the first chunk in the datagram should be a P-DATA chunk... 
> So we should
> > just look for the value 0xc3 in the first two bytes after 
> the header (bytes
> > 13th and 14th)... It would be a quickly check, and in case 
> that number is
> > there, we should make the parsing before verifying if the 
> checksum is
> > correct, otherwise not...
> > 
> > 	This can bring up some problems, since the DATA chunks 
> (and I guess
> > that the P-DATA chunks as well, that's what logically I 
> would do, but it is
> > not explicitly stated... Maybe the end of section 5 would 
> be the best place
> > to state it...) must be inside the datagram in ascending 
> order of TSNs (RFC
> > 2960, section 6.10, third paragraph), so, in case there are 
> DATA and P-DATA
> > chunks mixed in the same datagram, the first P-DATA should 
> have a TSN
> > previous to any other TSN in that datagram... This would 
> affect the way we
> > bundle the chunks inside a datagram... nothing that 
> couldn't be done...
> > Also, if an application makes use of these P-DATA chunks, 
> maybe it won't
> > even use the DATA chunks, so this restriction won't even 
> been noticed...
> > 
> > 	Any comments about this? Thanks!
> 
> I like this solution.  I was going to propose a P-DATA-PRESENT control
> chunk that would have to be the first chunk in the packet, but just
> saying that you can't bundle P-DATA with control chunks (AND the first
> P-DATA must be the first chunk) accomplishes much the same thing
> without a new control chunk.  Hmm... that DOES mean most of your SACKs
> in an unreliable association would have to travel stand-alone.

	Thinking about how to avoid this, I have a proposal that avoids
sending SACKs on their own, and at the same time makes much easier the
calculation of the checksum in case of unreliable DATA chunks included in
the datagram... This is what I have thought about (I won't do it again, it
hurts! ;-)):

	- Firstly, we should have a new chunk, called Partial Checksum
Coverage (P-CHECKSUM). It would be like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 0 0 0 0 1 1|  Chunk Flags  |    Chunk Length = 4 + N*4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Byte Block* Uncovered Start #1|  Byte Block* Uncovered End #1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                              ...                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Byte Block Uncovered Start #N |  Byte Block Uncovered End #N  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	* One Byte Block is simply a piece of the datagram.

	- The type would be the same as the one assigned to the P-DATA chunk
since that new chunk wouldn't be necessary any more (as you will see later).

	- This would be a control chunk that would have to be the first
chunk in the datagram (right after the common SCTP header), and should be
included in case any of the DATA chunks inside the datagram is only
partially covered by the Adler-32 Checksum.

	- Inside the datagram, the bytes starting from the one in position
"Byte Block Uncovered Start #X" (and including it) to "Byte Block Uncovered
End #X" (also this one included) are NOT covered by the Adler-32 Checksum.
All the rest (from byte number 0 to ("Byte Block Uncovered Start #1" - 1);
from ("Byte Block Uncovered End #X" + 1) to ("Byte Block Uncovered Start
#X+1" - 1); and from ("Byte Block Uncovered End #N" + 1) to the end of the
datagram (including padding)), ARE covered by the Adler-32 Checksum.

	- These byte blocks that are not covered by the Adler-32 Checksum,
should primarily be located inside the "User Data" part of DATA chunks, but
I don't know if this should be a must... Some other future chunks, or even
the ones that already exist, can be also partially covered by the checksum.
However, I think that this is not advisable (why doing it?). In any case, if
the goal is not parsing the datagram, that shouldn't be verified by the
receiver of the datagram.

	- The header of all the chunks in the datagram should always be
covered by the Adler-32 Checksum. This also makes that one uncovered byte
block should be located inside one chunk's bounds (the same block can't
affect more that one chunk), but there can be several byte blocks located
inside the same chunk.

	- The common header, and the whole P-CHECKSUM should always be
covered by the Adler-32. So, "Byte Block Uncovered Start #1" should be at
least: 12 (common header) + 4 + N*4 (P-CHECKSUM chunk) + 4 (next chunk
header) = 20 + N*4. If the restriction that only the "User Data" part of
DATA chunks can be uncovered, as I think is the logical way, that minimum
value would be: 12 + 4 + N*4 + 16 (fixed part of a DATA chunk) = 32 + N*4.

	- "Byte Block Uncovered Start #X" should be strictly smaller than
"Byte Block Uncovered End #X", for every byte block in the P-CHECKSUM. Also,
for every X and X+1 consecutive byte blocks, "Byte Block Uncovered End #X"
should be strictly smaller than "Byte Block Uncovered Start #X+1". In other
words, the byte blocks should be at least 1 byte length, and the "distance"
between byte blocks should be at least 1 byte. This is done not to make the
Adler-32 calculation unnecessarily longer.

	- "Byte Block Uncovered End #N" shouldn't be bigger than the length
of the SCTP datagram. The same can be said about any other "Byte Block
Uncovered Start" or "Byte Block Uncovered End"...

	- I think that we could allow not including any byte block at all
inside the P-CHECKSUM. This is because, for the shake of the simplicity, one
implementation could choose including the P-CHECKSUM always after the common
header. This could make things easier for the MTU restriction calculation, I
mean, when you bundle a DATA chunk with partial checksum coverage, you know
you have to add 4 more bytes (as with the P-DATA option) to set the
beginning and ending of the uncovered block (supposing you only have one
uncovered block in that DATA chunk), but the 4 bytes of the header of the
P-CHECKSUM must be added only the first time you add a partial covered DATA
chunk...

	- Maybe the DATA chunks with part of its "User Data" not covered by
the checksum could have a new flag set... But I don't think this would
really give you extra information at all or how this can be helpful...

	So, let's illustrate the "conversion" between the way of achieving
the not inclusion of some data inside the Adler-32 as stated in the draft,
and the new way proposed. Let's consider this datagram:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source Port Number        |     Destination Port Number   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Verification Tag                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Checksum                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = SACK  |  Chunk  Flags |       Chunk Length = 20       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Cumulative TSN Ack                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Advertised Receiver Window Credit (a_rwnd)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Number of Gap Ack Blocks = 1  |  Number of Duplicate TSNs = 0 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Gap Ack Block #1 Start     |     Gap Ack Block #1 End      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = P-DATA | Reserved|U|B|E|       Length = 64             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload Protocol Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Checksum Coverage = 4                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = P-DATA | Reserved|U|B|E|       Length = 104            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload Protocol Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Checksum Coverage = 48                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = DATA  | Reserved|U|B|E|       Length = 80             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload Protocol Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Using the P-CHECKSUM chunk, that SCTP datagram would become this
other one:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source Port Number        |     Destination Port Number   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Verification Tag                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Checksum                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=P-CHECKSUM|  Chunk Flags  |       Chunk Length = 12       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Byte Block Uncovered Start = 64|Byte Block Uncovered End = 103 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Byte Block Uncovered Start =168|Byte Block Uncovered End = 203 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = SACK  |  Chunk  Flags |       Chunk Length = 28       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Cumulative TSN Ack                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Advertised Receiver Window Credit (a_rwnd)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Number of Gap Ack Blocks = 1  |  Number of Duplicate TSNs = 0 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Gap Ack Block #1 Start     |     Gap Ack Block #1 End      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = DATA  | Reserved|U|B|E|       Length = 60             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload Protocol Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = DATA  | Reserved|U|B|E|       Length = 100            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload Protocol Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = DATA  | Reserved|U|B|E|       Length = 80             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Payload Protocol Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                 User Data (seq n of Stream S)                 /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Thinking about advantages and disadvantages of the change, I would
point these. Disadvantages... I can now think about these:

	- You use 4 more bytes than with the P-DATA usage option. I hope
that this is not that important...
	- When processing internally the DATA chunks, you don't know which
bytes have been covered by the Adler-32 Checksum and which not (at least not
that easily). Since you don't pass that information to the upper user, I
don't think that this is really important...
	- You need to feel this P-CHECKSUM chunk. But, since you really have
to know those byte positions when calculating the Adler-32 Checksum in your
outgoing datagrams, I think that this could be very easily to do...
	- You need to modify the draft in case you like it... :-)

	About the advantages... Maybe these ones:

	- It doesn't include the addition of any new type of chunk. You add
the P-CHECKSUM type, and delete the P-DATA type...
	- It is not necessary that the uncovered data is at the beginning of
the chunk. Also, there can be several uncovered byte blocks inside the same
DATA chunk. I don't know if this is important, but it gives you more
freedom...
	- The calculation of the Adler-32 Checksum takes almost the same
time as before. If the P-CHECKSUM is not the first chunk in the datagram, it
means that it is not there at all, and the calculation is almost exactly the
same as before, it only takes one more comparison, to see if byte in
position 12 is 0xc3.  If we allow including P-CHECKSUM chunks without byte
blocks, we should also check that bytes 14 and 15 make a two bytes unsigned
integer bigger than 8. If the P-CHECKSUM is there and includes at least one
byte block, the knowledge about which specific bytes are covered and which
are not is passed from the sender to the receiver in a neat way, without
extra calculation...
	- As the P-CHECKSUM is a control chunk, there isn't any problem
about putting it before any SACK chunk. So the problem about sending SACK
chunks on standalone datagrams is also solved.
	- The sending of user data is done in a regular way. From the
receivers point of view, there is no difference between data sent covered by
the checksum or not, since they are equally sent in DATA chunks. You don't
need to explain things in the draft regarding the differences between DATA
and P-DATA chunks, since there isn't such a difference any more.

	So, what the authors think about this? I hope this can be of any
help...

	Thanks!

	BR Iván Arias Rodríguez

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Fri, 16 Mar 2001 21:30:06 +0200

> Ivan,
> 
> Interesting proposal! But the issue raised by LaMonte still 
> concerns me
> and your this proposal doesn't change it. You still need to parse
> through the data structure __before__ you can validate the 
> checksum/data
> integrity. Your proposal just makes the calculation easier. 
> 
> I think this issue is fundamental and needs to be addressed somehow. 

	Well, yes..., you still have to "be confident" on one chunk before
you validate the checksum...

	But in any case, if the checksum is calculated differently depending
on the chunks carried inside the datagram, you need some information before
calculating the checksum... Unless you make kind of same partial checksum
calculation for all the datagrams (something that could be negotiated in
advance), I think that the information about the coverage of the checksum
must be included in the datagram... so you must trust it before you can
calculate the checksum...

	Well... thinking about it... Actually if the association is made so
partial coverage is supported that already makes the Adler-32 checksum not
covering the whole datagram... So... we can always cover with that checksum
a small and fixed part of the datagram in which we would have enough
information to calculate the checksum for the whole datagram... This can be
interesting...

	I have a new idea... that maybe somebody could find interesting... I
will also use the basis of the previous proposal... First, take a look to
the new P-CHECKSUM I'm thinking about:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 0 0 0 0 1 1|  Chunk Flags  |    Chunk Length = 12 + N*4    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Second Adler-32 Checksum                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Byte Block Uncovered Start #1 |  Byte Block  Uncovered End #1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                              ...                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Byte Block Uncovered Start #N |  Byte Block Uncovered End #N  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Third Adler-32 Checksum                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Imagine that in case the 'Partial Checksum Support' parameter is
included in both the INIT and INIT ACK, you continue with the COOKIE ECHO
and COOKIE ACK using the Adler-32 as always, and not including this
P-CHECKSUM chunk, but then, once the association is established, the
Adler-32 Checksum only covers the SCTP header, and the next 8 bytes. And you
have to include the P-CHECKSUM chunk in every datagram. Then with this
Adler-32 Checksum of the common header (First Adler-32 Checksum), you
validate the P-CHECKSUM header and the Second Adler-32 Checksum... You can
trust them...

	That value of Second Adler-32 Checksum would be the checksum for the
next 4 + N*4 bytes (byte blocks plus the Third Adler-32 Checksum). So you
calculate the Adler-32 checksum of those 4 + N*4 bytes and compare the value
obtained with the Second Adler-32 Checksum (already validated). Now you can
trust on the byte blocks and the Third Adler-32 Checksum.

	Finally, with the information of the byte blocks, you calculate the
Adler-32 of the rest of the datagram as the last proposal (not including any
of the bytes already "trustable"), and that value should be equal to the
Third Adler-32 Checksum... As a result you have never taken information of
any byte not already proved to be uncorrupted... To make easier this last
checksum calculation, maybe the "byte number 0" in the byte blocks could be
the first byte after the P-CHECKSUM chunk...

	You would need only two Adler-32 calculations if the number N
wouldn't be variable... but I guess this is not that useful...

	To calculate the checksums when sending the datagram, you should,
first calculate the Adler-32 of all the chunks of the datagram (not
including the P-CHECKSUM), taking into account the byte blocks as stated in
the previous proposal, and include that value in the 'Third Adler-32
Checksum' field of the P-CHECKSUM. You also should fill in the Byte Block
values...

	Then you calculate the Adler-32 checksum of those fields (byte
blocks and 3rd checksum), and you include that value in the 2nd checksum,
and you also fill in the value of the Chunk Length of the P-CHECKSUM chunk.
Finally, you calculate the Adler-32 of the common header (with the Adler-32
field of the common header set to all 0s), the P-CHECKSUM header and the 2nd
Adler-32, and you fill in the Adler-32 Checksum of the common header...

	This seems complicated to do, but maybe it is not such a big extra
task... Actually the calculation of the Third Adler-32 Checksum is almost
the same as the calculation of the normal Adler-32... And the other two ones
are made over just a few bytes... So I don't think that the extra
calculation would take that much time... maybe it can be the price you have
to pay for having this partial checksum coverage and not being able to trust
anything that hasn't already passed the checksum...

	I think this could be a solution to avoid the problem you were
pointing... It also makes easier the calculation of the Adler-32 checksum
due to the "Byte Blocks" (at least the most complex one, the 'Third Adler-32
Checksum'), as the previous proposal... On the other hand it gives you some
extra work, and 12 more bytes per datagram...

	Thinking a little bit more... With this new mechanism, apart from
'Partial Checksum Support' ('P C Support')I think we should have 'Partial
Checksum Use' ('P C Use') or something like that... If the sender of the
INIT supports the partial checksum, it should send the 'P C Support' (this
can be thought as an invitation to the peer to use partial checksumming, we
can receive them, but it doesn't mean we are going to send them), but if it
wants to send P-CHECKSUM chunks and so on, it should also send the 'P C Use'
parameter (this can be considered as a petition to the peer, we are going to
send them)... Maybe in case we send the 'P C Use' we don't have to send at
all the 'P C Support' parameter at all...

	If the receiver of the INIT also support this extension (otherwise
it would send an ERROR chunk with the 'Unrecognized Parameters' error code),
should answer with an INIT ACK with the 'P C Support' in case the 'P C Use'
was included in the INIT, and also should include the 'P C Use' in case it
wants to send partial covered chunks (and then the 'P C Support' wouldn't be
necessary), but this can be done only if it wants to send P-CHECKSUM chunks
AND the sender of the INIT supports them (it has sent 'P C Use' or 'P C
Support').

	This need is because now one peer not only have to know if the other
peer supports our "modified" datagrams (so we can send them), but also, if
it is going to send us "modified" datagrams (so we can calculate the
checksum in the right way)...

	Comments? For sure this mechanism is not the ideal one, but maybe it
can help people to think about a better one... I hope it helps somehow to
solve the problem...

> I am also contemplating to put the partial checksum DATA into 
> a separate
> draft from U-SCTP draft, just to ease the discussions.

	I think it would be a good idea, since both things are not really
very much related...

> -Qiaobing

	Thanks for you valuable time!

	BR Iván Arias Rodríguez

---

---

From: [email-masked]
Date: Sat, 17 Mar 2001 14:48:22 +0200

> Qiaobing Xie <[email-masked]> writes:
> > I am also contemplating to put the partial checksum DATA 
> into a separate
> Please don't do this.  Partial checksum really does depend on
> the unreliable extension.  Separating pcheck may make it easier to
> finish the work on usctp, but it greatly decreases the odds of getting
> pcheck implemented.  How many vendors do you know who habitually
> implement extensions of extensions?

	Maybe both things are a little bit related, but in my opinion one
thing is having a limited amounth of retransmissions of one DATA chunk, so
the whole DATA chunk (TSN, SSN, user data...) is unreliable in a way that if
the peer doesn't receive it after few attepmts it won't ever be received,
and another different thing is sending a DATA chunk (reliably or unreliably)
with some unreliable information inside it (i.e. not covered by the
checksum)...

	The relation I can see is that in both cases the receiver maybe
won't receive the same stuff you sent... You can combine reliable DATA
chunks with unreliable information inside, and the opposite...

	I don't see P-DATA as an extension to the U-SCTP at all...

	Thanks!

	BR Iván Arias Rodríguez

---

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 16 Mar 2001 11:58:11 -0600

Ivan,

Interesting proposal! But the issue raised by LaMonte still concerns me
and your this proposal doesn't change it. You still need to parse
through the data structure __before__ you can validate the checksum/data
integrity. Your proposal just makes the calculation easier. 

I am also contemplating to put the partial checksum DATA into a separate
draft from U-SCTP draft, just to ease the discussions.

-Qiaobing

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

---