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

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

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
> 
> 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: 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]
>>Subject: 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)
>>
> 
> 
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

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

Randy,

       0                   1                   2                   3

Best regards
Michael