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

From: Michael Tüxen <[email-masked]>
Date: Sun, 10 Jul 2011 17:50:39 +0200

Hi Gavin,

thank you very much for your comments.
Please see my corresponding answers in-line.

Best regards
Michael

On Mar 29, 2011, at 1:05 PM, Gavin Shearer (gasheare) wrote:

> 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. 
Please see the discussion on the mailing list.
> 
> 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 ...).
I already did some renaming like you suggested for revision 10.
So this is already done.
> 
> 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?
The corresponding setsockopt() will fail. I've added:
<t>If a call to setsockopt() is used to issue a Re-configuration request
while the Re-configuration timer is running, setsockopt() will return
-1 and error is set to EALREADY.</t>
> 
> 
> 
> 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?
For example if you receive two request parameters listed as case 3.
> .
> .
> .
> 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"
Done.
> 
>      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"
This was already done, when doing the renaming. It now reads:
It is increased by 1 whenever sending a new Re-configuration Request parameter.

> 
> .
> .
> .
> 
> 
> 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"
Already done.
> 
>      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"
Already done.
> 
>   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"
Already done.
> 
>      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"
Already done.
> 
>   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."
It now uses Re-configuration Request parameter.
> .
> .
> .
>   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
Done.
> 
> 
> 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"
Done.
> 
>      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"
It reads now
It is increased by 1 whenever sending a new Re-configuration Request parameter.
> .
> .
> .
> 
> 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".
Yes, it reads now:
<t>This section defines the procedures used by both the sender and
receiver of a RE-CONFIG chunk.
Various examples of re-configuration scenarios are given in
<xref target="examples"/>.</t>
> 
>   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
Fixed.
> 
>   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
Fixed.
> 
>   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
Fixed
> 
>   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
Yes, assigning SSN must be done before sending, since the SSN field
is part of the DATA chunk.
> #### 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?
I think that is clear. Without assigning the SSN, you can't put
it on the wire.
> 
> .
> .
> .
> 
> 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
Fixed.
> 
>   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
Only user messages sent after the application
has requested the SSN/TSN reset are affected. So only these need to
be queued.
> #### 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?
I added:
The sender has either no outstanding TSNs or considers all outstanding
TSNs abondoned.
> 
>   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?
No: It MUST be filled. However, the suggested value SHOULD be the one
given 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
I took the sentence out of 5.2.3, since there is a generic statement
in 5.2.1.
> 
> 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
Fixed.
> 
>   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?
Fixed.
> 
>   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
> ..."
Fixed.
> 
>      respond to the requestor with a acknowledgment indicating that
> 
> #### GSS: Typo: a -> an
Fixed.
> 
>      there was 'Nothing to do'.
> 
>   2) Otherwise process the stream reset request normally responding to
>      the requestor with a acknowledgment.
> 
> #### GSS: Typo: a -> an
Fixed.
> .
> .
> .
> 
> 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
We recommend the value given. It is the next expected TSN.