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

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

Hi Chris,

>-----Oorspronkelijk bericht-----
>Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove at baesystems.com]
>Verzonden: maandag 9 november 2009 23:48
>Aan: Teco Boot; Ulrich Herberg
>CC: manet at ietf.org
>Onderwerp: RE: [manet] NHDP: Link quality based on seq-num
>
>> What if someone defines a reliable transport and suppress
>> repeating messages?
>
>There are many ways in which this is not relevant
>- NHDP messages are local broadcast. If you have a reliable
>  local broadcast mechanism to unknown recipients, I think
>  we'd like to know.

PGM and NORM can do the job.


>- The transport mechanism sees packets, not messages. These
>  are much less likely to be repeats. but even messages may
>  not be repeated, due to e.g. message sequence numbers and
>  security mechanisms.

Yes, see other posting. Why are the sequence numbers incremented
For each packet? Sorry, it could be written in the draft and I
have overlooked it. 


>- It's no business of the transport mechanism to do this.
>  There are reasons to repeat messages due to mobility, trying
>  to find unknown nodes etc.

For hello, especially incremental hello, reliable multicast
doesn't help. For TC, it is another story. 


>> Are we sure we want to use missing sequence numbers as
>> indication of missed packets?
>
>It's an option. Nothing in that area is something that must
>be done. It's not my first choice of options, I think there
>are better ones. But that doesn't make it unusable.

After the fix, I can agree.


>> What if other reasons caused the loss, e.g. tail drop during
>> congestion caused by the MANET protocol itself?
>
>If your congestion gets to the point where sufficient dropping
>is occurring to make this happen, then there is a real problem in
>any case, especially if (as one should) give routing signalling
>a better than average priority.

Yes, but broadcast queues with infinite depth have drawbacks to.
Especially when giving priority to it. At least, we need some form 
of shaping or fair queuing.


Teco.

>********************************************************************
>This email and any attachments are confidential to the intended
>recipient and may also be privileged. If you are not the intended
>recipient please delete it from your system and notify the sender.
>You should not copy it or use it for any purpose nor disclose or
>distribute its contents to any other person.
>********************************************************************