<html><head></head><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:16px">Thank you both for your answers.<br><div dir="ltr" id="yui_3_16_0_1_1487964732332_43017">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.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr" id="yui_3_16_0_1_1487964732332_43018"><br></div><div dir="ltr" id="yui_3_16_0_1_1487964732332_43019"><br></div><div id="yui_3_16_0_1_1487964732332_43245"><br></div><div><br></div><div id="yui_3_16_0_1_1487964732332_43246"><span></span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: verdana, helvetica, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Sunday, February 26, 2017 3:48 PM, Klaus Schneider <klaus@cs.arizona.edu> wrote:<br></font></div> <br><br> <div class="y_msg_container">Hi Scott,<br clear="none"><br clear="none">I think we should also note that using NDNLP headers to modify <br clear="none">information at intermediate nodes is more a workaround of the current <br clear="none">implementation than a permanent requirement of NDN.<br clear="none"><br clear="none">The information you are talking about is relevant to the endpoints of <br clear="none">the connection (consumer and producer), but seems completely irrelevant <br clear="none">to the endpoints of each link on the path. Putting it inside NDNLP is, I <br clear="none">think, to choose the wrong layer for the task.<br clear="none"><br clear="none">An analogy would be that you want a new feature in the IP protocol, <br clear="none">let's say larger addresses. But instead of changing IPv4, you add the <br clear="none">larger addresses to all the link/MAC layer protocols on the way and copy <br clear="none">the information at each hop.<br clear="none"><br clear="none">This has two results: First, you bloat the link layer protocols with <br clear="none">functionality that doesn't belong there. Second, you create a dependency <br clear="none">for each newly invented link layer protocol to support the shared <br clear="none">features (e.g. larger addresses).<br clear="none"><br clear="none">This failure of decoupling seems to be exactly what is happening with <br clear="none">NDNLP.<br clear="none"><br clear="none"><br clear="none">> NDN architecture doesn't allow the payload to be modified<br clear="none"><br clear="none">This is true for the current implementation. However, there might be use <br clear="none">cases for allowing certain parts of the payload or certain metainfo to <br clear="none">be modified at each node (by keeping them outside the "security <br clear="none">envelope" of the packet).<br clear="none"><br clear="none">Given the bloating of NDNLP, maybe it's time to think about allowing <br clear="none">intermediate nodes to manipulate well-defined parts of Interest and Data <br clear="none">packets.<br clear="none"><br clear="none"><br clear="none">Best regards,<br clear="none">Klaus<br clear="none"><br clear="none"><br clear="none"><br clear="none">On 02/24/2017 10:21 PM, Junxiao Shi wrote:<br clear="none">> Hi Scott<br clear="none">><br clear="none">> Neither Name nor MetaInfo should be modified on intermediate nodes.<br clear="none">> Instead, hop-by-hop information can appear as NDNLPv2 headers.<br clear="none">> NDNLP is a link protocol for NDN, specifically designed for carrying<br clear="none">> hop-by-hop information. You may find more information about NDNLPv2<br clear="none">> on <a shape="rect" href="https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2" target="_blank">https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2</a><br clear="none">> <<a shape="rect" href="https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2" target="_blank">https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2</a>><br clear="none">><br clear="none">> Yours, Junxiao<br clear="none">><br clear="none">> On Fri, Feb 24, 2017 at 2:14 PM, <<a shape="rect" ymailto="mailto:scott1091@yahoo.com" href="mailto:scott1091@yahoo.com">scott1091@yahoo.com</a><br clear="none">> <mailto:<a shape="rect" ymailto="mailto:scott1091@yahoo.com" href="mailto:scott1091@yahoo.com">scott1091@yahoo.com</a>>> wrote:<div class="yqt5100766651" id="yqtfd44918"><br clear="none">><br clear="none">> Hi all,<br clear="none">><br clear="none">> Thanks for accepting my request.<br clear="none">><br clear="none">> I am working on a NDN forwarding strategy and consumer/producer<br clear="none">> applications on ndnSIM. Assuming that there are multiple paths from<br clear="none">> the consumer to a data source, the goal is to improve data delivery<br clear="none">> based on cross-layer information from the network, so the consumer<br clear="none">> can select the best face to send the following Interest packets<br clear="none">> based on number of hops, node ID, throughput, round-trip delay, and<br clear="none">> geographical location.<br clear="none">><br clear="none">> I see two possible ways to implement that:<br clear="none">> 1. Insert the cross layer information direct in the packet payload<br clear="none">> Every node along the path would have to update the packet<br clear="none">> payload or meta data accordingly, and the producer would insert its<br clear="none">> coordinates.<br clear="none">> The consumer can then select which face to send the following<br clear="none">> Interests based on throughput, or distance to content source, or<br clear="none">> path with less hops, etc.<br clear="none">> Since the NDN architecture doesn't allow the payload to be<br clear="none">> modified, intermediate nodes would have to create a copy of the<br clear="none">> packets. Can I use MetaInfo field?<br clear="none">><br clear="none">> 2. Design a naming scheme (more common in the literature)<br clear="none">> Use a naming scheme to accomodate that. For instance the<br clear="none">> Interest packet would be /<desired_content>/<hop_count>/<+node_id><br clear="none">> and the data packet would be something like<br clear="none">> /<content>/<hop_count>/<lat_long>/<node_id1 + node_id2 + ... +<br clear="none">> node_idN>, where node_id1-N refers to the nodes along the path.<br clear="none">><br clear="none">> Are the two implementations feasible? Could you comment on the<br clear="none">> recommended way to use information from the network in the<br clear="none">> forwarding decision?<br clear="none">><br clear="none">> Thank you!</div><br clear="none">><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">> Ndn-interest mailing list<br clear="none">> <a shape="rect" ymailto="mailto:Ndn-interest@lists.cs.ucla.edu" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br clear="none">> <a shape="rect" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><div class="yqt5100766651" id="yqtfd51229"><br clear="none">><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>