Re: [homenet] DNCP questions (and minor nits)
Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to a REQ-NODE-STATE MUST NOT contain the optional part. I assume you are talking about REQ-NET-STATE. The underlying problem here [...] Now that we discuss it, I think SHOULD NOT might be correct, though; if you haven't shared it with _anyone_, obviously first one is at least unknown to the rest of the network. This explanation is enlightening and should be in the draft. Still in the same section, when a duplicate node-id is detected, the new seqno chosen myst be significantly higher than the one received. Why is that? Is +1 not enough? (I'm using +42 right now, of course.) [...] Funnily enough I thought +1 was enough at first too. This explanation is enlightening and should be in the draft. Markus, DNCP is a beautiful protocol. There are a number of things that I've asked before that are subtle enough to warrant an explanation. In addition to the two points above, the following come to mind: - the fact that you use a single-line change to Trickle that has huge consequences on its behaviour in case of persistent desynchronisation; - the fact that flooding link-local data, while wasteful of storage, avoids the need for keeping reliable state beyond what is in the Merckle tree. These things need to be clearly explained to the naive implementor. I've been deliberately copying the list with all of my questions (sorry for the spam) so that we can have a record. Now somebody (somebody with strong nerves) needs to go through my recent flurry of epistolar activity and decide, for each of my questions, whether I'm just being stupid or whether this deserves a clarification. In case of doubt, clarify. I realise I'm being a pain, especially since it contradicts our motto it was difficult to write, there's no reason it should be easy to read. Hmm. Wonder if removing the guidance altogether is the preferable choice here. No, please leave it, just add the missing pair of brackets, and add where (a % b) represents the remainder of a modulo b and (a b) represents bitwise conjunction of a and b. [Aside: I think the official IETF definition of seqno comparisons is in RFC 1982, which uses a slightly different definition than both HNCP and Babel: comparision between s and s + 2^(n-1) is undefined, implementations are free to return either result, or flag an error. Yeah, right. They use a definition by cases. RFC 793 Section 3.3 says There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values., and then they define the in-window relation by cases. RFC 6126, simply says seqno seqno' ... where sequence numbers are compared modulo 2^16, with no further ado. End of aside.] Section 4.5 suggests sending a unicast REQ-NETWORK-STATE when receiving ENDPOINT. If adding the peer fails (say, out of memory), won't this cause a livelock? Given stream case, yes, as there is no guarantee of second one ever showing up. For datagrams, next ENDPOINT should do it, no? Not if allocation fails again. Am I being even more paranoid than you? I suggest putting a word of caution in there. 6.1.2 a new t MUST be chosen, but is the interval not reset? Same in 6.1.3. Hm, true. Any suggestions on better wording? Even the current one is bit cumbersome, and repeating it twice with even more stuff in it is not very appealing either. This really needs to be stated accurately. I think you have two choices: you either repeat the definition of Trickle in this document, or you put precise references to RFC 6206 whenever you mention a Trickle action. I think the latter is a better choice from the implementors point of view, the former is the better choice for the casual reader. Screw the casual reader. In this particular instance, I think what you want to say is and starts a new trickle interval, as in step 2 of Section 4.2 of RFC 6206. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions (and minor nits)
On Sat, 4 Jul 2015, Juliusz Chroboczek wrote: These things need to be clearly explained to the naive implementor. I've been deliberately copying the list with all of my questions (sorry for the spam) so that we can have a record. Now somebody (somebody with strong nerves) needs to go through my recent flurry of epistolar activity and decide, for each of my questions, whether I'm just being stupid or whether this deserves a clarification. In case of doubt, clarify. I realise I'm being a pain, especially since it contradicts our motto it was difficult to write, there's no reason it should be easy to read. For what it's worth, I fully agree with you. This was what I meant by my earlier comment that there is a lot of valuable information in the heads of the implementors/designers that isn't written down in the drafts as they stand right now. Remember also that this is intended to be a protocol that's being implemented and run by a lot of different vendors who do not have a great track record of writing and maintaining excellent software (to put it mildly). Any help given to them to get their implementations right is very valuable. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions (and minor nits)
On 4.7.2015 0.28, Juliusz Chroboczek wrote: Markus, Steven, Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to a REQ-NODE-STATE MUST NOT contain the optional part. Why is that? If I've recently republished my own data (e.g. because I gained a neighbour), it makes sense to me to send my own NODE-STATE in order to avoid a round-trip. I assume you are talking about REQ-NET-STATE. The underlying problem here is that (generally speaking) there is no way to know if they have received the state already from someone else even if you did change it recently. Especially given large node datas, the difference is relatively large. Now that we discuss it, I think SHOULD NOT might be correct, though; if you haven't shared it with _anyone_, obviously first one is at least unknown to the rest of the network. Still in the same section, when a duplicate node-id is detected, the new seqno chosen myst be significantly higher than the one received. Why is that? Is +1 not enough? (I'm using +42 right now, of course.) There may be more than one update from previous reboot cycle in the network still; it is not even bounded, given infinitely large network, but 'few' is enough in real world, and so should 42. Funnily enough I thought +1 was enough at first too. The DNCP profile MUST provide guidance about how to deal with node-id collisions. Where is that guidance provided in HNCP? o HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP SHOULD generate and use a random node identifier. If using a random node identifier and there is a node identifier collision, the node MUST immediately generate and use a new random node identifier which is not used by any other node. The expression defining the circular ordering is written in C syntax, but I think it assumes different priorities than C. Please put brackets around the bitwise conjunction. Actually I do not even think it is C; at least, for it to be valid C, some bonus parentheses and 1X should replace 2^ portions. eg what we use is uint32_t)(a) - (uint32_t)(b)) ((uint32_t)131)) != 0) Hmm. Wonder if removing the guidance altogether is the preferable choice here. Section 4.5 suggests sending a unicast REQ-NETWORK-STATE when receiving ENDPOINT. If adding the peer fails (say, out of memory), won't this cause a livelock? Given stream case, yes, as there is no guarantee of second one ever showing up. For datagrams, next ENDPOINT should do it, no? Shouldn't the first part of 4.5 be moved into 4.4? Hm, it might improve the readability a bit :) 4.6, MUST be traversed Either immediately... Is it not better to say that it must be traversed before the next message is scheduled to be sent? Not really, as in some cases, you may have relatively long next keepalive or Trickle timer, and waiting until then to discover that you should have gotten rid of the stuff sooner and updated others about the change is not good. 6.1.2 a new t MUST be chosen, but is the interval not reset? Same in 6.1.3. Hm, true. Any suggestions on better wording? Even the current one is bit cumbersome, and repeating it twice with even more stuff in it is not very appealing either. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] DNCP questions (and minor nits)
Markus, Steven, Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to a REQ-NODE-STATE MUST NOT contain the optional part. Why is that? If I've recently republished my own data (e.g. because I gained a neighbour), it makes sense to me to send my own NODE-STATE in order to avoid a round-trip. Still in the same section, when a duplicate node-id is detected, the new seqno chosen myst be significantly higher than the one received. Why is that? Is +1 not enough? (I'm using +42 right now, of course.) The DNCP profile MUST provide guidance about how to deal with node-id collisions. Where is that guidance provided in HNCP? The expression defining the circular ordering is written in C syntax, but I think it assumes different priorities than C. Please put brackets around the bitwise conjunction. Section 4.5 suggests sending a unicast REQ-NETWORK-STATE when receiving ENDPOINT. If adding the peer fails (say, out of memory), won't this cause a livelock? Shouldn't the first part of 4.5 be moved into 4.4? 4.6, MUST be traversed Either immediately... Is it not better to say that it must be traversed before the next message is scheduled to be sent? 6.1.2 a new t MUST be chosen, but is the interval not reset? Same in 6.1.3. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
Yep, intentionally so for now; of course, we could turn it even more in the scalable (routing) protocol direction if there is desire. That's not quite what I meant. I'll try to put it differently. Right now, an HNCP node performs the following actions: 1. participate in Trickle-based flooding; 2a. contribute a neighbour TLV to the global state; 2b. optionally contribute other TLVs; 3a. maintain a full set of TLVs being published; 3b. maintain a copy of the topology graph. Now there are different costs associated to these activities, both for this node and for other nodes. (1) is cheap for both. (2) is cheap for this node, but expensive for other nodes -- the state being contributed is replicated in all the other nodes. (3) is the opposite -- it's expensive for this node, since it requires storing the whole replicated state, but doen't contribute anything to other nodes. Now HNCP doesn't allow participating in just some of those activities. In particular, there is no way to participate in flooding without contributing a neighbour TLV (and hence increasing the size of the replicated state and the replicated neighbour graph). When you split HNCP into DNCP, I was hoping that you were providing a means to have nodes that do (1) and (3a) without contributing to the replicated global state. But unless I'm missing something, it doesn't. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
On 25/02/2015 21:15, Markus Stenberg wrote: On 25.2.2015, at 0.56, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size. I guess this is another MUST to be added to HNCP text (DNCP itself is not IPv6-specific as such). You mean that every HNCP node MUST ba able to accept packets of up to 64kB? What’s the status of typical embedded stacks? Configuration dependant more than implementation at least in the few I have played with, but usually they’re really short of RAM so usually configuration is rather conservative. Sticking (say) DTLS in one is probably no-go due to lack of computing power to start with so I am not sure this is that relevant. That said, from my point of view, if this is really thought to be an issue by the WG, correct solution is to use TLS (+TCP) instead of DTLS (+UDP) in any case. I've thought about this in the Anima/GDNP context and reached the same conclusion. Why make life complicated when TLS makes it simple? Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size. I guess this is another MUST to be added to HNCP text (DNCP itself is not IPv6-specific as such). You mean that every HNCP node MUST ba able to accept packets of up to 64kB? What's the status of typical embedded stacks? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
Another question -- is it possible to participate in Trickle-driven flooding without building the full topology graph? The current answer based on strict reading of the spec is no. [...] Is this desirable to be changed? Probably so. There's not only the stub case that you consider, but also the pure client/forwarder node -- a node that doesn't wish to publish any data, but uses static HNCP data, and serves as a link between two parts of the network. Ideally, such a node should not contribute any replicated state. (Note that a Babel/AHCP router that doesn't announce any routes contributes no state whatsoever to non-neighbouring nodes. So you can add arbitrary many intermediary hops with no cost incurred by distant nodes.) The reason I'm asking is somewhat out of scope for Homenet -- I'm looking into deprecating AHCP in mesh networks in favour of a subset implementation of HNCP. AHCP is a very simple protocol, and one can implement an AHCP client/forwarder in constant space. Not so with HNCP -- in HNCP, every node has a copy of the topology, and contributes a vertex to the replicated neighbour graph. HNCP is naive link state, with no network nodes (pseudonodes) and no DR/DIS/MPR election. So its scaling is quadratic in the worst case. Consider a network containing a switched Ethernet backbone consisting a mere 30 routers. Unless I'm missing something, this backbone will contribute no less than 30 vertices and 435 edges in the neighbour graph, and this state will be duplicated in every single node in the network. There's an obvious solution -- it is to have pure client nodes that participate in Trickle but don't contribute a vertex to the neighbour graph. But HNCP doesn't support that. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
The minimum MTU in IPv6 is 1280 bytes, and the minimum maximum packet size (before fragmentation) is 1500 bytes. I assume you refer to Long Network Status (on multicast); Yes, sorry. post MTU, or in secure mode, it should just use the Short one (which is of fixed length). Ok. So I send multicast SNS. I receive NSR. I'm supposed to send LSR, right? But it doesn't fit in maximum packet size, even with fragmentation. RFC 2460, Section 5: A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size. 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. You cannot count on that. See above. 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. Please make that very clear. Implementors will get it wrong, and we'll find ourselves unable to extend the protocol. 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. Again, please make this very clear. In particular, make it clear that upon encountering an unknown TLV, the rest of the packet must be processed as usual. (The other possible choice is that the whole rest of the packet is ignored.) 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. I see. I still dislike the term of connection, which seems to imply a point-to-point thing. Ideas? 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? Actually, looking at it again, I'm not sure I know what is the neighbour graph. It's the directed graph defined by all neighbour TLVs, or the undirected graph that you get after removing unidirectional neighbours? I assume the latter. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
On 23.2.2015, at 18.51, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Another question -- is it possible to participate in Trickle-driven flooding without building the full topology graph? If not, that's a little disappointing, since Trickle is designed so that it can be implemented while knowing just my immediate neighbours. But it looks to me like I cannot do the activities mandated in Section 5.4 without building full topology. You are coming up with same things I have thought about quite a bit too. The current answer based on strict reading of the spec is no. The reason isn’t 5.4 (it is just a SHOULD, because you can implement something stubby that just relies on LNS being complete list of nodes known by neighbors). Why is it impossible then? Simply because the 5.2 specifies that node data requests MUST be always responded to (as you may not want to actually store any data about anyone else than yourself to start with). I have been debating with myself how to change this. Is this desirable to be changed? Probably so. Simplest change to achieve this would be simply to add ‘if available’ to 5.2 (and perhaps to note in section 4 that the data model is not really normative), and some sort of flag about stubby behavior (notably, assume that there is no HNCP talkers behind the node so it is asked only about it’s own state). With this scheme, you can have: [1] ’really stubby HNCP write-only’ which does not store anything except (possibly empty-ish set) of it’s own published node data and one neighbor - the non-stubby router it has chosen. All it needs to know about the other nodes is just a copy of LNS stored somewhere so it can interact with non-stubby router (and pretend nobody else exists so no need for keeping track of even other local neighbors). However, I am not sure if this scheme is actually sensible; in practise, if you want ‘write-only’, you really want to just have some exchange with a genuine long-lived HNCP participant with a TTL + early revocation scheme. [2] ’bit less minimal but still stubby’ HNCP could just keep all node data that has reference in LNS of it’s peers but otherwise work like [1]. Relatively useful, and much simpler to implement than whole thing still. Note that both of these ’stubby’ variants need ’non-stubby’ one to leech off on the same link. Both would be fine to stick in e.g. host though. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
On 23.2.2015, at 17.24, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
post MTU, or in secure mode, it should just use the Short one (which is
of fixed length).
Ok. So I send multicast SNS. I receive NSR. I'm supposed to send LSR,
right? But it doesn't fit in maximum packet size, even with fragmentation.
RFC 2460, Section 5:
A node must be able to accept a fragmented packet that, after
reassembly, is as large as 1500 octets. A node is permitted to
accept fragmented packets that reassemble to more than 1500 octets.
An upper-layer protocol or application that depends on IPv6
fragmentation to send packets larger than the MTU of a path should
not send packets larger than 1500 octets unless it has assurance that
the destination is capable of reassembling packets of that larger
size.
I guess this is another MUST to be added to HNCP text (DNCP itself is not
IPv6-specific as such).
I am not convinced by the trend to add fragmentation to every protocol on top
of IP{v4,v6} but can be convinced otherwise of course given good arguments. At
least in case of HNCP as it works on link-local level only, I think saying you
MUST have sane IP stack on both nodes is not overreaching it as there are no
middleboxes to worry about.
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.
You cannot count on that. See above.
I consider it documentation error, see above :)
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.
Please make that very clear. Implementors will get it wrong, and we'll
find ourselves unable to extend the protocol.
Ok, I will add one more MUST (although reading the text, I thought it obvious
already from the context but guess not).
+ Whole “node data is owned by the node that
+ publishes it, and it MUST be passed along as-is, including TLVs
+ unknown to the forwarder.
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.
Again, please make this very clear. In particular, make it clear that
upon encountering an unknown TLV, the rest of the packet must be processed
as usual. (The other possible choice is that the whole rest of the packet
is ignored.)
tDNCP profiles MAY add additional TLVs to the message specified
- here, or even define additional messages as needed./t
+ here, or even define additional messages as needed. TLVs not
+ recognized by the receiver MUST be ignored. /t
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.
I see. I still dislike the term of connection, which seems to imply
a point-to-point thing. Ideas?
Not from me; we had relatively long (and fruitless) internal discussion on this
in November IIRC.
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?
Actually, looking at it again, I'm not sure I know what is the neighbour
graph. It's the directed graph defined by all neighbour TLVs, or the
undirected graph that you get after removing unidirectional neighbours?
I assume the latter.
The latter. Edited text a bit in few places, dunno if it really helped :)
-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP questions
On 23.2.2015, at 4.57, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr 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
[homenet] DNCP questions
I have a few questions and comments about DNCP. (I haven't finished grokking HNCP yet, so that will have to wait.) 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? 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? 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? * 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. * 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? 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? 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? 4. Jitter Am I missing something or you're not applying jitter to keepalives? 5. Connections There's a single connection for all neighbours on a given interface, right? Why not call that an Interface, then? 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? 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. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
