Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt

[Yoshifumi Nishida <[e-mail]>]

Hi Karen,

2011/12/15  <[e-mail]>:
> Hi Nishida,
>
> One more follow up, second thoughts :-)
>
> I still believe that the aggressive HBs of the potentially failed feature SHOULD NOT contribute
> to the association error counter.
>
> One reason is the discussed situation when no data is flowing.
> But actually also in the case where data IS flowing may the aggressive HBs
> have impact on the robustness of the association error counter. Indeed if data retransmissions
> fail on other paths (while locating a new working data transmission path) due to
> failure of other paths or simply due to random packet drops, the fact that we may have
> aggressive step up of the association error counter due to the aggressive HB on the
> potentially failed path does impact the robustness of the association error counter.
>
> I would encourage for the aggressive HBs to be prescribed not to impact the association error counter.

Is it possible for you to give me some sample scenarios?
I would like to think how bad this is more precisely.

> I also (again) do believe that it is questionable in general why HBs sent
> on anything but towards the primary destination address should contribute
> to the association error counter. But that is a general issue relevant to the
> base spec, not to this spec.

I agree that this needs to go rfc4960, while I'm still not very sure
how this is effective.
In some cases, you might want to terminate association smoothly if
there's no available connections in order to save resources.
In case where you want to keep associations robust, I think you can do
it by increasing asoc.max.retr or increasing HB.interval or disabling
HB.

Thanks,
--
Yoshifumi Nishida
[e-mail]