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

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

Hi Thomas,

>>>>>> What if someone defines a reliable transport and suppress
>>>>>> repeating messages?
>>>>>
>>>>> In that case, that mechanism of using packet seq. numbers would not
>>>>> work. But I think this is okay, since the NHDP draft does not
>>>>> mandate
>>>>> this mechanism. If one decides to use packet sequence numbers for
>>>>> indicating lost packets, one probably has to assume a non-reliable
>>>>> transport transport protocol such as UDP.
>>>>
>>>> You missed my point.
>>>> The protocol would suppress the repeated info.
>>>>
>>>
>>> Then I do not understand. Your L2 (or "something-behaving-as-L2")
>>> below IP is reliable. That's fine, you'll get 100% of packets across.
>>
>> 100% delivery ratio is the goal of reliable multicast.
>> But at cost of delay and other annoying aspects.
>> It runs at layer 4 (instead of UDP or vanilla IP).
>
>However, if you run it for NHDP, it would effectively look as a "very
>good L2", yes?

Yes.
I did not suggest exchanging hello messages over it. For TCs, originated
from over the place, it would make sense. OSPF tackles the problem
from the other end of the spectrum, here we have only the reliable LSA
transfer.


>>> A great L2 and a great feat if you can do reliable broadcast to an
>>> unknown recipient set (I'd like to learn more if you have one at
>>> hand).
>>>
>>>>>> Are we sure we want to use missing sequence numbers as
>>>>>> indication of missed packets?
>>>>>
>>>>> No, we don't want to mandate it. It is just *one* possible way,
>>>>> under
>>>>> certain assumptions (no reliable transport protocol).
>>>>
>>>> But it is an impossible way, as defined today in the spec.
>>>
>>> How so? Your L2 does not lend itself to "counting packets" - so you
>>> won't, you'll use something else (more appropriate to your L2) for
>>> establishing the quality.
>>>
>>> This is not only enabled by the spec, but even recommended.
>>
>> Back to my first comment, the spec needs a fix. Then, we can recommend
>> to use it. But only when sequence numbers are used.
>> We could regret this in the future, when working on optimizing TC
>> load.
>
>What do you suggest to fix in the spec? If it does say "you MUST use
>sequence number counting", then the spec is wrong. If the spec says
>that "sequence number counting MAY be used, if nothing better is
>available", then I am not sure what's wrong?

I recommend using hello messages sequence numbers only.


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.


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.
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.


Teco.