MIME-Version: 1.0
Sender: alcortesm.uc3m@gmail.com
In-Reply-To: <CABxaRLHFc5jin9tfjQxZV2SH-yMW80x0goe1QiOVSS7fynq_kA@mail.gmail.com>
References: <20110916075854.4673.6360.idtracker@ietfa.amsl.com>
 <CABxaRLET3w_MhRtakjuA1Mc4sXd1-FpmorSgjK78K_6WjOX-Qg@mail.gmail.com>
 <CF340E42AED0874C81947E18863DE77B13340F715E@EXMB03.eu.tieto.com>
 <CABxaRLHFc5jin9tfjQxZV2SH-yMW80x0goe1QiOVSS7fynq_kA@mail.gmail.com>
From: =?UTF-8?Q?Alberto_Cort=C3=A9s?= <alcortes@it.uc3m.es>
Date: Fri, 9 Dec 2011 13:51:21 +0100
Message-ID: <CAGK4rN=SjvJ4o70hEFKGNeSU=L1ZzS46F_6Oh0Nbnoa46gOCHQ@mail.gmail.com>
Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Karen.Nielsen@tieto.com, tsvwg@ietf.org
Precedence: list

On Fri, Dec 9, 2011 at 10:05 AM, Yoshifumi Nishida
<nishida@sfc.wide.ad.jp> wrote:
> 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.

I would like to point out that in RFC4960, retransmissions SHOULD be
sent to a different address than the one that failed (section 6.4),
and as far as I know, that's generally the case in all
implementations.

The probing of the failed address is performed by fresh, new
transmissions, not by retransmissions.


> 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 =C2=A0<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 shou=
ld not contribute
>> to the association overall error counter. I.e., a failed HB should not i=
ncrement the associations error counter.
>>
>> At least that it how I firmly believe that things should be as the robus=
tness 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 O=
f 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 =C2=A0<internet-drafts@ietf.org>:
>>> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
>>>
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Q=
uick Failover Algorithm in SCTP
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Yoshifumi N=
ishida
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Preethi Natarajan
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Armando Caro
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-=
nishida-tsvwg-sctp-failover-04.txt
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 1=
6
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 2011-09-16
>>>
>>> =C2=A0 One of the major advantages in SCTP is supporting multi-homing
>>> =C2=A0 communication. =C2=A0If a multi-homed end-point has redundant ne=
twork
>>> =C2=A0 connections, SCTP sessions can have a good chance to survive fro=
m
>>> =C2=A0 network failures by migrating inactive network to active one.
>>> =C2=A0 However, if we follow the SCTP standard, there can be significan=
t
>>> =C2=A0 delay for the network migration. =C2=A0During this migration per=
iod, SCTP
>>> =C2=A0 cannot transmit much data to the destination. =C2=A0This issue d=
rastically
>>> =C2=A0 impairs the usability of SCTP in some situations. =C2=A0This mem=
o
>>> =C2=A0 describes the issue of SCTP failover mechanism and discuss its
>>> =C2=A0 solutions which require minimal modification to the current stan=
dard.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-0=
4.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
>>>



--=20
Alberto Cort=C3=A9s-Mart=C3=ADn
Telematic Engineering Dept. at UC3M
http://www.it.uc3m.es/alcortes/index.html