Subject: M2UA / M3UA / SUA: Sending Data Messages on Stream 0

From: [email-masked]
Date: Tue, 6 Nov 2001 09:55:25 +0200

Hi all,

There has been some comment on limiting the sending of 
data messages on Stream 0.

>> "DATA messages SHOULD be sent on an SCTP  stream other than
>>  stream '0'."
>>
>> This Should be changed to "DATA messages MUST be sent on an SCTP  
>> stream other than stream '0'."
>  
> Sorry, I asked for this one too and was told that it was necessary
> to leave it at SHOULD to allow the single-stream implementation.

I think that this needs to be harmonized with all of the UAs.
Ken & Greg, what do you think should be done with this?  Is 
SHOULD enough?

John

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

---

From: [email-masked]
Date: Tue, 6 Nov 2001 13:37:38 +0530

Hi John,

i have a querry
that if we use the same stream for Data and MGMT messages.
If Congestion occurs due to heavy data flow.
MGMT messages will not be able to reach the other end.
I think this is wrong  :-o

I believe DATA should be sent on any stream other than stream 0,
which is used for sequenced delivery of MGMT messages.

If it needs to be addressed on all UA level it should.

best regards
dipak

[email-masked] on 11/06/2001 01:25:25 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Dipak Aggarwal/HSS)

Subject:  M2UA / M3UA / SUA: Sending Data Messages on Stream 0

Hi all,

John

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

---

---

From: [email-masked]
Date: Tue, 6 Nov 2001 10:08:49 +0200

Hi Dipak,

> If it needs to be addressed on all UA level it should.

I agree with your point, this is why we use SHOULD to state this.
Currently, single stream implementations of the UAs are not
forbidden, so we cannot say forbid sending of DATA messages on
stream 0. 

However, I can adjust the language, if it is agreed by the
authors of the other UAs.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 02:15:19 -0600

Dipak,

[email-masked] wrote:                          (Tue, 06 Nov 2001 13:37:38)
> I think this is wrong  :-o

You misunderstand the way SCTP works: All messages get
impaired during congestion regardless of the stream that
they are on.  Sending MGMT on a stream other than the
stream that DATA is sent on will not give MGMT message
priority over DATA in the face of congestion or overloads
of DATA traffic.

> which is used for sequenced delivery of MGMT messages.

But neither congestion nor heavy data flow is a reason.

--brian

> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 06 Nov 2001 21:33:14 -0500

John,

There is no functional reason why "SHOULD" needs to be changed
to "MUST". 

I would keep the text the same.

Ken

At 09:55 AM 11/6/2001 +0200, you wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 21:50:34 -0600

Ken,

As I recall the reason was that if an implementation wishes
to split off a control process on stream 0 and split off
data processes on other streams, the control process is
simpler if it does not have to deal with data on stream 0.

This would be consistent with the split-off capability of
the sockets draft for SCTP.

If there are indeed multiple streams established at SCTP
association initilization, there should be no reason why
an implementation must accept data on stream 0 and, indeed,
there is an error message "Invalid Stream Identifier" which
it appears can be used to reject a management message on
other than stream 0, so why not a data message on stream 0
if there is more than one stream in the association?

Perhaps the SHOULD does not need to be changed to a MUST,
but is needs to be made clear that an implementation can
choose to send ERR("Invalid Stream Identifier") if it receives
data on stream 0.

Can we change the description of the error message:

	The "Invalid Stream Identifier" error is sent if a message is received 
	on an unexpected SCTP stream (e.g., a Management message was received 
	on a stream other than "0").

to

	The "Invalid Stream Identifier" error is sent if a message is received 
	on an unexpected SCTP stream (e.g., a Management message was received 
	on a stream other than "0", or a Data message was received on stream
	"0").

--brian

Ken Morneault wrote:             (Tue, 06 Nov 2001 21:33:14)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Wed, 7 Nov 2001 09:26:42 +0530

I Dont c a reason why M2PA is being left out of this discussion ! ! !

regards
dipak

"Brian F. G. Bidulock" <[email-masked]> on 11/07/2001 09:20:34 AM

To:   "sigtran" <[email-masked]>
cc:   [email-masked] (bcc: Dipak Aggarwal/HSS)

Subject:  Re: M2UA / M3UA / SUA: Sending Data Messages on Stream 0

Ken,

to

--brian

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

---

---

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 8 Nov 2001 02:30:32 +0100

Dear Brian,

what is the split-off capability of the socket draft for SCTP?

Best regards
Michael

On Wednesday, November 7, 2001, at 04:50  Uhr, Brian F. G. Bidulock 
wrote:

>>> To unsubscribe send a blank email to leave-
>>> [email-masked]
>>
>>
>>
>> ---
>> To unsubscribe send a blank email to leave-
>> [email-masked]
>
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
>
>
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to leave-
> [email-masked]
>
[email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 20:07:08 -0600

Michael,

The ability to split off a stream of an association onto
a separate socket file descriptor.

--brian

Michael Tuexen wrote:                                     (Thu, 08 Nov 2001 02:30:32)

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

---