Re: [homenet] Brian Haberman's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Markus Stenberg <[e-mail]>]

On 18.9.2015, at 23.58, Juliusz Chroboczek <[e-mail]> 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