Subject: Re: [Tsvwg] Why Payload Protocol in every data chunk?

From: [email-masked]
Date: Thu, 11 Jul 2002 15:43:43 -0400

Phillip,
Yes, sorry 'bout not mentioning SCTP in my original post, but you are 
correct, I did mean the PPID.
I'm convinced by the responses from you and Michael that the PPID is 
valuable in each chunk even if only for the sniffers.
As far as using the PPID to differentiate between app messages and control 
messages, I say use different streams, or add a 'data type' field to the 
upper layer!
Thanks,
DaveS.

Phillip Conrad <[email-masked]>
07/11/2002 02:56 PM

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        Re: [Tsvwg] Why Payload Protocol in every data chunk?

At 12:56 PM 7/11/2002 -0400, [email-masked] wrote:
>Can anyone explain why we have the payload protocol parameter in every
>data chunk?  The only reason I can come up with would be to allow an
>association to be shared by multiple upper layers, otherwise this value
>could be exchanged only once, during assoc initialization...
>I realize its late to change such a thing, but I'm just curious.

I'm assuming you mean the Payload Protocol ID (PPID) in the SCTP header 
(note that the scope of the tsvwg list is much broader than just SCTP, so 
it's helpful to mention which protocol you are discussing :-) ).

Two benefits of having the PPID per chunk:

(1) Multiplexing different kinds of data over the same SCTP association.

For example, in the RSerPool working group, one possibly design for ASAP 
would use an IANA-registered PPID to differentiate application messages 
from RSerPool control messages.   (This particular design might or might 
not still be on the table; I've been out of that loop for a couple of 
weeks.)

(2) Facilitating the construction of packet decoders (e.g. tcpdump, 
ethereal).  In current packet sniffers, well-known port numbers are 
sometimes used to infer which upper layer protocol is being used; the PPID 

is an alternative design.

I've had mixed feelings about whether this is a good use of bits or 
not.  An argument against the field is that since the protocol entities 
never touch it (they only pass it through to the other side) it is really 
just a glorified piece of payload.... so why not just make it contiguous 
with the rest of the payload bits?

However, I've become convinced that it will be helpful in the long run to 
have a standard way to identify what kind of data is being sent on a 
per-chunk basis, separate from conventions related to port numbers and/or 
stream numbers.   Since it made it into RFC2960, I'm inferring that this 
was the rough consensus of the working group as well.

Phill

-- Phill Conrad, Asst. Professor, Temple University
-- http://netlab.cis.temple.edu    [email-masked]

>Thanks,
>Dave Sclarsky
>Radisys Corporation
>520 Fellowship Road
>Suite C-304
>Mt. Laurel, NJ 08054
>email:[email-masked]

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