Subject: A question of Un-Ordered SCTP

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

Hi all:

In working with the RDDP adaption for SCTP one of the things
my co-authors and I have discussed is the 16bit SSN number when
sending a "unordered" message.

I have thought on this pro's/con's and would like to hear
your feedback...

Currently the sender of a Unordered data chunk sets the
SSN to 0 and the receiver of the Unordered data chunk ignores
the contents of the field..

What has been discussed is, "could we instead allow the
ULP to specify a value to be set in the SSN and sent
in that field with the receiving SCTP to continue to ignore the
value but instead pass it, as is,  to the ULP"

Now, the more I have thought on this the more I think that
it is rather harmless for the following reasons:

a) Currently receivers are ignoring the SSN, they have to
    be otherwise they could not process the unordered data
    properly.

b) The sending side API is pretty much in place for this
    since the send_rcv_info structure (in the socket api) includes
    the SSN which currently on sending is ignored.

c) It seems to me that these 16 bits are just wasted bandwidth
    and with minor changes to most implementations it would allow
    useage of these bits in other situations besides RDDP..

So what do all think of the idea? Good? Bad?

Thanks

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

---

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

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

On Tue, 11 Feb 2003, Randall Stewart wrote:

> _______________________________________________
> 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 ¦

---

From: David Lehmann <[email-masked]>
Date: Wed, 12 Feb 2003 10:45:18 -0500

> the contents of the field..

When did this change?  RFC 2960, section 6.6 states,
    The 'Stream Sequence Number' field in a DATA chunk with U flag set to
    1 has no significance.  The sender can fill it with arbitrary value,
    but the receiver MUST ignore the field.

Where is it stated that the SSN should be set to zero for unordered data
chunks?

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 12 Feb 2003 13:13:12 -0600

> Where is it stated that the SSN should be set to zero for unordered data
Your correct.. it is an arbitrary value..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

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

Randall,

Meaning most of the argument for backwards compatability vaporizes...

INIT negotiation will be required for an unordered data chunk approach,
but would not be necessary for an ordered data chunk approach.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Sat, 15 Feb 2003 14:25:05 -0600

> Meaning most of the argument for backwards compatability vaporizes...

And what pre-tell do you mean by "backwards compatability vaporizes"?

RFC2960 basically says that an arbitrary value is put in the SSN. It
seems to me that if my implementation wants to number each SSN that is
un-ordered .. then that qualify's as an arbitrary value. If we call
that a feature it does not break any backward compatability... and the
only way it would effect the peer is if it was looking inside the
SSN (which it is prohibited from doing). Now the only issue would
be if the peer bothered to deliver the "arbitrary value" to the
ULP.

> but would not be necessary for an ordered data chunk approach.

I don't see why negotiation is needed. It would be nice if I notified my
peer that I could do something, aka, I number my unordered data, but
telling you I am going to do something with a "arbitrary value" is
far from negotiation...

The only real issue would be if the peer delivered the SSN up to the
ULP (as I said above). Which I would bet most implementations
do.. since it is more work to NOT deliver the SSN and special
case the code. I know I deliver what ever junk is in the
SSN... it was easier...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 15 Feb 2003 17:10:33 -0700

Randall,

> And what pre-tell do you mean by "backwards compatability vaporizes"?

Pray-tell?

> be if the peer bothered to deliver the "arbitrary value" to the

The receiver cannot detect a modified SCTP by observing non-zero values
in the SSN of unordered chunks.

> telling you I am going to do something with a "arbitrary value" is

The negotiation is: A tells B that it supports it and B tells A that it
supports it.  Otherwise, the modification is unsupported for ths
association.

A telling B and just numbering its SSNs acheives nothing.

> do..

Because SSN is monotonitcally increasing from zero on ordered data and
the data is reliably delivered, there is no need to deliver SSN even of
ordered data.  For unordered data it is arbitrary and does not need to
be delivered either.

Nevertheless, if RDDP needs SSN and runs as a ULP, it would have to
place this requirement on the SCTP ULP interface, regardless of whether
it is order of arrival deliverery of ordered data chunks or delivery of
unordered data chunks with modified SSNs.

> since it is more work to NOT deliver the SSN and special

