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

From: "Brian Haberman" <[email-masked]>
Date: Tue, 15 Sep 2015 07:02:20 -0700

Brian Haberman has entered the following ballot position for
draft-ietf-homenet-dncp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have no objections to the publication of this document, but I do have a
couple of points that I want to discuss...

* The spec says that all TLVs are transmitted every time any value in the
TLV set changes. Section 1 says that a delta synchronization scheme is
not defined.  What is the justification for not using a delta
synchronization approach?  The ordering of the TLVs needed to compute the
hash can be done at the receiver and a delta approach would minimize
bandwidth consumption.  I think it would be useful to provide some
justification in the spec for the design decision made to not use a delta
synchronization approach.

* Section 4.4 says that all responses are sent unicast, even for requests
received via multicast over a multi-access medium. Was consideration
given to use multicast responses and supporting message suppression on
other nodes? Or, was the design decision made to ensure that all nodes
responded with their TLV set to the requester?  Either approach may be
reasonable, but there is no justification given.

* 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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. I think the mention of the trickle variable 'k' in section 1 is
gratuitous and causes confusion.

2. Why does this document say (section 7) that the hash function is
non-cryptographic?  Shouldn't that be determined by each profile?

---

From: Steven Barth <[email-masked]>
Date: Tue, 15 Sep 2015 18:52:18 +0200

Hello Brian,

thank you for your feedback.

Delta synchronization was mainly omitted due to our intended goal of
focusing on optimizing for simplicity and only infrequent and potentially
larger (in relation to the whole dataset) state changes as noted in 1.1.
Applicability. It is therefore not in the base draft, however it should
not be too difficult for a DNCP-based protocol that is in need of such a
feature (e.g. due to it being "on the edge" of DNCPs applicability) to add
it as an extension.

> reasonable, but there is no justification given.

There are multiple factors involved here. One important issue is that
securing these multicast transactions is difficult and I don't even know
if there is a standardized and deployed way to do this e.g. using (D)TLS
that we use for unicast. This is slightly touched in 4.2. Data Transport
and 10. Security Considerations.

Another reason is that on some link types - such as Wifi - multicast
transmissions can be disadvantageous and reducing their number can be
beneficial in many cases.

> is the randomization of the transmit time only a SHOULD?  I would think

I think this more or less depends on the type of link and its characteristics
and the current state, so I'm not sure if a MUST is necessary in all cases.

Since the meaning does not really suffer we can simply remove
the bracket "(ideally with k < 2)" if that makes it less confusing.

> non-cryptographic?  Shouldn't that be determined by each profile?

The intended meaning was really "not necessarily cryptographic",
we might just remove the word "non-cryptographic" in that section if
that makes it more apparent. 9. DNCP Profile-Specific Definitions provides
some guidance on the choice of functions already and indicates that it can
be either.

Regards,

Steven

---

From: Brian Haberman <[email-masked]>
Date: Tue, 15 Sep 2015 13:24:23 -0400

Hi Steven,

> feature (e.g. due to it being "on the edge" of DNCPs applicability) to add

My point above comes from this in section 1.1:

   Another consideration is the size of the published TLV set by a node
   compared to the size of deltas in the TLV set.  If the TLV set
   published by a node is very large, and has frequent small changes,
   DNCP as currently specified may be unsuitable since it does not
   define any delta synchronization scheme but always transmits the
   complete updated TLV set verbatim.

The tradeoffs here really focus on the whether those "frequent small
changes" are isolated to 1 or 2 TLVs or are spread out across all the
TLVs.  I don't think there is any concrete statement that can be made in
this document as to where the inflection point is in this decision.

It seems to me that the justification for not doing delta updates is
really just simplicity in implementation.  That is a perfectly fine
reason in my opinion.  I think the hand waving around the above and the
computation of A_NC_I really don't provide useful justification.

> and 10. Security Considerations.

Depends on what you mean by securing them.  Is there really a need to
provide confidentiality?  It seems like the necessary security functions
are integrity and authentication. Given that, multicast responses are
quite feasible.  But, that really doesn't address my question...

There are useful benefits to multicast responses, one primary one being
that everyone who receives the multicast response can update their state
for the sending node.  On the flip side, a unicast response forces all
nodes to respond and provide their TLV sets.

