Re: quick failover in SCTP

[Preethi Natarajan <[e-mail]>]

Hello all,

A new version of the quick failover draft
(draft-nishida-tsvwg-sctp-failover-01) is now available at
http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-01.txt.

The failover algorithm details have been updated in Section 4.3 based on
feedback from TSVWG.

Please let us know if you have questions/comments.

Thanks,
Preethi

On 10/11/10 9:02 AM, "Preethi Natarajan" <[e-mail]> 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?
> 
>>>> * 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.
> 
>>>> 
>>>> * 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