Subject: [tsvwg] About the socket option SCTP_ENABLE_STREAM_RESET

From: Wei Yongjun <[email-masked]>
Date: Sun, 29 Nov 2009 11:32:26 +0800

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

Regards

Wei Yongjun

---

From: Wei Yongjun <[email-masked]>
Date: Sun, 29 Nov 2009 11:47:10 +0800

> I saw that the following text in draft-ietf-tsvwg-sctp-strrst-01.txt:

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.

2. If the assoc is ESTABLISHED, the action of this option is what? Just
return
error?

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 29 Nov 2009 09:54:39 +0100

Hi Wei,

see my comments in-line.

Best regards
Michael

> I saw that the following text in draft-ietf-tsvwg-sctp-strrst-01.txt:
The next revision will read:

The default is not to process incoming requests.

and then you need the SCTP_ENABLE_STREAM_RESET socket option to enable the processing
of incoming requests. This is for backward compatibility.
> And also said:
No this is different: If you support this extension (it is implemented),
then you will announce it. But if the SCTP_ENABLE_STREAM_RESET option
is not set, all incoming requests will be denied.
> The one-to-one style socket can not use this extension?
Both can. The SCTP_ENABLE_STREAM_RESET options takes an sctp_assoc_value.
> enable/disable the extension. Does this make the action of extensions
Somewhat. The application need to enable it. Since legacy applications
might not handle the case correctly where the peer resets a stream.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 29 Nov 2009 09:57:26 +0100

> 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
No, after you enable the processing, incoming request should be processed
and not denied anymore. If you disable it, incoming requests should be
denied.

---

From: Wei Yongjun <[email-masked]>
Date: Mon, 30 Nov 2009 08:34:41 +0800

Michael Tuexen wrote:
>>> 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;   <--------------
};

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 30 Nov 2009 18:22:05 +0100

>        __u8 sctp_stream_reset_event;   <--------------
This was left out intentionally. The next rev of the socket API ID will
provide a way to subscribe to a notification by using only the type.

This avoids that we need to break ABI compatibility for every new
extension.

However, you are free to include such a field as an implementation dependent
way. In FreeBSD, we currently use sctp_stream_reset_events (not sure why there
is the final s), but I do not want to put this into the ID.

Best regards
Michael