The problem is that these benefits seem better suited for the profile
documents that use DNCP.  I don't see the need to pick one response
method over another in this base specification.

> beneficial in many cases.

Agreed, but with infrequent TLV changes, this cost is minimized.  So, I
don't see the need to specify a fixed approach in this document.

> and the current state, so I'm not sure if a MUST is necessary in all cases.

Multicast-based implosion is a problem.  If implementations ignore the
SHOULD, you run a very real risk of overloading the request sender with
unicast responses.  If the WG is not willing to make this a MUST, the
spec should clearly spell out the potential of amplification attacks
using this protocol.

> the bracket "(ideally with k < 2)" if that makes it less confusing.

Makes sense.

> some guidance on the choice of functions already and indicates that it can

I think dropping "non-cryptographic" is perfectly reasonable and leaves
the decision up to the profile developers.

Regards,
Brian

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Sep 2015 21:45:45 +0300

On 15.9.2015, at 20.24, Brian Haberman <[email-masked]> wrote:
> computation of A_NC_I really don’t provide useful justification.

A_NC_I calculation does not depend on how you synchronize things (full state dump <> delta). It is mostly about value <> cost of having Trickle, as opposed to fixed timers.

What would you propose then?

> quite feasible.  But, that really doesn’t address my question...

Yes, on insecure links, c.f. HNCP document, we transmit PSK for other protocols there.

(And yes, we could also specify this in the HNCP’s profile; however, the more abstract we make the DNCP itself, the less reusable it is if all operating constraints are actually specified in a profile.)

> method over another in this base specification.

I guess this boils down to how many options we want to leave open; certainly, this is (yet another) thing that could be left to profiles.

> spec should clearly spell out the potential of amplification attacks

I am not sure what you mean by this, as I cannot really see it; in _some applications_ on _some links_ perhaps, with bad implementations _without rate limiting_ (that is stated that is acceptable for about anything in the message processing flow).

As specified, the _only_ multicast TLV that MUST be responded is the Network State TLV, and those replies MUST be rate limited already.

How many more MUSTs should we stick here? Whether you rate limit it to one response per time interval (current), or mandatory delay (what I guess you propose), I do not think it makes much of a difference.

That said, if we go with your proposal to allow for multicast response with multiple types to be the MUST path, then this needs to be reconsidered. The original design _was_ to minimize the amount of multicast, and for that the SHOULD delay (+ MUST rate limit replies in general) seems sufficient to me.

Cheers,

-Markus

---

From: Brian Haberman <[email-masked]>
Date: Tue, 15 Sep 2015 15:10:34 -0400

On 9/15/15 2:45 PM, Markus Stenberg wrote:
>>> Hello Brian, thank you for your feedback.
>>> 
>>>> * The spec says that all TLVs are transmitted every time any
>>>> value in the TLV set changes. Section 1 says that a delta
>>>> synchronization scheme is not defined.  What is the
>>>> justification for not using a delta synchronization approach?
>>>> The ordering of the TLVs needed to compute the hash can be done
>>>> at the receiver and a delta approach would minimize bandwidth
>>>> consumption.  I think it would be useful to provide some 
>>>> justification in the spec for the design decision made to not
>>>> use a delta synchronization approach.
>>> 
>>> Delta synchronization was mainly omitted due to our intended goal
>>> of focusing on optimizing for simplicity and only infrequent and
>>> potentially larger (in relation to the whole dataset) state
>>> changes as noted in 1.1. Applicability. It is therefore not in
>>> the base draft, however it should not be too difficult for a
>>> DNCP-based protocol that is in need of such a feature (e.g. due
>>> to it being "on the edge" of DNCPs applicability) to add it as an
>>> extension.
>> Another consideration is the size of the published TLV set by a
>> node compared to the size of deltas in the TLV set.  If the TLV
>> set published by a node is very large, and has frequent small
>> changes, DNCP as currently specified may be unsuitable since it
>> does not define any delta synchronization scheme but always
>> transmits the complete updated TLV set verbatim.
>> 
>> The tradeoffs here really focus on the whether those "frequent
>> small changes" are isolated to 1 or 2 TLVs or are spread out across
>> all the TLVs.  I don't think there is any concrete statement that
>> can be made in this document as to where the inflection point is in
>> this decision.
>> 
>> It seems to me that the justification for not doing delta updates
>> is really just simplicity in implementation.  That is a perfectly
>> fine reason in my opinion.  I think the hand waving around the
>> above and the computation of A_NC_I really don’t provide useful
>> justification.
> 
> A_NC_I calculation does not depend on how you synchronize things
> (full state dump <> delta). It is mostly about value <> cost of
> having Trickle, as opposed to fixed timers.
> 

