Subject: [manet] Questions on DYMO

From: Fred Baker <[email-masked]>
Date: Sat, 24 Jul 2010 02:00:46 +0200

I have not been looking at DYMO for a while, and am taking the time to think about it. Please consider these to be questions, not complaints or issues.

> 1.  Overview

>    Route maintenance consists of two operations.  In order to preserve
>    routes in use, DYMO routers extend route lifetimes upon successfully
>    forwarding a packet.  In order to react to changes in the network
>    topology, DYMO routers monitor routes over which traffic is flowing.
>    When a data packet is received for forwarding and a route for the
>    destination is not known or the route is broken, then the DYMO router
>    of the source of the packet is notified.  A Route Error (RERR) is
>    sent toward the packet source to indicate the route to that
>    particular destination is invalid or missing.  When the source's DYMO
>    router receives the RERR, it deletes the route.  If this source's
>    DYMO router later receives a packet for forwarding to the same
>    destination, it will need to perform route discovery again for that
>    destination.

Question. It seems to me that splicing routes has some short term advantages; If my path is right now A->B->C->D in

  +-+          +-+           +-+         +-+
  |A|-->...--->|B|---------->|C|-->...-->|D|
  +-+          +-+           +-+         +-+
                  \         /
                   \       /
                    \     /
                     \   /
                      +-+
                      |E|
                      +-+

and B loses its path to C, B could splice the path through E by sending a route request to D via E and letting A retransmit along the subsequently-working path. DSR had explored such things, although I had some concerns with the way they did it. Did the WG look at options such as this?

> 2.  Applicability Statement
> 
>    The DYMO routing protocol is designed for stub or disconnected mobile
>    ad hoc networks (MANETs).

Do the nets have to be mobile? Could they be, for example, low power and lossy (eg sensor) networks?

>    DYMO is applicable to memory constrained devices, since little
>    routing state is maintained in each DYMO router.  Only routing
>    information related to active sources and destinations is maintained,
>    in contrast to most other more proactive routing protocols that
>    require routing information to all routers within the routing region
>    be maintained.

Has there been any analysis of the sizes of route tables in active networks using DYMO? For example, if I have a mesh network consisting of perhaps 30 sensor nodes that can relay for each other and ultimately get back to one of a couple of gateways to other types of networks, perhaps light switches and lamp controllers in a home connected to an energy management system, has there been consideration of how much memory is required at peak loads?

>    DYMO MUST only utilizes bidirectional links.

I very much like this part...

> 3.  Terminology

>    Distance (Dist)
>       A metric of the distance a message or piece of information has
>       traversed.  The minimum value of distance is the number of IP hops
>       traversed.  The maximum value is 65,535.

Routers traditionally play interesting games with things like this. For example, one could imagine a router that received the last M of N updates from a neighboring router reporting a metric of N/M (or some other function), with a view to biasing routes in the direction of the more stable linkages. Did the working group consider such things, or is this left to operational practice?

> 4.  Data Structures
> 
> 4.1.  Route Table Entry
>     ...
>    Route.Address
>       The (host or network) destination address of the node(s)
>       associated with the routing table entry.
> 
>    Route.Prefix
>       Indicates that the associated address is a network address, rather
>       than a host address.  The value is the length of the netmask/
>       prefix.

Could we get Route.Address and Route.Prefix stated as a network layer identity and locator? This would match terminology used in RRG. An identity identifies a system independent of its link layer address, and a locator indicates where it is in the network layer topology.

>    Route.NextHopAddress
>       The IP address of the adjacent DYMO router on the path toward the
>       Route.Address.
> 
>    Route.NextHopInterface
>       The interface used to send packets toward the Route.Address.

From a resiliency perspective, it would be very nice if a DYMO router could maintain a set of next hops; losing one or link congestion simply results in traffic being re-routed via a different next hop.

> 4.2.  DYMO Messages
> 
>    When describing DYMO protocol messages, it is necessary to refer to
>    fields in several distinct parts of the overall packet.  These
>    locations include the IP header, the UDP header, and fields from
>    [RFC5444].  This document uses the following notation conventions.

Dumb question. Why can DYMO not support transports other than UDP, or IPsec traffic? UDP is heavily referenced in the document, but I don't see the connection. Hint: DYMO is being considered for some non-mobile uses, and these would likely carry netconf/soap or netconf/rest-http messages among others, which implies TCP.

> 4.2.1.  Generalized Packet and Message Structure

