Subject: Review of draft-ietf-tsvwg-sctp-strrst-09.txt

From: "Gavin Shearer (gasheare)" <[email-masked]>
Date: Tue, 29 Mar 2011 13:05:09 +0200

Hi,

I have been reviewing the draft RFC:

   Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
                  draft-ietf-tsvwg-sctp-strrst-09.txt

I think the RFC is useful, especially the option to add more outgoing
streams, which is used in "IPFIX Export per SCTP Stream"
(draft-ietf-ipfix-export-per-sctp-stream-08)i, so I believe the ID
should progress. However, I do have some review comments, though most
of them are document text suggestions, and I think with the few changes
I have suggested, that the information to implementors is quite clear.

One area I am questioning is why there needs to be a feature to reset
both SSN and TSN, but if that is needed by others, then I will accept it
as part of this draft.

Cheers, Gavin Shearer

The following are my comments and suggestions on:

My comments are marked below with #### GSS. I have included
some context of the document to aid locating where the comments relates.
I have some general comments first.

What is the purpose of the TSN/SSN reset? What do you gain from
allowing the TSNs to also be reset considering that they are not set to
a specific value in the first place, and when changed the way it
"SHOULD"
be changed does not allow much control of the values the TSNs are
changed
to? It also adds more complexity as you have to be concerned whether the

the TSN's of recent chunks before the change may be muddled with new
chunks after the change if the "SHOULD" suggestions on values are not
followed. 

As the new STREAM_RESET chunk is for more than just resetting streams
(i.e.
adding extra outgoing streams), should it be named STREAM_RECONFIG
instead of STREAM_RESET?
Other similar changes in line with this are suggested below:
    Stream Reset Response Parameter ->
	Stream Reconfig Response Parameter
    Stream Reset Request Sequence Number ->
	Stream Reconfig Request Sequence Number
    Stream Reset Response Sequence Number ->
	Stream Reconfig Response Sequence Number
    Stream Reset Chunk[s] ->
	Stream Reconfig Chunk[s]
    Stream Reset Timer ->
	Stream Reconfig Timer
    reset request parameter ->
	reconfig request parameter

For consistency should decide on STREAM_RESET or STREAM RESET when
discussing
the chunk (it also uses Stream Reset ...).

For the Sockets API, what should happen if the timer is already running
when a request is received? Should the request be failed (and so a
failure
event needs specified) or should the request be queued?

3.1.  STREAM RESET Chunk
.
.
.
   Note that each STREAM RESET chunk holds at least one parameter and at
   most two parameters.  Only the following combinations are allowed:

   1.  Outgoing SSN Reset Request Parameter.

   2.  Incoming SSN Reset Request Parameter.

   3.  Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request
       Parameter.

   4.  SSN/TSN Reset Request Parameter.

   5.  Add Outgoing Streams Request Parameter.

   6.  Stream Reset Response Parameter.

   7.  Stream Reset Response Parameter, Outgoing SSN Reset Request
       Parameter.

   8.  Stream Reset Response Parameter, Stream Reset Response Parameter.

#### GSS: Under what situation do you expect there to be 2 response
#### GSS: parameters?
.
.
.
4.1.  Outgoing SSN Reset Request Parameter

   This parameter is used by the sender to request the reset of some or
   all outgoing streams.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x000d   | Parameter Length = 16 + 2 * N |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Stream Reset Request Sequence Number              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Stream Reset Response Sequence Number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Sender's Last Assigned TSN                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stream Number 1 (optional)   |    Stream Number 2 (optional) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                            ......                             /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stream Number N-1 (optional) |    Stream Number N (optional) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type: 2 bytes (unsigned integer)
      This field holds the IANA defined parameter type for Stream Reset

#### GSS: Change "Stream Reset Request Parameter" to
#### GSS: "Outgoing SSN Reset Request Parameter"

      Request Parameter.  The suggested value of this field for IANA is
      0x000d.

   Parameter Length: 2 bytes (unsigned integer)
      This field holds the length in bytes of the parameter; the value
      MUST be 16 + 2 * N.

   Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
      This field is used to identify the request.  It is a monotonically
      increasing number that is initialized to the same value as the
      Initial TSN number.  It is increased by 1 whenever sending a new
      Stream Reset Request parameter.

#### GSS: Change "Stream Reset Request parameter" to "request
parameter",
#### GSS: as also used when adding additional streams, and there is also
#### GSS: no specific parameter named "Stream Reset Request"