My proposal is based on the observation that the design decisions made
appear to be really grounded in simplicity of implementation.  And, to
me, that is perfectly fine.  I think the discussion of justification in
the Applicability section should simply focus on that simplicity and not
theoretical arguments about relationships between various variables.  If
this were a full-blown protocol specification (e.g., an actual profile
spec), I would expect more focused justification.

> 
>>>> * Section 4.4 says that all responses are sent unicast, even
>>>> for requests received via multicast over a multi-access medium.
>>>> Was consideration given to use multicast responses and
>>>> supporting message suppression on other nodes? Or, was the
>>>> design decision made to ensure that all nodes responded with
>>>> their TLV set to the requester?  Either approach may be 
>>> There are multiple factors involved here. One important issue is
>>> that securing these multicast transactions is difficult and I
>>> don't even know if there is a standardized and deployed way to do
>>> this e.g. using (D)TLS that we use for unicast. This is slightly
>>> touched in 4.2. Data Transport and 10. Security Considerations.
>> Depends on what you mean by securing them.  Is there really a need
>> to provide confidentiality?  It seems like the necessary security
>> functions are integrity and authentication. Given that, multicast
>> responses are quite feasible.  But, that really doesn’t address my
>> question...
> 
> (And yes, we could also specify this in the HNCP’s profile; however,
> the more abstract we make the DNCP itself, the less reusable it is if
> all operating constraints are actually specified in a profile.)
> 
>> There are useful benefits to multicast responses, one primary one
>> being that everyone who receives the multicast response can update
>> their state for the sending node.  On the flip side, a unicast
>> response forces all nodes to respond and provide their TLV sets.
>> 
>> The problem is that these benefits seem better suited for the
>> profile documents that use DNCP.  I don't see the need to pick one
>> response method over another in this base specification.
> 
> I guess this boils down to how many options we want to leave open;
> certainly, this is (yet another) thing that could be left to
> profiles.

Actually, your earlier response about DNCP carrying PSK for other
protocols is a fine justification for needing encryption and there not
being a viable multicast security mechanism to use in such cases.
Perhaps all you need is a statement in 4.4 that says that DNCP
instantiations may carry sensitive information for other protocols and
unicast-based security mechanisms are necessary to ensure confidentiality.

> 
>>>> * 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.
>>> I think this more or less depends on the type of link and its
>>> characteristics and the current state, so I'm not sure if a MUST
>>> is necessary in all cases.
>> Multicast-based implosion is a problem.  If implementations ignore
>> the SHOULD, you run a very real risk of overloading the request
>> sender with unicast responses.  If the WG is not willing to make
>> this a MUST, the spec should clearly spell out the potential of
>> amplification attacks using this protocol.
> 
> I am not sure what you mean by this, as I cannot really see it; in
> _some applications_ on _some links_ perhaps, with bad implementations
> _without rate limiting_ (that is stated that is acceptable for about
> anything in the message processing flow).
> 
> As specified, the _only_ multicast TLV that MUST be responded is the
> Network State TLV, and those replies MUST be rate limited already.

I don't think that is true based on this statement in the draft:

   However, an
   implementation MUST eventually reply to similar repeated requests, as
   otherwise state synchronization breaks.

Does that not apply to any TLV sent via multicast?

> 
> How many more MUSTs should we stick here? Whether you rate limit it
> to one response per time interval (current), or mandatory delay (what
> I guess you propose), I do not think it makes much of a difference.
> 
> That said, if we go with your proposal to allow for multicast
> response with multiple types to be the MUST path, then this needs to
> be reconsidered. The original design _was_ to minimize the amount of
> multicast, and for that the SHOULD delay (+ MUST rate limit replies
> in general) seems sufficient to me.

