Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 09 December 2011 09:05 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 7989C21F84B3 for <tsvwg@ietfa.amsl.com>; Fri, 9 Dec 2011 01:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.657
X-Spam-Level:
X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LILfwvwuDY+U for <tsvwg@ietfa.amsl.com>; Fri, 9 Dec 2011 01:05:38 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBD3621F84B0 for <tsvwg@ietf.org>; Fri, 9 Dec 2011 01:05:38 -0800 (PST)
Received: by iaek3 with SMTP id k3so4601110iae.31 for <tsvwg@ietf.org>; Fri, 09 Dec 2011 01:05:38 -0800 (PST)
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=LsHjoMShz1DcNE+9s01rFRRH563L4nQse5nbni6f7ms=; b=dg+l+bBGxj0GxahavSH8gXemPt6hjQwLeJhNdaGcWr3aRkJpGuNXQvLvo9KIJBOdxP o3TuLid5BorrZw2XrN0+EMtG+qIHg2bmpu3VluHACbmSw8ldtv4zxejn9sH11VE/TM5K KfreKZDnC2hDDKIsbPAlnfPZwdyaKdAJmOg7c=
MIME-Version: 1.0
Received: by 10.50.197.167 with SMTP id iv7mr2746067igc.46.1323421538312; Fri, 09 Dec 2011 01:05:38 -0800 (PST)
Sender: yoshifumi.nishida@gmail.com
Received: by 10.42.240.74 with HTTP; Fri, 9 Dec 2011 01:05:38 -0800 (PST)
In-Reply-To: <CF340E42AED0874C81947E18863DE77B13340F715E@EXMB03.eu.tieto.com>
References: <20110916075854.4673.6360.idtracker@ietfa.amsl.com> <CABxaRLET3w_MhRtakjuA1Mc4sXd1-FpmorSgjK78K_6WjOX-Qg@mail.gmail.com> <CF340E42AED0874C81947E18863DE77B13340F715E@EXMB03.eu.tieto.com>
Date: Fri, 09 Dec 2011 01:05:38 -0800
X-Google-Sender-Auth: 6_vk4Fw7XgMnuK-P6pXBRpsQ6cI
Message-ID: <CABxaRLHFc5jin9tfjQxZV2SH-yMW80x0goe1QiOVSS7fynq_kA@mail.gmail.com>
Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Karen.Nielsen@tieto.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 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: Fri, 09 Dec 2011 09:05:39 -0000

Hi Karen, thanks for the comment.

I think PF is not aggressive on the point you mentioned. Please point
out if I miss something.
In RFC4960, retransmitted data packets are sent to the failed
destination address and it will contribute to the
Association.Max.Retrans.
In PF, HBs are sent to the failed destination address instead of data
packets. The interval of HBs for the destination is RTO, which will be
the same as those of the retransmitted packets.
So, I believe both approach will have similar results on the
robustness of the association error count.

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


2011/12/8  <Karen.Nielsen@tieto.com>:
> Hi,
>
> One additional comment to the draft.
> Not sure about whether it has been raised already though.
>
> The aggressive HBs sent on a potentially failed destination address should not contribute
> to the association overall error counter. I.e., a failed HB should not increment the associations error counter.
>
> At least that it how I firmly believe that things should be as the robustness of the
> association error count should not be impacted by the more aggressive HB probing
> (Also simply following the approach of RFC4960 Path Verification. 5.4 of RFC4960)
>
> Would it be possible to have this explicitly clarified in the draft ?
>
> Thanks.
> BR, Karen
>
> -----Original Message-----
> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Yoshifumi Nishida
> Sent: 16. september 2011 10:22
> To: tsvwg
> Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
>
> Hi folks,
>
> Based on the michael's review, we have updated the sctp failover draft.
> We believe we addressed the comments we got so far.
>
> Please let us know if we overlook something or if you have more comments.
>
> Thanks,
> --
> Yoshifumi Nishida
> nishida@sfc.wide.ad.jp
>
>
> 2011/9/16  <internet-drafts@ietf.org>:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>        Title           : Quick Failover Algorithm in SCTP
>>        Author(s)       : Yoshifumi Nishida
>>                          Preethi Natarajan
>>                          Armando Caro
>>        Filename        : draft-nishida-tsvwg-sctp-failover-04.txt
>>        Pages           : 16
>>        Date            : 2011-09-16
>>
>>   One of the major advantages in SCTP is supporting multi-homing
>>   communication.  If a multi-homed end-point has redundant network
>>   connections, SCTP sessions can have a good chance to survive from
>>   network failures by migrating inactive network to active one.
>>   However, if we follow the SCTP standard, there can be significant
>>   delay for the network migration.  During this migration period, SCTP
>>   cannot transmit much data to the destination.  This issue drastically
>>   impairs the usability of SCTP in some situations.  This memo
>>   describes the issue of SCTP failover mechanism and discuss its
>>   solutions which require minimal modification to the current standard.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-04.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-04.txt
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>