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

From: Jon Berger <[email-masked]>
Date: Fri, 16 Mar 2001 13:01:06 -0000

The advantage of a P-DATA-PRESENT chunk is that with the exception of the
actual checksum calculation, all of the rest of the processing on the sender
and receiver is identical to the existing DATA chunk which is really nice.
The cost of defining another chunk is way less than compromising all future
implementations IMHO.

(If you are in a situation where you only use P-DATA chunks and not DATA,
the existing version of the draft is just fine.  There is no need for an
additional mechanism.  There is only a problem when you mix P-DATA and
DATA.)

Jon

-----Original Message-----
From: La Monte Henry Piggy Yarroll [mailto:[email-masked]]
Sent: 15 March 2001 13:57
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] Re: U-SCTP comments 

[email-masked] writes:
> > ["La Monte Henry Piggy Yarroll" <[email-masked]> wrote:]
> > 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.
> 
> 	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.

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

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Sat, 17 Mar 2001 06:49:58 -0600

> The cost of defining another chunk is way less than compromising all future

Remember, we still have to negotiate for P-DATA chunks in the INIT--an
implementation that doesn't support them won't be compromised at all.

While there is an elegance to a extension which allows us to localize
the changes, I don't think that should be a dominant design
constraint.  I want P-DATA to be fast and safe.

> additional mechanism.  There is only a problem when you mix P-DATA and

Even if you know (somehow--currently unspecified) that only P-DATA
will be used, you still have the problem of parsing the chunk with
untrusted data.