Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Wed, 24 August 2011 18:46 UTC

Return-Path: <yoshifumi.nishida@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1A521F8A58 for <tsvwg@ietfa.amsl.com>; Wed, 24 Aug 2011 11:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.761
X-Spam-Level:
X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 QRGlUd-8xRyC for <tsvwg@ietfa.amsl.com>; Wed, 24 Aug 2011 11:46:38 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id CA15E21F89B8 for <tsvwg@ietf.org>; Wed, 24 Aug 2011 11:46:38 -0700 (PDT)
Received: by iye1 with SMTP id 1so2275805iye.27 for <tsvwg@ietf.org>; Wed, 24 Aug 2011 11:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uJVN4j3wzn50+N2ZDAJq2ecqoOBpeIk3Y+Y3d0odXvQ=; b=Kn+Gtjk+bLdYO98XunXAYQ70v/wyMQQ2piE9cJueJ8HtT/di3GGGn5JDuAfYi6x5wI GT+0aTqOUkahqiXtS0HeFo+qSsunU3eDhBVtjG8DzZXwzWL6cfyCoX8/qS0SClfcsV45 h3Y9QBR7/y1yJQo1dgN4YR+oylFwTsOCRAXEQ=
MIME-Version: 1.0
Received: by 10.231.47.17 with SMTP id l17mr6827289ibf.24.1314211669902; Wed, 24 Aug 2011 11:47:49 -0700 (PDT)
Sender: yoshifumi.nishida@gmail.com
Received: by 10.231.199.80 with HTTP; Wed, 24 Aug 2011 11:47:49 -0700 (PDT)
In-Reply-To: <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de>
References: <D9D4D27D-0234-444C-801A-B4916F1D9A5A@lurchi.franken.de> <CABxaRLE3BQTvQ69ga8F8FTSGBBh+YiXqBVy_HwNJp06bQ9D8ig@mail.gmail.com> <91A7771A-DFD8-401D-B9E1-BB1199C12CC6@lurchi.franken.de>
Date: Wed, 24 Aug 2011 11:47:49 -0700
X-Google-Sender-Auth: PykZo2XUm6TxCycqfI8Q2QrRfZs
Message-ID: <CABxaRLF3NcdfQ+vzwUW6+9ZxMawJ5-X3B=mBCUz-GML5PuDn6g@mail.gmail.com>
Subject: Re: Comments regarding draft-nishida-tsvwg-sctp-failover-03.txt
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tsvwg list <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 24 Aug 2011 18:46:39 -0000

2011/8/24 Michael Tüxen <Michael.Tuexen@lurchi.franken.de>:
> On Aug 24, 2011, at 12:24 PM, Yoshifumi Nishida wrote:
>
>> Hi Michael,
>>
>> Thank you so much for the review.  Most points were addressed by Preethi.
>> So, I just would like to clarify one point.
>>
>> 2011/8/22 Michael Tüxen <Michael.Tuexen@lurchi.franken.de>:
>>
>>>
>>>   o  When the sender receives an heartbeat ACK from a PF destination,
>>>      the sender clears the destination's error counter and transitions
>>>      the PF destination back to active state.  This state transition
>>>      MUST NOT be notified to the ULP unless it is explicitly requested.
>>>      This destination's cwnd is set to 1 MTU (TODO: or 2?  Needs more
>>>      text discussing rationale; can revisit later?)
>>>
>>> We don't have defined a notification. I don't see the value
>>> of it. So maybe you want to get rid of it?
>>
>> Hmm. I might miss your point, but I believe we cannot use arbitrary value..
>> Shall we refer 7.2.1 in RFC4960?
> I was not clear... I'm referring to the sentence:
>
> This state transition MUST NOT be notified to the ULP unless it
> is explicitly requested.
>
> Currently we do not have such a notification. That is why I'm asking,
> if it would be better to remove it.

Oh. I see. Make sense. Thanks for the clarification.

Regards,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp