[Ndn-interest] Problem of PIT not aggregating Interests

[David R. Oran]

On 25 Apr 2019, at 7:01, Junxiao Shi wrote:

> Hi yjinking
>
> Thanks for complete information and packet capture. This behavior is 
> by
> design.
>
Thanks for explanation. While this is indeed “by design”, I find 
this design somewhere between suboptimal and bizarre. Why?

- It is utterly insensitive to congestion on the outbound faces. 
Retransmissions should be more conservative under congestion conditions 
as they exacerbate congestion
- Exponential backoff completely defeats applications or upstream 
forwarders (if forwarders are doing retransmissions) basing 
retransmission policy on an EDF scheduler.
- Why the aggregation policy ought to be coupled to forwarding strategy 
is perhaps justifiable, but certainly open to question. Is there a 
different aggregation algorithm for other forwarding strategies, like 
weighted round robin of FIB entries for a load-balanced forwarding 
strategy?
- While it sort of makes sense that you can’t know whether the 
upstream forwarder is the one associated with a consumer or not, two 
interests with the same {Name+nonce} by definition came from the same 
consumer and hence are intended by the consumer as a retransmission, 
right? That means the only reason to suppress it would be congestion, 
not the gain by aggregation. Conversely, if the downstream forwarder 
hasn’t already aggregated, there must be some good reason for this, so 
why is the upstream forwarder second-guessing arrivals on the same 
incoming face?

There are more things I could say here, but they are secondary 
considerations and you get the drift…

> You are using the best-route v5 strategy. For this strategy, after
> forwarding an Interest, if another Interest with same Name+CBP+MBF 
> arrives,
> it may choose to either retransmit or aggregate. As you see in the 
> pcap,
> the strategy has chosen to retransmit the Interest.
> RetxSuppressionExponential
> <https://github.com/named-data/NFD/blob/b31206e87ef7b282fd0ac295f93a626048805c27/daemon/fw/retx-suppression-exponential.hpp>
> type
> decides between retransmit and aggregate. It gives every PIT entry a
> "suppression duration". If a subsequent Interest arrives within the
> suppression interval, the decision is "aggregate"; if a subsequent 
> Interest
> arrives past the suppression interval, the decision is "retransmit". 
> This
> happens at PIT entry granularity. The configuration is: initial 
> suppression
> interval is 10 milliseconds, and it doubles every time the Interest is
> retransmitted, up to 250ms.
> As pcap shows, the first Interest arrived at 1556172304.931403000, the
> second Interest arrived at 1556172304.949144000. The interval between 
> these
> two Interests is 16ms that is greater than the initial suppression
> interval. Therefore, the strategy decides to retransmit.
>
> I wish there's a way to change suppression settings via strategy
> parameters, but there isn't. I've entered NFD Feature 4924
> <https://redmine.named-data.net/issues/4924> to add this feature.
>
> If you just want to see Interest aggregation in action, time your 
> consumers
> better so that the Interests arrive within 10ms of each other.
> If it's a real problem affecting your application, you may "watch" 
> this
> feature on Redmine to get updates, or contribute code to that feature
> following contribution guidelines.
>
> Yours, Junxiao
>
> On Thu, Apr 25, 2019 at 2:58 AM yjinking at mail.ustc.edu.cn <
> yjinking at mail.ustc.edu.cn> wrote:
>
>> Hi, Junxiao,
>> Sorry, on previous email I only attached the pcap files when two 
>> Interests
>> were issued from the same consumer node. Here are the the pcap files 
>> when
>> two Interests were issued from two different consumer nodes.
>> NFD is the original one. We only added some codes in forwarder.cpp to
>> print some information on the screen.
>>
>>
>>> On Mon, Apr 22, 2019, 22:16 yjinking at mail.ustc.edu.cn <
>>> yjinking at mail.ustc.edu.cn> wrote:
>>>
>>>>
>>>> Hi,all:
>>>> We encountered a problem that PIT can not aggregate two Interest 
>>>> packets
>>>> with same name from two different nodes, but it can aggregate two 
>>>> Interest
>>>> packets with same name from one nodes.
>>>> We run NFD on 4 physical nodes consisting "Y"-shape 
>>>> topology(central
>>>> node is forwarder, one Producer, two Consumers). Then two 
>>>> experiment were
>>>> conducted:
>>>>
>>>> 1. We run ./examples/producer on producer node. We extended 
>>>> Producer's
>>>> execution time to 5 seconds when Producer receives Interest. Then 
>>>> two
>>>> Interest packets with same name from two different nodes were 
>>>> issued nearly
>>>> at the same time. After about 5 second and 10 second, two Consumers
>>>> received their Data packets subsequently. And two Data packets' 
>>>> timestamp
>>>> were different. Producer responded twice.
>>>>
>>>> 2. In another experiment, all is same with the first experiment, 
>>>> except
>>>> that we only use one consumer node. Two Interest packets with same 
>>>> name
>>>> from one nodes were issued nearly at the same time. After about 5 
>>>> seconds,
>>>> the consumer node received 2 Data packets with same timestamp 
>>>> subsequently.
>>>> Producer responded once.
>>>>
>>>> According to the process of NDN, the result of the first experiment 
>>>> is
>>>> very strange. Why didn't PIT aggregate the second Interest? Does 
>>>> NFD build
>>>> PIT for each face separately? or maybe is there anything wrong in 
>>>> our
>>>> experiment?
>>>>
>>>> Plus, how can I print the content of FIB/CS/PIT on real time? Does 
>>>> NFD
>>>> provide any interfaces?
>>>>
>>>>
>>>> Thank you!
>>>> ------------------------------
>>>>
>>>>
>>>>


> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

DaveO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190425/06cf0570/attachment-0001.html>