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

[Randy Stewart <[e-mail]>]

Tom:

Thanks for the comment... and this is a good point. I have
thought about this for a bit.. and I think there is no
worries here.. but its not documented and should be.

I will add a section on this in the next spin and include a diagram or
two. Basically if you think about it you have:

------Outgoing Reset(str=2) ----->
    <----Incoming Reset(str=2)---|
    <-----Reset-Ack(str=2)-------+

Or you could even get

------Outgoing Reset(str=2) ----->
    <--   | Incoming Reset(str=2)---|
       \--Reset-Ack(str=2)-------+
          |
   <------+

In one case you get a request while asking to reset your stream
and in the other you just reset your stream and you get requested
to reset it again.

In either case I think the thing to do is just ACK the request.. since in
one case you are in the process of doing what the peer wants (even though
its the same thing you want to do).. and in the other you have just finished
doing what it wants...

I suppose you could even do it again.. but the point is rather moot since the
end state is the same as before.. i.e. the stream sequence goes to 0.. where it
already was.

So overall just saying "yes" and completing your request (or saying yes and ignoring it
since you are at 0) is fine..

I will find some place to put this in the documents next spin...which will be shortly.

R

On Nov 3, 2010, at 7:59 AM, t.petch wrote:

> What happens in a race condition, eg when one endpoint requests an Incoming SSN
> Reset for streams 1,2,3 and simultaneously the other endpoint requests an
> Outgoing SSN Reset for stream 2? (races are a bit of a mess in TCP)
> 
> E1 last sentence; which acknowledgement is being referred to?
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Randy Stewart" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: "Michael Tüxen" <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> Sent: Tuesday, October 26, 2010 6:39 PM
> Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt
> 

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