Subject: Re: [manet] How does DYMO differ from AODV?

From: Ulrich Herberg <[email-masked]>
Date: Fri, 6 Aug 2010 15:15:24 +0200

Hi,

On Thu, Jul 29, 2010 at 2:27 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> In order to better understand things, a question that I'm not
> clear on, and I think would be interesting, is how does DYMO
> differ from AODV? Obviously in message format, but ignoring
> that, how does the essential protocol differ?

I am also interested in that question.

Ulrich

---

From: Fred Baker <[email-masked]>
Date: Fri, 6 Aug 2010 15:56:58 +0200

> that, how does the essential protocol differ?

1) DYMO has a MIB

2) DYMO requires that neighbors be duplex - each can reliably hear the other. This is a major issue in AODV.

3) AODV allows for unicast links

4) AODV allows for local route repair

5) DYMO has TLVs to allow for extensibility

6) DYMO allows a route to be "improved": changed in response to superior routing information.

There might be other things, but those are the ones that jump out at me.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 6 Aug 2010 15:36:06 +0100

Thanks for that. I'm not regarding 1 and 5 (which I did know
about) as fundamental (which is not to say they aren't
important). The others (especially 2, 4 and 5) are what I
would consider the key issues. Now the question would be why.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: 06 August 2010 14:57
To: Dearlove, Christopher (UK)
Cc: MANET IETF
Subject: Re: [manet] How does DYMO differ from AODV?

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

1) DYMO has a MIB

2) DYMO requires that neighbors be duplex - each can reliably hear the
other. This is a major issue in AODV.

6) DYMO allows a route to be "improved": changed in response to superior
routing information.

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 6 Aug 2010 17:11:13 +0200

> would consider the key issues. Now the question would be why.

I think your numbers got garbled. I would agree that a MIB is important to have but not fundamental. On the the other points...

Unicast links are very optional; I can think of some scenarios that would really like to have them, but there are issues. A concern in AODV was that if Alice could hear Bob 100% but Bob could hear 10% of what Alice said, and Alice periodically managed to get an RRSP to Bob, Alice would happily ship traffic directly to Bob - black-holing 90%. Establishing duplex connectivity ("Bob and Alice can hear each other just fine") eliminates the black hole, and eliminates simplex operation. So, ix-nay on the implex-say is fine with me given duplex checks.

Local route repair is, IMHO, very nice to have in some mobility scenarios. It does mean that routes aren't necessarily optimal (which they aren't guaranteed to be anyway) - if the route from Alice to Bob is via Carol and Dave, and Carol and Dave move apart, still have a common neighbor in Erin, and repair the route in that way, we may keep communication going but at the cost of a few extra hops. To my mind, in such a circumstance keeping communication going for the duration of the next few RTTs is generally more useful than worrying about the hops. I'm not complaining about DYMO in context, but...

Given that DYMO allows a route to be improved, such inefficiencies would seem very temporary...

Extensibility; well, there have been suggested extensions to AODV such as carrying a bandwidth number in a route request and dropping the request if that amount of bandwidth isn't available. If one uses DYMO to search for "any address in a certain prefix", a TLV could carry the prefix length. I don't automatically want to go to such places, but the option may prove nice to have at some point in the future.

> There might be other things, but those are the ones that jump out at me.

http://www.ipinc.net/IPv4.GIF

---

From: Joe Macker <[email-masked]>
Date: Fri, 6 Aug 2010 14:30:45 -0400

While I'd like hear the authors response on (4), my feeling is local route repair while promising benefits has a less understood tradeoffs in practice adding maintenance complexity.
While implemented perhaps still an experimental type feature.  Did you mean 2,4,(6)? since you said you didnt regard 5 but then listed it later?

On Aug 6, 2010, at 10:36 AM, Dearlove, Christopher (UK) wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
> 

Joe Macker
[email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 9 Aug 2010 09:43:38 +0100

Yes, I meant 2, 4, 6. Thanks for the catch (Fred also).

-----Original Message-----
From: Joe Macker [mailto:[email-masked]] 
Sent: 06 August 2010 19:31
To: Dearlove, Christopher (UK)
Cc: Fred Baker; MANET IETF
Subject: Re: [manet] How does DYMO differ from AODV?

                    *** WARNING ***

While I'd like hear the authors response on (4), my feeling is local
route repair while promising benefits has a less understood tradeoffs in
practice adding maintenance complexity.
While implemented perhaps still an experimental type feature.  Did you
mean 2,4,(6)? since you said you didnt regard 5 but then listed it
later?

Joe Macker