Re: quick failover in SCTP

[Yoshifumi Nishida <[e-mail]>]

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