<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 8:42 AM, Dave Oran (oran) <span dir="ltr"><<a href="mailto:oran@cisco.com" target="_blank">oran@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Oct 10, 2014, at 11:19 AM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br>
<br>
> Hi Dave<br>
><br>
> The scenario is: switches understand Names, NICs understand Names.<br>
><br>
</span>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.<br>
<br>
I still argue that we need L3<->L2 binding machinery either built into NDN or in some kind of convergence layer, </blockquote><div><br></div><div>Agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and that either multicasting everything or re-inventing ARP are poor choices.<br></blockquote><div><br></div><div>But I don't know what other options we may have. Something like NDN Neighbor Discovery? :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For example, I’d think about at least the following:<br>
- use different multicast addresses for Interests and Data<br>
- perhaps partition the multicast space using prefix hashes (analogous to what is done when mapping IP multicast to L2 multicast)<br>
- 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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 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.<br>
<br>
And there’s probably a whole lot more, including how to do liveness assessment without relying on Hellos - perhaps we just run BFD.<br>
<span class=""><br>
<br>
> 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.<br>
><br>
</span>This seems quite unrealistic for a NIC to do.<br>
<span class=""><br>
> We have high-end home routers running NFD. They have enough memory to keep a PIT.<br>
</span>No doubt.<br>
I’ll grant the home router case. It’s the easy one. Bandwidth is low, node count is low.<br>
<span class="im HOEnZb"><br>
><br>
><br>
> Wireless is a scenario I haven't studied much about. I'll be sure to look up the terms you mentioned.<br>
><br>
> Yours, Junxiao<br>
><br>
> On Thu, Oct 9, 2014 at 12:38 PM, Dave Oran (oran) <<a href="mailto:oran@cisco.com">oran@cisco.com</a>> wrote:<br>
><br>
> On Oct 8, 2014, at 9:28 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br>
><br>
> > Dear folks<br>
> ><br>
> > If a local area network is using regular Ethernet (learn paths from source MAC address) today, self-learning can work on it.<br>
> > Self-learning idea also has been tested on a 16-server fat tree topology.<br>
> ><br>
> > It's not crazy to multicast every packet.<br>
> 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.<br>
><br>
> > Switches are expected to understand NDN Names and act as NDN forwarders;<br>
> good luck with that. No switches I’ve met in the last 10 years have enough memory to keep a PIT.<br>
><br>
> > at physical layer there's no difference between multicast and unicast.<br>
> ><br>
> Also not true for pt-multipoint radios with hidden terminals.<br>
> Not to mention the rate minimization pathologies of wireless LANs like 802.11.<br>
><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">PhD @ IRL, CSD, UCLA</div>
</div></div>