[Nfd-dev] a question about PIT entry

Junxiao Shi shijunxiao at email.arizona.edu
Wed Jun 29 16:25:23 PDT 2016


Hi Lan

Let me expand the topology as:
appA   appB
  |     |
 fwA---fwB

   1. appA sends Interest /P nonce=1 to fwA, which is forwarded to fwB, and
   then appB
   fwA has PIT entry /P in=["appA nonce=1"] out=["fwB nonce=1"]
   fwB has PIT entry /P in=["fwA nonce=1"] out=["appB nonce=1"]
   2. appB sends Interest /P nonce=2 to fwB, which is forwarded to fwA, and
   then appA
   fwB has PIT entry /P in=["fwA nonce=1", "appB nonce=2"] out=["appB
   nonce=1", "fwA nonce=2"]
   fwA has PIT entry /P in=["appA nonce=1", "fwB nonce=2"] out=["fwB
   nonce=1", "appA nonce=2"]
   3. appA responds Data /P to fwA, which is returned to fwB, and then appB
   fwA has PIT entry /P in=[] out=["fwB nonce=1"]
   fwB has PIT entry /P in=[] out=["appB nonce=1"]

In step3, fwA will clear the in-record "appA nonce=1" but will not return
Data to appA. fwA assumes appA can internally satisfy this pending
Interest; this "internal satisfying" feature is not implemented in ndn-cxx,
so application should handle this by itself.
Similarly, fwB will clear the in-record "fwA nonce=1" but will not return
Data to fwA. fwB assumes fwA can internally satisfy this pending Interest;
this "internal satisfying" feature is implemented in NFD, in the form of
returning Data to all consumers and admitting Data into CS.
The PIT entries on fwA and fwB are not erased. Instead, it's kept for loop
detection and measurement purpose, and will be erased by the straggler
timer.

If appB would respond to appA's Interest with the same Data, the same
effect can be achieved by implementing "internal satisfying" feature
mentioned above.
If appB would respond to appA's Interest with a different Data of same
name, the protocol design is wrong because it violates Data immutability
principle <http://named-data.net/project/ndn-design-principles/>. Instead,
appB should create a Data with a higher version number, and appA can
express another Interest that excludes its own version number in order to
receive appB's Data.

Yours, Junxiao

On Tue, Jun 28, 2016 at 10:04 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> Hi,
>
> I have a question about how to keep a PIT entry in a particular
> situation.  Suppose there are two nodes:
>
> a — b
>
> 1) a and b both send the same interests (same name) to each other.
> 2) a responds to b’s interest with a data packet.  In the current PIT
> implementation, it will remove both a and b's PIT entry for this interest.
>
> We hope that a’s data packet would not erase the PIT entry in a and b
> completely (only remove the necessary in and out records) so that b can
> still respond to a’s interest.
>
> This is inspired by a partialsync implementation issue.  Is there any way
> to achieve this result?
>
> Lan
>
>
> _______________________________________________
> 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160629/8728c5bc/attachment.html>


More information about the Nfd-dev mailing list