Re: quick failover in SCTP

[Yoshifumi Nishida <[e-mail]>]

Hello Michael,

Thanks for the clarification.

2010/10/9 Michael Tüxen <[e-mail]>:
> 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.
>>
>> Great!
>> Please check my comments bellow.
>>
>>> 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.

OK. I think it would be good to have tunable parameter for users. I
agree with this.

>> If we just want a switch to disable PF, having USE_PF parameter might be enough?
>> May be Preethi has an opinion on this?
>>
>>> * 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.

I see. My main motivation here is not to use HB.interval since it's
usually rather big value.
So, using RTO is fine for me.
However, I think there might be useful case for PFHB.interval. (e.g.
all paths have mostly the same bandwidth and priority)
I prefer to keep tunable parameter here while recommended behavior is using RTO.

Thanks,
--
Yoshifumi Nishida
[e-mail]

> Best regards
> Michael
>>
>>
>> I agree with all of the following points. I think these are very good points.
>>
>>> * 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).
>>>
>>> * Provide a way that applications are not bothered with
>>>  state change notification related to PF when not explicitly
>>>  subscribed.
>>>
>>> * Make clear what to do when all paths are PF.
>>>
>>> * Make clear what to do when all paths are failed.
>>>
>>> What do you think?
>>>
>>> Best regards
>>> Michael
>>>
>>> On Aug 24, 2010, at 12:04 PM, Yoshifumi Nishida wrote:
>>>
>>>> Hello Michael,
>>>>
>>>> Thanks for your reply. In a nutshell, the difference between PF and PMR=0 are:
>>>>   PF allows SCTP to use another path while SCTP is checking the
>>>> primary path is active or inactive, but don't change the behavior of
>>>> marking the path as inactive.
>>>>   PMR=0 allows SCTP to mark the primary as inactive quickly.
>>>>
>>>> In my feeling, this will create several differences although it looks similar
>>>>
>>>> For example, if we use PMR=0, we will need to modify at least the
>>>> following points in the RFC4960
>>>>   1) recommended value for PMR
>>>>   2) behavior in dormant state
>>>>   3) relationship between PMR and AMR
>>>>        RFC4960 states users should avoid having the value of
>>>> 'Association.Max.Retrans' larger than the
>>>>        summation of the 'Path.Max.Retrans'  we'll need to change this part.
>>>>
>>>> Also, I think we'll need to think about the following points
>>>>   a) Some of current applications or OS local configurations might
>>>> already have specified PMR on their own. If they're not using PMR=0,
>>>> their benefit might be reduced.
>>>>   b) When you have 100Mbps and 1Mbps links and you set 100Mbps as
>>>> primary, everytime packet loss happens on the 100Mbps link, it will
>>>> switch over to the 1Mbps link and have to wait for HeartBeat which is
>>>> likely less frequent (30secs or so). Or, you'll need to add special
>>>> logic here in the spec.
>>>>
>>>> If we use PF,
>>>>   PF allows SCTP to keep PMR and AMR unchange. Hence, we don't have
>>>> to modify 1) and 3).
>>>>       and issue 2) will be a minor point since we don't change PMR and AMR.
>>>>   Also, PF already has a solution for b) as described in the draft.
>>>>
>>>> In my view, PMR=0 will requires several "modifications" to the spec
>>>> which might be a bit tricky to understand for implementers while PF
>>>> will requires explicit "addition".
>>>>
>>>> Thanks,
>>>> --
>>>> Yoshifumi Nishida
>>>> [e-mail]
>>>>
>>>>
>>>> 2010/8/23 Michael Tüxen <[e-mail]>
>>>>>
>>>>> On Aug 17, 2010, at 12:16 PM, Yoshifumi Nishida wrote:
>>>>>
>>>>>> Hi folks,
>>>>>> This is a follow-up from the Maastricht meeting.
>>>>>> Preethi and I are proposing quick failover algorithm in SCTP and gave a presentation about this one.
>>>>>>
>>>>>> In my feeling, the community seems to be positive in enhancing the SCTP standard to some extent to address this issue.
>>>>>> Also, in my understanding, Michael and Randy suggested that minor updates in the current spec can have the similar effects as the PF approach can do.
>>>>>> So,  we're going to start with investigating the alternatives for PF approach and would like to know about the detail of the suggestion.
>>>>>> If Michael and Randy could give us some info about this, we would be grateful very much.
>>>>> Sure.
>>>>> One point is that RFC 4960 does not specify what to do when all paths
>>>>> are INACTIVE. If that happens, the association is called dormant.
>>>>> I think it should be clarified that you still send HB to get a path
>>>>> to ACTIVE again until the association finally fails. This could be
>>>>> handled as an errata, I think.
>>>>>
>>>>> Now assume that handling of the dormant state.  If I understand PF correctly,
>>>>> you could simply set Path.Max.Retrans to 0 to get the same behavior on the
>>>>> wire as when using PF, or am I missing something? The only difference I see,
>>>>> are the path state change notification sent locally to the user.
>>>>>
>>>>> But maybe I have overlooked something...
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>> Also, if someone who has comments or feedbacks for this, please let us know.
>>>>>>
>>>>>> Thank you so much.
>>>>>> --
>>>>>> Yoshifumi Nishida
>>>>>> [e-mail]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>