Re: [manet] NHDP: Link quality based on seq-num

["Teco Boot" <teco at inf-net.nl>]

Hi Henning,

>-----Oorspronkelijk bericht-----
>Van: Henning Rogge [mailto:hrogge at googlemail.com]
>Verzonden: dinsdag 10 november 2009 5:10
>Aan: manet at ietf.org
>CC: Teco Boot; 'Thomas Heide Clausen'; 'Dearlove, Christopher (UK)'
>Onderwerp: Re: [manet] NHDP: Link quality based on seq-num
>
>Am Montag 09 November 2009 20:47:39 schrieb Teco Boot:
>> Hi Thomas,
>> I recommend using hello messages sequence numbers only.
>I thought we were talking about packet sequence numbers. Message
>sequence
>numbers are something totally different.

Yes. But my recommendation is to use msg-seq-num. I'm not sure
all packets send via an interface are received by all neighbors.
For hello's, I'll say this is a valid assumption. Or we can make
it mandatory for NHDP. I heard Justin the other day promoting 
PacketBB for a very different application. What if I write a 
draft on multicast joins / prunes, that uses unicast?


>> It need more thoughts, but what about using hello msg-seq-num?
>> Hello messages could have msg-seq-num per interface. Then, we
>> have the timer based detection and the sequence number detection,
>> both using hello messages.
>> We need a RFC5444 errata on msg-seq-num if we use this.
>> I think it makes sense to have hello incrementing msg-seq-num per
>> interface and incrementing TC msg-seq-num per message. The errata
>> would say incrementing sequence numbers for 1-hop advertized messages
>> and packets must have per interface numberspaces.
>I don't think that makes sense Teco.
>
>> For TCs, I prefer not incrementing the msg-seq-num for repeating,
>> identical messages. Then, suppression or reliable transfer with
>> regenerating the repeating messages becomes doable.
>> Also, the receiving node has better knowledge on having a topology
>> update or not, by checking the sequence number only. Little gain here,
>> but still.
>That's why TCs have an answer-set number.

It must have been the product of jet-lag, readability of the draft and
a TLV for just a seq-num. By the way, did you mean the sequence number 
as value in TLV CONT_SEQ_NUM, called ANSN?.


>
>> With this approach, the OLSR spec would say the repeating TC message
>is
>> not regenerated each time send out. The mechanism shall be implemented
>> on a generating node A for support for a suppressing node B. So it
>needs
>> implementation on all nodes for interoperability.
>I think you are really mixing up multiple sequence numbers in OLSR. At
>the
>moment we have three different numbers:
>
>1.) packet sequence numbers. They have some kind of "link local scope"
>and can
>be used for estimating the packet loss on a link.

IMHO this is not always true.


>2.) message sequence numbers. These are "end to end", generated by the
>originator of the message and are used for duplicate detection.

OK. But then, are they mandatory for TC?


>3.) answer set numbers. They are only in the TCs and are increased every
>times
>the topology information a nodes sends has changed.

Is this OLSRv2?
I need more time to read this over.


Teco.