<div dir="ltr"><div>For the record, I'm from the industry :).</div><div><br></div>Sure, that is good application application you are referring to, where waiting for an RTT for PULL is something one doesn't want. Using any Interest primitive to PUSH data, is always going to be treated as a content fetch by the forwarder, unless one has marked these Interests in someway. Also once you start marking, it is more or less another primitive. Moreover, if one wants to multicast content through a PUSH, then there are routing implications on how those name prefixes have to be treated in the forwarder as well.<div><br></div><div>Regards,</div><div>Ravi</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 9:53 AM, Syed Hassan Ahmed <span dir="ltr"><<a href="mailto:s.h.ahmed@ieee.org" target="_blank">s.h.ahmed@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Dear Prof. Ravi,</div><div><br></div><div>I do agree and in fact would like to highlight the issue with my advisor as well. According to my understanding, NDN doesn't provide mechanisms to address the demand of Push based communications. One would argue for the example, so here is one: </div><div><br></div><div>If we expect NDN to support mobile networks, so we may wanna consider VANETs. In vehicular communications, the important messages are BSMs (safety messages) that needs to be push regardless of any Interest message to arrived. </div><div><br></div><div>Also, there are so many situations, where the Data may want to be delivered by itself. I refer it as "Data Speaks".</div><div><br></div><div>Precisely, we need to figure out sooner to get PUSH support while keeping the principles of NDN. I may be wrong to come up with a varying solution, however, we can design an "Interest for Interest" special packet and let neighbors to broadcast Interest packet for Data (that wants to be shared) in response to the special packet. <br><br>Expert opinions are welcomed. <br><br><div><div><span style="background-color:rgba(255,255,255,0)">Best Regards,</span></div><div><span style="background-color:rgba(255,255,255,0)">Syed Hassan Ahmed. (하산)</span></div><div><span style="background-color:rgba(255,255,255,0)">Kyungpook National University,</span></div><div><span style="background-color:rgba(255,255,255,0)">Daegu, Republic of Korea. </span></div><div><span style="background-color:rgba(255,255,255,0)"><a href="https://sites.google.com/site/shahmedknu/" target="_blank">https://sites.google.com/site/shahmedknu/</a></span></div></div></div><div><div class="h5"><div><br>On Mar 16, 2016, at 1:22 AM, Ravi Ravindran <<a href="mailto:ravi.ravindran@gmail.com" target="_blank">ravi.ravindran@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Another primitive that is missing in NDN/CCN is the need to PUSH content, most of the IoT and social networking applications requires this primitive. Today the solutions include using the long-lived interests or polling mechanisms which are not desirable, so if once such primitive is introduced this also questions the per-hop flow control objective.<div><br></div><div>Regards,</div><div>Ravi</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 4:09 PM, <span dir="ltr"><<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[ Disclaimer: CCN currently uses flow balance as well ]<br>
<br>
The current Hop-by-Hop Flow Balance is nonsense.<br>
<br>
<br>
<br>
<br>
<br>
On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" <<a href="mailto:ndn-interest-bounces@lists.cs.ucla.edu" target="_blank">ndn-interest-bounces@lists.cs.ucla.edu</a> on behalf of <a href="mailto:aa@CS.UCLA.EDU" target="_blank">aa@CS.UCLA.EDU</a>> wrote:<br>
>[6] **Hop-by-Hop Flow Balance**:<br>
> Over each link, one interest packet should bring back no more than one data packet.<br>
<br>
Seriously, who thinks this actually works?<br>
<br>
Let me quote the webpage ( <a href="http://named-data.net/project/ndn-design-principles/" rel="noreferrer" target="_blank">http://named-data.net/project/ndn-design-principles/</a> ):<br>
"[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet.<br>
Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive.<br>
"<br>
<br>
Either there is a lot of information missing here to justify why this is so, or this is very naïve.<br>
<br>
First, if what you want to do is limit the number of content objects (or packets) returned, you don’t need to send one interest. _Specially_ for NDN, which has prefix matching, you could send one interest with a count number (10) and expect to receive 10 content objects back. There is no reason why I need to send 10 exact copies of the same interest. Even if the interests had small variations, why send 10? Why not send 1 + the 10 deltas? I guess it’s possible you may call that part of the “network adaptation layer”, who knows.<br>
<br>
Also by requiring 1-to-1, you are always requiring an overhead (on the requester side) that is quite high. If you think of today’s type of networks, where a packet (internet sized) is around 1500 bytes, that means that even if we send interests of 30 bytes, we are incurring quite a bit of overhead in the upstream. This becomes considerable when doing high bandwidth video.<br>
<br>
Please explain why the 1-to-1 is good.<br>
<br>
Second, NDN allows very large packet sizes. So, when I send 1 interest, I don’t now if what I’m going to get back is 1 byte or 18 exabytes. How do routers use this information to control how much data they’re going to receive? Are they going to reserve 18 exabytes of traffic time?<br>
<br>
If this principle were to be re-written as:<br>
“Allow network nodes to participate in flow control” then the actual engineering solution might be able to achieve this.<br>
<br>
Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding.<br>
<br>
It would be awkward if the only way for NDN to work over Satellite links would be to break the principles.<br>
<br>
Nacho<br>
<br>
<br>
PS. Yes, there are people in this community who have looked at other ways to do flow-balance and flow-control. Maybe we should be learning from those and not just claiming as principle what we do today because we don’t want it questioned.<br>
<br>
--<br>
Nacho (Ignacio) Solis<br>
Protocol Architect<br>
Principal Scientist<br>
Palo Alto Research Center (PARC)<br>
<a href="tel:%2B1%28650%29812-4458" value="+16508124458" target="_blank">+1(650)812-4458</a><br>
<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a><br>
<br>
_______________________________________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Ndn-interest mailing list</span><br><span><a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a></span><br><span><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>