<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Yusung,</div><div><br></div><div>Yes. Normally drops are due to transmission queue overflow at layer 2. The "trace source" path "/NodeList/*/DeviceList/*/TxQueue/Drop" is saying that we are selecting all simulation nodes (/NodeList/*), all network devices on each node (DeviceList/*), from each netdevice we are accessing TxQueue, in where we are connecting to Drop trace source. You may want to check NS-3 documentation about trace sources and connecting to them.</div><div><br></div><div>NS-3 does not implement concept of dropping on input and there are no input interface queues. Time to handle packet is relevant in a real system, in NS-3, unless you specifically design processing to emulate real process, it is assumed that any method takes exactly 0s of simulation time. </div><div><br></div><div>In NDN, a forwarding strategy may decide to drop Interest if it thinks that there is a congestion in the reverse path. This is not real congestion, but NDN-specific drop. If you want, you can check out our paper (<a href="http://dx.doi.org/10.1016/j.comcom.2013.01.005">http://dx.doi.org/10.1016/j.comcom.2013.01.005</a>, <a href="http://lasr.cs.ucla.edu/afanasyev/data/files/Yi/comcom-stateful-forwarding.pdf">http://lasr.cs.ucla.edu/afanasyev/data/files/Yi/comcom-stateful-forwarding.pdf</a>) where we designed a rough prototype for such strategy.</div><div><br></div><div>---</div><div>Alex</div><br><div><div>On Feb 27, 2013, at 5:53 PM, Yusung Kim <<a href="mailto:yskim525@gmail.com">yskim525@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello Mohammad and Alex, <div><br></div><div>May I ask you more scenarios in which <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">congestion happens in NDN ? </span></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">One example, Alex said, is </font><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">drops due to queue overflows.</span></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Is the transmission queue at Layer2 , right ?</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">( To Alex, what is the default queue size ? )</span></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif"><br></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">Is it possible that packets are dropped at an input interface queue ?</span></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">For example, When lots of packets arrived from multiple input interfaces,</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">if the time to handle the packets ( name look-up, cache replacement.. ) increases, </span></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">new incoming packets may be dropped at input interface queues ?</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif"><br></span></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">If you know another scenarios about packet drops, would you let me know the scenarios?</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif">Thank you,</span></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">- Yusung Kim -</font></div><div><font color="#222222" face="arial, sans-serif"><br></font></div><div>
<font color="#222222" face="arial, sans-serif"><br></font><br><div class="gmail_quote">On Thu, Feb 28, 2013 at 5:27 AM, 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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">Hi Mohammad,<br>
<br>
If you're talking about normal drops due to queue overflows, then you can use packet drop traces from NetDevice queue (you can check examples in src/visualizer/model/pyviz.cc):<br>
<br>
- /NodeList/*/DeviceList/*/TxQueue/Drop<br>
<br>
If you want to factor in cases when ndnSIM stops forwarding packet (which is not exactly a drop), then you may want to also use<br>
<br>
- /NodeList/*/$ns3::ndn::ForwardingStrategy/DropInterests<br>
- /NodeList/*/$ns3::ndn::ForwardingStrategy/DropData<br>
<br>
However, I'm not confident 100% that right now ndnSIM tracks all the cases of stopped forwarding of Interst/Data.<br>
<br>
---<br>
Alex<br>
<div><div class="h5"><br>
On Feb 27, 2013, at 5:51 AM, Hovaidi Ardestani Mohammad <<a href="mailto:mohammad.hovaidi.ardestani@aalto.fi">mohammad.hovaidi.ardestani@aalto.fi</a>> wrote:<br>
<br>
> Hello everybody!<br>
> I have several scenarios in which congestion happens. I am wondering how I can trace dropped packets or know when packet dropping has been started?<br>
> Any help is appreciated in advance<br>
> BR<br>
> -Mohammad<br>
<br>
</div></div>_______________________________________________<br>
ndnSIM mailing list<br>
<a href="mailto:ndnSIM@lists.cs.ucla.edu">ndnSIM@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
</blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu">ndnSIM@lists.cs.ucla.edu</a><br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim<br></blockquote></div><br></body></html>