On 18.9.2015, at 23.58, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: >>>>>> * When responding to a multicast request over a multi-access medium, >>>>>> why is the randomization of the transmit time only a SHOULD? >>>>>> I would think that needs to be a MUST. > >> Therefore I consider it a SHOULD; certainly, _for some link layer_, you >> may want it a MUST, but in general, I think MUST increases >> implementation complexity more than it brings to the table. > Markus, I would tend to agree with Brian here. The cost to implementations > is negligible: since you are already buffering the outgoing datagram in > order to aggregate TLVs, adding a random delay to the flushing doesn't > cost you much at all.
Buffering is good implementation practise but _is not required_. Dealing with additional timer (and minimal extra memory usage) seem unneccessary to me. That said, if Brian insists it should be a MUST, I can change it, as implementations do what implementations will (=my minimal Python implementation will not do it in any case as not doing it does not break protocol and I know it will not have 1000+ nodes on a link or the world is definitely strange place). hnetd already has the delay. (The point I was trying to make about collisions is that _as long as one of 1000 unicasts goes through, the network eventually would converge_, and I am pretty sure they would, assuming the nodes are not 100% same location / same hardware+software.) Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
