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

[Yoshifumi Nishida <[e-mail]>]

Hi Karen,

2011/12/9  <[e-mail]>:
> Hi,
>
> Please accept the follow up below.
>
>
> Hi Karen, thanks for the comment.
>
> I think PF is not aggressive on the point you mentioned. Please point
> out if I miss something.
> In RFC4960, retransmitted data packets are sent to the failed
> destination address and it will contribute to the
> Association.Max.Retrans.
>
> [Karen] In RFC4960 retransmitted packets will be send to most divergent path. Not to the PF path. But I suppose that you mean that as new data continues to be send on "PF" path in RFC4960, then the association error count will be hurt by the failure of these like it may be hurt
> by the failure of the aggressive HBs.

Sorry, that's what I meant. Thanks for the correction.

> In PF, HBs are sent to the failed destination address instead of data
> packets. The interval of HBs for the destination is RTO, which will be
> the same as those of the retransmitted packets.
> So, I believe both approach will have similar results on the
> robustness of the association error count.
>
> [Karen] I agree for the case where there continuously is data flowing.
> But when there is not such data, then the aggressive HBs will impact the robustness of
> the association error count as there is no successful data that will reset it, as the successful retransmissions of data would.

Hmm. I see your point. In case where all path's status are active, but
somehow all of them become unavailable and one packet is sent. PF can
aggressively increase error count than RFC4960.. I would like to think
about how bad this is more.

>
> Generally, I have never understood why the faith of HBs should EVER contribute to the
> association error counter, EXCEPT when in idle state. And in this case, then in my opinion,
> it would suffice if it was the HBs on the primary path which were allowed to contribute to the association error counter. Indeed the association error counter is not there to ascertain whether all paths are available, only it should be there to ascertain whether some path of the association is available. In that respect HBs on non working (auxiliary) paths impacts the robustness of the association error counter.

It might be an interesting point. But, I'm not sure how much impact
this has. To make this effective, we need to presume the case where
all paths become unavailable, but at least one path comes back within
a certain amount of time. If this duration is too long or too short,
there'll be no difference even if we exclude HB's contributions. In
case of RFC4960, HB's contribution seems to be minor to me.

Thanks,
--
Yoshifumi Nishida
[e-mail]