[Ndn-interest] HopLimit vs Interest aggregation

[David R. Oran]

Ignore if you want because the below is off-topic…

DaveO

On 1 Apr 2018, at 10:42, Christos Papadopoulos wrote:

> On 04/01/2018 08:19 AM, David R. Oran wrote:
>> On 30 Mar 2018, at 12:38, Junxiao Shi wrote:
>>
>>> Dear folks
>>>
>>> NDN Packet Format v0.3 introduces a HopLimit element in Interest packet.
>>> The spec says:
>>>
>>> If element is present: if the HopLimit value is larger than or equal to 1,
>>> a node should accept the packet and decrease the encoded value by 1.
>>>
>>>
>>> My question is, how should a node proceed if multiple Interests with same
>>> name but different HopLimit values are aggregated?
>>>
>>> Consider the following topology:
>>>
>>> A--\
>>>      G---P
>>> B--/
>>>
>>> First, G receives an Interest /P HopLimit=10 from A and forwards it to P
>>> with HopLimit=9.
>>> Later, after any suppression period has elapsed but before P replies and
>>> before A's Interest expires, G receives another Interest /P HopLimit=5 from
>>> B.
>>> Should G forward the Interest to P with HopLimit=4, or HopLimit=9?
>>>
>>> I can see arguments both ways.
>>> The argument for choosing HopLimit=4 is: it is possible that the Interest
>>> from B is the previous Interest looped back. There could be a path from P
>>> to B (not shown in the topology, as G does not know the global topology),
>>> and one of the routers on that path has changed the nonce for probing.
>>> The argument for choosing HopLimit=9 is: when G retries the Interest, it
>>> should use the maximum HopLimit among unexpired downstream nodes, to
>>> maximize the possibility of reaching the content.
>>>
>> Safety over optimality. Hop Limit is a protection mechanism. Be conservative.
>> Always decrement the hop limit when forwarding. NEVER increase it.
>
> In addition, Hop Limit (or the equivalent TTL in IP) has proven useful in scoped communication, especially in multicast.
Using hop limits for this is a hack. IP should have had scoped communication. If we want scoped communication or resource control for multicast spread in ICN, this should be designed into the protocol explicitly rather than overloading a protection mechanism.

> I think the wishes of the Interest sender should be respected, there may be a reason for the selected value of Hop Limit. Moreover, changing the value in the middle of the network without notifying the sender makes things very hard to debug.
>
Yes.

> Christos.
>
>>
>>> What do others think?
>>>
>>> Yours, Junxiao
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> DaveO
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2076 bytes
Desc: S/MIME digital signature
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20180401/7c803b42/attachment.p7s>