Subject: Re: [manet] AODVv2 comments

From: Charlie Perkins <[email-masked]>
Date: Tue, 1 Sep 2015 13:40:17 -0700

Hello Marc,

I tend to agree that we should reduce the normative specification related to
packet buffering.  However, it is pretty clear that buffering can be 
very helpful,
especially for TCP; for this reason, I think the document should at 
least suggest the
use of buffering and describe a little bit about the benefit. Presumably any
implementation that includes buffering will also not make silly choices 
about the
implementation-dependent parameters.  Given that, I reckon we could 
follow your
suggestion about deleting that paragraph.

A few moments with Google showed the following references:

    Load Balanced and Energy Efficient AODV protocol
    http://www.crcnetbase.com/doi/abs/10.1201/b18508-33

    Smooth handoff with enhanced packet buffering-and-forwarding in
    wireless/mobile networks
    http://dl.acm.org/citation.cfm?id=1276170

If you have any more suggestions, they would be appreciated.

Regards,
Charlie P.

On 8/21/2015 12:59 PM, [email-masked] wrote:
> Charlie,
>
> In regards to Chris’ comment about section 6.4 page 23 para 3, I agree 
> that specifying a fixed length (in packets or bytes) buffer does not 
> belong here.  It’s one way to do it, but this feature has nothing to 
> do with the AODV protocol.  The two defined constants in this 
> paragraph are only used in this paragraph, so I think para 3 can just 
> about be dropped.
>
> Para 2 already says “MAY” be queued, so I think all one needs to say 
> is that the nature of the queue is implementation dependent.
>
> Marc Mosko
>
>> *From: *"Charles E. Perkins" <[email-masked] 
>> <mailto:[email-masked]>>
>> *Subject: **Re: [manet] AODVv2 comments*
>> *Date: *August 20, 2015 at 11:36:59 AM PDT
>> *To: *Mobile Ad Hoc Networks mailing list <[email-masked] 
>> <mailto:[email-masked]>>
>> *Reply-To: *Mobile Ad Hoc Networks mailing list <[email-masked] 
>> <mailto:[email-masked]>>
>
> [snip]
>>>
>>> Section 6.4 page 23 para 3 why fixed buffer? And as this is supposed 
>>> to be IP’s job, why specify?
>>>
>>
>> IP never had to do this before, because IP never had to work with 
>> reactive route establishment.
>>
>>>
>
> [snip]
>> Regards,
>> Charlie P.
>>
>>
>> _______________________________________________
>> manet mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 21 Sep 2015 09:52:18 +0000

I said I hadn't thought this one through, so  here is the thinking.

Charlie quoted RFC 3651

   In order to ascertain that information about a destination is not

   stale, the node compares its current numerical value for the sequence

   number with that obtained from the incoming AODV message.  This

   comparison MUST be done using signed 32-bit arithmetic, this is

   necessary to accomplish sequence number rollover.  If the result of

   subtracting the currently stored sequence number from the value of

   the incoming sequence number is less than zero, then the information

   related to that destination in the AODV message MUST be discarded,

   since that information is stale compared to the node's currently

   stored information.

But noted that for AODVv2 this should be 16 bit. I'm going to work with 8 bits, simply because the examples are easier. But of course the principle applies to 16 bits too.

First, I don't actually know exactly what the above means. I can guess, but am not certain. So the words, whether right or wrong, really should be clearer.

Let's take a simple case, current stored 128, incoming 129. We can't use signed 8 bit arithmetic unless those are signed 8 bit values, so I assume (this should be clearer) that means we assume that the current stored is -128, the incoming is -127, we subtract current from incoming i.e. -127 - -128 = 1. Which is not less than zero, we don't discard, as expected. OK.

Now let's try current 127, incoming 128 (-128). Now we have -128 - 127 which is 1, but only if we assume signed arithmetic wraps. Signed arithmetic does wrap on most processors, but if for example you were coding that in C, that's actually explicitly not defined by the standard. This isn't C, but at the least the text needs to mention wrapping. (Unsigned arithmetic is guaranteed to wrap in C, and mathematically it's more easily defined, which is why that's generally preferable.)

OK, now let's try current 64, incoming 192 (-64). Now we have -64 -64 = -128. That's negative, so we discard. As we should, the separation is 128, more than half of the 255 range.

But try current 192 (-64), incoming 64. Now we have 64 - -64 = -128 (with wrapping). Which is negative, so we discard. But given that 0 is ignored, the wraparound from 192 to 64 is actually only 127, less than half of 255, so we shouldn't discard.

OK, that's a bit of a corner case, frankly by the time you are that separated it's pretty clear something has gone wrong, so in practice it doesn't matter. But then actually something pretty similar applies to smaller separations 127, 126, ...

(In OLSRv2 we have no 0 omitted, so we have an actual ambiguity over the half range separation, which we just decided to say do what you like. I think we did discuss introducing a  parameterisable separation that if exceeded meant something was wrong and you should ... what? As we didn't have an answer for that, that idea went nowhere.)

So in summary (a) this really needs a clearer explanation, (b) it needs to say overflow means wrap, (c) it would be technically better to write using unsigned arithmetic, (d) this gets a corner case wrong, though that probably doesn't matter in practice (because of which I'm going to make no attempt to write a corner case correct version).

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

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