Subject: Does SCTP support 65535 or 65536 streams per association?

From: Anders Torger <[email-masked]>
Date: Thu, 19 Apr 2007 10:42:47 +0200

Using the socket API, the maximum number of streams can be set to 65535, 
since the value is a 16 bit unsigned integer. Looking in RFC2960 it 
seems like there could be 65536 streams, index 0 to 65535.

One could think however that the value provided in SCTP_INITMSG is the 
number of streams excluding stream 0, so setting 65535 means 65535 
streams plus stream 0.

However, this is not how it works in Linux and Solaris at least. When I 
set 65535 in SCTP_INITMSG, then I get stream indexes 0 - 65534, if I 
try sending on stream with index 65535 it fails with EINVAL. Thus these 
implementations support 65535 streams.

Is this the way it should be? Is the Linux/Solaris implementations 
buggy, is the socket API deliberately designed to limit stream count to 
65535, or is actually the SCTP protocol itself limited to 65535 rather 
than 65536 streams?

/Anders Torger

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 19 Apr 2007 18:47:40 +0800

> seems like there could be 65536 streams, index 0 to 65535.

I guess this is a bug in the API...

> 65535, or is actually the SCTP protocol itself limited to 65535 rather 

I think it is a bug in the API.  We cannot use a uint16_t to
represent the maximum number 65536...  I guess it is too late
to change the API.  You may just consider that all platforms
implementing this API can only support 65535 streams :-)

-- 

						K. Poon.
						[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Apr 2007 05:13:02 -0600

Kacheong,

It more than the API, it is the protocol:

   Number of Outbound Streams (OS):  16 bits (unsigned integer)

      Defines the number of outbound streams the sender of this INIT
      chunk wishes to create in this association.  The value of 0 MUST
      NOT be used.

      Note: A receiver of an INIT with the OS value set to 0 SHOULD
      abort the association.

   Number of Inbound Streams (MIS) : 16 bits (unsigned integer)

      Defines the maximum number of streams the sender of this INIT
      chunk allows the peer end to create in this association.  The
      value 0 MUST NOT be used.

      Note: There is no negotiation of the actual number of streams but
      instead the two endpoints will use the min(requested, offered).
      See Section 5.1.1 for details.

      Note: A receiver of an INIT with the MIS value of 0 SHOULD abort
      the association.

So, even though the Stream ID can represent 65536 streams, only 65535
can be requested in the INIT.

That application that wants one more stream is SOL.

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 20 Apr 2007 08:59:48 +0200

Hi Brians,

Qiaobing wrote me a while ago that it was done on purpose. Have  
forgotten,
what purpose. But the question came up some time ago.

Best regards
Michael

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 20 Apr 2007 13:10:33 -0500

I don't remember what I said then, but I believe the purpose for setting 
0 aside is to reserve it for future use (a general practice in stds).

regards,
-Qiaobing

Michael Tuexen wrote:
> Hi Brians,
> 
> Qiaobing wrote me a while ago that it was done on purpose. Have forgotten,
>> --Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 20 Apr 2007 20:24:31 +0200

Hi Qiaobing,

it is what you said...

Best regards
Michael

On Apr 20, 2007, at 8:10 PM, Qiaobing Xie wrote:

> I don't remember what I said then, but I believe the purpose for  
> setting 0 aside is to reserve it for future use (a general practice  
> in stds).
>
> regards,
> -Qiaobing
>
> Michael Tuexen wrote:
>> Hi Brians,

---

From: Randall Stewart <[email-masked]>
Date: Sat, 21 Apr 2007 07:43:20 -0400

I shutter to ask this question.. but it continually comes
up..

Maybe we need to add back a method to add a stream
to an association...

We had this in the original spec.. (and a way to delete
streams too).. but some in the team (Vern and Lixia if
I remember right) thought it was to complicated and had
it removed... It did add a lot of code.. but that was
mainly for the delete case.. so maybe adding a stream would
not be too bad..

And then if you really really really wanted 65,536 streams and
65,535 was not enough.. then you could negotiate the 65k-1 and
then add the last stream :-D

Of course if you really are to the point where 65k-1 is NOT
enough.. I doubt you will be happy with 65k :-D

R

Michael Tuexen wrote:
>> setting 0 aside is to reserve it for future use (a general practice in 
>> stds).
>>
>> regards,
>> -Qiaobing
>>
>> Michael Tuexen wrote:
>>> Hi Brians,
>>>>> --                        K. Poon.

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Anders Torger <[email-masked]>
Date: Mon, 23 Apr 2007 08:43:17 +0200

The reason I asked the question originally was simply to clear out how 
many streams that SCTP supports, and if it would be 65536 then the 
socket API would be buggy. A small bug, but still a bug.

But as it seems SCTP supports 65535 natively in the protocol, and thus 
there is no problem with the socket API.

I don't think anyone thinks 65535 is too little, or at least if so that 
65536 would be enough. A criticism I could think of is that someone may 
think it is a bit 'ugly' to make that last stream id unavailable, that 
is a question of beauty rather than use. The stream negotiation could 
be about how many streams that should be set up *in addition* to stream 
0 (since it makes no sense to want 0 streams, does it?), that way the 
protocol would support 65536 streams, but that would require a change 
in the protocol...

The new protocol spec perhaps should contain some text that actually 
states the valid values of the stream id (0 - 65534). Many texts that 
I've read about SCTP states incorrectly that SCTP supports 65536 
streams, and I think that comes from the fact that one has to realize 
that streams are indirectly limited to 65535 which is not too obvious.

/Anders Torger

On Saturday 21 April 2007 13:43, Randall Stewart wrote:
> >> setting 0 aside is to reserve it for future use (a general
> >> practice in stds).
> >>
> >> regards,
> >> -Qiaobing
> >>
> >> Michael Tuexen wrote:
> >>> Hi Brians,
> >>>>       Defines the number of outbound streams the sender of this
> >>>> INIT chunk wishes to create in this association.  The value of 0
> >>>> MUST NOT be used.
> >>>>
> >>>>       Note: A receiver of an INIT with the OS value set to 0
> >>>> SHOULD abort the association.
> >>>>
> >>>>       Defines the maximum number of streams the sender of this
> >>>> INIT chunk allows the peer end to create in this association. 
> >>>> The value 0 MUST NOT be used.
> >>>>
> >>>>       Note: There is no negotiation of the actual number of
> >>>> streams but instead the two endpoints will use the
> >>>> min(requested, offered). See Section 5.1.1 for details.
> >>>>
> >>>>       Note: A receiver of an INIT with the MIS value of 0 SHOULD
> >>>> abort the association.
> >>>>
> >>>> So, even though the Stream ID can represent 65536 streams, only
> >>>> 65535 can be requested in the INIT.
> >>>>
> >>>>>> since the value is a 16 bit unsigned integer. Looking in
> >>>>>> RFC2960 it seems like there could be 65536 streams, index 0 to
> >>>>>> 65535.
> >>>>>
> >>>>>> number of streams excluding stream 0, so setting 65535 means
> >>>>>> 65535 streams plus stream 0.
> >>>>>>
> >>>>>> set 65535 in SCTP_INITMSG, then I get stream indexes 0 -
> >>>>>> 65534, if I try sending on stream with index 65535 it fails
> >>>>>> with EINVAL. Thus these
> >>>>>> Is this the way it should be? Is the Linux/Solaris
> >>>>>> implementations buggy, is the socket API deliberately designed
> >>>>>> to limit stream count to
> >>>> --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 ¦