Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt

[Randy Stewart <[e-mail]>]

Tom:

Some comments in-line...

On Dec 1, 2010, at 1:13 AM, t.petch wrote:

> Um; I was expecting perhaps a little more on race conditions.
> 
> I had a more complex race condition in mind, which will work, I have
> convinced myself of that, provided everyone expects it to:-)
> 
> A appl requests a reset of streams 2 and 3
> A sends Incoming SSN Reset Request Parameter for streams 2 and 3 and starts
> timer
> A receives Outgoing SSN Reset Request Parameter for streams 1 and 2 with zero
> Stream Reset Request Sequence Number
> A sends ACK and  has a think about what to do .....
> - waits for Outgoing SSN Reset Request Parameter for streams 2 and 3?
> - resets streams 1 and 2?
> - raises an event for streams 1 and 2?


Each implementation has to keep a queue of stream reset actions. Basically consider..

A user does

stream-reset (2,3)
followed by
stream-reset (4,5)

the reset of 2/3 will not be finished when the socketoption (thats how we did it anyway) is
called on 4-5.. thus the implementation has to keep a queue of requests that have not been sent.

So its always possible to queue a stream reset.

As to your scenario...

There would be nothing stopping A of responding right away to the Outgoing Reset request. The
incoming request is outstanding, but it can respond to the outgoing request.. which it would.


> 
> Meanwhile,
> B appl requests a reset of streams 1 and 2
> B sends Outgoing SSN Reset Request Parameter for streams 1 and 2 and starts
> timer
> B receives Incoming SSN Reset Request Parameter for streams 2 and 3
> B has timer running so must wait
> 

On the other side, B sends his request and then gets the request for the incoming.
It then adds this to its queue of things to do... and waits its response..

It gets A's reset response.. and then processes its queue sending the
outgoing reset request for 2/3.

> Therefore
> A must reset streams 1 and 2 and send Stream Reset Response Parameter to let B
> proceed

It of course would.. there is nothing stopping it from doing so unless of
course it deny's the request (which is allowed).

> B receives Stream Reset Response Parameter and stops timer
> B can and must now send Outgoing SSN Reset Request Parameter for streams 2 and 3
> with non-zero Stream Reset Request Sequence Number and starts timer
> A receives Outgoing SSN Reset Request Parameter for streams 2 and 3 with
> non-zero Stream Reset Request Sequence Number and stops timer
> A resets streams 2 and 3 and sends Stream Reset Response Parameter
> B receives Stream Reset Response Parameter and stops timer
> 
> A appl and B appl both receive events, one for reset of streams 1 and 2, the
> other for streams 2 and 3 (which may puzzle them).
> 


Well thats true... but App's are going to have to either coordinate there
reset requests or be able to handle getting a reset on 1/2 followed by
another reset 2/3...


> Of course, a slightly different scenario would be for both A and B to select the
> same streams, say 1 and 3 (perhaps as a result of an application level event) in
> which case, the scope for getting it wrong is even greater; when A receives
> Outgoing SSN Reset Request Parameter with zero Stream Reset Request Sequence
> Number, it might send an Error - Bad Sequence Number, which could really confuse
> B
> 

Why would it do that?

In this scenario you have exactly the race condition that I mentioned in the
new version of the document. When B goes to process the "queued" request for 1/3 it
finds they are both already at 1/3... so it could easily send the "success - no action required" in
response.

The sequence number is unique to each side. I.e. Side A has a number it is sending and a different
number it is expecting from B..

I.e. (lets use different numbers than 0)

A;

Next_sending_SReset = 1
Next_Expected_SReset_from_peer = 10

B would have:

Next_sending_SReset = 10
Next_Expected_SReset_from_peer = 1

So A does

-----In-Reset(1/3)OSeq=1------->

B does:

<----Reset(1/3)OSeq=10,RSeq=0)-----

Now

A would do reset 1/3 and do

-----Reset-Response(Seq=10)------>

B would now find its queued request and do either (per the draft)

-----Reset-Response(Seq=1)-sucess:nothing to do---->
<or>
-----Reset(1/3)OSeq=11, RSeq=1)----->

Its choice...

R



> Tom Petch
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, November 29, 2010 6:30 PM
> Subject: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt
> 
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the Transport Area Working Group Working Group of
> the IETF.
>> 
>> 
>> Title           : Stream Control Transmission Protocol (SCTP) Stream
> Reconfiguration
>> Author(s)       : R. Stewart, et al.
>> Filename        : draft-ietf-tsvwg-sctp-strrst-08.txt
>> Pages           : 31
>> Date            : 2010-11-29
>> 
>> Many applications that use SCTP want the ability to "reset" a stream.
>> The intention of resetting a stream is to set the numbering sequence
>> of the stream back to 'zero' with a corresponding notification to the
>> upper layer that this has been performed.  The applications that want
>> this feature want it so that they can "re-use" streams for different
>> purposes but still utilize the stream sequence number so that the
>> application can track the message flows.  Thus, without this feature,
>> a new use of an old stream would result in message numbers greater
>> than expected unless there is a protocol mechanism to "reset the
>> streams back to zero".  This document also includes methods for
>> resetting the transport sequence numbers, adding additional streams
>> and resetting all stream sequence numbers.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-08.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> 
> 

-----
Randall Stewart
[e-mail]