I think we are talking about different things.  I am wondering why the
randomization of response transmission *to multicasted requests* is only
a SHOULD and not a MUST.  Amplification attacks can be (and have been)
launched by sending multicast messages that result in a large number of
unicast responses hitting the source IP address of the request.

Let me ask my question a different way... Can you provide an example of
where nodes that receive a DNCP request via multicast should not
randomize the transmit time of their responses?

Regards,
Brian

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Sep 2015 23:00:58 +0300

> spec), I would expect more focused justification.

Hmm. T. Clausen review told us that we should essentially describe what this is good for; that calculation explains where it is applicable. We got push-back from some other reviewers where we used less exact terms like ’small to medium sized networks of nodes with low amount of change’ in some iteration of the document (’small’? ‘medium’? ‘low’?). We even got asked for explicitly writing out intervals to the introduction of an abstract protocol earlier..

’simple to implement’ (or ’not complex to implement’) could be added there to the delta part though.

> unicast-based security mechanisms are necessary to ensure confidentiality.

Section 4.2?

   As multicast is used only to identify potential new DNCP
   nodes and to send status messages which merely notify that a unicast
   exchange should be triggered, the multicast transport does not have
   to be secured.  If unicast security is desired and one of the built-
   in security methods is to be used, support for some TLS-derived
   transport scheme - such as TLS [RFC5246] on top of TCP or DTLS
   [RFC6347] on top of UDP - is also required. 

> Does that not apply to any TLV sent via multicast?

Depends on profile (see section 9).

I wonder how this should be rephrased to make it more clear; as what DNCP spec _says_ essentially that only mandatory to send/receive multicast TLV is the Network State TLV (+ associated Node Endpoint TLV), and everything else comes from the unicast reply sequences stemming from there.

Receiving other TLVs via multicast is allowed but they are not explicitly generated by the default processing flow, and the section 9 describes which multicast TLVs can be explicitly ignored in a profile without breaking DNCP synchronization mechanism, and it turns out to be all of them except for the two noted above.

They were left as options to allow e.g. sending multicast Node State TLVs _with data_ in profiles where confidentiality of the data does not matter.

> randomize the transmit time of their responses?

Simple implementation[1] with a super paranoid profile (handles only those two above multicast TLVs) with the mandatory MUST ratelimit Request Network State TLVs.

It does not really matter if it sends the one reply per link per Trickle interval either immediately or after delay for most part (barring some crippled link layers). 

Cheers,

-Markus

[1] ~500 LoC of Python for ‘full’ minimal DNCP implementation with HNCP-ish transport profile (which does not have any frilly bits) that I use for my home automation :)

---

From: Brian Haberman <[email-masked]>
Date: Wed, 16 Sep 2015 11:39:50 -0400

On 9/15/15 4:00 PM, Markus Stenberg wrote:
>> My proposal is based on the observation that the design decisions
>> made appear to be really grounded in simplicity of implementation.
>> And, to me, that is perfectly fine.  I think the discussion of
>> justification in the Applicability section should simply focus on
>> that simplicity and not theoretical arguments about relationships
>> between various variables.  If this were a full-blown protocol
>> specification (e.g., an actual profile spec), I would expect more
>> focused justification.
> 
> Hmm. T. Clausen review told us that we should essentially describe
> what this is good for; that calculation explains where it is
> applicable. We got push-back from some other reviewers where we used
> less exact terms like ’small to medium sized networks of nodes with
> low amount of change’ in some iteration of the document (’small’?
> ‘medium’? ‘low’?). We even got asked for explicitly writing out
> intervals to the introduction of an abstract protocol earlier..

So, this may turn into more of an IESG-based discussion.  Given the
generalities introduced by this "abstract protocol specification", I
think it will be useful for the IESG to work this out.

> there to the delta part though.

IMO, it wouldn't hurt.

