[aodvv2-discuss] Re: [manet] AODVv2 comments

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Tue, 6 Oct 2015 21:45:30 +0100

Hi Charlie,

Comment in line

On 6 Oct 2015 19:38, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx>
wrote:


Hello Vicky,

Follow-up below:

On 10/6/2015 11:27 AM, Victoria Mercieca wrote:

......... text deleted ............

As far as I understand the discussion, if seqnums differ by half the
range or more then the message is considered stale, even if the incoming
one is greater than the current one.


In any modular arithmetic, "greater than" is ambiguous. The matter
has to be settled
somehow, and interpreting the result of subtraction as a signed number
does a nice job.


But since this amount of separation would indicate something bigger
went wrong, this is fine...? Does that need explaining?


I don't understand this question.


My point here was that if the seqnums differ by 128 in the 8bit
examples, ie half the range of the seqnum, then the subtraction and
interpretation of the result says we should discard the info. But if
seqnums differ by this much anyway it probably means something wrong has
happened...? So it's OK that the info gets discarded...?


I think it is better to turn this question around. Your example shows
why AODVv2 should
not use an 8-bit sequence number.


OK, but does the principle apply to the 16-bit seqnum too? What I'm getting
at is that if the difference between seqnums is THAT large, the arithmetic
would decide to discard information which actually has a higher seqnum ...
but I'm getting the idea that, as an example (which I didn't actually
check), if our current seqnum is 5 and the received seqnum is 35005 then
there are bigger issues...skating on thin ice as you say below...so in that
case does it matter that the seqnum comparison would result in discarding
the incoming info?

Vicky.

Using a 16- bit sequence number, if two sequence numbers differ by
32,000, then it means
the deployment is skating on thin ice. For such systems, we might need
to create a new
24-bit sequence number TLV. Up until now, people have not gotten
anywhere close to the
thin ice. If people wanted to go to the effort, it would be simple to
define an operating
signal along the lines of "sequence number overflow danger" to be
reported to the user.

Regards,
Charlie P.



Other related posts: