In my previous mails, I used the term "persistent state desynchronisation". Since this apparently worried some people, so I guess I'll explain.
DNCP uses dynamic timers (Trickle) to flood a hash of the global state and separate unicast request/response pairs to propagate actual data. Bad things will happen if the hash is successfully flooded but the data cannot be propagated, for example because it doesn't fit in the maximum packet size, because a node is not publishing enough NEIGHBOR TLVs, or because of implementation bugs. More precisely, under such circumstances each attempt to flood the inconsistent network hash is followed with a flurry of request/response pairs and a reset of the Trickle timers to their minimal value (200ms). The result is persistent spam. Therefore, (1) we must make sure that a compliant implementation does not cause state to become persistently inconsistent, and (2) we should develop some mechanism that detects persistently desynchronised neighbours and rate-limits them. (1) needs to go in the spec, while (2) is a "mere" implementation detail. -- Juilusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
