Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-strrst-12

"Vijay K. Gurbani" <vkg@bell-labs.com> Wed, 30 November 2011 21:08 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5B1F0C8A for <gen-art@ietfa.amsl.com>; Wed, 30 Nov 2011 13:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.243
X-Spam-Level:
X-Spam-Status: No, score=-106.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+TFC8wpwnUa for <gen-art@ietfa.amsl.com>; Wed, 30 Nov 2011 13:08:20 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 075941F0C83 for <gen-art@ietf.org>; Wed, 30 Nov 2011 13:08:19 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pAUL6veJ020181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 15:06:58 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pAUL6vND026942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Nov 2011 15:06:57 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pAUL6rOZ013719; Wed, 30 Nov 2011 15:06:54 -0600 (CST)
Message-ID: <4ED69BB9.4030001@bell-labs.com>
Date: Wed, 30 Nov 2011 15:10:17 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Michael Tuexen <tuexen@fh-muenster.de>
References: <4ED66709.50304@bell-labs.com> <22C7D48E-485B-4333-B29A-DB16BCCD3626@fh-muenster.de>
In-Reply-To: <22C7D48E-485B-4333-B29A-DB16BCCD3626@fh-muenster.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: gorry@erg.abdn.ac.uk, Wesley Eddy <wes@mti-systems.com>, draft-ietf-tsvwg-sctp-strrst@tools.ietf.org, "James M. Polk" <jmpolk@cisco.com>, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-strrst-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2011 21:08:21 -0000

On 11/30/2011 02:19 PM, Michael Tuexen wrote:
>> - S5, second paragraph --- "The procedures outlined in this section are
>> designed so that the incoming side will always reset their stream
>> sequence number first before the outgoing side which means the re-
>> configuration request must always originate from the outgoing side."
> A stream is unidirectional. So it is outgoing for one side, incoming
> for the other. The outgoing side has to request the reset, the incoming
> side will perform it and acknowledge that the reset has been performed and
> then the outgoing side will also do the reset.

OK, so let's see ... assume two hosts A and B with two unidrectional
streams open between them:


     --------- a' -------->
  A                         B
     <-------- b' ---------

a' is outgoing stream for A and incoming stream for B.
b' is outgoing stream for B and incoming stream for A.

What you are saying is that either A has to request a reset on a'
or B has to request a reset on b'.  In the worst possible case,
both A and B can request a reset on their respective streams
(A on a' and B on b') without leading to deadlock or a violation
of the protocol.  Yes?

If so, then this discussion at least makes it clear to me.  However,
I will leave it to you on whether or not to clarify this further
in the draft.  When I read the draft initially, I certainly had
enough doubts that resulted in this email exchange.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/