.
.
.

4.2.  Incoming SSN Reset Request Parameter

   This parameter is used by the sender to request that the peer resets
   some or all of its outgoing streams.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x000e   |  Parameter Length = 8 + 2 * N |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Stream Reset Request Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stream Number 1 (optional)   |    Stream Number 2 (optional) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                            ......                             /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stream Number N-1 (optional) |    Stream Number N (optional) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type: 2 bytes (unsigned integer)
      This field holds the IANA defined parameter type for Stream Reset

#### GSS: Change "Stream Reset Request Parameter" to
#### GSS: "Incoming SSN Reset Request Parameter"

      Request Parameter.  The suggested value of this field for IANA is
      0x000e.

   Parameter Length: 2 bytes (unsigned integer)
      This field holds the length in bytes of the parameter; the value
      MUST be 8 + 2 * N.

   Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
      This field is used to identify the request.  It is a monotonically
      increasing number that is initialized to the same value as the
      Initial TSN number.  It is increased by 1 whenever sending a new
      Stream Reset Request parameter.

#### GSS: Change "Stream Reset Request parameter" to "request
parameter",
#### GSS: as also used when adding additional streams, and there is also
#### GSS: no specific parameter named "Stream Reset Request"

   Stream Number 1..N: 2 bytes (unsigned integer)
      This optional field, if included, is used to indicate specific
      streams that are to be reset.  If no streams are listed, then all
      streams are to be reset.

   This parameter can appear in a STREAM RESET chunk.  This parameter
   MUST NOT appear in any other chunk type.

4.3.  SSN/TSN Reset Request Parameter

   This parameter is used by the sender to request a reset of the TSN
   and SSN numbering of all streams.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x000f   |      Parameter Length = 8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Stream Reset Request Sequence Number                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type: 2 bytes (unsigned integer)
      This field holds the IANA defined parameter type for Stream Reset

#### GSS: Change "Stream Reset Request Parameter" to
#### GSS: "SSN/TSN Reset Request Parameter"

      Request Parameter.  The suggested value of this field for IANA is
      0x000f.

   Parameter Length: 2 bytes (unsigned integer)
      This field holds the length in bytes of the parameter; the value
      MUST be 8.

   Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
      This field is used to identify the request.  It is a monotonically
      increasing number that is initialized to the same value as the
      Initial TSN number.  It is increased by 1 whenever sending a new
      Stream Reset Request parameter.

#### GSS: Change "Stream Reset Request parameter" to "request
parameter",
#### GSS: as also used when adding additional streams, and there is also
#### GSS: no specific parameter named "Stream Reset Request"

   This parameter can appear in a STREAM RESET chunk.  This parameter
   MUST NOT appear in any other chunk type.

4.4.  Stream Reset Response Parameter

   This parameter is used by the receiver of a stream reset request
   parameter to respond to the stream reset request.

#### GSS: As also used for adding additional streams change to:
#### GSS: "This parameter is used by the receiver of a request parameter
#### GSS: to respond to the request."
.
.
.
   Sender's next TSN: 4 bytes (unsigned integer)
      This field holds the TSN the sender of the Response will use to

#### GSS: lower case "R" in response

