[Nfd-dev] NDN Congestion Control Design
Junxiao Shi
shijunxiao at email.arizona.edu
Mon May 2 16:34:43 PDT 2016
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>
More information about the Nfd-dev
mailing list