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

From: Tuexen Michael <[email-masked]>
Date: Wed, 12 Feb 2003 09:39:41 +0100

Brian,
see my comments below.
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]

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2003 3:16 AM
> To: Randall Stewart
> Cc: Michael Tuexen; Caitlin Bestler; [email-masked]; Tuexen Michael;
> [email-masked]
> Subject: Re: [Tsvwg] A question of Un-Ordered SCTP
> 
> 
> 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
> 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 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/
> > >> _______________________________________________
> > >> tsvwg mailing list
> > >> [email-masked]
> > >> https://www1.ietf.org/mailman/listinfo/tsvwg
> > >>
> > > 
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> > > 
> > > 
> > 
> > 
> > -- 
> > Randall R. Stewart
> > [email-masked] 815-342-5222 (cell phone)
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> 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 ¦
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

> From: Randall Stewart [mailto:[email-masked]]
> 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
> > 
> >>From: Randall Stewart [mailto:[email-masked]]
> >>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,
> >>>
> >>>number begin at 1 and be monotonically increasing in the 
> >>
> >>saem fashion
> >>
> >>>as ordered streams.
> >>>
> >>>That way RDDP and other applications could perform their 
> >>
> >>own reordering
> >>
> >>>(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.
> >>
> >>>Up until now, the only solution was to place a sequence 
> >>
> >>number in with
> >>
> >>>the control information.
> >>>
> >>>the sender wishes to send unordered data but the receive 
> >>
> >>needs to know
> >>

---

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