[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Nov 10, 2009, at 12:38 AM, Teco Boot wrote:





-----Oorspronkelijk bericht-----
Van: Thomas Heide Clausen [mailto:ietf at thomasclausen.org]
Verzonden: dinsdag 10 november 2009 0:09
Aan: Teco Boot
CC: 'Ulrich Herberg'; 'Dearlove, Christopher (UK)'; manet at ietf.org
Onderwerp: Re: [manet] NHDP: Link quality based on seq-num


On Nov 10, 2009, at 12:02 AM, Teco Boot wrote:


Hi Ulrich,


-----Oorspronkelijk bericht-----
Van: Ulrich Herberg [mailto:ulrich at herberg.name]
Verzonden: maandag 9 november 2009 23:41
Aan: Teco Boot
CC: Dearlove, Christopher (UK); manet at ietf.org
Onderwerp: Re: [manet] NHDP: Link quality based on seq-num

Teco,

On Mon, Nov 9, 2009 at 11:31 PM, Teco Boot <teco at inf-net.nl> wrote:

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? 





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? 

Thomas