Subject: RE: [Tsvwg] A question of Un-Ordered SCTP

From: "Williams, Jim" <[email-masked]>
Date: Tue, 11 Feb 2003 11:23:02 -0500

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2003 7:39 AM
> To: TSV WG list; SCTP Implementors
> Subject: [Tsvwg] A question of Un-Ordered SCTP
> 
> 
> Hi all:
> 
> In working with the RDDP adaption for SCTP one of the things
> my co-authors and I have discussed is the 16bit SSN number when
> sending a "unordered" message.
> 
> I have thought on this pro's/con's and would like to hear
> your feedback...
> 
> Currently the sender of a Unordered data chunk sets the
> SSN to 0 and the receiver of the Unordered data chunk ignores
> the contents of the field..

For SCTP to provide unordered but sequenced delivery seems like
a useful and constructive feature.  This would require that
a sequence number (rather than zero) is placed in SSN on transmit,
and and passed to application on receive.

This is exactly what RDDP requires, and seems like a general
mechanism that would have uses beyond RDDP.

The problem, is that it would be a change to SCTP, and RDDP
if it relied on this feature would not work with implementations
of SCTP that did not support it.  However it is a rather
trivial change to implementations that could be adopted
quite quickly.

On balance, I would support this change to SCTP provided there
is sentiment that this would be useful beyond just RDDP.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Tuexen Michael <[email-masked]>
Date: Wed, 12 Feb 2003 12:50:04 +0100

Brian,

it is NOT a procedure. You just put the parameter in the
INIT or INIT-ACK chunk if you support it. 

On a communication up event you pass this info to the ULP.

That is all, very simple.

Best regards
Michael

Michael Tuexen   Tel.:   +49 89 722 47210
Siemens AG       Fax:    +49 89 722 48212
ICN CP SE C 7    e-mail: [email-masked]

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2003 12:34 PM
> To: Tuexen Michael
> Cc: Randall Stewart; Michael Tuexen; Caitlin Bestler; [email-masked]
> Subject: Re: [Tsvwg] A question of Un-Ordered SCTP
> 
> 
> Michael,
> 
> I disagree.  Adding an new INIT/INIT ACK procedure to start
> counting at 0 instead of 1 seems excessive to me.
> 
> --brian
> 
> On Wed, 12 Feb 2003, Tuexen Michael wrote:
> 
> > Brian,
> > 
> > I understand your point, but I think it is clearer to
> > define a new parameter of length 8 bytes to be included
> > in the INIT / INIT-ACK which indicates that this feature used.
> > Like in the case of PR-SCTP. This make the stuff explicit
> > and introduces almost no additional complexity.
> > 
> > Best regards
> > Michael
> > 
> > Michael Tuexen   Tel.:   +49 89 722 47210
> > Siemens AG       Fax:    +49 89 722 48212
> > ICN CP SE C 7    e-mail: [email-masked]
> > 
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, February 12, 2003 10:44 AM
> > > To: Tuexen Michael
> > > Cc: Randall Stewart; Michael Tuexen; Caitlin Bestler; 
> [email-masked]
> > > Subject: Re: [Tsvwg] A question of Un-Ordered SCTP
> > > 
> > > 
> > > Michael,
> > > 
> > > Tuexen Michael wrote:                                         
> > >                       (Wed, 12 Feb 2003 09:39:41)
> > > > > 
> > > > > I think it would be good to see the requirement that 
> the sequence
> > > > > number begin at 1 and be monotonically increasing in the 
> > > saem fashion
> > > > > as ordered streams.
> > > > > 
> > > > I would prefer that the two sequence spaces are handled the same
> > > > way. Thus both start with SSN=0.
> > > 
> > > That would make it impossible to distinguish between 
> SCTP's supporting
> > > the feature and SCTP's not supporting the feature on the 
> first message
> > > in a stream.
> > > 
> > > Leaving '0' for unordered packets of unspecified transmission 
> > > order has
> > > some value for backwards compatibility and interoperability.
> > > 
> > > --brian
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>

---

From: Tuexen Michael <[email-masked]>
Date: Thu, 13 Feb 2003 15:17:11 +0100

Sounds good to me.

Best regards
Michael

> Sent: Thursday, February 13, 2003 2:57 PM
> To: Tuexen Michael; Caitlin Bestler
> Cc: Michael Tuexen; [email-masked]; [email-masked]
> Michael/Caitlin:
> Ok, I think that there is enough mixed sentiment on this issue
> that here is how we should proceed:
> 
> a) A CAPABILITIES TLV should probably be created, possibly in
>     the add-ip draft? That could then indicate different supported
>     cababilities like, add/del/set-primary/pr-sctp and our new
>     idea unreliable with sender sequencing.
> 
> b) A new small draft should be created outlining:
>      1) a seperate sequence space,
>      2) how it would be used with un-ordered
>      3) a recommendation to the receivers to pass
>         the unordered SSN to the ULP as is, I know
>         in my impelementation I did this anyway.. it
>         takes extra code to NOT do this :> so I think
>         thats pretty non-controversial.
>      4) specify a capability value for this.
> 
> c) Update the pr-sctp draft to use the capabilites as
>     well and get rid of its specialized TLV to annoucne
>     pr-sctp.
> 
> Get all of this submitted and see how the general wg feels about
> it..
> 
> If you would like I will send you a rought draft in a
> week or two.. sound ok?
> 
> R
> 
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>

