On 15.9.2015, at 20.24, Brian Haberman <[email protected]> wrote: > On 9/15/15 12:52 PM, Steven Barth wrote: >> Hello Brian, >> thank you for your feedback. >> >>> ---------------------------------------------------------------------- >>> 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. >> >> 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. > 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.
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? >>> * 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... 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.) > 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. >>> * 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. 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 _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
