On 23.2.2015, at 4.57, Juliusz Chroboczek <[email protected]> wrote: > I have a few questions and comments about DNCP. (I haven't finished > grokking HNCP yet, so that will have to wait.)
Thanks, we definitely need more eyes on this (keepalive logic was actually flawed in -00, but I dare you to find it without looking at our git repo on drafts :>). > 1. Fragmentation > > The minimum MTU in IPv6 is 1280 bytes, and the minimum maximum packet size > (before fragmentation) is 1500 bytes. This means that a Short Network > Status can carry information about 160 nodes or so, which is a little > tight for comfort. Is there a fragmentation mechanism I've missed > somewhere? I assume you refer to Long Network Status (on multicast); post MTU, or in secure mode, it should just use the Short one (which is of fixed length). The network state TLV used in the short one is just one hash of (ordered sequence of) hashes of all nodes on the network. The Long is just opportunistic scheme to enable clients to do immediate requests for node data, instead of unicast exchange, if network is small enough and not in secure mode. > Related to that -- what happens if you receive a Node Data Request, and > the reply doesn't fit in the MTU? Are you allowed to split it into > multiple Node Data Replies? If so, how do you know if you've received the > whole set? The assumption currently is that replies are always unicast, and the IPv6 fragmentation works on local link. Current assumption is that sane set of node data fits inside one (potentially fragmented) IPv6 packet (non-jumbogram), essentially limiting the maximum size to <64kb. (If we hit that size limit, I would rather advocate some sort of node data delta transmission protocol in any case.) > 2. Packet loss > > What happens on packet loss? > > * what happens when the reply to a Node Data Request doesn't arrive? > Are you supposed to resend the request? With exponential or linear > backoff, and with what constants? Nothing happens. You wait for the event that caused the original request to happen again (essentially, Trickle ensures that everyone hears of an update ‘few’ times before it backs off down to relatively long value.) > * is there a way to detect that a link exhibits packet loss? There are > no sequence numbers in state updates (there's the state seqno, but > that's not incremented with each message), so you cannot easily find > how many you’ve missed. Nope. > * Are you allowed to do something special when you have new data to > publish over a connection that exhibits packet loss? For example > keeping I at Imin for two or three updates? Not in the current spec; the whole thing is ‘best-effort’ and _intentionally_ much slower than it could be. e.g. initial transmission is caused by Trickle, and not immediately, always; a lot of routing protocols for example send immediately (at least in some cases), but current aim is for “sufficient” speed of the state sync and processing/bandwidth conservation than raw speed. As Trickle parameters used are local implementation choice, I _suppose_ we could actually mandate just a Trickle-like sending algorithm, with default recommendation being Trickle, but it gets complex in writing if not in implementation :) Pull requests welcome though. > 3. Extensibility > > What should I do if I receive an unknown TLV? I assume I should silently > ignore it if it's inside a Data TLV, and include it in my database and > flood it if it’s within a Data TLV, right? Right. Almost all of node data is essentially opaque to the DNCP base protocol, with the few noted exceptions. > Which messages are allowed to contain extra TLVs? For example, what > should I do if I receive a Long Network State Update with a bunch of > unknown TLVs interleaved with the Node State TLVs? Any of them. The messages are defined just by the MUST be present TLVs. However, interesting question is, what if the received payload matches multiple messages? Current text > 4. Jitter > > Am I missing something or you’re not applying jitter to keepalives? That is a good point; we will address that in -01. (Similarly to what we do to replies to multicast messages; just [0, Imin/2] SHOULD delay.) > 5. Connections > > There's a single connection for all neighbours on a given interface, > right? Why not call that an Interface, then? In case of HNCP, this is true, as it has connection=(link-local IPv6 UDP-using) interface. In DNCP, a connection may be just e.g. one unicast endpoint you want to talk with over the internet. > 6. Link-local addresses > > You're assuming a link-local multicast group, right? What about the > sender address and unicast packets? What should I do if I receive a DHCP > message from a global address? Discard it, right? This is specified in HNCP as it is the one with link-local address binding. DNCP can be also used with globals so I do not think the limitation fits there (although obviously the profile will probably want to limit global use to secure mode). > 7. Neighbor graph > > The notion of "neighbor graph" suddenly appears in Section 5.4. It's > pretty obvious what you mean, but this should be precisely defined > somewhere. The later traversing definition more or less describes what it ‘is’; any idea of what a good definition would look like? Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
