<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 24, 2016, at 3:32 AM, Ahmed Sadek <<a href="mailto:don1559@gmail.com" class="">don1559@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thank you all for your replies, I really appreciate it.<div class=""><br class=""></div><div class="">I have googled and found some papers but was interested to find out if there was implementation for those ideas in NDN or ndnSIM.</div></div></div></blockquote><div><br class=""></div>no.</div><div>but people can help implement in ndnSIM</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Another question, NDN is pull based so flow control is controlled by the receiver but what will happen if the link between source and destination change bandwidth capacity (2 mega -> 1 mega ) or have data more than it's capacity (3 mega data request over 2 mega link ) , does data packets gets dropped and interest re transmitted ? so what is the expected behavior in NDN and ndnSIM ?</div></div></div></blockquote><div><br class=""></div><div>"the expected behavior in NDN and ndnSIM" sounds a bit ambiguous.</div>Lets separate out what can be done from what has been implemented.</div><div><br class=""></div><div><div class=""><div class="gmail_extra">NDN's 2-way interest-data exchanges form a feedback loop, enabling intelligent forwarding.</div><div class="gmail_extra">in your above example: the router knows how fast it can pull in data before the BW change, and can notice the failure after the change. The router can try alternative path if one exists, or send a NACK back to the prev hop (wonder if you had taken a look of the paper I pointed to below?  paper <a href="http://named-data.net/wp-content/uploads/comcom-stateful-forwarding.pdf" target="_blank" class="">http://named-data.net/wp-content/uploads/comcom-stateful-forwarding.pdf</a>)</div><div class="gmail_extra"><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 23, 2016 at 7:59 PM, Lixia Zhang <span dir="ltr" class=""><<a href="mailto:lixia@cs.ucla.edu" target="_blank" class="">lixia@cs.ucla.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Mar 23, 2016, at 11:25 AM, Spyridon (Spyros) Mastorakis <<a href="mailto:mastorakis@cs.ucla.edu" target="_blank" class="">mastorakis@CS.UCLA.EDU</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">Hi Ahmed,<div class=""><br class=""></div><div class="">this is a quite open-ended question about the NDN architecture in general. Currently, there is no way to perform congestion control in NDN. </div></div></div></blockquote><div class=""><br class=""></div></span>this seems some English expression issue -- there are plenty of ways to perform congestion control (e.g. see some ideas from this paper <a href="http://named-data.net/wp-content/uploads/comcom-stateful-forwarding.pdf" target="_blank" class="">http://named-data.net/wp-content/uploads/comcom-stateful-forwarding.pdf</a>)</div><div class=""><br class=""></div><div class="">I believe Spyros meant that today's NFD implementation has not adopted any specific solutions, hence he has not put a congestion control into ndnSIM. </div><div class=""><br class=""></div><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class="">Klaus Schneider is working on CC as Spyros already mentioned; a quick google search on "ndn congestion control" also returns lots pointers to the papers on the topic</div><div class=""><br class=""></div><div class="">to the original question:</div></div></div></div><span class=""><div class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 21, 2016, at 3:44 AM, Ahmed Sadek <<a href="mailto:don1559@gmail.com" target="_blank" class="">don1559@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Dear All,<div class=""><br class=""></div><div class="">I was wondering if someone can point me to information on the <b class="">Flow Control and Congestion Control</b> <b class="">mechanism </b>used in ndnsim and is it the same as in NDN ?</div><div class=""><br class=""></div><div class="">Also, if the client keep sending interests on different interfaces and not receive response then what is the expected behavior ?</div></div></div></blockquote></div></div></div></div></blockquote><br class=""></div></span><div class="">the question is: what's the cause, right?</div><div class="">e.g.</div><div class="">- if the node is not connected, that's a connect problem</div><div class="">- if there is local connectivity but the network is partitioned, that's a slightly different problem</div><div class="">- if the interest the data does not exist, ideally one should receive an app level NACK as explained in <a href="http://named-data.net/wp-content/uploads/2016/01/consumer_producer_communication.pdf" target="_blank" class="">http://named-data.net/wp-content/uploads/2016/01/consumer_producer_communication.pdf</a> </div><div class="">- if the named producer does not exists, then it is up to how your strategy works (could generate a "NO ROUTE" NACK)</div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>