[Ndn-interest] Hop-by-Hop Flow Balance

[Syed Hassan Ahmed]

Dear Prof. Ravi,

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: 

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. 

Also, there are so many situations, where the Data may want to be delivered by itself. I refer it as "Data Speaks".

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. 

Expert opinions are welcomed. 

Best Regards,
Syed Hassan Ahmed. (하산)
Kyungpook National University,
Daegu, Republic of Korea. 
https://sites.google.com/site/shahmedknu/

> On Mar 16, 2016, at 1:22 AM, Ravi Ravindran <ravi.ravindran at gmail.com> wrote:
> 
> 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.
> 
> Regards,
> Ravi
> 
>> On Mon, Mar 14, 2016 at 4:09 PM, <Ignacio.Solis at parc.com> wrote:
>> [ Disclaimer: CCN currently uses flow balance as well ]
>> 
>> The current Hop-by-Hop Flow Balance is nonsense.
>> 
>> 
>> 
>> 
>> 
>> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" <ndn-interest-bounces at lists.cs.ucla.edu on behalf of aa at CS.UCLA.EDU> wrote:
>> >[6] **Hop-by-Hop Flow Balance**:
>> >    Over each link, one interest packet should bring back no more than one data packet.
>> 
>> Seriously, who thinks this actually works?
>> 
>> Let me quote the webpage ( http://named-data.net/project/ndn-design-principles/ ):
>> "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet.
>> 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.
>> "
>> 
>> Either there is a lot of information missing here to justify why this is so, or this is very naïve.
>> 
>> 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.
>> 
>> 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.
>> 
>> Please explain why the 1-to-1 is good.
>> 
>> 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?
>> 
>> If this principle were to be re-written as:
>> “Allow network nodes to participate in flow control” then the actual engineering solution might be able to achieve this.
>> 
>> Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding.
>> 
>> It would be awkward if the only way for NDN to work over Satellite links would be to break the principles.
>> 
>> Nacho
>> 
>> 
>> 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.
>> 
>> --
>> Nacho (Ignacio) Solis
>> Protocol Architect
>> Principal Scientist
>> Palo Alto Research Center (PARC)
>> +1(650)812-4458
>> Ignacio.Solis at parc.com
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160316/725f0882/attachment.html>