<div dir="ltr"><div><div><div><div>Hi Alex,<br><br></div>That's a fair point. At this stage, however, I control the queue overflows by making sure that total number of generated interests during my entire simulation time will not exceed the capacity of individual queues. Also, I keep the interests rate fairly low---consumer nodes will request on average 1 interest per sec. While keeping the interest rate fixed, the channel delay, however, is going to be my independent variable which I'd like to be able to set to different values ranging between 1-500ms and still not get packet timeouts/drops.<br><br>With the previously described configurations, a 500ms channel delay makes the majority of interests timed out (i.e., #TimedOutInterests almost matches #InInterests, even though #DropInterests is fairly low---strange?). Also, on data packets #DropData almost matches #InData and I barely receive any data on the consumers side. I suspect all such drops are purely due to timeouts which presumably could be avoided if packets time-to-live is set sufficiently high. Isn't that right?<br><br></div>Thanks,<br></div>Ali<br><br></div>P.S. -- The topology I use is a binary tree of height 6, consumers as leaves and the sole provider as root.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 28, 2015 at 3:21 PM, Alex Afanasyev <span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi Ali,</div><div><br></div><div>No matter how big queue you set, if the rate with which you send packets exceed the capacity of the link, you will get data or interest packet to be dropped and interests will timeout.</div><div><br></div><div>To prevent losses, you just need to make sure your topology matches the application demand.</div><div><br></div><div>—</div><span class="HOEnZb"><font color="#888888"><div>Alex</div></font></span><div><div class="h5"><br><div><blockquote type="cite"><div>On Feb 28, 2015, at 11:10 AM, Al Dab <<a href="mailto:ali090385@gmail.com" target="_blank">ali090385@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div><div><div><div>Hi,<br><br>I am performing some simulations on ndnSIM 1.0 and for some of my measurements I'd like to completely eliminate interest/data drops or at least make them as close to zero as possible. My understanding is that most packet drops happen due to a timeout or a queue overflow. For the interest part, I have tried to increase the lifetime of the interest packets, <span style="font-family:monospace,monospace">MaxPitEntryLifetime</span> and also the queue size as follows:<br><br><font><span style="font-family:monospace,monospace">ndn::AppHelper consumerHelper ("ns3::ndn::ConsumerZipfMandelbrot"); // to be installed on all consumers<br>consumerHelper.SetAttribute ("LifeTime", StringValue ("9999s"));<br>...<br>Config::Set ("/NodeList/<nodeID>/$ns3::ndn::Pit/MaxPitEntryLifetime", TimeValue (Seconds (9999))); // for all nodeID's<br>...<br>Config::SetDefault ("ns3::DropTailQueue::MaxPackets", StringValue ("9999"));<br><br></span></font></div><font><span style="font-family:arial,helvetica,sans-serif">Still, I am getting some interest and data drops. These drops are measured through </span><span style="font-family:monospace,monospace">L3AggregateTracer</span><span style="font-family:arial,helvetica,sans-serif"> and tend to increase</span></font><span style="font-family:arial,helvetica,sans-serif"> by i</span>ncreasing the channel delay using the following command:<br><br><span style="font-family:monospace,monospace">Config::SetDefault ("ns3::PointToPointChannel::Delay", StringValue ("500ms"));</span><br><br></div>I am wondering what other settings can lead to packet drops, both on interests and data and what is the most efficient way of preventing such drops?<br><br></div>Thanks,<br></div>Ali<br></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>