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

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Wed, 12 Feb 2003 13:15:42 +0100

Randy,

I definitely would appreciate such a possibility, but not based on a bit map.
Using only one bit per feature would narrow limits on the number of features that could be supported.

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Randall Stewart [mailto:[email-masked]]
> Gesendet: Mittwoch, 12. Februar 2003 12:59
> An: [email-masked]; Michael Tuexen
> Cc: Caitlin Bestler; [email-masked]; Tuexen Michael; [email-masked]
> Betreff: [Sigtran] Re: [Tsvwg] A question of Un-Ordered SCTP
> 
> 
> 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)
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Feb 2003 06:22:36 -0600

Hanns:

Yes.. I knew you would feel that way and thats why I said
bit mask or byte array :>

I do like Michaels proposal..

R