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

Randy Stewart <randall@lakerest.net> Wed, 09 February 2011 16:18 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 A47173A63EC for <tsvwg@core3.amsl.com>; Wed, 9 Feb 2011 08:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.643
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nha650WWUBDx for <tsvwg@core3.amsl.com>; Wed, 9 Feb 2011 08:18:51 -0800 (PST)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id DD4063A6866 for <tsvwg@ietf.org>; Wed, 9 Feb 2011 08:18:50 -0800 (PST)
Received: from [10.193.34.57] ([12.133.183.34]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p19GImsh057115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Feb 2011 11:18:50 -0500 (EST) (envelope-from randall@lakerest.net)
Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-09.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: <00a801cbb4aa$544a8140$4001a8c0@gateway.2wire.net>
Date: Wed, 09 Feb 2011 11:18:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <86BC9A07-C996-4E88-B2DF-1E42B39CDDD7@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> <971CDA6A-93A2-40D2-86E9-7956C5A7BCF3@lakerest.net> <00a801cbb4aa$544a8140$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: Wed, 09 Feb 2011 16:18:52 -0000

Tom:

Just to let you know I did NOT forget about this... Here is the text that is
waiting in the xml for the -10 revision:
***********************************************************
   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 MUST do the following:

   1) If the stream reset overlaps the outstanding request completely
      respond to the requestor with an acknowledgment indicating that
      there was 'Nothing to do'.

   2) Otherwise process the stream reset request normally responding to
      the requestor with an acknowledgment.

   It is also possible that the Incoming request will arrive after the
   Outgoing SSN Reset Request just completed.  In such a case the local
   endpoint MUST do the following:

   1) If the stream reset overlaps the outstanding request completely
      all of the streams being requested will be already set to 0.  If
      so, the local endpoint SHOULD send back a Stream Reset Response
      with the success code "Nothing to do".

   2) Otherwise process the stream reset request normally responding to
      the requestor an acknowledgment.

   Note that in either race condition the local endpoint could
   optionally also perform the reset.  This would result in streams that
   are already at sequence 0 being reset again to 0 which would cause no
   harm to the application but will add an extra message to the network.

   Note also that in any of the race conditions listed above the
   receiver MUST NOT send more than one response.  In other words two
   responses MUST NOT be sent for the same request.

*******************************************************************

When we get any other comments after LC I will issue the updated draft with the above...

If you would like further changes or this does not satisfy your comments below
let me know.. you can even send suggested text :-)

Best wishes

R

On Jan 15, 2011, at 6:49 AM, t.petch wrote:

> I like the change to 5.2.3 but think that it needs to go further.
> 
> -08 split out two cases,
> 
> Incoming SSN Reset Request received but no response yet to the Outgoing request
> Incoming SSN Reset Request received after response to the Outgoing request
> 
> assuming that the Incoming and Outgoing requests have overlapping stream
> numbers.
> 
> -09 subdivides the first case into overlaps completely and overlaps partially
> but
> I think that the second case is also in need of subdivision in the same way.
> 
> And, a point of clarification, in any of the four cases, is it required to send
> just
> the one response, ie you cannot send two responses in the partial overlap case,
> one saying no-op and the will do (or won't do!)?
> 
> 
> Tom Petch
> 

-----
Randall Stewart
randall@lakerest.net