[Ndn-interest] Valid Data packet from non-existing FIB Interface

[Boubakr Nour]

Many thanks for your replies.
________________________________
From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Cenk Gündoğan <mail+ndn at gundogan.net>
Sent: Monday, April 9, 2018 1:56 PM
To: ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Valid Data packet from non-existing FIB Interface

Hey,

On 18-04-09 08:15:54, David R. Oran wrote:
> On 9 Apr 2018, at 5:30, Boubakr Nour wrote:
>
> > Dear all,
> >
> > What is the normal behavior of an intermediate node when receiving a
> > Data packet for a valid entry in PIT, from an interface does not used in
> > the Interest forwarding of the received content.
> >
> > For example, the node receives two requests for content “n1” from
> > interfaces “f1” and “f2”. According to FIB, the Interest is forwarded
> > using interface “f4” (only "f4" can be used to reach "n1"). However, a
> > Data packet for “n1” has been received from interface “f3”.
> >
> > Should we consider it as an unsolicited data packet regardless the name
> > already exists in PIT table?
> Yes, I believe so, as otherwise an off-path forwarder could pollute caches
> and/or deny service to consumers.

I also support that statement. I think of the PIT as a data structure
that takes the tuple <name;face_id> as an argument for the lookup
function. Anything not matching that tuple results in a miss.
(Joining tuples by the name attribute to get the often used form
<name;face_1,face_2,...face_n> is just syntactic sugar.)

>
> A grey area is the case of a data packet received by an interface which is a
> VALID FIB interface for an interest, but on which a particular interest was
> not forwarded. It might be ok to relax the rule for that case, at some cost
> to performance to do the extra lookup.
>
> Another potential scenario (not discussed anywhere in the NDN design as far
> as I can remember) are whether you can have unidirectional interfaces, which
> are useful under some limited but highly useful cases, such as satellite
> broadcast with terrestrial return. For this scenario the FIB needs to be
> structured with paired interfaces such that the forwarder can match incoming
> data over one interface with interests sent over a different one.

I think interface pairing can be hidden away in the "face" data
structure of CCNx/NDN. In the end, the PIT and FIB structures operate on
faces, not interfaces. So for the network stack it might look like it's
using the same face path, but it might use different interfaces
underneath. Well, ... probably it's just a matter of taste where to put
the control logic into .. either into the FIB/PIT structures, or into
the face structure.

Cheers,
Cenk

>
> > If not how can map the allowed interface from FIB table with the
> > received ones in PIT table? (FIB table is not involved in Data
> > forwarding).
> >
> There are ways around this - you can pre-populate the PIT with the valid
> interface ids from the FIB when you forward the interest.
>
> > Warm regards,
> > Nour
>
>
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
> DaveO
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

--
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendogan at haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20180410/ed4f6b27/attachment-0001.html>