From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxx> Date: Thu, 20 Feb 2014 14:13:04 +0100 > In current implementation it is possible to reach PF state from unconfirmed. > We can interpret sctp-failover-02 in a way that PF state is meant to be reached > only from active state, in the end, this is when entering PF state makes sense. > Here are few quotes from sctp-failover-02, but regardless of these, same > understanding can be reached from whole section 5: > > Section 5.1, quickfailover guide: > "The PF state is an intermediate state between Active and Failed states." > > "Each time the T3-rtx timer expires on an active or idle > destination, the error counter of that destination address will > be incremented. When the value in the error counter exceeds > PFMR, the endpoint should mark the destination transport address as PF." > > There are several concrete reasons for such interpretation. For start, rfc4960 > does not take into concern quickfailover algorithm. Therefore, quickfailover > must comply to 4960. Point where this compliance can be argued is following > behavior: > When PF is entered, association overall error counter is incremented for each > missed HB. This is contradictory to rfc4960, as address, while in unconfirmed > state, is subjected to probing, and while it is probed, it should not increment > association overall error counter. This has as a consequence that we might end > up in situation in which we drop association due path failure on unconfirmed > address, in case we have wrong configuration in a way: > Association.Max.Retrans == Path.Max.Retrans. > > Another reason is that entering PF from unconfirmed will cause a loss of address > confirmed event when address is once (if) confirmed. This is fine from failover > guide point of view, but it is not consistent with behavior preceding failover > implementation and recommendation from 4960: > > 5.4. Path Verification > Whenever a path is confirmed, an indication MAY be given to the upper > layer. > > Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxx> Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
