Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt
Randy Stewart <randall@lakerest.net> Fri, 03 December 2010 18:57 UTC
Return-Path: <randall@lakerest.net>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1158928C155 for <tsvwg@core3.amsl.com>; Fri, 3 Dec 2010 10:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.77
X-Spam-Level:
X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTjhI7xGuecK for <tsvwg@core3.amsl.com>; Fri, 3 Dec 2010 10:57:30 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 885D928C14F for <tsvwg@ietf.org>; Fri, 3 Dec 2010 10:57:29 -0800 (PST)
Received: from [192.168.1.19] ([12.133.183.34]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id oB3IwWQO009495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Dec 2010 13:58:35 -0500 (EST) (envelope-from randall@lakerest.net)
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>
X-Priority: 3
In-Reply-To: <01c001cb9311$1a274760$4001a8c0@gateway.2wire.net>
Date: Fri, 03 Dec 2010 10:58:20 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <971CDA6A-93A2-40D2-86E9-7956C5A7BCF3@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> <8C635E3F-12CA-4EA1-9C80-33D3FFB2E393@lakerest.net> <01c001cb9311$1a274760$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
X-Mailer: Apple Mail (2.1082)
Cc: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2010 18:57:32 -0000
On Dec 3, 2010, at 9:37 AM, t.petch wrote: > ---- 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: Thursday, December 02, 2010 3:49 PM > > 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. >> >> 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 > 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 ;-) > > <tp> > Yup; I look forward to the text (and some more dry running:-). One aspect I am > unclear on is just when the reset takes place; presumably after > sending/receiving the Stream Reset Response Parameter to the Outgoing SSN Reset > Request Parameter so that the 'stream receiver' resets before the 'stream > sender'; is this correct? So generally a sender of a outgoing type reset does: 1) Send the Outgoing reset 2) Stop all SSN assignment (if any is happening) holding off until the stream resets 3) Get the response back from the peer (acking the request). 4) Now go ahead and reset the outgoing numbers and allow sending again. You have to do this in order to make sure the receiver is happy.. otherwise it might get a stream-seq=0 before it has process the reset... and that would most likely mean an abort of the connection (if the implementation has mis-order protection in stream processing... which many do.. at least they did at the last inter-op ;-d) > > Also; > > After B4, suggest > > " When sending a Incoming SSN Reset Request, there is a possibility that > the peer has just reset or is in the process of resetting some or all of the > same > streams via an Outgoing SSN Request..." > > E4 needs to refer to E2 Thanks... I will update it ;-) > > > Tom Petch > > </tp> > > R > > >> >> Tom Petch >> >> ----- 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 >> >> >> 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: <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 >>> >> > > ----- > Randall Stewart > randall@lakerest.net > > > > ----- Randall Stewart randall@lakerest.net
- I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt Internet-Drafts
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt t.petch
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt Randy Stewart
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt t.petch
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt Randy Stewart
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt t.petch
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-08.txt Randy Stewart
- I-D Action:draft-ietf-tsvwg-sctp-strrst-09.txt t.petch
- Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-09.txt Randy Stewart