[Nfd-dev] [Ndn-interest] NDN link protocol

[Wentao Shang]

On Fri, Oct 10, 2014 at 8:42 AM, Dave Oran (oran) <oran at cisco.com> wrote:

>
> On Oct 10, 2014, at 11:19 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> > Hi Dave
> >
> > The scenario is: switches understand Names, NICs understand Names.
> >
> I understand the scenario. I’m pointing out first that it’s highly
> unrealistic, and second that when you have a big flat L2 waking up all the
> nodes with multicasts is a very bad idea.
>
> I still argue that we need L3<->L2 binding machinery either built into NDN
> or in some kind of convergence layer,


Agree.


> and that either multicasting everything or re-inventing ARP are poor
> choices.
>

But I don't know what other options we may have. Something like NDN
Neighbor Discovery? :)


>
> For example, I’d think about at least the following:
> - use different multicast addresses for Interests and Data
> - perhaps partition the multicast space using prefix hashes (analogous to
> what is done when mapping IP multicast to L2 multicast)
> - Record in the PIT the source MAC address of the interest as well as the
> incoming face. This allows you to make an intelligent decision as to
> whether to multicast or unicast the data packet based on how many consumers
> have asked for a given data packet.
>

Personally I like this idea. This can be extended to other NBMA links as
well. Eventually we should have individual faces per L2 host (or per L2
interface). This will be very useful in wireless mesh networks where L2
multicast is much more expensive than on the Ethernet.

Best,
Wentao


> - use routing to suppress redundant forwarding of interests received by
> multiple forwarders on the same LAN. This can be done using designated
> router techniques as in OSPF/ISIS for IP, or perhaps we can do something
> cleverer.
>
> And there’s probably a whole lot more, including how to do liveness
> assessment without relying on Hellos - perhaps we just run BFD.
>
>
> > When an Interest / Data arrives at a NIC but the host is not listening
> to this Name prefix, the NIC should drop or NACK the packet, without waking
> up rest of the PC.
> >
> This seems quite unrealistic for a NIC to do.
>
> > We have high-end home routers running NFD. They have enough memory to
> keep a PIT.
> No doubt.
> I’ll grant the home router case. It’s the easy one. Bandwidth is low, node
> count is low.
>
> >
> >
> > Wireless is a scenario I haven't studied much about. I'll be sure to
> look up the terms you mentioned.
> >
> > Yours, Junxiao
> >
> > On Thu, Oct 9, 2014 at 12:38 PM, Dave Oran (oran) <oran at cisco.com>
> wrote:
> >
> > On Oct 8, 2014, at 9:28 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> >
> > > Dear folks
> > >
> > > If a local area network is using regular Ethernet (learn paths from
> source MAC address) today, self-learning can work on it.
> > > Self-learning idea also has been tested on a 16-server fat tree
> topology.
> > >
> > > It's not crazy to multicast every packet.
> > I beg to differ. Waking up 10,000 hosts on an extended LAN with a data
> packet when only one of them sent an interest, is, I’m afraid, actually
> crazy.
> >
> > > Switches are expected to understand NDN Names and act as NDN
> forwarders;
> > good luck with that. No switches I’ve met in the last 10 years have
> enough memory to keep a PIT.
> >
> > > at physical layer there's no difference between multicast and unicast.
> > >
> > Also not true for pt-multipoint radios with hidden terminals.
> > Not to mention the rate minimization pathologies of wireless LANs like
> 802.11.
> >
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



-- 
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141010/3edda294/attachment.html>