[net2-wg] Should CTP header have hop count?
Rodrigo Fonseca
rfonseca at cs.berkeley.edu
Wed Nov 12 22:09:55 PST 2008
I would say that THL fits the bill.
It says how many hops the packet traversed, and that's what's really important.
If we want to compare the origin's idea of its distance from the root
to the THL when the packet actually arrives at the root, we could put
the hopcount in the payload for this experiment.
We can also change the name from THL to Hopcount :) (I'm not serious here)
Rodrigo
On Wed, Nov 12, 2008 at 2:30 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Nov 12, 2008, at 1:23 PM, Omprakash Gnawali wrote:
>
>> On Wed, Nov 12, 2008 at 12:10 PM, Philip Levis <pal at cs.stanford.edu>
>> wrote:
>>>
>>> On Nov 11, 2008, at 9:41 PM, Omprakash Gnawali wrote:
>>>
>>>> As we get closer to standardizing the protocol, it might be good to
>>>> discuss if we should include the hop count field in the CTP header.
>>>>
>>>> Many times it would have made our life easier if we had this field.
>>>
>>>
>>> How would it have made our lives easier? The only case I can think
>>> of is
>>> detecting routing inconsistencies. Given recent experimental results,
>>> however, this doesn't seem to be a big issue. This is something we
>>> can
>>> evaluate, though: if we include a hop count field and use it for
>>> trickle
>>> timer resets, does it reduce control traffic/reduce cost?
>>
>> Directly knowing the topological depth of a node would have made it
>> easier to debug and understand but that would not be the reason to
>> include this field in a live network.
>>
>>>> Many times users have asked how to know how many hops away a
>>>> particular node is.
>>>
>>> I'm a bit wary of including a field for something like this,
>>> especially
>>> given how adaptive CTP is. THL fits this need: it tells you how
>>> many hops a
>>> packet took, which tells you how many hops a node was away for that
>>> packet.
>>> Maybe if we added some tools to help visualize this?
>>
>> If someone wants to implement a different forwarding engine, which
>> many have done and many are planning to do, they might appreciate
>> knowing the depth of a node or maybe they won't. ETX of a node gives
>> some approximation of that.
>>
>>>> Having hop-count would also provide an alternate mechanism for loop
>>>> detection in case someone wants to use that mechanism.
>>>
>>> Agreed, and it may well be that it would lead to a more efficient
>>> protocol.
>>> But this is something we can evaluate.
>>
>> Even if the performance is comparable, should we preclude those
>> mechanisms?
>>
>> Is there any reason people want to use hop count information in higher
>> level protocols?
>
> One question is whether this is the origin hopcount or the single-hop
> hopcount. If the former, it's only useful for networking information;
> if the latter, it's only useful for detecting topology
> inconsistencies. I assume ARC uses the latter?
>
> THL already fills the need for origin hopcount. So the question is
> whether we want a single-hop hopcount.
>
> Phil
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg
>
More information about the net2-wg
mailing list