4.5.  Add Outgoing Streams Request Parameter

   This parameter is used by the sender to request that an additional
   number of outgoing streams (i.e. the receiver's incoming streams) be
   added to the association.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x0011   |      Parameter Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Stream Reset Request Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Number of new streams    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type: 2 bytes (unsigned integer)
      This field holds the IANA defined parameter type for the Add
      Streams Parameter.  The suggested value of this field for IANA is

#### GSS: Change "Add Streams Parameter" to
#### GSS: "Add Outgoing Streams Request Parameter"

      0x0011.

   Parameter Length: 2 bytes (unsigned integer)
      This field holds the length in bytes of the parameter; the value
      MUST be 12.

   Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
      This field is used to identify the request.  It is a monotonically
      increasing number that is initialized to the same value as the
      Initial TSN number.  It is increased by 1 whenever sending a new
      Stream Reset Request parameter.

#### GSS: Change "Stream Reset Request parameter" to "request
parameter",
#### GSS: as also used when adding additional streams, and there is also
#### GSS: no specific parameter named "Stream Reset Request"
.
.
.

5.  Procedures

   This section defines the procedures used by both the sender and
   receiver of a stream reset.  We also give various example stream
   reset scenarios.

#### GSS: As it gives more than reset, maybe change to talk about
handling of
#### GSS: the chunks, e.g.:
#### GSS: This section defines the procedures used by both the sender
and
#### GSS: receiver of a STREAMS_RESET chunk.

#### GSS: I don't think this section gives example scenarios (they are
in
#### GSS: Appendix A), so remove the line: "We also give various example
#### GSS: stream reset scenarios".

   One important thing to remember about SCTP streams is that they are
   uni-directional and there is no coorespondance between outgoing and

#### GSS: Typo: coorespondance -> correspondance

   incoming streams.  The procedures outlined in this section are
   designed so that the incoming side will always reset their stream
   sequence number first before the outgoing side which means the stream
   reset request must always originate from the outgoing side.  These
   two issues have important ramifications upon how an SCTP endpoint
   might request that its incoming streams be reset.  In effect it must
   ask the peer to start an outgoing reset proceedure and once that

#### GSS: Typo: proceedure -> procedure

   request is acknowledged let the peer actually control the reset
   operation.

5.1.  Sender Side Procedures

   This section describes the procedures related to the sending of
   Stream Reset Chunks.  A Stream Reset Chunk is composed of one or two
   Type Length Value (TLV) parameters.

5.1.1.  Sender Side Procedures for the Stream Reset Chunk

   This SCTP extension uses the Supported Extensions Parameter defined
   in [RFC5061] for negotiating the support for it.

   An SCTP endpoint supporting this extension MUST include the chunk
   type of the STREAM_RESET chunk in the Supported Extensions Parameter
   in either the INIT or INIT-ACK.  Before sending a Stream Reset Chunk
   the sender MUST ensure that the peer advertised support for the
   stream reset extension.  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.

   After packaging the Stream Reset Chunk and sending it to the peer the
   sender MUST start a 'Stream Reset Timer' if the STREAM RESET chunk
   contains at least one request parameter.  If it contains no request
   parameter, the Stream Reset Timer MUST NOT be started.  This timer

#### GSS: Typo: parameter -> parameters

   MUST use the same value as SCTP's Data transmission timer (i.e. the
   RTO timer) and MUST use exponential backoff doubling the value at
   every expiration.  If the timer expires, besides doubling the value,
   the sender MUST retransmit the Stream Reset Chunk, increment the
   appropriate error counts (both for the association and the
   destination), and perform threshold management possibly destroying
   the association if SCTP retransmission thresholds are exceeded.

5.1.2.  Sender Side Procedures for the Outgoing SSN Reset Request
        Parameter

   When an SCTP sender wants to reset the SSNs of some or all outgoing
   streams it can send an Outgoing SSN Reset Request Parameter provided
   that the Stream Reset Timer is not running.  The following steps must
   be followed:

   A1:  The sender MUST stop assigning new SSNs to new user data
        provided by the upper layer for the affected streams and queue
        it.  This is because it is not known whether the receiver of the
        request will accept or deny it and moreover, a lost request
        might cause an out-of-sequence error in a stream that the
        receiver is not yet prepared to handle.

#### GSS: What happens to user data already assigned SSNs, or do we
assume
#### GSS: that they are only assigned just before sending? If we do not
#### GSS: assume this, should it say that the request can only be sent
#### GSS: out after all data with assigned SSNs have been sent?

#### GSS: Also should it emphasize that transmission of data must be
suspended
#### GSS: until a response is received for the request?

.
.
.

5.1.3.  Sender Side Procedures for the Incoming SSN Reset Request
        Parameter

.
.
.

   When sending a Incoming SSN Reset Request their is a potential that

#### GSS: Typos: a -> an, their -> there

   the peer has just reset or is in the process of resetting the same
   streams via an Outgoing SSN Reset Request.  This collision scenario
   is discussed in Section 5.2.3.

5.1.4.  Sender Side Procedures for the SSN/TSN Reset Request Parameter

   When an SCTP sender wants to reset the SSNs and TSNs it can send an
   SSN/TSN Reset Request Parameter provided that the Stream Reset Timer
   is not running.  The following steps must be followed:

   C1:  The sender MUST assign the next stream reset request sequence
        number and put it into the Stream Reset Request Sequence Number
        field of the SSN/TSN Reset Request Parameter.  After assigning
        it the next stream reset request sequence number MUST be
        incremented by 1.

   C2:  The sender MUST queue any user data suspending any new
        transmissions and TSN assignment until the reset procedure is