---

From: Tuexen Michael <[email-masked]>
Date: Wed, 12 Feb 2003 13:37:14 +0100

32 bits were easier to draw... No problem in making
them 16 bit unsigned. 

Best regards
Michael

> Sent: Wednesday, February 12, 2003 1:25 PM
> To: Tuexen Michael
> Cc: [email-masked]; Michael Tuexen; Caitlin Bestler;
> [email-masked]; [email-masked]
> This looks good.. but would it be
> better to make the FEATURE_ID 16 bits..
> 
> .. my reasoning is that cookies are getting
> bigger and it might be best to control there
> length to some degree... I could go either way
> but I think 65,535 features is more than enough
> to choose from :>
> 
> R
> 
> Tuexen Michael wrote:
> > Randy,
> > 
> > I think having a FEATURES parameter would be a good idea. I do not
> > like the idea of bitmask. Instead of this I would propose something
> > like a FEATURES parameter which looks like:
> > 
> >        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
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |   FEATURES_PARAMETER_ID       |       Parameter 
> Length        |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         FEATURE_ID 1                
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         FEATURE_ID 2                
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         FEATURE_ID 3                
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                         FEATURE_ID 4                
>           |
> >       
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Each feature will be an IANA assiged 32 bit uint. This is 
> extendable.
> > 
> > Best regards
> > Michael
> > 
> >>Sent: Wednesday, February 12, 2003 12:59 PM
> >>To: [email-masked]; Michael Tuexen
> >>Cc: Caitlin Bestler; [email-masked]; Tuexen Michael; 
> [email-masked]
> >>Brian/Michael:
> >>I do like the idea of keeping things the same (aka same
> >>methodology)... this is good.
> >>
> >>It is also neat to be able to tell the difference between
> >>an implementation that supports this feature and one that
> >>does not.  But there are positives and negatives, I think,
> >>to each idea...
> >>
> >>A) For using a TLV, (as Michael suggests)
> >>    we really need to put this into a seperate
> >>    draft.. when I do think one could easily fit
> >>    this into the IG as Brian as suggested.
> >>
> >>B) montonically increasing numbers would eventually
> >>    wrap when the SSN hit FFFF back to 0... thus
> >>    the application would need to have some sort
> >>    of state to track if the peer supported the
> >>    feature.
> >>
> >>It seems to me it is only the first message that
> >>arrives that benefits from the start at 0. If the
> >>application assumes a "not supported", then by
> >>starting the SSN at 1 the app can flip the flag
> >>from "not supported" to "supported" on the arrival
> >>of the first message.
> >>
> >>If the application instead set its flag to "supported"
> >>the first message would not tell this information and
> >>instead it would only be upon the second arriving message
> >>that the app could make the flag determination... causing
> >>either a delay in delivery of the first message (yuck) or
> >>just toss it up and wait.
> >>
> >>More importantly, I am wondering, if the implementation does
> >>NOT support this, what will the app do? Change its
> >>message structure? If so it will need to have some clues
> >>(as the initiator) that its implementation does not
> >>support the feature .. possibly a HAVE_SCTP_UNORDERED_SSN
> >>in sctp.h... but the problem is you would not know about
> >>the other guy until its first unordered message arrives.
> >>So if you have to send the first message what do you do?
> >>
> >>if HAVE_SCTP_UNORDERED_SSN is 0.. no problem.. you
> >>send a message that has the imbedded sequence number.. but
> >>what do you send when HAVE_SCTP_UNRODERED_SSN is set to 1?
> >>
> >>If you send the imbedded sequence in the message anyway whats
> >>the point of this little trick? The second message (which you
> >>may have to send before knowing receiving a unordered
> >>msg from the peer) would still have this, and maybe the third
> >>etc...
> >>
> >>Hmm.. the more I think on this the more it becomes clear that
> >>you must know ahead of time i.e. when the association comes
> >>up to "do the right thing".... which goes back to Michaels
> >>idea of a TLV.
> >>
> >>I have been wondering for quite some time now if we don't
> >>just need a TLV in the INIT/INIT-ACK that indicate features
> >>in general... something like a bit mask or byte array indicating
> >>each feature...
> >>
> >>addip
> >>delip
> >>prsctp
> >>setprimary
> >>unordered-assigns-sequences
> >>
> >>etc..
> >>
> >>Maybe this is a better way to go.. and we could write a short
> >>draft dictating this bit/byte TLV... code as a 0x80 class.. that
> >>way old implementations will throw it away... (we really don't
> >>care if they don't understand it)...
> >>
> >>I have been avoiding this.. but it might be the best approach..
> >>
> >>Then again, I guess it could also be put in addip or prsctp since
> >>it would effect them as well :> Then one could put the
> >>other change in the IG and thus have a very easy change that
> >>is in the IG and a minor update to either addip or prsctp...
> >>
> >>
> >>What do you all think?
> >>
> >>R
> >>
> >>Brian F. G. Bidulock wrote:
> >>
> >>>Randall,
> >>>
> >>>I agree to having SCTP set the sequence number and, as you said in
> >>>your first note, SCTP passing the sequence number to the ULP on
> >>>the receiving side is already done for ordered traffic.  Some even
> >>>pass the zero now.
> >>>
> >>>I suppose that SCTP would set this sequence number when it is given
> >>>the data for delivery at the sending ULP and the sequence 
> >>
> >>would represent
> >>
> >>>the order that the data was presented to SCTP by the ULP at 
> >>
> >>the sending
> >>
> >>>side.
> >>>
> >>>I think it would be good to see the requirement that the sequence
> >>>That way RDDP and other applications could perform their 
> >>
> >>own reordering
> >>
> >>>at the receiver.  I think it would be a good thing to have SCTP set
> >>>this value.
> >>>
> >>>In fact, I can see another application for this feature.  M2PA
> >>>(SIGTRAN protocol) needs in some circumstances to send data 
> >>
> >>unordered
> >>
> >>>with the hope of expedited delivery (does not want control 
> >>
> >>information
> >>
> >>>stuck behind large amounts of data in an ordered stream), 
> >>
> >>however, the
> >>
> >>>order of processing of the expedited control information is 
> >>
> >>important.
> >>
> >>>This facility would permit M2PA to send such information unordered
> >>>to expedite it and the receiver could perform the 
> reordering itself.
> >>>Up until now, the only solution was to place a sequence 
> >>
> >>number in with
> >>
> >>>the control information.
> >>>
> >>>Could we perhaps add a section to the SCTP IG.  "Problem statement:
> >>>the sender wishes to send unordered data but the receive 
> >>
> >>needs to know
> >>
> >>>the original order of sending..." or some such.
> >>>
> >>>It should be quite simple to add the feature to existing SCTP
> >>>implementations.
> >>>
> >>>--brian
> >>>
> >>>
> >>>On Tue, 11 Feb 2003, Randall Stewart wrote:
> >>>
> >>>
> >>>
> >>>>Michael:
> >>>>
> >>>>This seems like a valid method.. it gets around Brian's objection
> >>>>(which was a good point) and yet still provides the 
> application with
> >>>>a hint about what the assigned sequence order was on the unordered
> >>>>messages...
> >>>>
> >>>>R
> >>>>
> >>>>Michael Tuexen wrote:
> >>>>
> >>>>
> >>>>>Caitlin,
> >>>>>
> >>>>>thank you very much for the clarification.
> >>>>>
> >>>>>I do not like the idea to pass the SSN transparently from 
> >>>>
> >>the ULP to the 
> >>
> >>>>>ULP.
> >>>>>But having two sequence spaces is OK for me. This means 
> >>>>
> >>that the SSN at the
> >>
> >>>>>sending side is controlled by the SCTP and given to the 
> ULP at the 
> >>>>>receiving side.
> >>>>>
> >>>>>This would be a clean solution. So I voting for have two 
> >>>>
> >>separate number 
> >>
> >>>>>spaces
> >>>>>for user data. Since the one for ordered delivery exists 
> >>>>
> >>already in RFC 
> >>
> >>>>>2960, this
> >>>>>only means that a new one is introduced for the unordered 
> >>>>
> >>delivery user 
> >>
> >>>>>data.
> >>>>>
> >>>>>Best regards
> >>>>>Michael
> >>>>>
> >>>>>On Tuesday, Feb 11, 2003, at 17:37 Europe/Berlin, Caitlin 
> >>>>
> >>Bestler wrote:
> >>
> >>>>>
> >>>>>>On 2/11/03, Tuexen Michael wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Dear all,
> >>>>>>>
> >>>>>>>does this mean that you want two sequence spaces per
> >>>>>>>stream: one for the 'ordered' user data and one for the
> >>>>>>>unordered user data?
> >>>>>>>
> >>>>>>
> >>>>>>The RDDP/SCTP adaptation only uses unordered delivery, so
> >>>>>>that question did not really arise.
> >>>>>>
> >>>>>>But if you were to generalize the problem, I believe the
> >>>>>>answer would be yes.
> >>>>>>
> >>>>>>The SSN for ordered delivery would be unchanged. The
> >>>>>>addition would be providing "advisory ordering" for
> >>>>>>unordered delivery. The general characteristic is that
> >>>>>>the receiving ULP wants the data in whatever order it
> >>>>>>arrives, but wants to know what the original order was.
> >>>>>>
> >>>>>>In addition to RDDP, RTP over UDP is another example of
> >>>>>>an application that wants to be aware of the original
> >>>>>>ordering, even while accepting the data out-of-order.
> >>>>>>
> >>>>>>Caitlin Bestler
> >>>>>>http://asomi.com/CaitlinBestler/