Subject: Re: [tsvwg] About the socket option SCTP_ENABLE_STREAM_RESET

From: Randall Stewart <[email-masked]>
Date: Sat, 5 Dec 2009 07:32:47 -0800

Wei:

I believe we will be  moving to a model where you have an individual
option to enable notifications...

i.e. something like:

on = 1;
setsockopt(sd, SCTP_STREAM_NOTIFICATIONS, &on);

The BSD stack does have the field you mention, thats because we have
had the feature around for a while... but long term I believe the
consensus is to move to individual socket options even for the existing
notifications..

R

On Nov 29, 2009, at 4:34 PM, Wei Yongjun wrote:

> Michael Tuexen wrote:
>> On Nov 29, 2009, at 4:47 AM, Wei Yongjun wrote:
>>
>>
>>> Wei Yongjun wrote:
>>>
>>>> Hi, all
>>>>
>>>> I saw that the following text in draft-ietf-tsvwg-sctp- 
>>>> strrst-01.txt:
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> 6.2.1.  Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET)
>>>>
>>>>  This option allows a user to control whether the SCTP  
>>>> implementation
>>>>  processes or denies incoming reqests in STREAM_RESET chunks.
>>>>
>>>>  The default is to process incoming requests.
>>>>
>>>>  To set or get this option the user fills in the following  
>>>> structure:
>>>>
>>>>  struct sctp_assoc_value {
>>>>    sctp_assoc_t assoc_id;
>>>>    uint32_t assoc_value;
>>>>  };
>>>>
>>>>  assoc_id:  This parameter is ignored for one-to-one style sockets.
>>>>     For one-to-many style sockets this parameter indicates which
>>>>     association the user is performing an action upon.
>>>>
>>>>  assoc_value:  If this parameter is zero the processing of incoming
>>>>     requests will be denied.  If it is non-zero incoming requests  
>>>> will
>>>>     be processed.
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> It means that we need to set the socket option  
>>>> SCTP_ENABLE_STREAM_RESET to
>>>> enable the Stream Reconfiguration.
>>>>
>>>> And also said:
>>>>
>>>> -----------------------------------------------
>>>> 5.1.1.  Sender side procedures for the Stream Reset Chunk
>>>>
>>>>  Note that before sending a Stream Reset Chunk the sender MUST  
>>>> ensure
>>>>  that the peer advertised support for the stream reset  
>>>> extension.  The
>>>>  indication for support of the extensions MUST be determined  
>>>> using the
>>>>  Supported Extensions Parameter in either the INIT or INIT-ACK.   
>>>> This
>>>>  parameter is defined in [RFC5061].  If the chunk type of the
>>>>  STREAM_RESET chunk does NOT appear in the supported extensions  
>>>> list
>>>>  of chunks, then the sender MUST NOT send any stream reset  
>>>> request to
>>>>  the peer and any request by the application for such service  
>>>> SHOULD
>>>>  be responded to with an appropriate error indicating the peer SCTP
>>>>  stack does not support the stream reset extension.
>>>> ----------------------------------------------
>>>>
>>>>
>>>> So I think we must set the SCTP_ENABLE_STREAM_RESET before the  
>>>> init of
>>>> assoc. So
>>>> the assoc_id of the option is useless. If we set this option with
>>>> assoc_id, the Stream
>>>> Reconfiguration will not enable because the assoc be ESTABLISHED.  
>>>> It is
>>>> correctly?
>>>>
>>>> The one-to-one style socket can not use this extension?
>>>>
>>>>
>>> Oh ,sorry, the above question is my mistake, please ignore it.
>>>
>>> My questions are:
>>>
>>> 1. Do we need this option? ADDIP extension does not have a similar  
>>> option.
>>>
>> Yes, not all applications might handle the case where the peer  
>> resets a
>> stream. So the application has to say: I can handle it.
>> ADDIP is not user visible, except for the user enables  
>> notifications...
>>
>>> 2. If the assoc is ESTABLISHED, the action of this option is what?  
>>> Just
>>> return
>>> error?
>>>
>> No, after you enable the processing, incoming request should be  
>> processed
>> and not denied anymore. If you disable it, incoming requests should  
>> be
>> denied.
>>
>>>> If the assoc is ESTABLISHED, after we set this option, the action  
>>>> is?
>>>>
>>>> The other thing is that, ADDIP extension does not use similar  
>>>> socket
>>>> option to
>>>> enable/disable the extension. Does this make the action of  
>>>> extensions
>>>> different
>
> Thank you very much.
>
> Section '6.  Socket API considerations' does not define the
> field name for struct sctp_event_subscribe. May be
> 'sctp_stream_reset_event'?
>
> struct sctp_event_subscribe {
>        __u8 sctp_partial_delivery_event;
>        __u8 sctp_adaptation_layer_event;
>        __u8 sctp_authentication_event;
>        __u8 sctp_stream_reset_event;   <--------------
> };
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 5 Dec 2009 16:45:07 +0100

> consensus is to move to individual socket options even for the existing
As said in my earlier response:
FreeBSD has a field
sctp_stream_reset_events
not
sctp_stream_reset_event
I do not know why the 's' is there, probably a typo.

Best regards
Michael
>>>>> I saw that the following text in draft-ietf-tsvwg-sctp-strrst-01.txt:
>>>>> 
>>>>> This option allows a user to control whether the SCTP implementation
>>>>> To set or get this option the user fills in the following structure:
>>>>> 
>>>>>    requests will be denied.  If it is non-zero incoming requests will
>>>>>    be processed.
>>>>> 
>>>>> It means that we need to set the socket option SCTP_ENABLE_STREAM_RESET to
>>>>> Note that before sending a Stream Reset Chunk the sender MUST ensure
>>>>> that the peer advertised support for the stream reset extension.  The
>>>>> indication for support of the extensions MUST be determined using the
>>>>> Supported Extensions Parameter in either the INIT or INIT-ACK.  This
>>>>> STREAM_RESET chunk does NOT appear in the supported extensions list
>>>>> of chunks, then the sender MUST NOT send any stream reset request to
>>>>> the peer and any request by the application for such service SHOULD
>>>>> So I think we must set the SCTP_ENABLE_STREAM_RESET before the init of
>>>>> assoc. So
>>>>> Reconfiguration will not enable because the assoc be ESTABLISHED. It is
>>>>> correctly?
>>>>> 
>>>> 1. Do we need this option? ADDIP extension does not have a similar option.
>>>> 
>>> Yes, not all applications might handle the case where the peer resets a
>>> ADDIP is not user visible, except for the user enables notifications...
>>> 
>>>> 2. If the assoc is ESTABLISHED, the action of this option is what? Just
>>>> return
>>>> error?
>>>> 
>>> No, after you enable the processing, incoming request should be processed
>>> and not denied anymore. If you disable it, incoming requests should be
>>> denied.
>>> 
>>>>> If the assoc is ESTABLISHED, after we set this option, the action is?
>>>>> 
>>>>> The other thing is that, ADDIP extension does not use similar socket
>>>>> option to
>>>>> enable/disable the extension. Does this make the action of extensions
>>>>> different
>> 
>> Thank you very much.
>>