Subject: SUAv8: Primitivies from SCCP User

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 12 Oct 2001 21:29:35 -0500

Section 4.1.1 states:

   In addition, the message needs to be sent on the appropriate SCTP 
   stream, again taking care to meet the message sequencing needs of the 
   signalling application. DATA messages SHOULD be sent on an SCTP 
   stream other than stream '0'. 

Change "SHOULD" to "MUST" so that the implementation does not have
to look for DATA messages on stream '0'.

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Tue, 16 Oct 2001 20:49:29 +0300

Hi Brian,

> to look for DATA messages on stream '0'.

Change made.

John

---

---

From: [email-masked]
Date: Tue, 16 Oct 2001 23:04:16 +0300

Hi all,

The first rule of SIGTRAN should be:

"Don't reply to Brian's mails while in a meeting."
> to look for DATA messages on stream '0'.

Greg is right.  SHOULD is proper.  Single stream implementations
are legal.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Oct 2001 17:51:02 -0500

John,

John Loughney wrote:                                         (Tue, 16 Oct 2001 23:04:16)
> Greg is right.  SHOULD is proper.  Single stream implementations

Then let's restrict the exception to single stream implementations...
Can we say that the implementation MUST send DATA messages on an SCTP
stream other than stream '0' if it uses multiple streams?  But, MAY
send all messages on a single stream for a single stream implementation
(as an OPTION)?

(We really don't want multiple stream implementations stuffing DATA
 messages on stream '0'.  Some underlying SCTP implementations are
 handling stream '0' as completely separate from the others and are
 unable to accept DATA on stream '0'.)

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

---

From: [email-masked]
Date: Thu, 18 Oct 2001 00:08:46 +0300

Hi Brian,

> send all messages on a single stream for a single stream 
> implementation (as an OPTION)?

Not trying to be argumentative, but has the work group decided that
a single stream scenario is an exception, while the multi-stream
is the norm?

>  unable to accept DATA on stream '0'.)

Well, this could be considered a 'feature' of the implementation,
could it not? Then, would it not be the exception?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 17 Oct 2001 17:32:06 -0500

John,

John Loughney wrote:                                         (Thu, 18 Oct 2001 00:08:46)
> a single stream scenario is an exception, while the multi-stream

Not to be argumentative either, but what advantage does a single-
stream SCTP association have over TCP?

As this is the same WG which developed SCTP to have multiple streams
to address HOL blocking issues and address other single-stream TCP
deficiencies, I can only assume that the WG has "endorsed," no, let's
go further to "recommended" the use of multiple streams in SCTP.

The SCTP AS makes the advantages of separate streams clear.  Placing
independently sequenced traffic flows each in a different stream
permits streams not experiencing message loss to deliver around streams
blocked by message loss and retransmission.  The more streams that
can be used, the lower average latency in delivering messages on all
streams.

Anyone caring to ignore this aspect of SCTP by using only a single
stream had better be the exception, otherwise, years were spent
developing SCTP for nothing.  All other features of SCTP (with the
possible exception of multi-homing) have been proposed or adopted
as add-ons to TCP.

On the contrary, I cannot see why it is necessary to permit a single-
stream SCTP association for M3UA/SUA at all.  The other xAs do not
go to such great extent to permit it, and I cannot believe that
anyone is intending to use a single stream anyways.

> could it not? Then, would it not be the exception?

The SCTP sockets draft describes a peel-off function for peeling off
a stream under a separate socket descriptor.  It is, therefore, not
so implementation-specific.

Without priority streams extensions to SCTP, the only way to give one
stream (usually stream '0') preferrential priority  over other streams
is to associate a separate process or thread and file descriptor with
that stream.  Other streams queue while the priority process services
the more important stream's queue.  Even just because it is a priority
process, the process may have more priviledges than processes or threads
associated with other streams.  That process does not want to be dealing
with DATA messages.  Those messages should have queued to another stream.
This is not so exceptional as you might think: there are only a couple
of ways of doing things under modern day computing models.

These are techniques which can be used to better address peformance
in an implementation.

Although there are implementation specific here, the issue is one of
interoperability.  Such an implementation as described in fitting with
the SCTP sockets draft and common practice in computing need assurances
that it will not receive DATA on stream '0'.

Can we not say that if there are multiple streams that DATA and SNMM
messages MUST NOT be sent on stream '0'?  What is the problem with that?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---