[Ndn-interest] Design choice: naming scheme or packet payload?

scott1091 at yahoo.com scott1091 at yahoo.com
Sun Feb 26 16:55:45 PST 2017

Thank you both for your answers.
I believe that the packet information field in the NDNLP is useful for my application. The endpoints can handle the remaining features. I will let you know of any suggestions or struggles in the near future.


    On Sunday, February 26, 2017 3:48 PM, Klaus Schneider <klaus at cs.arizona.edu> wrote:

 Hi Scott,

I think we should also note that using NDNLP headers to modify 
information at intermediate nodes is more a workaround of the current 
implementation than a permanent requirement of NDN.

The information you are talking about is relevant to the endpoints of 
the connection (consumer and producer), but seems completely irrelevant 
to the endpoints of each link on the path. Putting it inside NDNLP is, I 
think, to choose the wrong layer for the task.

An analogy would be that you want a new feature in the IP protocol, 
let's say larger addresses. But instead of changing IPv4, you add the 
larger addresses to all the link/MAC layer protocols on the way and copy 
the information at each hop.

This has two results: First, you bloat the link layer protocols with 
functionality that doesn't belong there. Second, you create a dependency 
for each newly invented link layer protocol to support the shared 
features (e.g. larger addresses).

This failure of decoupling seems to be exactly what is happening with 

> NDN architecture doesn't allow the payload to be modified

This is true for the current implementation. However, there might be use 
cases for allowing certain parts of the payload or certain metainfo to 
be modified at each node (by keeping them outside the "security 
envelope" of the packet).

Given the bloating of NDNLP, maybe it's time to think about allowing 
intermediate nodes to manipulate well-defined parts of Interest and Data 

Best regards,

On 02/24/2017 10:21 PM, Junxiao Shi wrote:
> Hi Scott
> Neither Name nor MetaInfo should be modified on intermediate nodes.
> Instead, hop-by-hop information can appear as NDNLPv2 headers.
> NDNLP is a link protocol for NDN, specifically designed for carrying
> hop-by-hop information. You may find more information about NDNLPv2
> on https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
> <https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2>
> Yours, Junxiao
> On Fri, Feb 24, 2017 at 2:14 PM, <scott1091 at yahoo.com
> <mailto:scott1091 at yahoo.com>> wrote:
>    Hi all,
>    Thanks for accepting my request.
>    I am working on a NDN forwarding strategy and consumer/producer
>    applications on ndnSIM. Assuming that there are multiple paths from
>    the consumer to a data source, the goal is to improve data delivery
>    based on cross-layer information from the network, so the consumer
>    can select the best face to send the following Interest packets
>    based on number of hops, node ID, throughput, round-trip delay, and
>    geographical location.
>    I see two possible ways to implement that:
>    1. Insert the cross layer information direct in the packet payload
>        Every node along the path would have to update the packet
>    payload or meta data accordingly, and the producer would insert its
>    coordinates.
>        The consumer can then select which face to send the following
>    Interests based on throughput, or distance to content source, or
>    path with less hops, etc.
>        Since the NDN architecture doesn't allow the payload to be
>    modified, intermediate nodes would have to create a copy of the
>    packets. Can I use MetaInfo field?
>    2. Design a naming scheme (more common in the literature)
>        Use a naming scheme to accomodate that. For instance the
>    Interest packet would be /<desired_content>/<hop_count>/<+node_id>
>    and the data packet would be something like
>    /<content>/<hop_count>/<lat_long>/<node_id1 + node_id2 + ... +
>    node_idN>, where node_id1-N refers to the nodes along the path.
>    Are the two implementations feasible? Could you comment on the
>    recommended way to use information from the network in the
>    forwarding decision?
>    Thank you!
> _______________________________________________
> 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/20170227/e617bbd3/attachment.html>

More information about the Ndn-interest mailing list