>    For interoperability with other DYMO routers, all DYMO messages
>    specified in this document SHOULD sent using the IP protocol number
>    (138) reserved for manet protocols [RFC5498]; or the UDP destination
>    port (269) reserved for manet protocols [RFC5498] and IP protocol
>    number for UDP.

How well does DYMO interoperate with other manet protocols that are using the generic manet routing protocol identifiers?

>    Implementations MAY choose to temporarily delay transmission of
>    messages for the purpose of aggregation (into a single packet) or to
>    improve performance by using jitter [RFC5148].

There may be value in specifying upper bounds here. For example, if a host has a retransmission algorithm, it generally will do so on a timeout. It would be nice to have some guidance on how to estimate reasonable RTTs.

>    DYMO control packets SHOULD be given priority queuing and channel
>    access.

Why? For most routing protocols, it is merely necessary that they not be dropped and not be unreasonably delayed, where the definition of "unreasonably" depends on network configuration. For example, in OSPF, a router will drop a neighbor if it doesn't receive a HELLO from it within some stated interval dependent on configuration, and what is required of the sender of the HELLO is that it not intentionally drop them (if they are sent and not received, that is out of its control), and it should not be delayed long enough to transgress the neighbor down interval. That is hardly "priority", which would suggest that it has to be the next message sent.

> 5.  Detailed Operation

I have not gone through this in detail on this round, although I have in the past. I would be very interested in implementation reports comparable to RFC 1246.

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 26 Jul 2010 10:55:10 -0400

Hi Fred, 

Thanks for all the all the great feedback. 

If you have any additional suggestions, please don't hesitate to pass them on.

Ian

More comments inline.

> Question. It seems to me that splicing routes has some short term advantages; If my path is right now A->B->C->D in

We did not explicitly look at this type of behavior being done proactively or automatically. That said, the DYMO protocol specification would allow this type of behavior.

> Do the nets have to be mobile? Could they be, for example, low power and lossy (eg sensor) networks?

The nets do not have be mobile, and DYMO may be applicable in low power lossy sensor networks. Without lots of details about a particular network deployment and application traffic, it is very hard to make generalizations in MANET.

> Has there been any analysis of the sizes of route tables in active networks using DYMO? For example, if I have a mesh network consisting of perhaps 30 sensor nodes that can relay for each other and…

I am not aware of any studies directly along these lines. As I stated above, it is very hard to generalize the performance without a lot of details.

> Routers traditionally play interesting games with things like this. For example, one could imagine a router that received the last M of N updates from a neighboring router reporting a metric of N/M…

The MANET WG has had a lot of discussion about this topic, but we've been unable to provide any generic rules that apply to different deployments. For this reason, the base protocols have stuck to using dimensionless protocols to influence routing decisions.

> Could we get Route.Address and Route.Prefix stated as a network layer identity and locator? This would match terminology used in RRG. An identity identifies a system independent of its link layer a…

Can you please provide some replacement text?

> From a resiliency perspective, it would be very nice if a DYMO router could maintain a set of next hops; losing one or link congestion simply results in traffic being re-routed via a different next…

The base spec does not describe this type of behavior, but I know people are playing with it. For those out there reading this email, I think this would make for a wonderful extension to DYMO. Anyone interested in writing a draft?

> Dumb question. Why can DYMO not support transports other than UDP, or IPsec traffic? UDP is heavily referenced in the document, but I don't see the connection. Hint: DYMO is being considered for so…

DYMO could use other transports. Can you please suggest changes to the text that would more easily allow for other transports while still maintaining interoperability?

> How well does DYMO interoperate with other manet protocols that are using the generic manet routing protocol identifiers?

DYMO's messages have their own IDs to differentiate them from other MANET protocol messages.

> There may be value in specifying upper bounds here. For example, if a host has a retransmission algorithm, it generally will do so on a timeout. It would be nice to have some guidance on how to est…

This is a great topic, I'll start up another thread to the MANET list on this topic since it is applicable to all the MANET protocols.

> Why? For most routing protocols, it is merely necessary that they not be dropped and not be unreasonably delayed, where the definition of "unreasonably" depends on network configuration. For exampl…

Although there are multiple situations that would benifit from control packets having priority, I will describe only one; RERR. If RERR have priority then they can stop traffic from entering the network. For wireless networks this could have a large impact network wide.

This function is described as a SHOULD and not a MUST to allow for non-priority access.

If others in the group feel it would be good to remove this statement, I personally am not strongly opposed.

Ian
</end>

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