<div dir="ltr">Dear folks<div><br></div><div>I have the following comments on the 2020-05-08 autoconfiguration presentation.</div><div>To prevent complaints, I'm writing my comments instead of trying to speak during conference calls.<div><br></div><div>I totally agree with Lixia's definition of NDN configuration:</div><div>The goal is to be able to publish and receive Data, including signing and verification.</div><div>The steps include obtaining certificates and trust schemas (note that trust anchor is part of trust schema, according to schematized trust paper).</div><div><br></div><div><br></div><div>Once again, the question about "<a href="https://www.lists.cs.ucla.edu/pipermail/ndn-interest/2015-June/000716.html">whether a face is an interface or an adjacency</a>" came up.</div><div>My well-known opinion has been: <a href="https://hdl.handle.net/10150/625652">a face is an interface</a>, and you should broadcast everything. Hardware-based packet filtering can avoid degrading performance due to broadcasting.</div><div>In today's call, Lixia also thinks a face should be an interface, and broadcast should be used by default.</div><div>Note that there has been some confusion on terminology "multicast vs broadcast". In NFD transports are called "multicast" because they use a well-known multicast address. The effect is broadcasting to every node that understands NDN. There is really no need to use the 

FF:FF:FF:FF:FF:FF address and bother other nodes that do not even understand NDN.<br></div><div><br></div><div>One problem with "broadcast everything" is, today's WiFi access points perform poorly on broadcast frames.</div><div>In today's call, Lixia believed that this is a "layer 9, human issue" that IEEE 802.11 specifies multicast and broadcast frames to be transmitted at 1Mbps. This is a misunderstanding. The real reason is explained in <a href="https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-11">draft-ietf-mboned-ieee802-mcast-problems</a> section 3.1: WiFi multicast has no acknowledgment, so that the AP has to use the basic rate to maximize the possibility of successful transmission.</div><div><br></div><div>To work around the WiFi broadcast problem, Teng wants to use unicast after self-learning has learned a route.</div><div>The design I came up with was: every <a href="https://redmine.named-data.net/issues/4283">incoming packet has an EndpointId</a> that indicates its source unicast address. Then, the self-learning strategy can send an outgoing packet via unicast, by tagging it with the same EndpointId.</div><div>The 2019-10-30 NFD call had a long discussion on this. During that call, Lixia was unhappy that NDN nodes have to deal with unicast addressing, but acknowledged the broadcast problem. Lixia agreed that unicast could be used, but it must be "hidden under the rug".</div><div>In Lixia's mind, the "rug" would be "in the face" (as recorded in the <a href="https://redmine.named-data.net/issues/1282#note-18">duplicate transmission suppression issue</a>). However, the algorithms need to know names, while the face does not know names, so these features are unimplementable in the face.</div><div>Eventually, <a href="https://redmine.named-data.net/journals/26056/diff?detail_id=22926">the EndpointId design was scrapped</a>. Instead, whenever self-learning wants to send a packet via unicast, it must create a unicast face if it does not exist. Effectively, face becomes an adjacency.<br></div><div><br></div><div>I observe that "whether a face is an interface or an adjacency" has been a major issue in NFD design, which impedes the design progress of self-learning, <a href="https://redmine.named-data.net/issues/1282">duplicate transmission suppression</a>, and other issues that may need to use both Ethernet multicast and unicast.</div><div>We need a final and irrevocable agreement on this choice, because going back and forth wastes development work.</div><div><br></div><div><br></div><div>The next question was: if a user has installed one or more NFD nodes, how to know "NDN is working"?</div><div>This divides into two scenarios:</div><div><ul><li>Scenario L: The user has two or more nodes, and does not need to connect to the global NDN testbed.</li><li>Scenario G: The user has only one node, and wants to connect to the global NDN testbed.<br></li></ul></div><div>Lixia believes that only Scenario L is worth considering. However, I think both should be supported, and they could be supported with the same configuration.</div><div><br></div><div>In Scenario L, user experience would be:</div><div><ol><li>Start NFD on both nodes.</li><li>On the producer node, run ndnpingserver /my-name , in which "/my-name" is any name that the user can make up, but it cannot start with "/localhost" or "/ndn".</li><li>On the consumer node, run ndnping /my-name . This should get responses from the producer.</li></ol></div><div>Note that there is no manual face creation and route insertion steps.</div><div><br></div><div>In Scenario G, user experience would be:</div><div><ol><li>Start NFD.</li><li>Run ndnping /ndn/multicast . This should get responses from a testbed router.</li></ol></div><div><div>Note that there is no manual face creation and route insertion steps.</div><div></div></div><div><br></div><div>To achieve both scenarios, the codebase changes include:</div><div><ul><li>Set self-learning as the default strategy.</li><li>Execute ndn-autoconfig during NFD initialization, to connect to the testbed if reachable.<br></li><li>Set best-route as the strategy for /ndn prefix, but only after a testbed connection has been established.<br></li><li>Run ndnpingserver /ndn/multicast on three or more testbed routers.</li></ul></div><div>The user needs to install both NFD and ndn-tools packages. I think this is a reasonable requirement.</div><div><br></div><div><br></div><div>Alex commented that, sometimes the configuration could be completely different depending on network environments.</div><div>In that case, the Ubuntu package could present a configuration menu that allows a user to select a preferred configuration.</div><div>For example, there could be a menu with options:</div><div><font face="monospace">[X] create a personal NDN network</font></div><div><span style="font-family:monospace">[ ] join a personal NDN network</span><br></div><div><span style="font-family:monospace">[ ] connect to the global NDN testbed</span></div><div><br></div><div><br></div><div>In today's call, Lixia mentioned that auto prefix propagation can only propagate to one connected router. This is partially true.</div><div>The truth is: auto prefix propagation can only <u>reliably</u> propagate to one connected router.</div><div>The reason is: every router listens on the same prefix /localhop/nfd/rib, so that the end host cannot distinguish between them when sending prefix registration commands (see #<a href="https://redmine.named-data.net/issues/3142">3142</a>).</div><div>One could configure the end host to multicast the prefix registration commands to several connected routers, but then the auto prefix propagation component would be unable to receive all Data replies: if the command succeeds on one connected router and fails on another connected router, the auto prefix propagation component might receive only the successful response, and thus would not retry the command.</div><div>There are two ways to resolve this problem:</div><div><ul><li>#<a href="https://redmine.named-data.net/issues/3142">3142</a> and #<a href="https://redmine.named-data.net/issues/3143">3143</a>: each connected router should listen on a different name prefix.</li><li>#<a href="https://redmine.named-data.net/issues/3162">3162</a>: do not aggregate Interests with different forwarding hints, treat NextHopFaceId as forwarding hint, and use NextHopFaceId in prefix registration commands from the auto prefix propagation component.</li></ul></div><div><br></div><div>Yours, Junxiao</div></div><div><br></div></div>