Subject: Re: [Tsvwg] Re: SCTP PAD chunk

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Apr 2006 06:12:39 -0600

Meyknecht,,

Meyknecht, Bernward wrote:                                                      (Wed, 12 Apr 2006 14:05:26)
> 
> Hi all,
> 
> concerning the altered passage I can only repeat my previous remark
> on compatibility to existing and deployed implementation,
> though I like Brians idea.
> 
> Maybe it's good to follow the approach from Randy with the supported
> chunk types parameter, and we should still be free to say, that any chunk 
> type that is presented in the supported chunk types parameter,
> is allowed to appear at any reasonable position within the SCTP
> packet. Would that be something to follow?
> 
> Of course 'reasonable' may include some rules concerning association
> establishment or shutdown.

Yes, that approach would address concern about future extensions, in that
the extension itself could define further placement within the packet.

--brian

> Kind regards,
> Bernward

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Meyknecht, Bernward" <[email-masked]>
Date: Wed, 12 Apr 2006 14:05:26 +0200

Hi all,

Kind regards,

Bernward

-----Ursprüngliche Nachricht-----
Von: Brian F. G. Bidulock [mailto:[email-masked]] 
Gesendet: Mittwoch, 12. April 2006 13:32
An: Randall Stewart
Cc: Mark Butler; Meyknecht, Bernward; Michael Tuexen; [email-masked]
Betreff: Re: [Tsvwg] Re: SCTP PAD chunk

Randall,

Yes, I agree.  The protocol is quite extensible and it is not
all that difficult to write an extension draft; however, I also
agree with Mark that writing a draft without some interest
within the WG might be a wasted effort.

Also, I am concerned with the base protocol in that it appears
that, as Mark put it, all future chunks will be considered
control chunks by a base implementation because they do not have
the precise tag value of a DATA chunk.  This is not so good for
future extensibility.  This is one of the considerations I made
when I changed my loop to not just check for DATA chunks.  If
there is an unrecognized chunk in the sequence of DATA chunks,
it should be reported and aborted or continued in accordance
with the bits in the chunk type.  That is, unrecognized chunk
types should be considered as possibly being of a "DATA" type.

I think that the passage should be considered for revision in
the 2960bis document, if nothing more, but to pave the way for
future DATA-chunk-like extensions.

Are there comments on altering the passage in question?

--brian

Randall Stewart wrote:                         (Wed, 12 Apr 2006 06:50:09)
> Brian:
> 
> I would ask that Mark go ahead and write his own
> draft... If he wants to have some cool features
> to have new types of data chunks and special padding..
> thats wonderful.. but lets not put it in the base spec.
> 
> He can go ahead and write a draft that has a data chunk
> that can have pad and all that stuff in it..
> 
> Lets leave the PAD chunk for control and what it
> was intended.. PMTU probing for Matt Mathis's stuff..
> 
> That way this whole thing can be negotiated at startup
> that you "support the advanced data chunk" and then
> the implementations that support this can use it instead
> of the normal data chunk... If he is defining a new
> data chunk he can surely add a "pad bytes" field to it
> to indicate the number of bytes of trailing pad..
> 
> Thus a control chunk pad.. and this new data chunk is
> all we need to handle all padding scenarios :-D
> 
> R
> 
> 
> Brian F. G. Bidulock wrote:
> > Mark,
> > 
> > While your defining the cool new data chunks that includes fragment
> > numbers, why not have it specify the length and offset of the data
> > within the chunk to allow for internal padding.
> > 
> > I really question the use of this ISO like feature.  Everything of
> > interest (including data) is already padded to a 32-bit alignment
> > boundary.  Did you have some 128-bit architecture for which that was
> > insufficient?
> > 
> > --brian
> > 
> > Mark Butler wrote:                             (Mon, 10 Apr 2006 09:24:19)
> > 
> >>Randall Stewart wrote:
> >>
> >>
> >>>Bernward:
> >>>
> >>>Yes, this is a real concern I have about putting a
> >>>pad chunk between two data chunks... I am not
> >>>to sure that implementations will support this... not
> >>>that they should not.. but it is something that we must
> >>>use care if we define this new chunk...
> >>>
> >>>If we make it able to go anywhere.. then maybe a restriction
> >>>on not sending it unless your peer announces support
> >>>for it... with the supported chunk types parameters... this
> >>>would then make it so an implemenation would say.. yes I
> >>>support this.. and in so doing .. say it may fall anywhere
> >>>in the packet.
> >>
> >>I would prefer a parameter that indicates the sender allows control and 
> >>data chunks to be bundled in any reasonable order, as if they were in 
> >>separate packets.  Any compliant implementation implicitly supports a 
> >>PAD chunk that occurs before any DATA chunks.
> >>
> >> - Mark B.
> > 
> > 
> 
> 
> -- 
> Randall Stewart
> ITD - Cisco Systems Inc.
> 803-345-0369 <or> 815-342-5222 (cell)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/