<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
Junxiao,</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div><font face="Calibri,sans-serif">Though it's only related indirectly, I wanted to re-raise an issue earlier: I think prefix registration by applications should be simple and </font><font face="Calibri,sans-serif"><i>fast – </i>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). </font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">Jeff</font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Date: </span>Tue, 24 Jun 2014 21:22:57 +0800<br>
<span style="font-weight:bold">To: </span>"<<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>[Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div dir="ltr">This is a design proposal for NFD RIB Daemon.
<div><br>
</div>
<div><font size="4">Background</font></div>
<div>RIB Management functionality is implemented as a separate process: NFD RIB Daemon.</div>
<div>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.</div>
<div>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.</div>
<div>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.</div>
<div>In the protocol translator, FIB updates are sent from RibManager, and a RIB update command is answered after the corresponding FIB update is complete.</div>
<div><br>
</div>
<div><font size="4">Problem</font></div>
<div>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.</div>
<div>During the code review <a href="http://gerrit.named-data.net/911">http://gerrit.named-data.net/911</a> (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?<br>
</div>
<div>Reviewer opinion is: expiration period is an attribute of a Route, so the timer should be set in RIB.</div>
<div>This leads to another problem: after removing the FaceEntry, if the FIB update(s) fails, RIB and FIB will be out-of-sync.</div>
<div>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.</div>
<div><br>
</div>
<div><font size="4">Proposed Design</font></div>
<div>RibManager updates the RIB only; it does not directly update the FIB.</div>
<div><br>
</div>
<div>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.</div>
<div>When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure.<br>
</div>
<div>When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure.</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>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.</div>
<div>If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated.</div>
<div><br>
</div>
<div>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.</div>
<div>For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete.</div>
<div><br>
</div>
<div><font size="4">Benefits</font></div>
<div>The proposed design decouples FIB updates from RIB updates.</div>
<div>A RIB update, regardless of source, can trigger FIB updates.</div>
<div>If a RIB update <u>command</u> needs to wait for the RIB update and FIB updates to complete, RibManager can wait on a callback from the RIB.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Yours, Junxiao</div>
</div>
_______________________________________________ Nfd-dev mailing list <a href="mailto:Nfd-dev@lists.cs.ucla.edu">
Nfd-dev@lists.cs.ucla.edu</a> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a> </blockquote>
</span>
</body>
</html>