> 
>>>>>> * Section 4.4 says that all responses are sent unicast,
>>>>>> even for requests received via multicast over a
>>>>>> multi-access medium. Was consideration given to use
>>>>>> multicast responses and supporting message suppression on
>>>>>> other nodes? Or, was the design decision made to ensure
>>>>>> that all nodes responded with their TLV set to the
>>>>>> requester?  Either approach may be reasonable, but there is
>>>>>> no justification given.
>>>>> There are multiple factors involved here. One important issue
>>>>> is that securing these multicast transactions is difficult
>>>>> and I don't even know if there is a standardized and deployed
>>>>> way to do this e.g. using (D)TLS that we use for unicast.
>>>>> This is slightly touched in 4.2. Data Transport and 10.
>>>>> Security Considerations.
>>>> Depends on what you mean by securing them.  Is there really a
>>>> need to provide confidentiality?  It seems like the necessary
>>>> security functions are integrity and authentication. Given
>>>> that, multicast responses are quite feasible.  But, that really
>>>> doesn’t address my question...
>>> 
>>> (And yes, we could also specify this in the HNCP’s profile;
>>> however, the more abstract we make the DNCP itself, the less
>>> reusable it is if all operating constraints are actually
>>> specified in a profile.)
>>> 
>>>> There are useful benefits to multicast responses, one primary
>>>> one being that everyone who receives the multicast response can
>>>> update their state for the sending node.  On the flip side, a
>>>> unicast response forces all nodes to respond and provide their
>>>> TLV sets.
>>>> 
>>>> profile documents that use DNCP.  I don't see the need to pick
>>>> one response method over another in this base specification.
>>> 
>>> I guess this boils down to how many options we want to leave
>>> open; certainly, this is (yet another) thing that could be left
>>> to profiles.
>> 
>> protocols is a fine justification for needing encryption and there
>> not being a viable multicast security mechanism to use in such
>> cases. Perhaps all you need is a statement in 4.4 that says that
>> DNCP instantiations may carry sensitive information for other
>> protocols and unicast-based security mechanisms are necessary to
>> ensure confidentiality.
> 
> Section 4.2?

I am not sure how that helps in this case.  What you want, I think, is
to explicitly state that profiles of DNCP could specify exchanges that
carry sensitive information and confidentiality is needed.  Section 4.2
is focused more on the underlying transport protocol (TCP vs. UDP) and
the nebulous "security" term.  The driver here should be whether
authentication, integrity protection, confidentiality, or authorization
is needed.  Perhaps that would make sense in Section 9.

> 
> As multicast is used only to identify potential new DNCP nodes and to
> send status messages which merely notify that a unicast exchange
> should be triggered, the multicast transport does not have to be
> secured.  If unicast security is desired and one of the built- in
> security methods is to be used, support for some TLS-derived 
>>>>>> * 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.
>>>>> I think this more or less depends on the type of link and
>>>>> its characteristics and the current state, so I'm not sure if
>>>>> a MUST is necessary in all cases.
>>>> Multicast-based implosion is a problem.  If implementations
>>>> ignore the SHOULD, you run a very real risk of overloading the
>>>> request sender with unicast responses.  If the WG is not
>>>> willing to make this a MUST, the spec should clearly spell out
>>>> the potential of amplification attacks using this protocol.
>>> 
>>> I am not sure what you mean by this, as I cannot really see it;
>>> in _some applications_ on _some links_ perhaps, with bad
>>> implementations _without rate limiting_ (that is stated that is
>>> acceptable for about anything in the message processing flow).
>>> 
>>> As specified, the _only_ multicast TLV that MUST be responded is
>>> the Network State TLV, and those replies MUST be rate limited
>>> already.
>> 
>> However, an implementation MUST eventually reply to similar
>> repeated requests, as otherwise state synchronization breaks.
>> 
> I wonder how this should be rephrased to make it more clear; as what
> DNCP spec _says_ essentially that only mandatory to send/receive
> multicast TLV is the Network State TLV (+ associated Node Endpoint
> TLV), and everything else comes from the unicast reply sequences
> stemming from there.
> 

I think that the MUST clause I quoted above from 4.4 needs to be put in
context with what is stated in section 9.

