From shijunxiao at email.arizona.edu Mon Jun 2 18:47:27 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 3 Jun 2014 09:47:27 +0800 Subject: [Nfd-dev] NFD mgmt: eliminate double-dispatch Message-ID: This proposal describes the original design intention of the Interest dispatch mechanism of NFD management. Current implemented design: NFD management module consists of: - several Managers, such as FaceManager, FibManager, StrategyChoiceManager - an InternalFace - a configuration parser To process an Interest: - InternalFace receives ndn:/localhost/nfd Interests from forwarding, looks at the third component (management module), and dispatch it to a Manager. - Upon Interest arrival, Manager looks at the fourth component, and do one of the following: - for command verb: validate Command Interest, and then dispatch the Interest to the function that handles this command - for dataset: dispatch the Interest to the function that generates data for this dataset - for notification stream: drop the Interest - Replies are directly written to InternalFace Design intention: partial interface InternalFace { // reply(const Data& data, bool isFinal); // data: unsigned and unencrypted Data // isFinal: true if this is that last Data to send typedef function ReplyFunc; // process(const Interest& interest, const Name& identity, ReplyFunc reply); // identity: verified identity of requester, if available; otherwise empty // reply: a function to send replies typedef function InterestHandler; // accept(const Name& identity) // identity: verified identity of requester, if available; otherwise empty typedef function AcceptContinuation; // reject(bool reply401) // send401: whether to reply 401 or silently drop typedef function RejectContinuation; // authorize(const Name& prefix, const Interest& interest, AcceptContinuation accept, RejectContinuation reject); typedef function Authorization; // ReplyEncryption: I don't have a good design for now void register(const Name& prefix, Authorization, ReplyEncryption, InterestHandler handler); } - During initialization, Manager should register its commands, datasets, and notification streams into InternalFace - examples: face->register("ndn:/localhost/nfd/faces/create", CommandInterestAuthorization("faces"), NullReplyEncryption(), bind(&FaceManager::onCreateCommand, this, _1, _2, _3)); face->register("ndn:/localhost/nfd/faces/list", DatasetAuthorization(), NullReplyEncryption(), bind(&FaceManager::generateFaceList, this, _3)); face->register("ndn:/localhost/nfd/faces/events", DropAllAuthorization(), nullptr, nullptr); - InternalFace receives ndn:/localhost/nfd Interests from forwarding, perform a longest prefix match on registered prefixes - if no registration is found, record to log, and drop the Interest - Perform authorization as requested - CommandInterestAuthorization(const std::string& privilege) accepts valid Command Interests with this privilege, and rejects with 401 otherwise - DatasetAuthorization accepts Interests with Name equal to the prefix, and drops other Interests (they should be satisfied by ContentStore) - DropAllAuthorization drops all Interests; this is used with notification streams because Interests should wait until notification is delivered - Dispatch to the handler - Handler calls ReplyFunc zero or more times with unsigned and unencrypted Data - ReplyFunc is a bound function that knows the ReplyEncryption; it encrypts Data as requested, and then sign and send it Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Tue Jun 10 09:55:42 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Tue, 10 Jun 2014 16:55:42 +0000 Subject: [Nfd-dev] repo-ng performance issues prevent porting the BMS application Message-ID: Hi folks, As you have probably heard from Wentao, performance issues in repo-ng, especially for large database sizes, have prevented a successful port of the current BMS data gathering applications that worked under NDNx. Given both the criticality of the repo to many NDN applications and this specific requirement for one of the NP network environments, it would be great if there are any short-term fixes that could be applied. (Also, perhaps the next round of repository work could consider application performance requirements more directly.) Please let me know how the apps folks can help as well as what the plans and performance targets are for a fix. If necessary, we can consider building a repo on the application side too, We plan to gather a much larger data set from campus building systems by Fall, so this is critical for us. Thanks! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzhang at cs.ARIZONA.EDU Wed Jun 18 22:40:13 2014 From: bzhang at cs.ARIZONA.EDU (Beichuan Zhang) Date: Thu, 19 Jun 2014 13:40:13 +0800 Subject: [Nfd-dev] comments for the nfd doc Message-ID: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Hi, We?ve been integrating the text of the NFD Developer?s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday. The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. Thanks, Beichuan -------------- next part -------------- A non-text attachment was scrubbed... Name: nfd-docs.pdf Type: application/pdf Size: 1357660 bytes Desc: not available URL: From lanwang at memphis.edu Thu Jun 19 11:55:29 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 19 Jun 2014 18:55:29 +0000 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Message-ID: On Jun 19, 2014, at 12:40 AM, Beichuan Zhang wrote: > Hi, > > We?ve been integrating the text of the NFD Developer?s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday. > > The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. > Some comments for Section 7 (Obaid please check): - "The RIB Manager that runs as a separate process, NRD (NFD RIB Daemon)" should be "NRD (NFD RIB Daemon), the RIB Manager that runs as a separate process, ?" - 19 diagram should be Figure 19. - Figure 19 can be bigger and Figure 20 should be much smaller. - Figure 19 shows only NLSR. What about other apps? I suggest adding an app's typical interactions with NRD at the end of the time line. - It's not clear what this part means: "7.7 Extending RIB Manager The RIB Manager currently supports only two commands { register and unregister. However, functionality of the RIB Manager can be extended by introducing more commands. For example, if a node needs to announce a pre x currently, it has to con gure the routing protocol. A set of commands for advertising and withdrawing pre xes, with the help of any application, could provide a more uni ed way for the operators to publish name pre xes." Isn't advertising and withdrawing prefixes supported through register and unregister already? or are you saying any application should be able to advertise and withdraw prefixes. If this is what you mean, first it's not introducing more commands. It's just allowing regular application to issue the existing commands, right? Also I'm not sure if it's a good to let any application do these things. Lan > Thanks, > > Beichuan > > > > [The attachment nfd-docs.pdf has been manually removed] > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From iliamo at ucla.edu Thu Jun 19 13:11:02 2014 From: iliamo at ucla.edu (Ilya Moiseenko) Date: Thu, 19 Jun 2014 16:11:02 -0400 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Message-ID: <3B070495-78EA-49D5-8CB6-F5E67FA09686@ucla.edu> I?ve read first 22 pages, here are my corrections/suggestions. Will send the rest tomorrow. Page 4 ?diverse experimentation of NDN technology? of -> with ?These include hash computation routines, DNS resolver? DNS resolver ?? ?different lower level transport mechanisms? various lower level transports ?StrategyChoice? Strategy Choice Table (SCT) Page 6 ?a local endpoint and a peer? ?? What is a local endpoint? Text should be more clear: 1) node to node, 2) app to node, 3) node to broadcast medium Page 7 ?When a peer makes a connection to a local endpoint? ? When local app connects to its face? Writing is obscure, because previously peer was defined as an app or a node, but node can connect only to remote endpoints. Page 10 ?return value is a FIB entry that? that -> such that ?and remove NextHop? -> removes ?The FIB is updated only through management. FIB manager (Section 6.1.1) is directly responsible for updating the FIB.? Both sentences have the same meaning. Remove one. ?configured by operation? ?? you mean manually ? Page 13 "collection of PIT entries which that ? which or that pick one Page 15 ?StrategyChoice? Strategy Choice = common name inconsistency Page 17 ?loopup/insertion? lookup ?FIB/PIT/StrategyChoice/Measurement? -> does not fit by width, replace / with , ?full enumerate? full enumeration ?partial enumerate? partial enumeration Page 19 ?ContentStore? Content Store Page 20 "first step after entring? entering "ContentStore ? Content Store Ilya On Jun 19, 2014, at 1:40 AM, Beichuan Zhang wrote: > Hi, > > We?ve been integrating the text of the NFD Developer?s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday. > > The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. > > Thanks, > > Beichuan > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Jun 19 18:50:29 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 19 Jun 2014 18:50:29 -0700 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Message-ID: <9E8CF32E-878D-4B51-9A9E-2E3D1AC7757B@ucla.edu> On Jun 19, 2014, at 11:55 AM, Lan Wang (lanwang) wrote: > > On Jun 19, 2014, at 12:40 AM, Beichuan Zhang > wrote: > >> Hi, >> >> We?ve been integrating the text of the NFD Developer?s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday. >> >> The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. >> > > Some comments for Section 7 (Obaid please check): > > - "The RIB Manager that runs as a separate process, NRD (NFD RIB Daemon)" should be "NRD (NFD RIB Daemon), the RIB Manager that runs as a separate process, ?" No. I think the description is correct. The correct name is NFD RIB Manager and NRD is just an abbreviation of this, not the other way around. > - 19 diagram should be Figure 19. > > - Figure 19 can be bigger and Figure 20 should be much smaller. > > - Figure 19 shows only NLSR. What about other apps? I suggest adding an app's typical interactions with NRD at the end of the time line. Including more stuff may clutter the picture. I'm ok with including more, but just want to make sure we don't include too much. > - It's not clear what this part means: "7.7 Extending RIB Manager > The RIB Manager currently supports only two commands { register and unregister. However, functionality of the RIB > Manager can be extended by introducing more commands. For example, if a node needs to announce a pre x currently, it > has to con gure the routing protocol. A set of commands for advertising and withdrawing pre xes, with the help of any > application, could provide a more uni ed way for the operators to publish name pre xes." > > Isn't advertising and withdrawing prefixes supported through register and unregister already? As I remember, withdraw and advertise were separate commands. At least in the original protocol spec, though I already forgot what was the difference. --- Alex > or are you saying any application should be able to advertise and withdraw prefixes. If this is what you mean, first it's not introducing more commands. It's just allowing regular application to issue the existing commands, right? Also I'm not sure if it's a good to let any application do these things. > > Lan >> Thanks, >> >> Beichuan >> >> >> >> [The attachment nfd-docs.pdf has been manually removed] >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From obaidasyed at gmail.com Thu Jun 19 20:03:24 2014 From: obaidasyed at gmail.com (Syed Obaid Amin) Date: Thu, 19 Jun 2014 22:03:24 -0500 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: <9E8CF32E-878D-4B51-9A9E-2E3D1AC7757B@ucla.edu> References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> <9E8CF32E-878D-4B51-9A9E-2E3D1AC7757B@ucla.edu> Message-ID: On Thu, Jun 19, 2014 at 8:50 PM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > > On Jun 19, 2014, at 11:55 AM, Lan Wang (lanwang) > wrote: > > > > > On Jun 19, 2014, at 12:40 AM, Beichuan Zhang > > wrote: > > > >> Hi, > >> > >> We?ve been integrating the text of the NFD Developer?s Guide, and now > it is in the final stage. Can everyone read the document or part of it, and > email in comments? Any comment would be appreciated. We plan to finish it > by the end of Sunday. > >> > >> The current PDF is attached. If you want the latest version, the > repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. > >> > > > > Some comments for Section 7 (Obaid please check): > > > > - "The RIB Manager that runs as a separate process, NRD (NFD RIB > Daemon)" should be "NRD (NFD RIB Daemon), the RIB Manager that runs as a > separate process, ?" > > No. I think the description is correct. The correct name is NFD RIB > Manager and NRD is just an abbreviation of this, not the other way around. > > > > - 19 diagram should be Figure 19. > > > > - Figure 19 can be bigger and Figure 20 should be much smaller. > > > > - Figure 19 shows only NLSR. What about other apps? I suggest adding > an app's typical interactions with NRD at the end of the time line. > > Including more stuff may clutter the picture. I'm ok with including more, > but just want to make sure we don't include too much. > Showing NLSR allowed me to show both self-registration (which should be same for other apps too) and prefix registration. I also think that adding more would clutter the figure. I can add a note at "Register NLSR" step that further interactions are only valid for NLSR or other routing protocols? > > > - It's not clear what this part means: "7.7 Extending RIB Manager > > The RIB Manager currently supports only two commands { register and > unregister. However, functionality of the RIB > > Manager can be extended by introducing more commands. For example, if a > node needs to announce a pre x currently, it > > has to con gure the routing protocol. A set of commands for advertising > and withdrawing pre xes, with the help of any > > application, could provide a more uni ed way for the operators to > publish name pre xes." > > > > Isn't advertising and withdrawing prefixes supported through register > and unregister already? > > As I remember, withdraw and advertise were separate commands. At least in > the original protocol spec, though I already forgot what was the difference. > Yes, these two commands came from the old protocol specs. We added these commands so that NRD can talk to the routing protocols and can advertise or withdraw name prefixes through them. If I remember correctly, the motivation was to allow a unified way of publishing prefixes, instead of configuring separate routing protocols. Regards, Obaid --- > Alex > > > or are you saying any application should be able to advertise and > withdraw prefixes. If this is what you mean, first it's not introducing > more commands. It's just allowing regular application to issue the > existing commands, right? Also I'm not sure if it's a good to let any > application do these things. > > > > Lan > >> Thanks, > >> > >> Beichuan > >> > >> > >> > >> [The attachment nfd-docs.pdf has been manually removed] > >> > >> _______________________________________________ > >> Nfd-dev mailing list > >> Nfd-dev at lists.cs.ucla.edu > >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > > > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Jun 19 21:58:30 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Fri, 20 Jun 2014 04:58:30 +0000 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> <9E8CF32E-878D-4B51-9A9E-2E3D1AC7757B@ucla.edu> Message-ID: On Jun 19, 2014, at 10:03 PM, Syed Obaid Amin > wrote: On Thu, Jun 19, 2014 at 8:50 PM, Alex Afanasyev > wrote: On Jun 19, 2014, at 11:55 AM, Lan Wang (lanwang) > wrote: > > On Jun 19, 2014, at 12:40 AM, Beichuan Zhang > > wrote: > >> Hi, >> >> We?ve been integrating the text of the NFD Developer?s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday. >> >> The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. >> > > Some comments for Section 7 (Obaid please check): > > - "The RIB Manager that runs as a separate process, NRD (NFD RIB Daemon)" should be "NRD (NFD RIB Daemon), the RIB Manager that runs as a separate process, ?" No. I think the description is correct. The correct name is NFD RIB Manager and NRD is just an abbreviation of this, not the other way around. > - 19 diagram should be Figure 19. > > - Figure 19 can be bigger and Figure 20 should be much smaller. > > - Figure 19 shows only NLSR. What about other apps? I suggest adding an app's typical interactions with NRD at the end of the time line. Including more stuff may clutter the picture. I'm ok with including more, but just want to make sure we don't include too much. Showing NLSR allowed me to show both self-registration (which should be same for other apps too) and prefix registration. I also think that adding more would clutter the figure. I can add a note at "Register NLSR" step that further interactions are only valid for NLSR or other routing protocols? OK, you can also add a note to say that other apps follow the same procedure to self-register their prefixes. > - It's not clear what this part means: "7.7 Extending RIB Manager > The RIB Manager currently supports only two commands { register and unregister. However, functionality of the RIB > Manager can be extended by introducing more commands. For example, if a node needs to announce a pre x currently, it > has to con gure the routing protocol. A set of commands for advertising and withdrawing pre xes, with the help of any > application, could provide a more uni ed way for the operators to publish name pre xes." > > Isn't advertising and withdrawing prefixes supported through register and unregister already? As I remember, withdraw and advertise were separate commands. At least in the original protocol spec, though I already forgot what was the difference. Yes, these two commands came from the old protocol specs. We added these commands so that NRD can talk to the routing protocols and can advertise or withdraw name prefixes through them. If I remember correctly, the motivation was to allow a unified way of publishing prefixes, instead of configuring separate routing protocols. Now I realize that advertise/withdraw is for NRD to tell routing protocols to announce or withdraw prefixes. These prefixes are supposed to be configured into nrd's configuration section. This is optional as long as each routing protocol has a configuration file that allows them to do the same. The register/unregister is for routing protocol to tell NRD to add prefixes into FIB. Lan Regards, Obaid --- Alex > or are you saying any application should be able to advertise and withdraw prefixes. If this is what you mean, first it's not introducing more commands. It's just allowing regular application to issue the existing commands, right? Also I'm not sure if it's a good to let any application do these things. > > Lan >> Thanks, >> >> Beichuan >> >> >> >> [The attachment nfd-docs.pdf has been manually removed] >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Jun 20 09:00:40 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Fri, 20 Jun 2014 16:00:40 +0000 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Message-ID: Hi, Below are some comments based on a pretty quick read of the document. I hope this is helpful. It's really exciting to have this as a starting point for understanding NFD, and I am looking forward to the NFD team's updates over time... Thanks, Jeff Big picture comments: 1. 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. 2. 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.) a. 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. b. 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. 3. 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. 4. 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 5. A future work / open issues section would be helpful. 6. Utilities (6.2) should likely be last in the document, and probably integrated with Section 9. 7. 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.? 8. Diagrams could be made more consistent, and you may want to allocate space based on their complexity. a. E.g., Figure 2 is really useful and has a lot of information, but is only given the same space a Figure 7. b. In fact, having more diagrams like Figure 2 per section would be very helpful. c. 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. d. There are too many visual styles of diagrams, but this could be fixed later. 9. 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. 10. 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. 11. When describing specific relationships, ?Management calls Cs::setLimit?, perhaps it is better to say which manager(s) specifically? Management is used generally several times 12. Summary figures like Fig 18 could perhaps come earlier 13. Should there be timing diagrams (p36) for other components besides the RIB manager? More low-level details: 1. ?Listen only? should be defined (p6) 2. Guiders and selectors are undefined but used occasionally 3. Tables should have numbers and captions 4. Colloquialisms should be avoided in technical definitions: ?starting point? and "understands" (p6) 5. The configuration file mentioned on p8 is not explained until much later, so the intro of section 2.4 is a little confusing. 6. The title of Section 3 should include all tables it discusses or no tables. 7. The ?unsatisfy timer? is a little confusing, as ?unsatisfy? is not a typical English word, and on p13 the explanation makes it a little unclear whether it refers to a PIT entry or the whole PIT. 8. Sections 3.4 and 3.5 really should come after or in the strategy section. 9. What it means to ?install a strategy? should be explained. 10. It?s unclear why the word ?choice? is in the strategy table name; perhaps this could be briefly explained. 11. The notion of an ?operator? is used several times but undefined. (And ?local operator? is used on p14.) This is actually a big-picture note, I guess. If the assumption is that NFD implements a stack on end-user devices, this word should be used sparingly or not at all. Footnote 3 is another example. I think the notion of an ?NFD operator? should be explained earlier or dropped. 12. What makes a strategy effective? Who is expected to write / override findEffectiveStrategy? (p14) Integrating the strategy table and strategy sections might help answer this easily. 13. The example of an anti-DDOS strategy begs the question of whether strategies can be composed together / more than one can operate on a packet. 14. Early in the document, performance optimizations are stated as a non-goal (for now) but on p16, it is used to motivate a custom hash table implementation. 15. A lot of detail is given on the NameTree (p17, etc.) ? perhaps an explanation of when it is expected that a developer would need to know the details / extend it would be helpful. 16. What?s the purpose of introducing ?Host? relative to Strategy Info? It?s the only non-TCP/IP mention of host in the document except for the notion of ?localhost?, which probably needs to be defined as well... why in the non-host-based world of NDN, is this so central (p26) 17. In 5.2.4, the NCC acronym needs to be written out, and probably a short explanation should be given so one does not have to go back to the CCNx doc. 18. What is a LocalControlHeader and a NextHopFaceId? Is this documented in the protocol specification? ? perhaps should have a citation, as it will be new for most people. 19. Section 5.3.1 is very useful, and there should be more like it. (However, the first sentence seems to overstate our knowledge at this time.) 20. The notion of an ?authorized user? is introduced on p29/p30 without explanation. 21. As with ?operator? I would recommend either explaining ?user? (p29-30) or eliminating it. What does user mean in the context of NFD-as-future-stack vs. NFD-as-standalone-forwarder? Similarly, ?administrator? is used only once on p40. 22. The configuration section of 6.1.2 is helpful ? perhaps somewhere there should be a section that explains what happens when you start NFD, and how it relates to all of these modules? 23. ?protect NFD from errors? may need rephrasing. Why would NFD need protecting? (p31) 24. URIs are introduced on p31, what is a FaceUri? 25. The bullet list on p31 seems focused on unicast faces; perhaps should cover all kinds? 26. What is dataset? (p32) Does this new term need to be introduced? May want to explain why measurement data is only available locally. 27. What are status codes and how are they used? (Introduced without much fanfare in section 6 ? perhaps just need a few more references to the management protocol doc?) 28. Consider providing the RFC reference for the websocket implementation being used. 29. The details of the command interest format don?t seem in the right place at the beginning of the trust model section, as it's something of an implementation / protocol detail ? in most other cases in the document, protocols are defined elsewhere. The security section seems somewhat sparse in general ? e.g., the seemingly critical term ?NDN identity certificate? is introduced without much fanfare, as are NDN Regular Expressions, which seem to be a significant and important topic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at seas.wustl.edu Fri Jun 20 09:14:14 2014 From: jdd at seas.wustl.edu (John DeHart) Date: Fri, 20 Jun 2014 11:14:14 -0500 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Message-ID: <53A45DD6.5010003@seas.wustl.edu> I'm doing a quick skim and have formatting issues in the following sections where text runs off into the right margin. There is also perhaps text lost there. 2.1 3.6.2 4.2.4 9.1.1 (near the end) 9.6 9.8 I'll try to get back to it some more before Sunday. John On 6/19/14, 12:40 AM, Beichuan Zhang wrote: > Hi, > > We?ve been integrating the text of the NFD Developer?s Guide, and now > it is in the final stage. Can everyone read the document or part of > it, and email in comments? Any comment would be appreciated. We plan > to finish it by the end of Sunday. > > The current PDF is attached. If you want the latest version, the > repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. > > Thanks, > > Beichuan > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From iliamo at ucla.edu Fri Jun 20 14:02:09 2014 From: iliamo at ucla.edu (Ilya Moiseenko) Date: Fri, 20 Jun 2014 17:02:09 -0400 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: <53A45DD6.5010003@seas.wustl.edu> References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> <53A45DD6.5010003@seas.wustl.edu> Message-ID: Page 25 ?list of the provided build-in strategies? built-in Page 27 ?only purpose of the strategy is to decides? decide ?forwarding pipelines..? remove comma Page 29 ?in particular, users can manipulate the:? sentence is unfinished ?destruction and enable/disable? enabling/disabling Page 39 ?timestamp state for each trusted public key ? missing comma Page 40 ?remote manchines? typo What is the access router? ?testbed site or instituion? typo ?register prefixes However? missing comma Page 41 ?regain superuser privileges in orde to? typo Ilya On Jun 20, 2014, at 12:14 PM, John DeHart wrote: > > I'm doing a quick skim and have formatting issues in the following sections > where text runs off into the right margin. There is also perhaps text lost there. > 2.1 > 3.6.2 > 4.2.4 > 9.1.1 (near the end) > 9.6 > 9.8 > > I'll try to get back to it some more before Sunday. > > John > > On 6/19/14, 12:40 AM, Beichuan Zhang wrote: >> Hi, >> >> We?ve been integrating the text of the NFD Developer?s Guide, and now it is in the final stage. Can everyone read the document or part of it, and email in comments? Any comment would be appreciated. We plan to finish it by the end of Sunday. >> >> The current PDF is attached. If you want the latest version, the repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git. >> >> Thanks, >> >> Beichuan >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Sat Jun 21 18:25:04 2014 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Sun, 22 Jun 2014 09:25:04 +0800 Subject: [Nfd-dev] comments for the nfd doc In-Reply-To: References: <30E664C6-0C8E-4D7A-AEAB-7DC2521C44FF@cs.arizona.edu> Message-ID: 20140622 NFD conference call discusses the big picture comments from Jeff Burke. On Sat, Jun 21, 2014 at 12:00 AM, Burke, Jeff wrote: > > Big picture comments: > > > > 1. 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. > We should expand the introduction: pick something from later sections and put in introduction. Contents in later sections should not be reduced. 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). Within this text, we should introduce all the major concepts. > > > 2. 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.) > > > > a. 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. > > > > b. 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. > This cannot be completed within 0.2 timeline, but we can consider it for next version. > > > 3. 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. > Agreed. > > > 4. 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 > We should create a "scope control" page on NFD website, which becomes part of protocol. This document is then cited in Developer Guide. > > > 5. A future work / open issues section would be helpful. > This does not belong in this document. Future work and open issues are on Redmine. We should create a webpage on NFD website. > > > 6. Utilities (6.2) should likely be last in the document, and > probably integrated with Section 9. > No. These classes are internal to management. They are not common services. We shall change the title to "Utilities for managers". > > > 7. 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.? > Agreed. > > > 8. Diagrams could be made more consistent, and you may want to > allocate space based on their complexity. > > > > a. E.g., Figure 2 is really useful and has a lot of information, but > is only given the same space a Figure 7. > > > > b. In fact, having more diagrams like Figure 2 per section would be > very helpful. > > > > c. 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. > > > > d. There are too many visual styles of diagrams, but this could be > fixed later. > We'll try to improve if time permits. > > > 9. 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. > No. They refer to the physical world: communication medias and computers. > > > 10. 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. > 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. 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.". > > > 11. When describing specific relationships, ?Management calls > Cs::setLimit?, perhaps it is better to say which manager(s) specifically? > Management is used generally several times > Agreed. This can be changed as "Management changes ContentStore capacity via Cs::setLimit". > > > 12. Summary figures like Fig 18 could perhaps come earlier > There's no need to distinguish between applications and routing protocol. 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. RIB Daemon can point to NFD with "FIB update". > > > 13. Should there be timing diagrams (p36) for other components besides > the RIB manager? > No. We shouldn't apply timing diagram to other sections. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jun 24 06:22:57 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 24 Jun 2014 21:22:57 +0800 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB Message-ID: This is a design proposal for NFD RIB Daemon. Background RIB Management functionality is implemented as a separate process: NFD RIB Daemon. RIB Daemon processes RIB updates from local applications and routing protocols, and then synchronizes the RIB to the FIB in main NFD process via FIB Management protocol. Currently, RIB Daemon has a RibManager component that is responsible for processing RIB updates, and a RIB data structure which is exclusively accessed by the RibManager. Historically, before RIB is implemented, RIB Daemon is a pass-through protocol translator that translates each RIB update into one FIB update, ignoring route inheritance flags. In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete. Problem Task 1326 implements Route expiration in RIB: when a Route (prefix registration) expires, the FaceEntry is removed from the RIB, which shall trigger FIB updates. During the code review http://gerrit.named-data.net/911 (patchset 4 rib-manager.cpp), a question is raised: should RibManager set the timer to remove the FaceEntry and trigger FIB updates, or should the RIB set the timer and notify RibManager? Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB. This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync. A related problem is: if a RIB update triggers multiple FIB updates, if some FIB updates succeed but others fail, RIB and FIB will also be out-of-sync. Proposed Design RibManager updates the RIB only; it does not directly update the FIB. RIB updates are batched. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. The RIB update procedure has admission control: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. If any FIB update fails, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) in other cases, the FIB update is retried. If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. Benefits The proposed design decouples FIB updates from RIB updates. A RIB update, regardless of source, can trigger FIB updates. If a RIB update *command* needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Tue Jun 24 07:08:56 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Tue, 24 Jun 2014 14:08:56 +0000 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: Message-ID: Junxiao, Though it's only related indirectly, I wanted to re-raise an issue earlier: I think prefix registration by applications should be simple and fast ? they are common, impact application startup time and responsiveness, and are a conceptually lightweight part of any two-way NDN communication. If they is handled through the mechanisms described below, which are also intended for more complex routing setup, it would be great if this could be done in such away that there is low latency and CPU overhead for local application prefix registration. I'm not sure what "low" is until considering it further, except to propose O(10ms) per local prefix registration rather than O(1s). Jeff From: Junxiao Shi > Date: Tue, 24 Jun 2014 21:22:57 +0800 To: ">" > Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB This is a design proposal for NFD RIB Daemon. Background RIB Management functionality is implemented as a separate process: NFD RIB Daemon. RIB Daemon processes RIB updates from local applications and routing protocols, and then synchronizes the RIB to the FIB in main NFD process via FIB Management protocol. Currently, RIB Daemon has a RibManager component that is responsible for processing RIB updates, and a RIB data structure which is exclusively accessed by the RibManager. Historically, before RIB is implemented, RIB Daemon is a pass-through protocol translator that translates each RIB update into one FIB update, ignoring route inheritance flags. In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete. Problem Task 1326 implements Route expiration in RIB: when a Route (prefix registration) expires, the FaceEntry is removed from the RIB, which shall trigger FIB updates. During the code review http://gerrit.named-data.net/911 (patchset 4 rib-manager.cpp), a question is raised: should RibManager set the timer to remove the FaceEntry and trigger FIB updates, or should the RIB set the timer and notify RibManager? Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB. This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync. A related problem is: if a RIB update triggers multiple FIB updates, if some FIB updates succeed but others fail, RIB and FIB will also be out-of-sync. Proposed Design RibManager updates the RIB only; it does not directly update the FIB. RIB updates are batched. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. The RIB update procedure has admission control: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. If any FIB update fails, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) in other cases, the FIB update is retried. If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. Benefits The proposed design decouples FIB updates from RIB updates. A RIB update, regardless of source, can trigger FIB updates. If a RIB update command needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB. Yours, Junxiao _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jun 24 07:30:09 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 24 Jun 2014 22:30:09 +0800 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: References: Message-ID: Hi Jeff It's possible to achieve 10ms prefix registration if RibManager responds to the request before FIB updates are complete. However, Interests will not be delivered to the application until FIB updates are complete. This may cause problem in the following scenario: 1. The email client registers a prefix for the email to be sent. 2. After the prefix registration is complete (RIB update request is answered), the email client sends a command to the server, which requests the server to retrieve the email. 3. The email server expresses an Interest toward the client. If the FIB updates are not completed before step 3, the email server will be unable to retrieve the email. Therefore, we think RIB Daemon should not answer a prefix registration request from application before all FIB updates are complete. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Tue Jun 24 10:26:52 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Tue, 24 Jun 2014 17:26:52 +0000 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: Message-ID: Hi Junxiao, Thanks for the quickly reply. Yes, I understand the reason not to return the request before the update is complete. What I am suggesting is that the return needs to be as fast as possible, so that applications do not need to block on this too long or consider it a Big Deal. Seems like the moral equivalent of prefix registration in today's apps s opening a socket or at the most starting an HTTPS server in today's apps, and we should have similar targets of responsiveness. Jeff From: Junxiao Shi > Date: Tue, 24 Jun 2014 22:30:09 +0800 To: Jeff Burke > Cc: ">" > Subject: Re: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB Hi Jeff It's possible to achieve 10ms prefix registration if RibManager responds to the request before FIB updates are complete. However, Interests will not be delivered to the application until FIB updates are complete. This may cause problem in the following scenario: 1. The email client registers a prefix for the email to be sent. 2. After the prefix registration is complete (RIB update request is answered), the email client sends a command to the server, which requests the server to retrieve the email. 3. The email server expresses an Interest toward the client. If the FIB updates are not completed before step 3, the email server will be unable to retrieve the email. Therefore, we think RIB Daemon should not answer a prefix registration request from application before all FIB updates are complete. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Jun 24 11:07:59 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 24 Jun 2014 18:07:59 +0000 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: References: Message-ID: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> Junxiao, I've asked Vince and Obaid to look at this proposal closely. But before you sent this proposal, Obaid and I already talked about the route expiration issue you raised, and he will implement the EvenTimer approach you suggested -- RIB maintains the time-out and sends a signal to RIBManager when the timer expires. Just FYI. Lan On Jun 24, 2014, at 8:22 AM, Junxiao Shi > wrote: This is a design proposal for NFD RIB Daemon. Background RIB Management functionality is implemented as a separate process: NFD RIB Daemon. RIB Daemon processes RIB updates from local applications and routing protocols, and then synchronizes the RIB to the FIB in main NFD process via FIB Management protocol. Currently, RIB Daemon has a RibManager component that is responsible for processing RIB updates, and a RIB data structure which is exclusively accessed by the RibManager. Historically, before RIB is implemented, RIB Daemon is a pass-through protocol translator that translates each RIB update into one FIB update, ignoring route inheritance flags. In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete. Problem Task 1326 implements Route expiration in RIB: when a Route (prefix registration) expires, the FaceEntry is removed from the RIB, which shall trigger FIB updates. During the code review http://gerrit.named-data.net/911 (patchset 4 rib-manager.cpp), a question is raised: should RibManager set the timer to remove the FaceEntry and trigger FIB updates, or should the RIB set the timer and notify RibManager? Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB. This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync. A related problem is: if a RIB update triggers multiple FIB updates, if some FIB updates succeed but others fail, RIB and FIB will also be out-of-sync. Proposed Design RibManager updates the RIB only; it does not directly update the FIB. RIB updates are batched. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. The RIB update procedure has admission control: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. If any FIB update fails, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) in other cases, the FIB update is retried. If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. Benefits The proposed design decouples FIB updates from RIB updates. A RIB update, regardless of source, can trigger FIB updates. If a RIB update command needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From obaidasyed at gmail.com Tue Jun 24 12:08:40 2014 From: obaidasyed at gmail.com (Syed Obaid Amin) Date: Tue, 24 Jun 2014 14:08:40 -0500 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> References: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> Message-ID: Lan, I left a comment on gerrit last night regarding a problem in using EventEmitter. This proposal of Junxiao is one of the possible solutions for that problem. Please see the following link for the details: http://gerrit.named-data.net/#/c/911/4/rib/rib-manager.cpp If we use EventEmitter then we need to make these changes as well, which I think would take time. Therefore I suggested that for v0.2 we can use the code that we have under review for task #1326 ( http://redmine.named-data.net/issues/1326). For later release we can use EventEmitter approach. Regards, Obaid On Tue, Jun 24, 2014 at 1:07 PM, Lan Wang (lanwang) wrote: > Junxiao, > > I've asked Vince and Obaid to look at this proposal closely. But before > you sent this proposal, Obaid and I already talked about the route > expiration issue you raised, and he will implement the EvenTimer approach > you suggested -- RIB maintains the time-out and sends a signal to > RIBManager when the timer expires. Just FYI. > > Lan > > On Jun 24, 2014, at 8:22 AM, Junxiao Shi > wrote: > > This is a design proposal for NFD RIB Daemon. > > Background > RIB Management functionality is implemented as a separate process: NFD RIB > Daemon. > RIB Daemon processes RIB updates from local applications and routing > protocols, and then synchronizes the RIB to the FIB in main NFD process via > FIB Management protocol. > Currently, RIB Daemon has a RibManager component that is responsible for > processing RIB updates, and a RIB data structure which is exclusively > accessed by the RibManager. > Historically, before RIB is implemented, RIB Daemon is a pass-through > protocol translator that translates each RIB update into one FIB update, > ignoring route inheritance flags. > In the protocol translator, FIB updates are sent from RibManager, and a > RIB update command is answered after the corresponding FIB update is > complete. > > Problem > Task 1326 implements Route expiration in RIB: when a Route (prefix > registration) expires, the FaceEntry is removed from the RIB, which shall > trigger FIB updates. > During the code review http://gerrit.named-data.net/911 (patchset 4 > rib-manager.cpp), a question is raised: should RibManager set the timer to > remove the FaceEntry and trigger FIB updates, or should the RIB set the > timer and notify RibManager? > Reviewer opinion is: expiration period is an attribute of a Route, so > the timer should be set in RIB. > This leads to another problem: after removing the FaceEntry, if the FIB > update(s) fails, RIB and FIB will be out-of-sync. > A related problem is: if a RIB update triggers multiple FIB updates, if > some FIB updates succeed but others fail, RIB and FIB will also be > out-of-sync. > > Proposed Design > RibManager updates the RIB only; it does not directly update the FIB. > > RIB updates are batched. A batch of RIB updates is packaged into a > RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object > must refer to the same face. > When RibManager receives one or more RIB updates, it generates a > RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB > update procedure. > When one or more Route expires, the RIB itself generates a > RibUpdateBatch, and begin the RIB update procedure. > > The RIB update procedure has admission control: if a previous > RibUpdateBatch is in progress, the new batch will be put in a queue until > the previous batch is complete. > To apply a batch of RIB updates, the current collection of RIB entries and > the RibUpdateBatch are passed to FibUpdater component to compute the > optimal set of FIB updates, and the FibUpdater component shall send these > FIB updates. > If any FIB update fails, (a) in case of a non-recoverable error (eg. > signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) > in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) > in other cases, the FIB update is retried. > If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after > all FIB updates are successful, the RIB entries are updated. > > For a prefix registration request from application, the RibManager > should pass a callback to Rib::beginApplyUpdate, which is called after all > FIB updates are successful and the RIB is updated. The called function can > respond to the prefix registration request. > For routing updates, the RibManager can respond with "100 continue" or > similar code right away without waiting for FIB updates to complete. > > Benefits > The proposed design decouples FIB updates from RIB updates. > A RIB update, regardless of source, can trigger FIB updates. > If a RIB update *command* needs to wait for the RIB update and FIB > updates to complete, RibManager can wait on a callback from the RIB. > > > > Yours, Junxiao > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Jun 24 14:33:54 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 24 Jun 2014 21:33:54 +0000 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: References: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> Message-ID: I agree with keeping the current code for v0.2. But for later release, we need to agree on what specific approach to follow. Do you have any comments for Junxiao's proposal? Lan On Jun 24, 2014, at 2:08 PM, Syed Obaid Amin > wrote: Lan, I left a comment on gerrit last night regarding a problem in using EventEmitter. This proposal of Junxiao is one of the possible solutions for that problem. Please see the following link for the details: http://gerrit.named-data.net/#/c/911/4/rib/rib-manager.cpp If we use EventEmitter then we need to make these changes as well, which I think would take time. Therefore I suggested that for v0.2 we can use the code that we have under review for task #1326 (http://redmine.named-data.net/issues/1326). For later release we can use EventEmitter approach. Regards, Obaid On Tue, Jun 24, 2014 at 1:07 PM, Lan Wang (lanwang) > wrote: Junxiao, I've asked Vince and Obaid to look at this proposal closely. But before you sent this proposal, Obaid and I already talked about the route expiration issue you raised, and he will implement the EvenTimer approach you suggested -- RIB maintains the time-out and sends a signal to RIBManager when the timer expires. Just FYI. Lan On Jun 24, 2014, at 8:22 AM, Junxiao Shi > wrote: This is a design proposal for NFD RIB Daemon. Background RIB Management functionality is implemented as a separate process: NFD RIB Daemon. RIB Daemon processes RIB updates from local applications and routing protocols, and then synchronizes the RIB to the FIB in main NFD process via FIB Management protocol. Currently, RIB Daemon has a RibManager component that is responsible for processing RIB updates, and a RIB data structure which is exclusively accessed by the RibManager. Historically, before RIB is implemented, RIB Daemon is a pass-through protocol translator that translates each RIB update into one FIB update, ignoring route inheritance flags. In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete. Problem Task 1326 implements Route expiration in RIB: when a Route (prefix registration) expires, the FaceEntry is removed from the RIB, which shall trigger FIB updates. During the code review http://gerrit.named-data.net/911 (patchset 4 rib-manager.cpp), a question is raised: should RibManager set the timer to remove the FaceEntry and trigger FIB updates, or should the RIB set the timer and notify RibManager? Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB. This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync. A related problem is: if a RIB update triggers multiple FIB updates, if some FIB updates succeed but others fail, RIB and FIB will also be out-of-sync. Proposed Design RibManager updates the RIB only; it does not directly update the FIB. RIB updates are batched. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. The RIB update procedure has admission control: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. If any FIB update fails, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) in other cases, the FIB update is retried. If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. Benefits The proposed design decouples FIB updates from RIB updates. A RIB update, regardless of source, can trigger FIB updates. If a RIB update command needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzhang at cs.arizona.edu Tue Jun 24 19:13:34 2014 From: bzhang at cs.arizona.edu (Beichuan Zhang) Date: Wed, 25 Jun 2014 10:13:34 +0800 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: References: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> Message-ID: <2583A1E1-2ADD-4BA8-882E-C7393118CA24@cs.arizona.edu> I just finished a call with Alex/Junxiao/Steve. Junxiao?s estimate is that this task (http://redmine.named-data.net/issues/1326) shouldn?t take too long, at least less than the time for finishing the RIB/FIB update code (http://redmine.named-data.net/issues/1325). So we suggest making these changes, but to make clear what changes we?re talking about, here?s my understanding: - RibManager doesn?t issue FIB updates. They are issued by the module implemented in task #1325. - RibManager doesn?t set/maintain route expiration timers. They are set/maintained by the RIB using EventEmitter. - In all cases, FIB should be updated first, then the RIB. + what is the current code doing? I guess to generate FIB updates, the code may need to update the RIB first, or at least traverse the RIB trie. Not sure how to consolidate these two. - One RIB update can generate multiple FIB updates, which may take time to complete. >>> For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. >>> For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. - If a RIB triggers multiple FIB updates, and one of them fails, take actions according to the reason of the failure: (a) Signing key of RIB Daemon is not trusted: the RIB Daemon should stop. (b) The face doesn?t exist: the RIB update is abandoned, thus the RIB is not changed. (c) Timeout (e.g., NFD is too busy): retry the remaining FIB updates. - Junxiao?s proposal has a part of bundling some RIB updates together as a batch. All RIB updates in the same batch must have the same nexthop face. Therefore when FIB update fails due to non-existent face, all RIB updates in the same batch can be abandoned at once. This is to improve the performance, but I?m not sure how much it helps. We don?t need this code for this release. If you agree with the design, you may implement the interface. Beichuan On Jun 25, 2014, at 5:33 AM, Lan Wang (lanwang) wrote: > I agree with keeping the current code for v0.2. But for later release, we need to agree on what specific approach to follow. Do you have any comments for Junxiao's proposal? > > Lan > On Jun 24, 2014, at 2:08 PM, Syed Obaid Amin wrote: > >> Lan, >> >> I left a comment on gerrit last night regarding a problem in using EventEmitter. This proposal of Junxiao is one of the possible solutions for that problem. Please see the following link for the details: >> >> http://gerrit.named-data.net/#/c/911/4/rib/rib-manager.cpp >> >> If we use EventEmitter then we need to make these changes as well, which I think would take time. Therefore I suggested that for v0.2 we can use the code that we have under review for task #1326 (http://redmine.named-data.net/issues/1326). For later release we can use EventEmitter approach. >> >> Regards, >> Obaid >> >> >> On Tue, Jun 24, 2014 at 1:07 PM, Lan Wang (lanwang) wrote: >> Junxiao, >> >> I've asked Vince and Obaid to look at this proposal closely. But before you sent this proposal, Obaid and I already talked about the route expiration issue you raised, and he will implement the EvenTimer approach you suggested -- RIB maintains the time-out and sends a signal to RIBManager when the timer expires. Just FYI. >> >> Lan >> >> On Jun 24, 2014, at 8:22 AM, Junxiao Shi wrote: >> >>> This is a design proposal for NFD RIB Daemon. >>> >>> Background >>> RIB Management functionality is implemented as a separate process: NFD RIB Daemon. >>> RIB Daemon processes RIB updates from local applications and routing protocols, and then synchronizes the RIB to the FIB in main NFD process via FIB Management protocol. >>> Currently, RIB Daemon has a RibManager component that is responsible for processing RIB updates, and a RIB data structure which is exclusively accessed by the RibManager. >>> Historically, before RIB is implemented, RIB Daemon is a pass-through protocol translator that translates each RIB update into one FIB update, ignoring route inheritance flags. >>> In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete. >>> >>> Problem >>> Task 1326 implements Route expiration in RIB: when a Route (prefix registration) expires, the FaceEntry is removed from the RIB, which shall trigger FIB updates. >>> During the code review http://gerrit.named-data.net/911 (patchset 4 rib-manager.cpp), a question is raised: should RibManager set the timer to remove the FaceEntry and trigger FIB updates, or should the RIB set the timer and notify RibManager? >>> Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB. >>> This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync. >>> A related problem is: if a RIB update triggers multiple FIB updates, if some FIB updates succeed but others fail, RIB and FIB will also be out-of-sync. >>> >>> Proposed Design >>> RibManager updates the RIB only; it does not directly update the FIB. >>> >>> RIB updates are batched. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. >>> When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. >>> When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. >>> >>> The RIB update procedure has admission control: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. >>> To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. >>> If any FIB update fails, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) in other cases, the FIB update is retried. >>> If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. >>> >>> For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. >>> For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. >>> >>> Benefits >>> The proposed design decouples FIB updates from RIB updates. >>> A RIB update, regardless of source, can trigger FIB updates. >>> If a RIB update command needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB. >>> >>> >>> >>> Yours, Junxiao >> >> > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.EDU Tue Jun 24 20:25:12 2014 From: lanwang at memphis.EDU (Lan Wang (lanwang)) Date: Wed, 25 Jun 2014 03:25:12 +0000 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: <2583A1E1-2ADD-4BA8-882E-C7393118CA24@cs.arizona.edu> References: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> , <2583A1E1-2ADD-4BA8-882E-C7393118CA24@cs.arizona.edu> Message-ID: Just realized one issue: if we really want to be consistent, then we also need to reverse all fib updates that belong to the same rib update if any of them fails. This would require keeping state of the original fib. Also batching rib updates may make this reversal difficult if the fib updates for several rib updates to one optimal set. There may be other complexities related to this. Just want to raise awareness. Lan -------- Original message -------- From: Beichuan Zhang Date: 06/24/2014 9:13 PM (GMT-06:00) To: "Lan Wang (lanwang)" Cc: Syed Obaid Amin ,"" Subject: Re: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB I just finished a call with Alex/Junxiao/Steve. Junxiao?s estimate is that this task (http://redmine.named-data.net/issues/1326) shouldn?t take too long, at least less than the time for finishing the RIB/FIB update code (http://redmine.named-data.net/issues/1325). So we suggest making these changes, but to make clear what changes we?re talking about, here?s my understanding: - RibManager doesn?t issue FIB updates. They are issued by the module implemented in task #1325. - RibManager doesn?t set/maintain route expiration timers. They are set/maintained by the RIB using EventEmitter. - In all cases, FIB should be updated first, then the RIB. + what is the current code doing? I guess to generate FIB updates, the code may need to update the RIB first, or at least traverse the RIB trie. Not sure how to consolidate these two. - One RIB update can generate multiple FIB updates, which may take time to complete. For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. - If a RIB triggers multiple FIB updates, and one of them fails, take actions according to the reason of the failure: (a) Signing key of RIB Daemon is not trusted: the RIB Daemon should stop. (b) The face doesn?t exist: the RIB update is abandoned, thus the RIB is not changed. (c) Timeout (e.g., NFD is too busy): retry the remaining FIB updates. - Junxiao?s proposal has a part of bundling some RIB updates together as a batch. All RIB updates in the same batch must have the same nexthop face. Therefore when FIB update fails due to non-existent face, all RIB updates in the same batch can be abandoned at once. This is to improve the performance, but I?m not sure how much it helps. We don?t need this code for this release. If you agree with the design, you may implement the interface. Beichuan On Jun 25, 2014, at 5:33 AM, Lan Wang (lanwang) > wrote: I agree with keeping the current code for v0.2. But for later release, we need to agree on what specific approach to follow. Do you have any comments for Junxiao's proposal? Lan On Jun 24, 2014, at 2:08 PM, Syed Obaid Amin > wrote: Lan, I left a comment on gerrit last night regarding a problem in using EventEmitter. This proposal of Junxiao is one of the possible solutions for that problem. Please see the following link for the details: http://gerrit.named-data.net/#/c/911/4/rib/rib-manager.cpp If we use EventEmitter then we need to make these changes as well, which I think would take time. Therefore I suggested that for v0.2 we can use the code that we have under review for task #1326 (http://redmine.named-data.net/issues/1326). For later release we can use EventEmitter approach. Regards, Obaid On Tue, Jun 24, 2014 at 1:07 PM, Lan Wang (lanwang) > wrote: Junxiao, I've asked Vince and Obaid to look at this proposal closely. But before you sent this proposal, Obaid and I already talked about the route expiration issue you raised, and he will implement the EvenTimer approach you suggested -- RIB maintains the time-out and sends a signal to RIBManager when the timer expires. Just FYI. Lan On Jun 24, 2014, at 8:22 AM, Junxiao Shi > wrote: This is a design proposal for NFD RIB Daemon. Background RIB Management functionality is implemented as a separate process: NFD RIB Daemon. RIB Daemon processes RIB updates from local applications and routing protocols, and then synchronizes the RIB to the FIB in main NFD process via FIB Management protocol. Currently, RIB Daemon has a RibManager component that is responsible for processing RIB updates, and a RIB data structure which is exclusively accessed by the RibManager. Historically, before RIB is implemented, RIB Daemon is a pass-through protocol translator that translates each RIB update into one FIB update, ignoring route inheritance flags. In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete. Problem Task 1326 implements Route expiration in RIB: when a Route (prefix registration) expires, the FaceEntry is removed from the RIB, which shall trigger FIB updates. During the code review http://gerrit.named-data.net/911 (patchset 4 rib-manager.cpp), a question is raised: should RibManager set the timer to remove the FaceEntry and trigger FIB updates, or should the RIB set the timer and notify RibManager? Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB. This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync. A related problem is: if a RIB update triggers multiple FIB updates, if some FIB updates succeed but others fail, RIB and FIB will also be out-of-sync. Proposed Design RibManager updates the RIB only; it does not directly update the FIB. RIB updates are batched. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. The RIB update procedure has admission control: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. If any FIB update fails, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b) in case of a non-existent face error, the RibUpdateBatch is abandoned; (c) in other cases, the FIB update is retried. If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. For a prefix registration request from application, the RibManager should pass a callback to Rib::beginApplyUpdate, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete. Benefits The proposed design decouples FIB updates from RIB updates. A RIB update, regardless of source, can trigger FIB updates. If a RIB update command needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB. Yours, Junxiao _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jun 24 21:34:18 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 25 Jun 2014 12:34:18 +0800 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: References: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> <2583A1E1-2ADD-4BA8-882E-C7393118CA24@cs.arizona.edu> Message-ID: Dear folks The only reasons for FIB update failures are: (a) authentication error; (b) face is closed; (c) timeouts. - Authentication error (RIB Daemon's certificate is not trusted by NFD) is not recoverable, so RIB Daemon should crash. - If face is closed, the whole batch is abandoned because all RIB updates in the batch are referring to a non-existent face; FIB reversing is unnecessary, because FIB will independently delete all NextHop records using the closing face. - In case of a timeout, the FIB update should be retried until it succeeds or has an unrecoverable failure, or until the face is closed. In any of the above reasons, FIB reversing is unnecessary. Yours, Junxiao On Wed, Jun 25, 2014 at 11:25 AM, Lan Wang (lanwang) wrote: > Just realized one issue: if we really want to be consistent, then we > also need to reverse all fib updates that belong to the same rib update if > any of them fails. This would require keeping state of the original fib. > Also batching rib updates may make this reversal difficult if the fib > updates for several rib updates to one optimal set. There may be other > complexities related to this. Just want to raise awareness. > > Lan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Jun 24 22:55:19 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 25 Jun 2014 05:55:19 +0000 Subject: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB In-Reply-To: References: <2B143634-5DD8-4021-BDB5-F835C936D2BA@memphis.edu> <2583A1E1-2ADD-4BA8-882E-C7393118CA24@cs.arizona.edu> , Message-ID: Just a couple comments: - the rib manager already handles face closing by removing rib entries with the closed face (it subscribes to face events) . I think if the rib manager keeps the closed face info in a list, it can check the list before generating any fib updates and directly rejects a rib update. - the other failures can also be handled by the rib manager. In the authentication case, it just crashes immediately. Whatever is in the rib doesn't matter if it is going to crash anyway. In the second case, the rib manager can try a few times too using a timer. I discussed this with Vince before. If it still doesn' work, just reverse the rib update (eg remove a rib entry if it was inserted). Lan -------- Original message -------- From: Junxiao Shi Date: 06/24/2014 11:34 PM (GMT-06:00) To: "Lan Wang (lanwang)" Cc: Beichuan Zhang ,"" Subject: Re: [Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB Dear folks The only reasons for FIB update failures are: (a) authentication error; (b) face is closed; (c) timeouts. * Authentication error (RIB Daemon's certificate is not trusted by NFD) is not recoverable, so RIB Daemon should crash. * If face is closed, the whole batch is abandoned because all RIB updates in the batch are referring to a non-existent face; FIB reversing is unnecessary, because FIB will independently delete all NextHop records using the closing face. * In case of a timeout, the FIB update should be retried until it succeeds or has an unrecoverable failure, or until the face is closed. In any of the above reasons, FIB reversing is unnecessary. Yours, Junxiao On Wed, Jun 25, 2014 at 11:25 AM, Lan Wang (lanwang) > wrote: Just realized one issue: if we really want to be consistent, then we also need to reverse all fib updates that belong to the same rib update if any of them fails. This would require keeping state of the original fib. Also batching rib updates may make this reversal difficult if the fib updates for several rib updates to one optimal set. There may be other complexities related to this. Just want to raise awareness. Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: