<div dir="ltr"><div class="gmail_extra">20140622 NFD conference call discusses the big picture comments from Jeff Burke.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 12:00 AM, Burke, Jeff <span dir="ltr"><<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)">
<div><br></div><div><p class="MsoNormal">Big picture comments:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>1.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>I think the document could be re-organized in a simple way to provide a clearer high-level view of how the forwarder functions first, and then dive into the details. While starting with Faces makes sense from a bottom-up perspective, a critical thing to understand first may be how NFD processes packets, and what the various modules/abstractions are. This might be accomplished by moving the pipelines section earlier or by expanding the introduction to talk about packet processing, the relationship between NRD / NFD, etc. </p>
</div></div></blockquote><div>We should expand the introduction: pick something from later sections and put in introduction.</div><div>Contents in later sections should not be reduced.</div><div><br></div><div>We can describe how a packet flow through the system: how an Interest/Data packet flow through the system (data plane); how a ControlCommand flow through the system (including the RIB Daemon).</div>
<div>Within this text, we should introduce all the major concepts.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p><u></u> <u></u></p><p>2.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>More generally, it would be nice if the document was re-organized to reduce the number of forward references needed to understand something in detail, and grouped discussion of functionality together. (E.g., Strategy, Strategy Choice Table, Strategy Manager could all be in a strategy section, rather than spread out, if the notion of managers and the Name Tree are introduced beforehand.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p style="margin-left:1in">a.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>For example, the strategy choice table structure section is hard to read / understand without reading about strategy first. While a forward pointer works, it would be better if the strategy section came first. <u></u><u></u></p>
<p style="margin-left:1in"><u></u> <u></u></p><p style="margin-left:1in">b.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Similarly, high-level abstractions used repeatedly that are relevant to the way the code is organized, e.g,. the notion of “managers”, should be introduced briefly at the beginning, rather than relying on forward references. Then, you could group the description of each manager with what it manages… the FIB manager description could go in the section about the FIB, the strategy manager in the section about strategy, etc. I think this would make these various things easier to grasp quickly. </p>
</div></blockquote><div>This cannot be completed within 0.2 timeline, but we can consider it for next version. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p style="margin-left:1in"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>3.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>I would highly recommend increasing the terseness / consistency of terminology. E.g., the terms callbacks and triggers are used in the early part of the document, but there is a whole section on the “event system” – what is the difference between a trigger, event, timer, signal (p7), and callback? Can the number of terms be reduced? It’s not that the relationship is particularly complicated, but it creates noise for the reader unnecessarily. If the terminology does not reflect functional differences, it should be collapsed; if it does, it should be explained more clearly. Other examples are distinguishing between Internal and Local (Internal doesn’t show up in the table in 2.1); non-local vs. remote and peer, etc. Similarly, there is a “face system” but a “tables module”… What is a system vs. a module? Namespace vs. a prefix? Operator vs. user vs. administrator (p40) vs. application vs. developer? Streamlining terminology may greatly improve readability for the first-time reader. </p>
</div></blockquote><div>Agreed. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)">
<p><u></u><u></u></p><p><u></u> <u></u></p><p>4.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Consider also putting security earlier, and working more security information into the other sections over time. Also, the notion of /localhost and /localhop are worked with throughout as a key concept, but not discussed in the security section</p>
</div></blockquote><div>We should create a "scope control" page on NFD website, which becomes part of protocol.</div><div>This document is then cited in Developer Guide. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>5.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>A future work / open issues section would be helpful.</p>
</div></blockquote><div>This does not belong in this document.</div><div>Future work and open issues are on Redmine. We should create a webpage on NFD website.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>6.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Utilities (6.2) should likely be last in the document, and probably integrated with Section 9.</p>
</div></blockquote><div>No. These classes are internal to management. They are not common services.</div><div>We shall change the title to "Utilities for managers". </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>7.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>As with any early draft, the document probably needs a single editor to do a pass to make the language more consistent and simpler. “The purpose of the channel abstraction is to encapsulate the functionalities needed to accept incoming connections or tostart outgoing connections, and to create a face when the connection attempt is successful.” (p7) => “Channels start outgoing connections and accept incoming connections. They create Faces for successful connections.”</p>
</div></blockquote><div>Agreed. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)">
<p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>8.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Diagrams could be made more consistent, and you may want to allocate space based on their complexity. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p style="margin-left:1in">a.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>E.g., Figure 2 is really useful and has a lot of information, but is only given the same space a Figure 7.<u></u><u></u></p>
<p style="margin-left:1in"><u></u> <u></u></p><p style="margin-left:1in">b.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>In fact, having more diagrams like Figure 2 per section would be very helpful. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p style="margin-left:1in">c.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>The visual overview of all pipelines (Figure 10) is critical and probably needs to be redrawn to be clearer (fewer colors, stronger lines, etc), have a key (what are yellow boxes) and perhaps give more detailed information.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p style="margin-left:1in">d.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>There are too many visual styles of diagrams, but this could be fixed later.</p>
</div></blockquote><div>We'll try to improve if time permits. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p style="margin-left:1in"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>9.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Things that are usually not NDN-like, in particular channels and hosts, should have some bit of explanation that explains why these abstractions or terms are used.</p>
</div></blockquote><div>No. They refer to the physical world: communication medias and computers. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p><u></u> <u></u></p><p>10.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>There are a few places where there is discussion of a use condition (e.g., “The FIB is expected to be relatively stable” p10) that are problematic, as they do not 1) provide evidence, explanation, or citation for the statement, 2) explain what it actually means in technical terms, or 3) explain why it’s relevant to what’s being read or what was designed. In the FIB example, would a vehicle’s FIB in a highly dynamic environment be considered “relatively stable” or not? Etc. These types of statements should be removed or explained in terms of the three aspects above, if possible. They a little distracting because they seem to beg the question rather than clarify the design strategy as intended. </p>
</div></blockquote><div>Junxiao's reason for writing this is to provide a direction for optimization. eg. "FIB is relatively stable" means FIB shall be optimized for faster lookups instead of updates.</div>
<div>
However, the writing is vague and should be improved. eg. "On wired Internet, frequency of FIB updates is much less than FIB lookups, so FIB should be optimized for lookups rather than updates.".</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>11.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>When describing specific relationships, “Management calls Cs::setLimit”, perhaps it is better to say which manager(s) specifically? Management is used generally several times</p>
</div></blockquote><div>Agreed. This can be changed as "Management changes ContentStore capacity via Cs::setLimit".</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>12.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Summary figures like Fig 18 could perhaps come earlier</p>
</div></blockquote><div>There's no need to distinguish between applications and routing protocol.</div><div>There's no need to distinguish between "self registration" and "routing update". Change them to "RIB update", and the arrow shall be curved to point to RIB Daemon.</div>
<div>RIB Daemon can point to NFD with "FIB update".</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p>13.<span style="font-size:7pt;font-family:'Times New Roman'"> </span>Should there be timing diagrams (p36) for other components besides the RIB manager?</p>
</div></blockquote><div>No. We shouldn't apply timing diagram to other sections. </div></div></div></div></div>