#### GSS: change "TSN" to "TSN and SSN"

        finished by the peer either acknowledging or denying the
        request.

#### GSS: What happens to data already assigned TSN and/or SSNs but have
#### GSS: but have not been sent, or do we assume that they are only
#### GSS: assigned just before sending? If we do not
#### GSS: assume this, should it say that the request can only be sent
#### GSS: out after all data with assigned TSNs and SSNs have been sent?

   C3:  The SSN/TSN Reset Request Parameter MUST be put into a STREAM
        RESET Chunk.  There MUST NOT be any other parameter in this
        chunk.

   C4:  The STREAM RESET Chunk MUST be sent following the rules given in
        Section 5.1.1.

   Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds,
   which is considered a maximum segment lifetime, the IP MSL.

5.1.5.  Sender Side Procedures for the Stream Reset Response Parameter

   When an implementation receives a reset request parameter it must
   respond with a Stream Reset Response Parameter in the following
   manner:

   D1:  The Stream Reset Request Sequence number of the incoming request
        MUST be copied to the Stream Reset Response Sequence Number
        field of the Stream Reset Response Parameter.

   D2:  The result of the processing of the incoming request according
        to Table 3 MUST be placed in the Result field of the Stream
        Reset Response Parameter.

   D3:  If the incoming request is an SSN/TSN reset request, the
        Sender's next TSN field MUST be filled with the next TSN the
        sender of this Stream Reset Response Parameter will assign.  For

#### GSS: should D3 also mention the SHOULD in G2?

        other requests the Sender's next TSN field, which is optional,
        MUST NOT be used.

.
.
.

5.2.2.  Receiver Side Procedures for the Outgoing SSN Reset Request
        Parameter
.
.
.
   E6:  The STREAM RESET chunk MUST be sent after the incoming STREAM
        RESET chunk is processed completely.

#### GSS Should it say about sending "Denied" if not supporting the
change,
#### GSS similar to  5.2.3

5.2.3.  Receiver Side Procedures for the Incoming SSN Reset Request
        Parameter

   In the case that the endpoint is willing to perform a stream reset
   the following steps must be followed:

   F1:  An Outgoing SSN Reset Request Parameter MUST be put into an
        STREAM RESET chunk according to Section 5.1.2.

   F2:  The STREAM RESET chunk MUST be sent after the incoming STREAM
        RESET chunk is processed completely.

   If the endpoint is un-willing to perform the stream reset it MUST
   send a Stream Reset Response Parameter with the appropriate error set
   to "Denied".

   When a peer endpoint requests a Incoming SSN Reset Request it is

#### GSS: Typo: a -> an

   possible that the local endpoint has just sent an Outgoing SSN Reset
   Request on the same stream and has not yet received a response.  In

#### GSS: stream -> association?

   such a case the local endpoint MUST do the following:

   1) If the stream reset overlaps the outstanding request completely

#### GSS: make clearer which is which? e.g.
#### GSS: "If the just sent Outgoing SSN Reset Request Parameter
completely 
#### GSS: overlaps the received Incoming SSN Reset Request Parameter
..."

      respond to the requestor with a acknowledgment indicating that

#### GSS: Typo: a -> an

      there was 'Nothing to do'.

   2) Otherwise process the stream reset request normally responding to
      the requestor with a acknowledgment.

#### GSS: Typo: a -> an
.
.
.

5.2.4.  Receiver Side Procedures for the SSN/TSN Reset Request Parameter

   In the case that the endpoint is willing to perform an SSN/TSN reset
   the following steps must be followed:

   G1:  Compute an appropriate value for the Receiver's next TSN, the
        TSN the peer should use to send the next DATA chunk.  The value
        SHOULD be the smallest TSN not acknowledged by the receiver of
        the request plus 2^31.

   G2:  Compute an appropriate value for the local endpoint's next TSN,
        i.e. the receiver of the SSN/TSN reset chunk next TSN to be
        assigned.  The value SHOULD be the highest TSN sent by the
        receiver of the request plus 1.

#### GSS: Is this recommended value not the value the other size would
#### GSS: normally expect at the TSN? If other values are allowed, are
#### GSS: there recommendations, e.g. add 2^31