It is not more work not to deliver the SSN, you are making a
presumpltion based on your implementation.  In our implementation it
must be requested and requires more work on each delivery (delivering
the SSN when data will do) and is only applicable to ordered data.  This
is because SSN is an internal number for use by SCTP as defined in the
RFC and has no use to applications.

If unordered data is used by RDDP to perform its own reordering, RDDP
will be unable to send unordered data using SCTP in the same fashion as
today.  (Some implementations expedite unordered data ahead of ordered
data for such applications as SIGTRAN or other POC applications)

If ordered data (with order of arrival delivery) is used for RDDP, RDDP
will still be able to send unordered data which is expedited around
ordered data for SIGTRAN/POC applications.  Is there some reason to keep
these applications from being able to use DDP effectively?

I really think that it would be more useful to put RDDP "inside" SCTP
rather than "above" SCTP.  If RDDP information is placed at the
beginning of ordered data chunks, SCTP could perform direct data
placement internally on data sent from peers supporting the procedure
and perform normal ordered delivery on those that do not.  Modified SCTP
receivers would perform DDP and strip the DDP header from the data.
Unmodified SCTP receivers receiving DDP data chunks would ignore and
deliver the DDP header prefixed to the data.  Then if it can also
support order of arrival delivery of ordered data, it can use an RDDP as
a layer above SCTP to do placement based on the header in the data.
Such an arrangement would still supported expedited delivery of out of
order data.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 15 Feb 2003 19:43:36 -0600

>in the SSN of unordered chunks.
I don't see this to be a problem. If the receiver needs this service
it won't be running on that implementaition very long :>
And I would think we could add one of the

HAVE_SCTP_UNORDERED_SEQ

flags to the socketapi draft... (HAVE_SCTP and some others
will be showing up in the next version).

>supports it.  Otherwise, the modification is unsupported for ths
I don't think this is negotiation.. my interpretation of negotiation is
something more akin to what DCCP does... or PPP...

>A telling B and just numbering its SSNs acheives nothing.

Depending on B's implementation yes.. but a lot of things depend on
implementations...

>unordered data chunks with modified SSNs.
That sounds like requirements for the adaption layer draft...

>RFC and has no use to applications.
But it is in the socket api sinfo structure.. and this (for those that
meet a socket api) will show up with the stream no.. and all the
other fluf.. Of course not everyone supports a socket api.. and thats
fine.. those that do would have the SSN as well as the SN.

>data for such applications as SIGTRAN or other POC applications)
But that is NOT specified in the RFC (expidited data). It mentions it yes,
but this again would depend on the implementation... One would need the
equivalant of a HAVE_UNORDERED_EXPIDITE in ones flags to
recognize your implementation did this... Sigtran MAY have made
such a requirments in some of its adaption layers.. But this is not
standard in SCTP.. I see no reason that RDDP could not require
it...

And I don't see that your statement 

"RDDP will be unable to send unordered data"

is true. Currently it is a "undefined value" and it has no
meaning per requirment EXPIDITED as you elude to or otherwise.
If RDDP sent unordered data with sequences this is COMPLETELY
within valid scope of RFC2960. It is unknown if the receiver
will ever be able to see what was in that field.. but it
IS conformant to RFC2960 if a RDDP-SCTP implementation numbered
each of its unordered data in a stream... nothing wrong with
that.. If you think so, please direct me to the MUST (or SHOULD
for that matter) in 2960 that tells me I can't sequence my
outgoing unordered data.... 

>If ordered data (with order of arrival delivery) is used for RDDP, RDDP
What is "ordered data (with order of arrival delivery"? This does NOT exist
in 2960. You either get unordered, or SCTP must hold the data in
stream and re-sequence.. anything else is NOT in conformance with
2960..

>these applications from being able to use DDP effectively?
There is NO "expedited" data requirement in 2960. You may have implemented
such a thing.. but this is left open to the implementation in 2960, so 
you can
NOT depend on it... just like you can't depend on a receiver passing along
the SSN on a un-ordered message.

>support order of arrival delivery of ordered data, it can use an RDDP as
Please show me where this new feature is you mention in 2960.. I don't see
it anywhere...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 16 Feb 2003 15:36:38 -0700

Randall,

> will be showing up in the next version).