> Receiving other TLVs via multicast is allowed but they are not
> explicitly generated by the default processing flow, and the section
> 9 describes which multicast TLVs can be explicitly ignored in a
> profile without breaking DNCP synchronization mechanism, and it turns
> out to be all of them except for the two noted above.
> 
> They were left as options to allow e.g. sending multicast Node State
> TLVs _with data_ in profiles where confidentiality of the data does
> not matter.
> 
>>> How many more MUSTs should we stick here? Whether you rate limit
>>> it to one response per time interval (current), or mandatory
>>> delay (what I guess you propose), I do not think it makes much of
>>> a difference.
>>> 
>>> response with multiple types to be the MUST path, then this needs
>>> to be reconsidered. The original design _was_ to minimize the
>>> amount of multicast, and for that the SHOULD delay (+ MUST rate
>>> limit replies in general) seems sufficient to me.
>> I think we are talking about different things.  I am wondering why
>> the randomization of response transmission *to multicasted
>> requests* is only a SHOULD and not a MUST.  Amplification attacks
>> can be (and have been) launched by sending multicast messages that
>> result in a large number of unicast responses hitting the source IP
>> address of the request.
>> 
>> Let me ask my question a different way... Can you provide an
>> example of where nodes that receive a DNCP request via multicast
>> should not randomize the transmit time of their responses?
> 
> Simple implementation[1] with a super paranoid profile (handles only
> those two above multicast TLVs) with the mandatory MUST ratelimit
> Request Network State TLVs.
> 
> It does not really matter if it sends the one reply per link per
> Trickle interval either immediately or after delay for most part
> (barring some crippled link layers).

What happens if that simple implementation is running on 1,000 nodes,
they receive a multicast request from a single neighbor, and they all
respond immediately without randomizing the transmit time of their
responses?

Regards,
Brian

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 17 Sep 2015 18:29:41 +0300

> think it will be useful for the IESG to work this out.

Ok, looking forward to what you guys tell us to do about it :)

> IMO, it wouldn’t hurt.

Added in [1] (and simplified the text bit, I think saying that there is no delta transmission scheme makes it obvious that you have to send the whole thing).

> is needed.  Perhaps that would make sense in Section 9.

As currently specified, there isn’t really half-way choice in the spec (e.g. no confidentiality); if you go for ‘insecure’, you get none, and if not, you are essentially forced to integrity protection+confidentiality  and your choice of authentication+authorization (section 8). 

Everything within node data is already covered by default (adding explicit statement to that effect in [1]) given adherence of the secure <> not-secure specification (notably, reception ignores Node State TLVs received via multicast), but it is true that if a DNCP profile specifies TLVs that are sent outside node data a security policy must be stated for them as well.

> context with what is stated in section 9.

Hm, true. Updated in [1] (also changed the ‘eventually’ to the meaning I meant, that is, non-zero probability but not neccessarily probability of 1).

However, if the TLV is not forbidden
        by the DNCP profile, an implementation MUST reply to resends of the
        TLV with a non-zero probability to avoid starvation which would
        break the state synchronization.

> respond immediately without randomizing the transmit time of their

Depends on the link layer to some extent; in worst case, none get through, and eventually network gradually splits. In about any other case (say, even 10% get through), the network converges, just bit slower (Trickled resends -> not even that slowly). In practise, barring naive hubs of 90s, I am not aware of such a link layer in use that would behave _that_ badly. Ethernet switches avoid mostly collisions these days, and wifi unicast is ‘reliable’. 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.

(I have yet to see a problem in real world due to this; then again, I do not have 1000 nodes on a single flat link..)

That said, if this gets deployed on such a network, I will gladly publish an errata saying MUST :-)

Cheers,

-Markus

[1] https://github.com/fingon/ietf-drafts/commit/e3dde8c59785bc509252978f73bb6532b3c7cc73 - to appear in -10.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Sep 2015 22:58:13 +0200

>>>>> * 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.

> In practise, barring naive hubs of 90s, I am not aware of such a link
> layer in use that would behave _that_ badly. Ethernet switches avoid
> mostly collisions these days, and wifi unicast is ‘reliable’.

Wifi unicast is based on CSMA, two stations sending simultaneously will
cause a collision and a reemission.

> publish an errata saying MUST :-)

It's a fine protocol, Markus, that solves a real problem.  If it works
well in home networks and is available on cheap hardware, people will
deploy it in larger networks whether we like it or not.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 19 Sep 2015 00:54:23 +0300

> order to aggregate TLVs, adding a random delay to the flushing doesn't

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