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

"Vijay K. Gurbani" <> Wed, 30 November 2011 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFE5B1F0C8A for <>; Wed, 30 Nov 2011 13:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.243
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d+TFC8wpwnUa for <>; Wed, 30 Nov 2011 13:08:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 075941F0C83 for <>; Wed, 30 Nov 2011 13:08:19 -0800 (PST)
Received: from ( []) by (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 ( []) by (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 ( []) by (8.13.8/TPES) with ESMTP id pAUL6rOZ013719; Wed, 30 Nov 2011 15:06:54 -0600 (CST)
Message-ID: <>
Date: Wed, 30 Nov 2011 15:10:17 -0600
From: "Vijay K. Gurbani" <>
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 <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Cc:, Wesley Eddy <>,, "James M. Polk" <>, General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-strrst-12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


- vijay
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{,} /