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

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Sat, 10 Oct 2015 15:34:08 -0700

Hello Vicky,

Follow-up below...


On 10/10/2015 9:27 AM, Victoria Mercieca wrote:


Hi Charlie,

I figured we were more or less in agreement here.



It seems so... except perhaps for picking the wording least likely to engender heated discussion.



>> Should we still add some reference to the Newer function Charlie wrote? And should we add any explanation that if the incoming sequence number is greater than the current seqnum by more than half the maximum value, then the incoming will be seen as stale? But that we dont care, because if that happened, something bigger is wrong...?
>
>
> It is not possible to measure differences of more than half the size of the sequence number space.
>
> So it is "not possible" for any seqnum to be "greater than" another seqnum by more than half the size of the sequence number space.
>

But this is because of the comparison arithmetic, yes?


Your characterization is true. However, we must have comparison arithmetic, so that makes it tautological.


Clearly if we are allowed to use seqnums between 1 and 65535, then in theory it is possible for seqnums to differ by half the size of the seqnum space. But the arithmetic will in this case always say to discard the incoming info. i.e. the arithmetic won't be able to interpret that difference correctly.


Agreed.

> Picking the size of the seqnum space amounts to a predetermination of what is possible to measure. I don't think it is appropriate to make statements that we "don't care", because we have to care enough to pick a workable seqnum space. In the preceding sentence, the "if" clause is always FALSE because the conditional could never be satisfied in the space of sequence numbers.
>

OK "don't care" was a lazy choice of words... but I was checking you agreed that if the incoming seqnum and current seqnum differed by that much, then something had probably gone wrong,


Yes, and in fact if the seqnums differ by more than 30000 it might be useful to alert the user to an error condition. But I didn't think we had to do that before Last Call.


and the fact that the arithmetic would say to discard the incoming info wouldn't make a big difference. I think (seqnum_a > seqnum_b) would be true, but since we need to do the subtraction to compare, (seqnum_a - seqnum_b > 0) would not be true.



Agreed.


> In fact, 8 bits would probably be O.K. for AODVv2, and that was an early design choice. But 16 bits is "super-O.K.".
>
> My discussion about "Newer()" was in response to a question by Chris Dearlove, and is not related to the size of the seqnum space.
>

I understand that, but my question was whether Newer() needs to be included in the draft?



It might belong in the draft if there is a time when an incoming RteMsg could involve a zero sequence number. But this seems to only happen for an error case:
- If the incoming message had a zero sequence number for OrigRtr or TargRtr, that would be an error
- If the incoming message is to be compared to a valid route, the valid route does not have a zero seqnum.
So it seems to me that we don't need Newer() as such. However, we could flag a zero seqnum as an error in a RteMsg.


And further, did we need to explain in the draft about seqnums that differ by half the seqnum space?


I don't think so, especially if we decide to make an error message eventually.

Maybe an example would help. If someone told you that the flight arrived at 9:00 and train arrived at 3:00, you could not be sure know which one would get you there first. Would you need to explain about the size of the clock space? Even if you knew 9:00am and 3:00pm, you couldn't be sure, but you would be able to make a much better guess. Even if you knew 9:00am Monday and 3:00pm Wednesday, you could not be absolutely absolutely sure, but you would be able to make a extremely much better guess.

I think with 32-bit seqnums, our guesses are going to be even better than the last example in the previous paragraph.

Regards,
Charlie P.



Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 10-2015