I never gave the socketapi draft much notice.  It largely deviates from
POSIX/OpenGroup socket semantics and is, afterall, only a draft of an
INFORMATIONAL, so feel free to say whatever you like in the draft.
Noone is required to follow it.

> That sounds like requirements for the adaption layer draft...

Yes, if it needs something it is going to have to say so.

> fine.. those that do would have the SSN as well as the SN.

Meet the socket api?  Noone is required to follow the socketapi draft.
It is not on standards track.  I disagree with most (if not all) of
the draft on the basis that it violates POSIX/OpenGroup semantics for
SOCK_SEQPACKET, but have needed to argue it because the draft is only
a draft of an INFORMATIONAL.

If you expect implementations to follow the socketapi draft you will have 
to make it more than INFORMATIONAL, and you will have to advance it to RFC
status.

> but this again would depend on the implementation...

The RFC does not prohibit it.  Those that expedite data (as mentioned, and
thus implicitly permitted) will not be able to expedite and use RDDP as well.

> One would need the
> recognize your implementation did this...

You are talking that INFORMATIONAL draft again...

> Sigtran MAY have made

Not standard in SCTP?  It is not prohibited, so a STANDARD SCTP is permitted
to do so.  SCTP will permit it, but an unordered approach to RDDP will not.
An unorderd approach would.  It is simply another failing of the unordered
approach.

> outgoing unordered data.... 

It just simple: as RDDP is going to be ordering unordered data itself, it
cannot send unordered data.

> stream and re-sequence.. anything else is NOT in conformance with

Ok, now you start with the same argument TCP brought up with RDDP.

The answer is simple, have RDDP reorder the data "inside" SCTP.

> the SSN on a un-ordered message.

So what?  Implementations that actually do so (and are permitted to do so
by RFC 2960) will not be able to use RDDP.  If you simply take the ordered
data approach rather than try to impose sequence on unordered data, then
it is not a problem for implementations that chose to permit expedited data.

> Please show me where this new feature is you mention in 2960.. I don't see

That was a proposal, you goof. ;)

--brian

---

From: "K. Poon" <[email-masked]>
Date: Sun, 16 Feb 2003 23:39:10 -0800 (PST)

> value but instead pass it, as is,  to the ULP"

Do you mean the sinfo_ssn field in the sctp_sndrcvinfo
structure?  I believe it is specified to be not "writeable"
on the send side.  And I think that it is best not to be
"writeable" by socket apps.  SSN is a SCTP internal concept.
It should not be "changeable" by an app.  To me, even the
receiver should not need to see it at all.  It is there 
now, if I remember correctly, simply because of the requirement
of returning unsent data.  Please correct me if I am wrong.

> it is rather harmless for the following reasons:

There are a lot of harmless things, it does not mean that

>     be otherwise they could not process the unordered data

This just means that the SSN field is not used in this
situation by SCTP.  It does not argue for the use of the
field by ULP...  To me, this is a semantic overload of the 
SSN field.  It is really not a good idea in protocol design,
especially if the overload is for the sake of an ULP.

>     the SSN which currently on sending is ignored.

The sinfo_ssn is there because of simplicity reason.  We
don't want to have different data structures for send and
receive.  I guess this should not be used as a reason for
letting an app change an internal SCTP concept.

>     useage of these bits in other situations besides RDDP..

Is this similar in suggesting that since there are some bits
unused (wasted) in the TCP reserved bit field, we should allow
an app to set whatever value it likes in those bits?  This may
sound a little bit extreme, but the idea is similar.  I believe
if it is allowed, it will be a very bad precedence in SCTP 
protocol development.  We should not encourage app protocol
to "require" changes in SCTP simply because it is "convenient"
and "harmless" while it is just a simple matter to support the
changes in the app protocol itself.

> So what do all think of the idea? Good? Bad?

Just my $0.02, I think it is a bad idea...

=====
K. Poon.				[email-masked]

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

---

From: David Lehmann <[email-masked]>
Date: Wed, 19 Feb 2003 10:32:32 -0500

> Just my $0.02, I think it is a bad idea...

I agree with K. Poon 100%.

Let the ULP put the sequence numbers of unordered data
(and whatever else it wants) in its own headers.
(K. Poon's stated it much more articulately, I must admit.)

--