DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=user-agent:date:subject:from:to:cc:message-id:thread-topic
 :thread-index:in-reply-to:mime-version:content-type
 :content-transfer-encoding;
 b=eyYi/tZ8n6yfPThJ069xFPunFSOHL+JfR2fw3gmchKN76lzf19GxItJiMNU36OYcj2
 Qp3oMokhec08hiQBXb0PHHlPHMmTq3/zKxJvU0eXn+HXkbPt7U+YPRqFLffIDBJm8G27
 iNY4qF8T+UjAgGDWehOt8tfwd+tTIW44GMLYQ=
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Fri, 10 Dec 2010 08:31:34 -0800
Subject: Re: quick failover in SCTP
From: Preethi Natarajan <preethi.cis@gmail.com>
To: Michael =?ISO-8859-1?B?VPx4ZW4=?= <Michael.Tuexen@lurchi.franken.de>,
 <tsvwg@ietf.org>
Message-ID: <C92795E6.B4C4%preethi.cis@gmail.com>
Thread-Topic: quick failover in SCTP
Thread-Index: AcuYh7VOqsxNYn1pSU6kV9xX/Jl6ow==
In-Reply-To: <73957417-9AE7-4C7E-A042-BC29033E9865@lurchi.franken.de>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Precedence: list

Hello all,

A new version of the quick failover draft
(draft-nishida-tsvwg-sctp-failover-02) is now available at
http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-02.txt.
=20
The failover algorithm (Section 4.3) has been updated based on
comments/feedback from TSVWG.
=20
Please let us know if you have questions/comments.

Thanks,
Preethi

On 10/11/10 10:01 AM, "Michael T=FCxen" <Michael.Tuexen@lurchi.franken.de>
wrote:

> Hi Preethi,
>=20
> comments in-lne.
>=20
> Best regards
> Michael
>=20
> On Oct 11, 2010, at 6:02 PM, Preethi Natarajan wrote:
>=20
>> Michael,
>>=20
>> Thanks for the insightful comments/suggestions. Please see my responses
>> below.
>>=20
>>=20
>> On 10/9/10 5:34 AM, "Michael T=FCxen" <Michael.Tuexen@lurchi.franken.de>
>> wrote:
>>=20
>>> On Oct 9, 2010, at 12:04 PM, Yoshifumi Nishida wrote:
>>>=20
>>>> Hello Michael,
>>>>=20
>>>> Thanks for your response.
>>>>=20
>>>> 2010/10/8 Michael T=FCxen <Michael.Tuexen@lurchi.franken.de>:
>>>>> Hello Nishida-san,
>>>>>=20
>>>>> OK, I thought about this some time and think it would be good
>>>>> to specify a way for a quick failover which can be implemented
>>>>> at the sender only.
>>>>> I would like to see some extensions to you suggestion:
>>>>> * Introduce a threshold (call it PFMR for now).
>>>>> Then use
>>>>> if (error counter > PMR)
>>>>>    the path is inactive.
>>>>> if (error counter <=3D PMR) && (error counter > PFMR)
>>>>>    the path is potentially failed.
>>>>> Using PFMR =3D 0 is what you suggest, PFMR=3DPMR gives
>>>>> the old behavior.
>>>>=20
>>>> I thought similar thing and I agree with providing a way to disable PF=
.
>>>> I tend to agree with this idea, but one thing I'm not very sure is how
>>>> PFMR !=3D 0 && PFMR < PMR can be useful.
>>> I could image someone wanting to call a path potentially failed
>>> after 2 consecutive timer based retransmission instead of 1.
>>> Just being a bit more conservative. This might help deploying
>>> such a feature in SIGTRAN networks where CMT is not deployed.
>>> For CMT traffic, PFMR=3D=3D0 is the right choice, I guess.
>>> But I think PF is also very helpful in non-CMT scenarios.
>>=20
>> Preethi: Good point. What you are suggesting is a tunable PFMR threshold
>> while the current draft always assumes PFMR=3D0, the most aggressive behav=
ior.
>> I don't see how conservative PFMR values can be helpful but it may be a =
good
>> idea to have it just in case.
>>=20
>>=20
>>>>> * Specify that you start sending HBs when the path is
>>>>> PF. Explicitly allow PFHB.interval=3D0, which
>>>>> I think is a good choice. Maybe we can just remove PFHB.interval.
>>>>=20
>>>> Hmm. Sorry. I might not quite follow this point.
>>>> Does PFHB.interval=3D0 mean suppress sending HB during PF state?
>>> No. I mean just to send them every RTO.
>>> Having a specific interval allows this by setting PFHB.interval=3D0.
>>> I was just thinking whether one can remove the parameter and send
>>> the HB every RTO (and doubling it)... The same as using PFHB.interval=3D0=
.
>>=20
>> Preethi: I agree. I don't think we need a PFHB.interval. In PF state, HB=
s
>> are sent once every RTO.
>>=20
>>=20
>>>>> * Make sure that the following works: The application disabled HBs.
>>>>> When a path enters PF (or failed) HB are sent to get the path
>>>>> active again. If it is active, no HB should be send (since
>>>>> the application disables them).
>>=20
>> Preethi: Michael can you clarify this a bit? Looks like we want to confi=
rm
>> the following -- apps can control only those HBs that get sent (or not s=
ent)
>> during path failure. Apps do not have control over PF HBs; i.e., apps ca=
nnot
>> enable/disable PF HBs. Is that right?
> The socket API allows to configure the HB.interval and to enable/disable
> HBs at all. What I suggest is the no matter if the HB are disabled, they
> are sent for
> * initial path verification (not within the scope of your ID, but noted
>   to make things clear)
> * getting a path out of potentially failed or failed.
> In other words: If the application disables HBs, it only enables the
> ones which do path supervision when the path is active and not potentiall=
y
> failed.
>=20
> Does this clarify things?
>>=20
>>>>> * Provide a way that applications are not bothered with
>>>>> state change notification related to PF when not explicitly
>>>>> subscribed.
>>=20
>> Preethi: Good point. To clarify: when PF is on, apps will be notified on=
ly
>> about PF-to-failure and failure-to-active state changes. Apps will not b=
e
>> notified about active-to-PF state change.
> Yes. This means that we can enable PF system wide without apps seeing
> any difference.
>>=20
>>>>>=20
>>>>> * Make clear what to do when all paths are PF.
>>>>>=20
>>>>> * Make clear what to do when all paths are failed.
>>>>>=20
>>=20
>> Preethi: I agree with both points. We can clarify these in the draft.
>>=20
>> Thanks,
>> Preethi
>>=20
>>=20
>=20