<div dir="ltr">Hi Peter<div><br></div><div>In your setup, the FIB entry toward the producer has only one nexthop. As answered in <a href="http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001716.html">this thread</a>, the difference between multicast strategy and best-route v4 strategy is whether they permit consumer retransmissions: multicast strategy does not permit any retransmission when the PIT entry is still pending; best-route v4 strategy will forward the Interest again after <a href="https://github.com/named-data/NFD/blob/4846f3711757d1dcca78639c19f7ce7629bd9646/daemon/fw/best-route-strategy2.cpp#L38">10ms suppression period</a>.</div><div>This is the primary reason we want to see the tcpdump trace, to examine the timing among Interests from multiple consumers and estimate how many extra Interests are forwarded to the producer.</div><div><br></div><div>The reason I'm suspecting a "congestion" is that your Interest rate may have exceeded the processing power of NFD. This is not a congestion on the network, but a congestion caused by CPU power limitation.</div><div>As benchmarked in #<a href="http://redmine.named-data.net/issues/1819#note-2">1819 note-2</a>, NFD can process 3500 Interest-Data exchanges per second with 6-component names, no Selectors in Interests, and very small Data packets, or 1100 exchanges for 26-component names. Interests in your scenario have approximately 10 components, so I'd estimate a throughput of 2000 exchanges per second.</div><div>More importantly, some Interests have ChildSelector=rightmost which could consume more than 150ms as shown in #<a href="http://redmine.named-data.net/issues/2626#note-2">2626 note-2</a>. With 9 consumers expressing such Interests once every 3000ms, almost half of the processing power is spent for those Interests. This leaves us a throughput of 1000 Interest-Data exchanges per second.</div><div><br></div><div>You have quoted 200Kbps per consumer times ten consumers.</div><div>With 8000-octet payload size, that's 32 Interest-Data exchanges per second. It would incur the overhead of NDNLPv2 reassembly which we don't have a benchmark result.</div><div>With 1200-octet payload size, that's 208 Interest-Data exchanges per second. There's no reassembly overhead.</div><div>In either case, this should be within the throughput limit, if each NFD instance is allocated one CPU core that is as good as ONL's CPU cores.</div><div>However, if each NFD instance only gets 50% of a CPU core, almost all this CPU time would be eaten by the ChildSelector=rightmost Interests, leaving very little processing power for other Interests.<br></div><div><br></div><div>Can you confirm that the experiment environment have enough CPU cores, so that each NFD instance can use up 100% of a CPU core? If not, it's more likely to have a congestion.</div><div>The reason of getting better performance with multicast strategy is that it suppresses any retransmission regardless of timing, so that there are less Interests delivered to producers, and thus less computation power is needed.</div><div>I'll also wait for nfd-status outputs and pcap trace, as requested in my last message.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 4:47 PM, Gusev, Peter <span dir="ltr"><<a href="mailto:peter@remap.ucla.edu" target="_blank">peter@remap.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">



<div style="word-wrap:break-word"><div><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div>From this face counters snapshot, I can see:</div>
<div>20695 Interests are forwarded to the producer (face 263), and 10558 Data come back.</div>
<div>There are ten consumers. Face 271 receives 15872 Interests, and 9959 Data are returned to this consumer. Other nine consumer faces only receive around 1000 Interests, and between 50 and 200 Data are returned.</div>
<div><br>
</div>
<div>I'm unsure whether there's a problem in forwarding, or it's simply a congestion.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>I see two arguments supporting that it is not a congestion:</div>
<div><span style="white-space:pre-wrap"></span>1/  everything works fine when I enable multicast on hub</div>
<div><span style="white-space:pre-wrap"></span>2/ streams are around ~200Kbps which translates ~2Mbps for 10 consumers.</div>
<div>I’m not convinced that there could be a congestion here.</div><span class="">
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>The difference of incoming Interest counter of face 271 and other consumers is most concerning.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>The difference is not striking to me, because other 9 consumers never leave bootstrapping phase - i.e. they continue to issue Rightmost Interests with approximately 3000ms interval. Only one of the consumers is in Fetching phase with Interest rate of ~200
 Interests/sec.</div><span class="">
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>Can you add the following:</div>
<div>(a) <font face="monospace, monospace">nfd-status -f | grep udp4://<a href="http://10.10.12.2:6363/" target="_blank">10.10.12.2:6363</a></font> output on consumers and producer, along with
<font face="monospace, monospace">nfd-status -fr</font> output on HUB, captured at the same time or after traffic stops. This would show whether there's packet loss between end host and HUB.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>I can check it now.</div><span class="">
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>(b) tcpdump trace (in .pcap format) captured on the HUB's 10.10.12.2 NIC. This would capture the timing of packets, which allows us to analyze the behavior of NFD.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>This will take me more time…</div></div></div><div><br></div></div></blockquote></div></div></div></div>