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

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

Brian,

I disagree. The upper layer can say that he is 
interested in the order or not by using the
ordered delivery service or not. The peer gets
in both cases an indication of the sending sequence.

You are proposing, that the ULP say I'm not interested
in ordered delivery, but I would like to use unordered
delivery. And now you have some Upper layer information
that some messages belong to two classes (which you
want to code SSN = 0 or != 0). From an SCTP service
point of view there is NO difference. All messages
marked for unordered delivery are given to the ULP
as soon as possible.

I think you want to encode some upper layer information
by using SSN=0 or SSN=!0. For me this looks like layer violation.

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 1:22 PM
> To: Randall Stewart
> Cc: Michael Tuexen; Caitlin Bestler; [email-masked]; Tuexen Michael;
> [email-masked]
> Subject: Re: [Tsvwg] A question of Un-Ordered SCTP
> 
> 
> Randall,
> 
> For the M2PA application, I think that reserving
> '0' for unordered messages for which the order of
> sending is unimportant is still a good idea.
> So the number space from 1 to 0xffff indicates
> importance of order.  '0' indicates no importance
> of order.  As in M2PA's case, a sender could mix
> both on the same stream.
> 
> There then becomes three different types of messages:
> 
> 1) Unordered messages for which the order of sending is
>    unimportant (U-bit SSN=0),
> 
> 2) unordered messages for which the order of sending is
>    important (U-bit SSN!=0), and
> 
> 3) ordered messages for which the order of sending is
>    important (~U-bit).
> 
> And this also handles compatibility because previous
> unordered messages fall into category (1) by nature
> of the fact that SSN==0.
> 
> But starting counting at 1, you get rid of the ability
> to indicate that the order of sending is unimportant and
> force the receiving ULP to handle ordering of all received
> unordered data.
> 
> So, in short, start counting at 1, regardless of whether
> there is an indicator in the INIT/INIT-ACK.
> 
> --brian
> 
> Randall Stewart wrote:                                        
>                      (Wed, 12 Feb 2003 05:58:55)
> > 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
> > > 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
> > > 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
> > > 
> > > 
> > 
> > 
> > -- 
> > Randall R. Stewart
> > [email-masked] 815-342-5222 (cell phone)
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Feb 2003 07:57:18 -0600

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