[Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB

[Burke, Jeff]

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 <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Tue, 24 Jun 2014 22:30:09 +0800
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140624/e1258201/attachment.html>