Re: quick failover in SCTP

[Preethi Natarajan <[e-mail]>]

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.
 
The failover algorithm (Section 4.3) has been updated based on
comments/feedback from TSVWG.
 
Please let us know if you have questions/comments.

Thanks,
Preethi

On 10/11/10 10:01 AM, "Michael Tüxen" <[e-mail]>
wrote:

> Hi Preethi,
> 
> comments in-lne.
> 
> Best regards
> Michael
> 
> On Oct 11, 2010, at 6:02 PM, Preethi Natarajan wrote:
> 
>> Michael,
>> 
>> Thanks for the insightful comments/suggestions. Please see my responses
>> below.
>> 
>> 
>> On 10/9/10 5:34 AM, "Michael Tüxen" <[e-mail]>
>> wrote:
>> 
>>> On Oct 9, 2010, at 12:04 PM, Yoshifumi Nishida wrote:
>>> 
>>>> Hello Michael,
>>>> 
>>>> Thanks for your response.
>>>> 
>>>> 2010/10/8 Michael Tüxen <[e-mail]>:
>>>>> Hello Nishida-san,
>>>>> 
>>>>> 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 <= PMR) && (error counter > PFMR)
>>>>>    the path is potentially failed.
>>>>> Using PFMR = 0 is what you suggest, PFMR=PMR gives
>>>>> the old behavior.
>>>> 
>>>> 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 != 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==0 is the right choice, I guess.
>>> But I think PF is also very helpful in non-CMT scenarios.
>> 
>> Preethi: Good point. What you are suggesting is a tunable PFMR threshold
>> while the current draft always assumes PFMR=0, the most aggressive behavior.
>> I don't see how conservative PFMR values can be helpful but it may be a good
>> idea to have it just in case.
>> 
>> 
>>>>> * Specify that you start sending HBs when the path is
>>>>> PF. Explicitly allow PFHB.interval=0, which
>>>>> I think is a good choice. Maybe we can just remove PFHB.interval.
>>>> 
>>>> Hmm. Sorry. I might not quite follow this point.
>>>> Does PFHB.interval=0 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=0.
>>> 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=0.
>> 
>> Preethi: I agree. I don't think we need a PFHB.interval. In PF state, HBs
>> are sent once every RTO.
>> 
>> 
>>>>> * 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).
>> 
>> Preethi: Michael can you clarify this a bit? Looks like we want to confirm
>> the following -- apps can control only those HBs that get sent (or not sent)
>> during path failure. Apps do not have control over PF HBs; i.e., apps cannot
>> 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 potentially
> failed.
> 
> Does this clarify things?
>> 
>>>>> * Provide a way that applications are not bothered with
>>>>> state change notification related to PF when not explicitly
>>>>> subscribed.
>> 
>> Preethi: Good point. To clarify: when PF is on, apps will be notified only
>> about PF-to-failure and failure-to-active state changes. Apps will not be
>> notified about active-to-PF state change.
> Yes. This means that we can enable PF system wide without apps seeing
> any difference.
>> 
>>>>> 
>>>>> * Make clear what to do when all paths are PF.
>>>>> 
>>>>> * Make clear what to do when all paths are failed.
>>>>> 
>> 
>> Preethi: I agree with both points. We can clarify these in the draft.
>> 
>> Thanks,
>> Preethi
>> 
>> 
>