Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Randy Stewart <randall@lakerest.net>
In-Reply-To: <017801cb917c$08d462e0$4001a8c0@gateway.2wire.net>
Date: Thu, 2 Dec 2010 06:49:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C635E3F-12CA-4EA1-9C80-33D3FFB2E393@lakerest.net>
References: <20101129173002.3461.46301.idtracker@localhost>
 <005501cb9138$122c99a0$4001a8c0@gateway.2wire.net>
 <2BA83253-C026-4A93-92D7-64C0324CC421@lakerest.net>
 <017801cb917c$08d462e0$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
Cc: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, tsvwg@ietf.org
Precedence: list

On Dec 1, 2010, at 9:20 AM, t.petch wrote:

> My previous, somewhat lengthy, worked example was intended to show =
that yes, it
> works, but that care is needed and that perhaps more description is =
needed in
> the I-D.
>=20
> Quoting from the I-D
> "When a peer endpoint requests a Incoming SSN Reset Request it is
>   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
>   such a case the local endpoint SHOULD silently discard the request
>   and continue processing any other request found in the Stream Reset
>   Chunk."
> This will I think fail.  If the local endpoint silently discards the =
request,
> then peer endpoint will never receive a Stream Reset Response =
Parameter
> and the peer will timeout, perhaps taking down the association.  So =
while it
> can work, I do not think that the I-D has it quite right.

Ahhh.. good point.. what I should have said is ... if the=20
stream reset is exactly the same.. and thinking a bit more on this
it should also really still respond with a  "nothing to do" ...

So discarding is probably wrong.. instead its either

a) If it overlap's but is not exact queue an outgoing request and ack =
the incoming request.
b) If it is an exact overlap to what has already been sent out ack it =
with a nothing-to-do.

I will put this down as a LC update.. for the final spin ;-)

R


>=20
> Tom Petch
>=20
> ----- Original Message -----
> From: "Randy Stewart" <randall@lakerest.net>
> To: "t.petch" <ietfc@btconnect.com>
> Cc: "Michael Tuexen" <Michael.Tuexen@lurchi.franken.de>; =
<tsvwg@ietf.org>
> Sent: Wednesday, December 01, 2010 6:09 PM
> Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt
>=20
>=20
> Tom:
>=20
> Some comments in-line...
>=20
> On Dec 1, 2010, at 1:13 AM, t.petch wrote:
>=20
>> Um; I was expecting perhaps a little more on race conditions.
>>=20
>> I had a more complex race condition in mind, which will work, I have
>> convinced myself of that, provided everyone expects it to:-)
>>=20
>> 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?
>=20
>=20
> Each implementation has to keep a queue of stream reset actions. =
Basically
> consider..
>=20
> A user does
>=20
> stream-reset (2,3)
> followed by
> stream-reset (4,5)
>=20
> 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.
>=20
> So its always possible to queue a stream reset.
>=20
> As to your scenario...
>=20
> 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.
>=20
>=20
>>=20
>> 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
>>=20
>=20
> 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..
>=20
> It gets A's reset response.. and then processes its queue sending the
> outgoing reset request for 2/3.
>=20
>> Therefore
>> A must reset streams 1 and 2 and send Stream Reset Response Parameter =
to let B
>> proceed
>=20
> It of course would.. there is nothing stopping it from doing so unless =
of
> course it deny's the request (which is allowed).
>=20
>> 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
>>=20
>> 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).
>>=20
>=20
>=20
> 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...
>=20
>=20
>> 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
>>=20
>=20
> Why would it do that?
>=20
> 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.
>=20
> 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..
>=20
> I.e. (lets use different numbers than 0)
>=20
> A;
>=20
> Next_sending_SReset =3D 1
> Next_Expected_SReset_from_peer =3D 10
>=20
> B would have:
>=20
> Next_sending_SReset =3D 10
> Next_Expected_SReset_from_peer =3D 1
>=20
> So A does
>=20
> -----In-Reset(1/3)OSeq=3D1------->
>=20
> B does:
>=20
> <----Reset(1/3)OSeq=3D10,RSeq=3D0)-----
>=20
> Now
>=20
> A would do reset 1/3 and do
>=20
> -----Reset-Response(Seq=3D10)------>
>=20
> B would now find its queued request and do either (per the draft)
>=20
> -----Reset-Response(Seq=3D1)-sucess:nothing to do---->
> <or>
> -----Reset(1/3)OSeq=3D11, RSeq=3D1)----->
>=20
> Its choice...
>=20
> R
>=20
>=20
>=20
>> Tom Petch
>>=20
>> ----- Original Message -----
>> From: <Internet-Drafts@ietf.org>
>> To: <i-d-announce@ietf.org>
>> Cc: <tsvwg@ietf.org>
>> Sent: Monday, November 29, 2010 6:30 PM
>> Subject: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt
>>=20
>=20

-----
Randall Stewart
randall@lakerest.net