https://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232014-02-22T16:59:12ZNDN project issue tracking systemNFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=9512014-02-22T16:59:12ZDavide Pesavento
<ul></ul><p>Doesn't this procedure require the local network interface to have an IPv4 address?</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=9542014-02-22T17:18:18ZJunxiao Shi
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/954/diff?detail_id=1021">diff</a>)</li></ul><p>This optimization is applied only if the Ethernet multicast group is in IPv4 multicast mapped range, and the NIC has IPv4 enabled. Otherwise, libpcap session should still use promiscuous mode.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=11562014-03-05T03:58:28ZDavide Pesavento
<ul></ul><p>The current implementation does NOT use promiscuous mode. Instead it generates a BPF program and installs it on the capturing interface. This is much more efficient since incoming packets that do not match the filter are immediately discarded, without having to copy them from kernel to userspace. Only NDN packets (i.e. with <em>ethertype</em> == 0x8624) destined to the multicast address for which the face was configured are allowed to pass the filter and are delivered to NFD. I believe this is the most efficient way of doing it in any case.</p>
<p>The only potential issue we have is that a switch doing IGMP snooping might not forward a multicast packet if we don't explicitly join the multicast group. This has nothing to do with promiscuous mode though.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=11572014-03-05T03:58:51ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul> NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=11582014-03-05T05:37:56ZAlex Afanasyev
<ul></ul><p>I think these are orthogonal issues. My understanding is that the promisc mode forces the driver to receive and process packets that are not destined to the node and BPF filter is just to filter packets that were received by the node. If the current way works (e.g., driver is smart enough to process packets that were destined to multicast address), then it is perfect.</p>
<p>After a brief reading of <a href="http://tools.ietf.org/html/rfc4541">http://tools.ietf.org/html/rfc4541</a> I think we don't even need to do anything to fix IGMP snooping (see section 2.1.2), as it specifically applies to IPv4 (not even sure if it applies to IPv6 multicast). So, I believe we don't really need to do anything.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=11622014-03-05T06:53:28ZJunxiao Shi
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Rejected</i></li></ul><p>Davide is right. Code does not call pcap_set_promisc so NIC is not in promiscuous mode.</p>
<p>If multicast works <em>without tcpdump or similar app running on the side</em>, this is fine.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12482014-03-07T14:22:42ZDavide Pesavento
<ul></ul><p>Alex Afanasyev wrote:</p>
<blockquote>
<p>After a brief reading of <a href="http://tools.ietf.org/html/rfc4541">http://tools.ietf.org/html/rfc4541</a> I think we don't even need to do anything to fix IGMP snooping (see section 2.1.2), as it specifically applies to IPv4 (not even sure if it applies to IPv6 multicast). So, I believe we don't really need to do anything.</p>
</blockquote>
<p>I believe you're correct. The RFC says (ยง2.1.2):</p>
<blockquote>
<p>4) All non-IPv4 multicast packets should continue to be flooded out<br>
to all remaining ports in the forwarding state as per normal IEEE<br>
bridging operations.</p>
</blockquote>
<p>Therefore even snooping switches will flood multicast ethernet frames on all ports since NDN packets have their own ethertype.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12492014-03-07T14:53:18ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>If multicast works <em>without tcpdump or similar app running on the side</em>, this is fine.</p>
</blockquote>
<p>I didn't say that multicast works. In fact, the EthernetFace is currently unable to receive multicast frames, because the kernel/driver don't know we are interested in them.</p>
<p>What I'm saying is that promiscuous mode might not be such a big performance hit, thanks to the BPF filter installed in the kernel that greatly reduces the amount of packets that are copied to userspace (on the other hand the kernel still has to run all packets through the BPF virtual machine, which is not free).<br>
I also think that abusing multicast MAC addresses in this way is a hack and shouldn't be done, unless in conjunction with real IP-level multicast which is not the case here.</p>
<p>Given that NDN multicast frames are flooded be switches anyway (i.e. the bandwidth saving on the network is zero), and that receiving multicast frames requires either promisc mode (which can be costly) or UDP/IP-level hacks (which in my opinion defeats the whole purpose of a purely L2 face), I propose to get rid of multicast on EthernetFace and always use broadcast frames (ff:ff:ff:ff:ff:ff) that do not require promisc mode.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12502014-03-07T15:52:26ZJunxiao Shi
<ul><li><strong>Status</strong> changed from <i>Rejected</i> to <i>New</i></li></ul><p>Reopen this task because multicast does not work.</p>
<p>BPF is in the kernel. Its cost is lower than a userspace filter, but it still consumes CPU.<br><br>
"Abusing" IP multicast offloads the filtering to the NIC.</p>
<p>I disagree with using broadcast frames, because not all hosts on a broadcast domain are NDN hosts.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12532014-03-07T17:45:38ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>BPF is in the kernel. Its cost is lower than a userspace filter, but it still consumes CPU.<br><br>
"Abusing" IP multicast offloads the filtering to the NIC.</p>
</blockquote>
<p>Correct.<br>
Using broadcast frames doesn't put the interface in promisc mode however, therefore the amount of received packets will be significantly smaller.</p>
<blockquote>
<p>I disagree with using broadcast frames, because not all hosts on a broadcast domain are NDN hosts.</p>
</blockquote>
<p>Our "multicast" frames will be flooded by switches anyway, i.e. they're effectively treated as broadcast, and will reach all attached hosts. So this point is moot.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12572014-03-07T19:13:27ZDavide Pesavento
<ul></ul><p>Another (untested) solution could be: call ioctl(SIOCSIFFLAGS) to set the IFF_ALLMULTI flag on the network device. This tells the NIC to accept all multicast packets and hand them to the kernel, without fiddling with IP-level stuff.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12602014-03-07T20:37:14ZJunxiao Shi
<ul></ul><blockquote>
<p>Our "multicast" frames will be flooded by switches anyway, i.e. they're effectively treated as broadcast, and will reach all attached hosts. So this point is moot.</p>
</blockquote>
<p>The difference is: Broadcast frames will reach the kernel of all hosts, and wastes CPU on non-NDN hosts. Multicast frames will reach the NIC of all hosts, but goes to the kernel on NDN hosts only.</p>
<blockquote>
<p>Another (untested) solution could be: call ioctl(SIOCSIFFLAGS) to set the IFF_ALLMULTI flag on the network device. This tells the NIC to accept all multicast packets and hand them to the kernel, without fiddling with IP-level stuff.</p>
</blockquote>
<p>This receives <em>all</em> multicast frames, including those used by IP multicast in groups not joined by the host. NDNLP only needs one specific multicast group.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=12632014-03-08T00:28:10ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>This receives <em>all</em> multicast frames, including those used by IP multicast in groups not joined by the host. NDNLP only needs one specific multicast group.</p>
</blockquote>
<p>Yes, I know, and it looks like a very reasonable and acceptable compromise to me... Extraneous (non-NDN) multicast frames will continue to be filtered by BPF.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=13022014-03-09T16:04:58ZDavide Pesavento
<ul></ul><p>Yet another way: we can use ioctl(... SIOCADDMULTI ...) or even better setsockopt(... SOL_PACKET, PACKET_ADD_MEMBERSHIP ...) on Linux.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=13032014-03-09T16:19:28ZJunxiao Shi
<ul></ul><p>SIOCADDMULTI looks nice. Please write a small program and give it a try.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=13672014-03-13T00:39:36ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul> NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=13682014-03-13T00:48:18ZJunxiao Shi
<ul></ul><p>@Davide, which solution are you using?</p>
<p>If you are using SIOCADDMULTI (and confirm it works), please update "Task Description" to reflect that.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=14042014-03-14T21:13:55ZDavide Pesavento
<ul><li><strong>Target version</strong> changed from <i>v0.1</i> to <i>v0.2</i></li></ul> NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=14112014-03-15T00:11:26ZJunxiao Shi
<ul><li><strong>Target version</strong> changed from <i>v0.2</i> to <i>v0.1</i></li></ul><p>Task cannot be moved to another version without being discussed in a conference call or in the nfd-dev mailing list.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=17162014-03-26T10:03:15ZJunxiao Shi
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>New</i></li><li><strong>Assignee</strong> deleted (<del><i>Davide Pesavento</i></del>)</li><li><strong>Target version</strong> changed from <i>v0.1</i> to <i>v0.2</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>0</i></li></ul><p>20140326 conference call agrees to defer this task to Version 2.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=19382014-04-07T03:42:53ZDavide Pesavento
<ul><li><strong>Assignee</strong> set to <i>Davide Pesavento</i></li></ul> NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=31692014-06-09T21:56:14ZJunxiao Shi
<ul><li><strong>Target version</strong> changed from <i>v0.2</i> to <i>v0.3</i></li></ul><p>20140609 conference call decides to defer this Task.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=51702014-10-07T18:26:38ZJunxiao Shi
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><p>I asked @Davide about the plan for this Task. The reply is:</p>
<blockquote>
<p>I think I already tried it months ago when we were discussing a solution. And I don't remember having problems so I guess it works.<br>
The best thing in my opinion is using the <code>PACKET_ADD_MEMBERSHIP</code> socket option on Linux and the <code>SIOCADDMULTI</code> ioctl on OSX.</p>
</blockquote>
<p>Regarding timeline:</p>
<blockquote>
<p>I might be able to take another look at it next month, but I cannot guarantee anything. We're all quite busy until early December.</p>
</blockquote>
<p>I think this Task should be retained in v0.3 for now, but as Low priority.</p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=61002014-11-17T13:32:01ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>40</i></li></ul> NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=61092014-11-17T17:08:26ZJunxiao Shi
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/6109/diff?detail_id=5833">diff</a>)</li></ul> NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=61272014-11-18T06:02:07ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Code review</i></li><li><strong>% Done</strong> changed from <i>40</i> to <i>60</i></li></ul><p><a href="http://gerrit.named-data.net/1437">http://gerrit.named-data.net/1437</a></p>
NFD - Task #1278: EthernetFace without promiscuous modehttps://redmine.named-data.net/issues/1278?journal_id=62552014-11-23T16:22:01ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>Code review</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>60</i> to <i>100</i></li></ul>