Re: quick failover in SCTP

[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.

* 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.

* 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]
>>> 
>>> 
>>> 
>> 
>