[Nfd-dev] NDN Congestion Control Design

[Junxiao Shi]

Hi Klaus

With only one FIB nexthop, the behavior of access v1, best-route v4, and
multicast v1 differs only in how they handle consumer retransmission.
best-route v4 has an exponential back-off suppression algorithm.
access v1, as you found, suppresses retransmission for a fixed 100ms
interval. As indicated in #1913-9
<http://redmine.named-data.net/issues/1913#note-9>, this isn't changed when
best-route goes to exponential back-off, because access strategy's
suppression algorithm needs an independent decision.
multicast v1 always suppress any retransmission before InterestLifetime.

#3219 is a performance issue, not a correctness issue.

Yours, Junxiao

On Mon, May 2, 2016 at 2:53 PM, Klaus Schneider <klaus at cs.arizona.edu>
wrote:

> Just some thoughts on the AccessStrategy. The problem could be related to
> a number of things:
>
> 1. The multicasting mechanism:
>
>
>> /** \brief Access Router Strategy version 1
>>  *
>>  *  This strategy is designed for the last hop on the NDN testbed,
>>  *  where each nexthop connects to a laptop, links are lossy, and FIB is
>> mostly correct.
>>  *
>>  *  1. Multicast the first Interest to all nexthops.
>>  *  2. When Data comes back, remember last working nexthop of the prefix;
>>  *     the granularity of this knowledge is the parent of Data Name.
>>  *  3. Forward subsequent Interests to the last working nexthop.
>>  *     If it doesn't respond, multicast again.
>>  */
>>
>
> 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).
>
>
> 2. The aggregation of measurement entries (
> http://redmine.named-data.net/issues/3219)
>
> However, this looks like it affects CPU/Memory performance more than
> actually influencing the correctness of NDN-RTC's behavior.
>
>
> 3. The Retransmission Suppression
>
> Junxiao can correct me, but I think NDN-RTC uses the class
> "RetxSuppressionFixed":
>
> const time::milliseconds
>> RetxSuppressionFixed::DEFAULT_MIN_RETX_INTERVAL(100);
>>
>
>   bool isNewPitEntry = !pitEntry.hasUnexpiredOutRecords();
>>   if (isNewPitEntry) {
>>     return NEW;
>>   }
>>
>>   time::steady_clock::TimePoint lastOutgoing =
>> this->getLastOutgoing(pitEntry);
>>   time::steady_clock::TimePoint now = time::steady_clock::now();
>>   time::steady_clock::Duration sinceLastOutgoing = now - lastOutgoing;
>>   bool shouldSuppress = sinceLastOutgoing < m_minRetxInterval;
>>   return shouldSuppress ? SUPPRESS : FORWARD;
>>
>
> 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.
>
> 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.
>
> Best regards,
> Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160502/139d4c7d/attachment.html>