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

Randy Stewart <> Thu, 11 November 2010 05:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5C933A69E4 for <>; Wed, 10 Nov 2010 21:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.643
X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_SUB_6CONS_WORD=0.356]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f9LBaftAFdoG for <>; Wed, 10 Nov 2010 21:57:09 -0800 (PST)
Received: from (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by (Postfix) with ESMTP id A39F93A69E5 for <>; Wed, 10 Nov 2010 21:57:08 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id oAB5vALB040928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Nov 2010 00:57:15 -0500 (EST) (envelope-from
Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Randy Stewart <>
X-Priority: 3
In-Reply-To: <002d01cb7b6b$0fd92fc0$>
Date: Wed, 10 Nov 2010 21:57:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <><> <> <005201cb4de6$40c41440$> <> <001501cb4e7b$f2fcf880$> <> <00b301cb74fc$5f6dc0c0$> <> <002d01cb7b6b$0fd92fc0$>
To: "t.petch" <>
X-Mailer: Apple Mail (2.1081)
Cc:, Michael Tüxen <>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Nov 2010 05:57:11 -0000


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

Or you could even get

------Outgoing Reset(str=2) ----->
    <--   | Incoming Reset(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.


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" <>
> To: "t.petch" <>
> Cc: "Michael Tüxen" <>; <>;
> <>
> Sent: Tuesday, October 26, 2010 6:39 PM
> Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt

Randall Stewart