<div dir="ltr">Hi Klaus<div><br></div><div>With only one FIB nexthop, the behavior of access v1, best-route v4, and multicast v1 differs only in how they handle consumer retransmission.</div><div>best-route v4 has an exponential back-off suppression algorithm.</div><div>access v1, as you found, suppresses retransmission for a fixed 100ms interval. As indicated in #<a href="http://redmine.named-data.net/issues/1913#note-9">1913-9</a>, this isn't changed when best-route goes to exponential back-off, because access strategy's suppression algorithm needs an independent decision.</div><div>multicast v1 always suppress any retransmission before InterestLifetime.</div><div><br></div><div>#3219 is a performance issue, not a correctness issue.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 2:53 PM, Klaus Schneider <span dir="ltr"><<a href="mailto:klaus@cs.arizona.edu" target="_blank">klaus@cs.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just some thoughts on the AccessStrategy. The problem could be related to a number of things:<br>
<br>
1. The multicasting mechanism:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/** \brief Access Router Strategy version 1<br>
*<br>
* This strategy is designed for the last hop on the NDN testbed,<br>
* where each nexthop connects to a laptop, links are lossy, and FIB is mostly correct.<br>
*<br>
* 1. Multicast the first Interest to all nexthops.<br>
* 2. When Data comes back, remember last working nexthop of the prefix;<br>
* the granularity of this knowledge is the parent of Data Name.<br>
* 3. Forward subsequent Interests to the last working nexthop.<br>
* If it doesn't respond, multicast again.<br>
*/<br>
</blockquote>
<br>
To test this, it would be enough to compare a scenario with one producer (in the FIB entry) with having multiple producers. With one producer, one can also compare the AccessStrategy against the BestRouteStrategy2 or the BroadcastStrategy (all should behave the same).<br>
<br>
<br>
2. The aggregation of measurement entries (<a href="http://redmine.named-data.net/issues/3219" rel="noreferrer" target="_blank">http://redmine.named-data.net/issues/3219</a>)<br>
<br>
However, this looks like it affects CPU/Memory performance more than actually influencing the correctness of NDN-RTC's behavior.<br>
<br>
<br>
3. The Retransmission Suppression<br>
<br>
Junxiao can correct me, but I think NDN-RTC uses the class "RetxSuppressionFixed":<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
const time::milliseconds RetxSuppressionFixed::DEFAULT_MIN_RETX_INTERVAL(100);<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
bool isNewPitEntry = !pitEntry.hasUnexpiredOutRecords();<br>
if (isNewPitEntry) {<br>
return NEW;<br>
}<br>
<br>
time::steady_clock::TimePoint lastOutgoing = this->getLastOutgoing(pitEntry);<br>
time::steady_clock::TimePoint now = time::steady_clock::now();<br>
time::steady_clock::Duration sinceLastOutgoing = now - lastOutgoing;<br>
bool shouldSuppress = sinceLastOutgoing < m_minRetxInterval;<br>
return shouldSuppress ? SUPPRESS : FORWARD;<br>
</blockquote>
<br>
Thus, only one packet will be forwarded every 100ms, no matter which face it came from. This could hinder NDN-RTC's loss recovery mechanism (retransmitting at some buffer threshold), because the retransmission might just get dropped.<br>
<br>
The RetxSuppression is only a problem if the producer loses or drops the initial data packet. It would be interesting to see if that happens.<br>
<br>
Best regards,<br>
Klaus<br></blockquote></div></div></div></div>