Subject: [manet] DYMO comments

From: "Romain Thouvenin" <[email-masked]>
Date: Tue, 24 Apr 2007 13:16:55 +0200

Having now a big part of the DYMO specs implemented, I reread the
whole document to see if  I have some general comments that I could
provide. I found some :

 - Well this one is just a question actually. According to the
recommendations, ROUTE_NEW_TIMEOUT = ROUTE_USED_TIMEOUT. So one could
use just one ROUTE_USED timer and set it at the creation of the route.
It would take less memory and be simpler to implement. When is it
relevant to have different timers ?

- A detail : though section 4.2.2 does not mention MsgHdr.HopCnt,
sections 5.3.1, 5.3.2, 5.3.4 and 5.5.3 do. Furthermore, packetbb does
not allow the message header to have a HopLimit but not a HopCnt. Thus
I guess 4.2.2 should also require MsgHdr.HopCnt

- section 5.3.4, "Next, this node checks whether its routing table has
an entry to the AddBlk.OrigNode.Address using longest-prefix
matching." Before doing that, ThisNode must check whether it is the
originator of the message. Otherwise it may add a route for himself, a
(wrong) route for additional nodes in the RM, and it may forward it,
introducing a lot of replicate messages. I agree this is kind of
obvious, but actually I didn't think about it at first, and I saw the
result...

- section 5.5.2, "To avoid removing forwarding routes that are being
used, a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT
for the route to the IP.SourceAddress upon receiving a data packet.".
I am working on sensor networks, and in this context it's quite often
that, most of the time, nodes send data measurement to a base station,
which will not reply. So the reverse route is not going to be used
soon, and it is useless to keep it for long. Maybe setting the timer
should be administratively configurable ?

Here is what I found, hope it helps.

Regards,
Romain

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 24 Apr 2007 10:38:04 -0700

Hello Romain,

Your questions raise some interesting issues about
the current documents.

> should be administratively configurable ?
Actually, I think there are two points here.

First, I think that a route request should be able to
require that the destination be the node to supply
a RREP, which means that intermediate nodes are
disqualified.  This was implicit in early versions of
DYMO, and the current specification provides this
functionality if the originator of a RREQ does not
include the destination sequence number (but see
below).

There is already the specification for gratuitous RREP,
which is a huge win for bidirectional routes.  When
only the destination is allowed to respond, then there is
no need for the gratuitous RREP, but I think that would
be a natural conclusion from the existing specification
when only the destination can send RREP.

I would prefer that there be a flag to control this
behavior of maintaining reverse routes.  This flag would
also inhibit the sending of gratuituous RREP.  If
intermediate nodes were explicitly excluded from
sending RREP, then they could still maintain reverse
routes, so these features are not tightly bound even
though there is some relationship.

I'd also be in favor of an explicit flag for excluding
RREPs from intermediate node, instead of the
abovementioned implicit behavior.  This would
have the side benefit of  avoiding unnecessary
incrementation of sequence number for this case,
which would only matter depending on how often
the intermediate node RREP were disabled in
practice.

Just where to put the flags is not so clear to me.
In the abstract, I am very much in favor of making
use of a generalized header for DYMO messages
(which is the intent in packetbb).  However, as
noted previously I think the balance has to be
tilted towards energy conservation whenever
possible.  I didn't see right off where to put flags
in the generalized header unless it would be in the
"message-semantics" field.  If we can't have message
flags, then I think the design is wrong.  But I might
have missed something.

I still owe a review of the packetbb specification,
which I have not completed.  I hope I find out
where to put flags before I finish the review.

Regards,
Charlie P.

---

From: "Romain Thouvenin" <[email-masked]>
Date: Tue, 24 Apr 2007 22:17:07 +0200

> the intermediate node RREP were disabled in

I agree.
Also, for sensor networks again, routes may be quite stable. So it
would save quite a lot of messages and energy if a new node could get
the routes from its neighbors, even if it has no idea of the
destination's sequence number. It would be even better if the new node
had a mean of asking for any additional information that intermediate
RREP senders would find useful, with another flag I guess.

> flags, then I think the design is wrong.  But I might

I can't see either. The only place where protocols can put
protocol-specific information that apply to the whole message in the
TLV-block. Using a TLV is definitely too much where a few bits could
do it. I guess you're right, packetbb misses a flag system.

> where to put flags before I finish the review.

I also would like to take some time to comment packetbb. In my DYMO
format we previously discussed, address blocks and address-tlv blocks
are the same block, and included values are specified with
DYMO-specific flags in the block header. Since routing protocols
probably don't need 256 TLV types, but rather less than 8 (or maybe
16), this kind of <flags><header>{<address><values>}* block might be
interesting for packetbb.

Regards,
Romain

---

From: "Romain Thouvenin" <[email-masked]>
Date: Tue, 24 Apr 2007 22:20:57 +0200

On 4/24/07, Romain Thouvenin <[email-masked]> wrote:
> TLV-block.

Please read : "seems to be the TLV block".

Romain

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 27 Apr 2007 14:16:49 +0530

Comments inline.

> relevant to have different timers ?

The different timers have different events upon expiration. If your
implementation fulfills the criteria spelled out, you can do it
however you like. This is one of the reasons, we explicitly called out
the different functionality, so that an implementor can take it at
liberty to implement it anyway they like. In earlier versions of DYMO,
we actually used one timer (value) with different flags. This type of
implementation is now optional.

> I guess 4.2.2 should also require MsgHdr.HopCnt

Done.

> obvious, but actually I didn't think about it at first, and I saw the

Done.

> should be administratively configurable ?

The behavior you describe is why SHOULD is there. Would you recommend
we lighten the restriction and change it to a MAY?

To subtly indicate the relative importance, I did switch the
IP.DestinationAddress (first) and IP.SourceAddress (second) route
updates position within the draft.

Ian

---

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 27 Apr 2007 11:13:15 +0200

> updates position within the draft.

I think SHOULD is better. I suggested administratively configurable
because, depending on the context of use, the timer either SHOULD or
SHOULD NOT be set, and an implementation that may be used in both
context would benefit from having the choice.

Romain