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

From: Caitlin Bestler <[email-masked]>
Date: Tue, 11 Feb 2003 10:37:05 -0600

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 11 Feb 2003 21:01:40 +0100

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

---

From: Tuexen Michael <[email-masked]>
Date: Tue, 11 Feb 2003 16:51:37 +0100

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?

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: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 11, 2003 4:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Tsvwg] A question of Un-Ordered SCTP
> 
> 
> > Randall,
> >
> > Bits inside of chunk headers should be used by SCTP and not
> > by the ULP.  The DATA chunk payload is for use by the ULP.
> >
> > If the use of these bits was to be interpreted by SCTP, I
> > would say ok.  But because they would be transparent to
> > SCTP, muddling user data and SCTP protocol bits in the
> > header of a DATA chunk is not very clean.  User headers
> > transparent to SCTP should be in the data payload.
> >
> > My $0.02
> >
> > --brian
> >
> Understood. That is the rationale for placing the sequence number
> in the Data Chunk (which is the alternate proposal).
> 
> The gotcha is that these two bytes have *exactly* the same semantics
> as the SSN would have had for ordered delivery. The RDDP 
> draft requires
> that all packets be unordered, but would prefer to know what 
> the per-stream
> order was. It allows earlier detection of when each stream is fully
> delivered.
> 
> The basic options are to rely solely on the cumulative TSN ack point,
> which can result in head-of-line blocking, use/abuse the "meaningless"
> SSN field within the SCTP header, or duplicate its 
> functionality within
> the Data Chunk.
> 
> I suspect there are other ULPs that would benefit from 
> per-stream ordering
> information when otherwise sending only unordered chunks. If 
> so, it makes
> sense to use the header for this purpose. But if this is 
> truly unique to
> RDDP then
> I agree with your position that ULP data belongs inside the 
> Data Chunks.
> 
> 
>

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 11 Feb 2003 17:07:06 -0600

>stream: one for the 'ordered' user data and one for the
RDDP only requires a single sequence space, which is used
solely for unordered data.

That would also suffice for the other applications that I
am aware of that could benefit from unordered delivery of
sequenced data chunks.

So the question would be, which would have the least impact
on existing implementations:

    Recognizing the concept of an "unordered stream", where
    *all* data chunks must be sent unordered, but the SSN
    is handled as though they were ordered.
    
    Tracking an additional "USSN" per stream.
    
The second option seems more natural, but the first one has
the benefit of being implementable in terms of current data
structures with only the definition of a single bit per
stream.

Caitlin Bestler

---

From: Randall Stewart <[email-masked]>
Date: Tue, 11 Feb 2003 17:39:06 -0600

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:
> 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
> This would be a clean solution. So I voting for have two separate number 
> spaces

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Feb 2003 19:15:43 -0700

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

-- 
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 ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 11 Feb 2003 21:48:38 -0600

On 2/11/03, Brian F. G. Bidulock wrote:

>
>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.
>
Excellent suggestion. A value of 0 is a tip-off that the
sender does not have the unordered sequencing feature.

When the receiver spots U-SSNs of 0, it knows that the best
it can do to infer sequence is to check the TSNs (which will
do sequence, but provides no clues as to whether the entire
stream has been delivered until the cumulative ack point
catches up).

Caitlin Bestler

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Feb 2003 22:44:26 -0700

Caitlin,

Bonus!

--brian

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Feb 2003 05:58:55 -0600

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 05:22:23 -0700

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 F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

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

> there is an indicator in the INIT/INIT-ACK.

That might be ok, but in the above does not that mean
when you reach 0xffff you end up sending a type
1) message... unless of course you want to have
a counting scheme where you always skip 0... which
is a bit more code on every sequence increase...

And I do still think you will need to "know" ahead of
time if both sides support 2) otherwise you would not
know to embed your own SSN (in cases where you must
emulate 2)

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 05:38:43 -0700

Randall,

So why not introduce another bit into the data chunk header?

Say, the O-bit which indicates that data is ordered at the
sender but not at the receiver?

An SCTP which does not know about the O-bit will assume that
ordered delivery is required.  Receivers which know about
the O-bit will know that unordered deliver is allowed.

That way you can start counting at 0 and leave unordered
data chunks alone.

While your at it, why not place the offset of the data chunk
in the final message in the DATA chunk header so that the
payload is identical for RDDP and non-RDDP SCTPs.  That way,
the non-RDDP receiver will be able to ignore the O-bit and
offset, and deliver the data ordered.  The RDDP receiver
will be able to observe the O-bit and offset and direct place
the data chunk.

--brian

Randall Stewart wrote:                                                             (Wed, 12 Feb 2003 06:30:26)

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Feb 2003 07:21:47 -0600

Brian:

I am really not interested in adding a bit in
the header for RDDP. I think it is better
to do something minimalist that meets there
needs instead of burning a bit (of only 5 left)
for one particular application.

Having a second sequence number space that is
allowed.. but not required.. and Michaels suggested
TLV in INIT/INIT-ACK would be more than adequate for
RDDP or for that matter any other application that
wants data right away but yet would like to know
presentation order to the sending SCTP.

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 08:25:39 -0700

Randall,

Then send them ordered and let the RDDP/SCTP receiver perform
direct data placement without waiting for reordering.  Ordered
data chunks already have usable stream sequence numbers.  It
appears that you want to use the U-bit to tell the receiver that
it doesn't need to order the messages when all you need is
unordered delivery at the receiver.  Ordered delivery across 
the SCTP ULP API is not a requirement as it is in TCP.

--brian

Randall Stewart wrote:                                                             (Wed, 12 Feb 2003 07:21:47)