[aodvv2-discuss] Re: Fwd: [manet] A few more AODVv2 comments
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Thu, 19 Mar 2015 11:52:22 +0000
Hi Charlie,
Comments below:
On Wed, Mar 18, 2015 at 9:47 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
>
> Hello folks,
>
> Comments please on these matters brought up by Chris.
>
>
>
> -------- Forwarded Message -------- Subject: [manet] A few more AODVv2
> comments Date: Thu, 12 Mar 2015 16:07:44 +0000 From: Dearlove,
> Christopher (UK) <chris.dearlove@xxxxxxxxxxxxxx>
> <chris.dearlove@xxxxxxxxxxxxxx> To: manet@xxxxxxxx <manet@xxxxxxxx>
> <manet@xxxxxxxx>
>
>
>
> Section 6.2 reasons to recognise bidirectionality could include L2
> information.
>
>
> It currently says: "Lower layer trigger that a link is broken"
>
>
> This could be changed to say "Lower layer trigger that a link is no longer
> bidirectional"
>
> or "Lower layer triggers, for example message reception or link status
notifications".
The fact we are receiving L2 frames could be seen as a confirmation of
bidirectionality?
>
>
> I would have explicitly said NHDP HELLO message, not just message later in
> that section (though it is the only NHDP message).
>
>
> That enlargement fits well in Section 4 during the discussion where NHDP
> is mentioned, and I put it there.
>
> Easily added in the list though?
>
> Blacklist removal seems to be MAY at one point, and SHOULD at another.
>
> Fixed.
>
> Also that’s discussing things that trigger additions to blacklists (e.g.
> failure to receive RREP_Ack) and removals due to timeouts. Might there not
> also be specific reasons to remove from blacklists (e.g. receiving NHDP
> HELLO that indicates that if using that option)?
>
> Yes, this is a good point.
>
> True, we have already put in that if RREP_Ack is received from a router
on the blacklist, it is removed from the blacklist. Maybe in Section 6.2
where we discuss adding to the blacklist if we receive notification of a
non-bidirectional link, we also mention "If any of these triggers signal
that bidirectional connectivity exists to a blacklisted router, the router
can be immediately removed from the blacklist." or something similar?
> It seems rather a lack of progress that we are still at the only form of
> metric that an implementation will know what to do with is a hop count.
>
> That's not true. It is known how to use other metrics, and in fact
> specifications for AODV were written for the other metrics. However those
> specifications have been considered to be out of scope for the base
> document.
>
> Well, almost. Most of the discussion of metrics appears to require only an
> increasing function. Except the penultimate bullet in the first list in
> Section 8.1 appears to be explicitly additive. Once you decide on additive,
> you can make the whole metrics decision much more open.
>
> Having gone to the trouble of including mechanism for alternative metrics,
> it would seem a shame to make such a severe restriction.
>
>
> Is it enough to say that the current draft will support any additive
metric / increasing metric, using Cost(R) = AdvRte.Metric + Cost(L), where
Cost(L) > 0, but also that LoopFree may be further optimised for other
metrics? Not mentioning specific metric types but making it extra clear
that its possible with the current spec to use a different metric. Note -
our Section 7.4 doesnt actually say a different LoopFree may also be
required.
> I’d go with Henning’s suggestion to fix a single data type (32 bit
> integer perhaps) which would replace the second paragraph of 7.4 and make
> things much more easily extensible.
>
>
> A single data type for metric cannot accurately represent the costs of the
> routes. All you can get is monotonicity. Or maybe I misunderstand?
>
> Section 8.1, from the numbered points onwards, appears to give three
> descriptions of how you handle competing routes. One is good, if completely
> rigorous. Two is fine if the other one is more human readable (and possibly
> belongs in an earlier section). Three appears more than is wanted. (I also
> note the use of both AND and && in the second.) Note that I haven’t
> actually checked if all three are consistent (that’s not trivial when they
> switch between formulae and terms like stale) let alone if they work. (I
> recall someone has done some work on the latter point, is that
> published/referenceable?)
>
> I agree with this, and perhaps the pseudo-code version is better left in
the appendix in A.1.1? And we may not need the summary at the end of 8.1?
We do have inconsistency with where LoopFree is checked. It is step 3 in
section 8.1, which means it is currently not checked if the advertised
route is lower cost, and is only checked if its repairing an invalid route.
But in the appendix we check LoopFree first before even checking SeqNum. I
suppose the correct thing would be to check it after determining the
incoming information is not stale. Suggestions:
8.1:
Switch step 2 and 3.
Add in to the new Step 2: "If LoopFree returns true, continue to step 3."
The final point in the new Step 3 should be: "If the advertised route's
cost is the same or greater than the stored route, but the stored route's
state is Invalid, the advertised route can be used to repair the Invalid
route, since it has been proven LoopFree in step 2."
Remove the rest of the section. At least remove the pseudo-code since this
is slightly inconsistent as is, and is present in a more accurate form in
the appendix.
A.1.1:
/* rules from 8.1 */
if (AdvRte.SeqNum < Route.SeqNum) /* advertised route is stale */
return null;
if (!LoopFree(advRte, rte))
{ /* incoming route cannot be guaranteed loop free */
return null;
}
if (
(advRte.SeqNum > Route.SeqNum) /* stored route is
stale, use advRte */
OR
((advRte.SeqNum == Route.SeqNum) /* same SeqNum */
AND
[(advRte.Cost < Route.Metric) /* advRte is better */
OR
((Route.State == Invalid))] /* advRte can repair stored */
{
Update_Route_Table_Entry (rte, advRte);
}
One publication is cited. Another publication about AODVv1 would still be
> valid and could be cited.
>
> Section 8.3 first paragraph I think would be better separating out
> AODVv2 from IP. Whether to forward a packet is a decision made consulting
> IP’s table, not AODVv2’s use of invalid. I think that means you should
> indicate that invalid routes should be struck from IP’s table.
>
> Well, not exactly, because invalid routes still contain valid sequence
> number information.
>
> So we have a local table which includes all the routes, including Invalid
ones, and we insert or remove entries in the main IP routing table
depending on state, so that the IP routing table contains all the AODVv2
routing table's Active and Idle routes but not the Invalid ones.
>
>
> Third paragraph in 8.3 precursor table appears from left field. (Unless
> I’ve missed an earlier reference, I haven’t done an electronic search).
> While postponing details is fine, the fact that there is such a thing,
> related to a route, and might matter, wants flagging up earlier. At the
> least indicated as a possible addition in Section 6.1.
>
>
> The precursors are indeed mentioned as an optional part of the route table
> entry. I added a cross reference in section 6.1 also. What more should be
> done? It was earlier thought that specification details about optional
> features should be in the optional section. For myself, I think the
> feature is important enough to belong in the main body of the text, but I
> had earlier been requested to describe it as optional ...
>
> Maybe to soften it, change to "Implementations which support the optional
feature of precursor lists as described in Section 12.2 MUST also expunge
the route's precursor list at the time that the route itself is expunged."?
Or is this an implementation detail we dont really need to put here? We
could have a Delete_Route_Table_Entry in the appendix where we stress that
the precursors list should be expunged?
>
>
> Section 8.4 invalid route may be expunged. What’s the intended status of
> the least recently used comment? Is that a may within a may, or a should
> within a may (you may do this, if you do, you should do it that way), or
> just a suggestion?
>
>
> It is a MAY and a SHOULD within the MAY.
>
> Does this make that clearer: "Any Invalid route MAY be expunged, but the
least recently used Invalid route SHOULD be expunged first."?
>
>
> The binary exponential backoff on page 25 needs more about what is and is
> not proposed (and how its parameters – not specified – relate to other
> parametesr).
>
>
> Here is the text from RFC 3561:
>
> To reduce congestion in a network, repeated attempts by a source node
> at route discovery for a single destination MUST utilize a binary
> exponential backoff. The first time a source node broadcasts a RREQ,
> it waits NET_TRAVERSAL_TIME milliseconds for the reception of a RREP.
> If a RREP is not received within that time, the source node sends a
> new RREQ. When calculating the time to wait for the RREP after
> sending the second RREQ, the source node MUST use a binary
> exponential backoff. Hence, the waiting time for the RREP
> corresponding to the second RREQ is 2 * NET_TRAVERSAL_TIME
> milliseconds. If a RREP is not received within this time period,
> another RREQ may be sent, up to RREQ_RETRIES additional attempts
> after the first RREQ. For each additional attempt, the waiting time
> for the RREP is multiplied by 2, so that the time conforms to a
> binary exponential backoff.
>
>
> Would that be sufficient?
>
> "SHOULD utilize a binary exponential backoff as described in RFC 3561." ?
Or:
"SHOULD utilize a binary exponential backoff where the wait time is
doubled for each retry based on an initial value of RREQ_WAIT_TIME."
>
> I’m not at all sure about the packet queuing comments. Do we have good
> experience here? Is affixed buffer right? Is that “usually positive”
> comment known to be so? I know enough about buffering to know I don’t know
> enough about buffering, and that there are some counterintuitive results
> in the field.
>
>
> I have had quite a bit of experience with buffering. This draft is not
> the place to review those results,
> but one thing for sure is that TCP session initiation packets ought to be
> buffered.
>
>
> I haven’t read section 9 in any detail yet, but I will note that figure 1
> is really about message contents, not message structure (or format).
>
>
> The contents of the message are organized according to the structure in
> the figure. We could mix up the contents in any order, and they
> would still truthfully be the contents. The ordering of the contents
> follows the structure as shown. I'm not sure how to make this clearer.
>
>
> I agree with you, it mirrors what the RFC5444 message will look like, and
> this is why we explain the messages in this order. Maybe using the word
> "format" makes it seem like this should be more specific, but it's for
> RFC5444 to handle the specifics of the format. We could replace "have the
> following general format:" with "have the following contents:" and it would
> appease Chris here without really making much difference? The reader gets the
> idea of the message structure anyway from the way we've written the rest of
> the section.
Regards,
Vicky.
Regards,
> Charlie P.
>
>
Other related posts:
