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

[Ravi Ravindran]

For the record, I'm from the industry :).

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.

Regards,
Ravi

On Tue, Mar 15, 2016 at 9:53 AM, Syed Hassan Ahmed <s.h.ahmed at ieee.org>
wrote:

> 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/20160315/7545da4f/attachment.html>