[aodvv2-discuss] Re: Call for help

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 31 Mar 2016 16:49:12 +0200

Hi Charlie, hi all,

Am 28.03.2016 um 05:32 schrieb Charlie Perkins 
<charles.perkins@xxxxxxxxxxxxx>:

Hello Lotte and all,

I can't find any email with text for the RERR table.  So here's some new text 
for that purpose.
As we discussed, it is not important for interoperability.

Add a new subsection in section 4:

   The transmission of each RERR message should be recorded
   in a conceptual table called the RECENT_RERR_MESSAGE table that includes
   the following entries:
   - time for deletion = current_time + RERR_AGELIMIT
   - Unreachable Addresses
   - The destination address: either PktSrc or LL-MANET-Routers
   Entries in RECENT_RERR_MESSAGE table SHOULD be deleted after
   their time for deletion.
Add this text at JWD's comment

   A new RERR message MUST NOT be generated if it matches the
   same destination and the Unreachable Addresses are a subset of the
   Unreachable Addresses in an entry of the RECENT_RERR_MESSAGE table.


Thanks for the sketch, I’ve compiled it into the following sections:

4.7.  Route Error (RERR) Table

   Each sent RERR message SHOULD be recorded in a conceptual table
   called the Route Error (RERR) Table.  Each entry contains the
   following information:

   RteMsg.Timeout
      The time after which the entry SHOULD be deleted.

   RteMsg.AddressList
      The AddressList of the RERR to be recorded.

   RteMsg.PktSource:
      The PktSource of the RERR to be recorded, if any.

   RteMsg.MetricTypeList:
      The MetricTypeList of the RERR to be recorded.

   See section Section 6.9 for instructions on how to update the table.

6.9.  Suppressing Redundant Route Error Messages using the Route Error
      Table

   In order to avoid flooding the network with RERR messages when a
   stream of IP packets to an unreachable address arrives, an AODVv2
   router SHOULD avoid creating duplicate messages by determining
   whether an equivalent RERR has recently been sent.  This is achieved
   with the help of the Route Error Table (see Section 4.7).

   To determine if a received RERR is redundant:

   1.  Search for an entry in the Route Error Table where:

       *  RteMsg.AddressList == RERR.AdressList

       *  RteMsg.PktSource == RERR.PktSource

       *  RteMsg.MetricTypeList == RERR.MetricTypeList

       If a matching entry is found, no further processing is required
       and the RERR SHOULD NOT be sent.

   2.  If no matching entry is found, a new entry with the following
       properties is created:

       *  RteMsg.Timeout := CurrentTime + RERR_TIMEOUT

       *  RteMsg.AddressList == RERR.AdressList

       *  RteMsg.PktSource == RERR.PktSource

       *  RteMsg.MetricTypeList == RERR.MetricTypeList

and I’ve extended 7.4.1.  RERR Generation with:

   The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been
   reached.  If approaching the limit, the message should be sent if the
   priorities in Section 6.5 allow it.
   The RERR also SHOULD NOT be generated if it is a duplicate, as
   determined by Section 6.9.

Some notes:
* should we check if a RERR about to be regenerated in 7.4.3.  RERR 
Regeneration is a duplicate as well? I’m thinking yes, but as a SHOULD. (if you 
have control over the whole network and you know everyone’s checking they’re 
not sending streams of RERRs in the first place I guess you can skip this 
step..)
* I’ve renamed RERR_AGELIMIT to RERR_TIMEOUT because all our other timeouts are 
called SOMETHING_TIMEOUT
* same thing with the table name: adjusted it to our other naming conventions
* I’ve also added MetricTypeList as a field to be recorded
* any corrections on my grammar etc are very welcome! :D


Add a line to Table 2:
    RERR_AGELIMIT     |  3 seconds    (or whatever you like)

Done. (I’ve used 3 seconds for now)

The full commit illustrating all changes can be found here: 
https://github.com/Lotterleben/AODVv2-Draft/commit/bbb7a78b8b16bccbe5b2ac3866203d30add32fb0

Regards,
Lotte




Regards,
Charlie P.


On 3/27/2016 6:38 PM, Stan Ratliff wrote:
Lotte, 

On Sun, Mar 27, 2016 at 5:56 PM, Lotte Steenbrink < 
<mailto:lotte.steenbrink@xxxxxxxxxxxx>lotte.steenbrink@xxxxxxxxxxxx 
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,
iirc, our consensus is to get a new Draft out as soon as we can… In order to 
get that done, I’ve got a few issues I feel personally responsible for but 
I’ll need your help with, so I thought I’d send a quick reminder since we’re 
all busy people and E-mails get lost quickly: 

1. Security Considerations TODOs: 
There are still a lot of TODOs in our Security Considerations (see 
http://ietf.10.n7.nabble.com/attachment/488740/1/13.%20Security%20Considerations_v3.txt
 
<http://ietf.10.n7.nabble.com/attachment/488740/1/13.%20Security%20Considerations_v3.txt>
 ). I put them there because I either couldn’t figure out the answer myself, 
or because I wasn’t sure if my answer was good enough. If you could have a 
look at them and send me any proposals for update (or a yay/nay, for example 
concerning (- is this sufficient? Am I overlooking a way to prevent this 
here?) in 13.1.1 Denial of Service), that’d be super helpful.

I took a look at the link - BTW, you've done a super job of collecting all 
of this. I'll need some more time to read & study, but wanted you to know 
I'm looking at it. 
 

2. Resolving all JWD!s:
The critical issues raised by Justin that I have not resolved yet are:

(How does one know which outgoing interface is the neighbor associated with? 
This seems like a very LARGE missing piece of required information JWD!)
(How is this done? There is no table with recently sent RERR messages to 
check. There needs to be though. JWD!)
(AODVv2_INTERFACES isn’t defined before now it should be. Also what does 
this configuration consist of? Also is the list empty if there is  only one 
interface? JWD!)

These all depend on Text promised by Charlie– I think the first one is part 
of a bigger discussion (the „is using MAC addresses a good idea/super 
painful“ one, iirc), but we still need to drill down on the Language that 
describes the *exact formatting* of the InterfaceSet (which is currently 
held in the thread „Definition for AODVv2_INTERFACES“). That would also 
resolve the third issue.

Charlie, did you find the time to write said text yet? I f you didn’t and 
won’t please say so, and in this case, does anybody else have the time? I 
can try, but I’m not quite sure about the quality I’ll be able to deliver, 
so somebody is going to have to volunteer to proofread that stuff.

I'm in the same boat you are - I can give it a go, but I'm *sure* it will be 
sliced and diced on a proofreading...:-) 


What does the editorial team think about getting a Google hangout setup for 
this week? I'd really like to see us post a draft version, with a list of 
items addressed (and items still to be addressed) when the IETF website 
opens back up on April 4. At least we're not talking about posting on April 
fools day... :-)   (Honest, true story - if you'll go browse  
<http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=7,353,261.PN.&OS=PN/7,353,261&RS=PN/7,353,261>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=7,353,261.PN.&OS=PN/7,353,261&RS=PN/7,353,261
 
<http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=7,353,261.PN.&OS=PN/7,353,261&RS=PN/7,353,261>
 , you'll see that the U.S. Patent office does *NOT* take the day off 
issuing patents on April Fool's day.... it kinda puts a sting into something 
that should be an achievement for a software engineer...)    ;-) 

Regards,
Stan


 

Best regards,
Lotte



Other related posts: