[aodvv2-discuss] Re: Resolutions for comments contained in file "draft-ietf-manet-aodvv2-11 (section 5-6).pdf"
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Thu, 13 Aug 2015 10:06:35 +0100
Hi Charlie,
On Wed, Aug 12, 2015 at 10:57 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
More follow-up below...
On 8/12/2015 12:23 PM, Victoria Mercieca wrote:
Alright, at this point we have “known
MetricType”, “configured MetricType” and
then “support the MetricType” — I *think*
that these all should be the same, right?
Diversity in language is great in literature,
but not so great when writing specifications
which are to be read by also non-natives to
the language.
We could replace "known" by "supported", perhaps.
So - we only defined hopcount, but if someone comes along and defines
"metric type a" and "metric type b", not all implementations in use would
necessarily support those.
Some implementations would see those as unknown metric types and would not
regenerate any RREQs or RREPs or RERR info using those metric types.
Some implementations might know about metric A but might not be
interested. So their config might say "ignore metric type a". I guess
that's a bad decision as it affects the rest of the network's ability to
discover routes. But if you're setting up a network and you dont care about
"metric type a" and would prefer not to waste the effort discovering routes
of that metric type, maybe you want to configure your routers not to use
it. Maybe we'd want to configure AODVv2notto use it. So now we have an
"unconfigured" metric type. We know what it means, it is supported, but we
just dont want to waste the effort. (Or maybe we just dont ever ask for a
route using that metric type? Depends how we decide metric type when a
route is requested.)
Everyone agree with this? I'll try to explain it better in the draft.
It's O.K., but I can imagine valid reasons for ignoring known metrics.
With only a few moments thought:
- a metric based on the estimated exposure to security vulnerabilities
- a metric that is difficult to calculate
- a metric requiring access to external arbiters
- a metric temporarily disabled by policy
VM: So we should have the idea of a configuring a list of enabled/in use
metrics, which will be a subset of supported (implemented) metrics?
In that case, would it not be worth calling
that out in the applicability statement also?
Here I am not so sure, but if someone has reasonable wording that is not
directly supported by the specification of alternate metrics in the current
draft, that would be a good thing to consider.
Added as part of this sentence in applicability statement:
"Since the route discovery process results in a route being established in
both directions along the
same path, uni-directional links are not suitable, but AODVv2 will detect
and exclude those links
from route discovery. The route discovered is optimised for the requesting
router, and the return path
may not be the optimal route."
Could we say "typically results"? I believe there are border cases where
the route may still be asymmetric.
VM: done.
“Some applications may require metric
information”
I am not sure what “applications” (L7?)
have to do with this, here.
More precisely, some applications will prefer routes with minimal cost
measured by metrics other than hop count.
reworded:
"Some application data traffic may require an optimal route using a metric
type other than hop count."
Better use "might" instead of "may".
VM: done.
Having it “possible to not include in an
unrealistic scenario” is a bad idea.
I don't understand this statement.
I actually do not see, for example, “convex”
discussed in RFC6551. Are you sure that
that’s the right reference?
Suggest striking that whole sentence, it
doesn’t appear particularly important that
metrics can be concave, convex, … —
what is important is “what sort of metrics
can be supported by this protocol”?
Metrics might be classified as additive, or multiplicative as discussed
in [RFC6551], or concave or convex [
https://en.wikipedia.org/wiki/Convex_metric_space]. I thought it was
important for people to know that there were various kinds of metrics.
Seems that people are afraid of these unusual metric types. Fair enough
though, I should have had a different reference for convex, I dont recall
exactly where I read it but there might be a paper somewhere. Should we
really quote Wikipedia?
I removed that paragraph for now.
It does bother me that we have to delete useful information because of
complaints like this. I'd rather see the text restored.
VM:
I found a paper I'd saved which talks about these classifications a bit. In
fact two articles that could be useful to reference.
One is "A Survey on Routing Metrics" from 2007 which mainly uses the terms
Addition, Multiplication, Maximum and Minimum. Actually has a list of
different metrics and the proposed operator to use.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.304.7863 if that
works for you.
The other is "A Portable Software Implementation of a Hybrid MANET Routing
Protocol" by Sholander, Coccoli, Oakes and Swank. This one talks about
concave, convex, additive and multiplicative. This is at
http://www.scires.com/products/cne/mr-paper2.pdf
I've re-added the text and put the Sholander reference as this uses the
exact terms we've listed.
“If the state is Confirmed, the
acknowledgement request is unnecessary”
This, then, assumes that link bidirectionality
properties are not time-varying? And so,
once you have confirmed a link as bidirectional,
then it will remain so forever?
Of course nothing lasts forever.
We are assuming that if the link turns bidirectional, we'll get some other
indication of this? RERR maybe? not sure if we really explain this though.
It's basically impossible to have an efficient MAC protocol that is
instantaneously responsive to such changes in the wireless link. I reckon
one could prove this as a theorem. Even disregarding the propagation delay.
VM: So what should we be doing, knowing that the link might become
uni-directional, or break completely? Once we have verified that there is
bidirectionality, we are expecting some other trigger I think, to tell us
if that changes? AODVv2 doesnt check again. We aren't saying "this neighbor
just verified bidirectional connectivity, but after some time period X
we'll want to check it still does (if we send a RREP again after time
period X has passed)" or anything are we?
Of what? From where?
What does “may be a problem with
bidirectionality” mean?
"the link may not be bidirectional"?
may or MAY?
"might not be"
VM: done.
A couple of very important things here.
First, I note that RFC6621, afaik, does not
explicitly specify “for each received
multicast message, here’s a hook to
inspect-and-modify-it (such as “update
route cost”) before retransmitting it”.
Rather, it supports “flooding an identical
copy of a message to all destinations inside
the MANET.
Well, we are sending single hop.
Is this bit relevant then? Would some other process come along and say "no
AODVv2, i'm not gonna let you send that multicast message" or would that
protocol normally say "i just received a multicast message, shall i
retransmit it?" because we dont retransmit, we regenerate as a new message.
I'm not sure what to say about this.
VM:
I dont feel I know enough about 6621 to really have an input on this point.
As far as I understand it, its about forwarding a copy of a multicast
message, and about who has the responsibility to do that. I'm guessing the
message itself is not altered, ie 6621 isn't going to update the metric
field, or add any TLVs. Also, we only want our messages to go one-hop. We
only want messages to and from the routers in range, when we're learning
routes. We dont want any process looking at AODVv2 multicast packets and
trying to work out if it should be retransmitting them. We want the packet
to reach AODVv2, and AODVv2 to decide whether to "regenerate" as a new
message.
So the paragraph in question I think does give the wrong idea:
"Implementations are free to choose their own heuristics for reducing
multicast overhead. Some
methods for doing so are described in [](#RFC6621). AODVv2 does not
specify which method
to use to restrict the set of AODVv2 routers that have the responsibility
to regenerate
multicast messages. Note that multicast messages MAY be sent via unicast.
For example, this may
occur for certain link-types (non-broadcast media), for manually configured
router adjacencies,
or in order to improve robustness."
Mentioning 6621 doesnt make sense to me, because
a) we're talking about which routers "have the responsibility to regenerate
multicast messages". But its AODVv2 itself which does this regeneration.
And I think they all have that responsibility, with the exceptions we talk
about in the message sections (where the control message generation limit
is reached, or where the router doesnt wish to forward traffic relating to
this route, etc).
b) 6621 is about sending a copy of the message, so doesnt cover updating
the metric value or adding any extra TLVs.
This only makes sense to me if theres something in 6621 which would be
implemented in the AODVv2 process to decide whether or not to regenerate a
message?
But I actually can’t figure out what you
really mean here.
First, I assume that it it, first of all, is
“conditional on having hit the rate limit”, so
it is not just *any* control message that
SHOULD be discarded.
Second, “discard” to me sounds like “I
receive a message, which I do not process”
— what you mean is “should eliminate
transmission of”, right?
That is a legitimate meaning of the word "discard". But we can use
another word.
Reworded it, but now it doesnt use "discard" - it just says "give these
priorities, because of this..." I didnt actually write what to do about not
sending or discarding a message. I guess I should...
"To avoid congestion, each AODVv2 router's rate of message generation
(CONTROL_TRAFFIC_LIMIT) SHOULD be
limited and administratively configurable. To prioritize transmission of
AODVv2 control messages in
order to respect the CONTROL_TRAFFIC_LIMIT, RREP_Ack messages SHOULD be
given the highest priority....." ...etc...
O.K.
VM: do you think we need to be explicit about avoiding generation, or
discarding? ie something like "if within x % of the limit, suppress sending
of lowest priority, if within y% of limit, suppress sending next
lowest,..." etc etc?
You cite RFC3561, which is an
Experimental RFC, normatively (by way of
SHOULD).
Yet RFC3561 is listed as an informational
reference.
Either this is not a SHOUD, or 3561 should
become a normative reference.
Well, we can import the trivial amount of text if need be.
I made it a normative reference, is that OK?
It is O.K. except unless people complain about a normative reference to an
Experimental protocol.
VM: yeah... :/ so the other option is that this is not a SHOULD...
"SHOULD utilize the binary exponential
backoff used in [](#RFC3561)."
Could we instead say "SHOULD utilize a binary exponential backoff as
follows:" and avoid the reference, since we were asked to explain what this
means anyway (and the sentences directly after, do explain how to do this)?
How about, if the latter case, starting “Unidirectional
links manifest themselves to the
routing protocol in this way ____, and are
handled according to the following ____” ?
I think it would be a mistake to add this text. I don't understand what
it improves.
I couldnt get it to sound right in the context of this section.
This is what I ended up with:
"Links which are not bidirectional cause problems. If a link is unavailable
in the direction toward OrigAddr, an
RREP is not received at the next hop, so cannot be regenerated, and it will
never reach RREQ_Gen. However, since
routers monitor adjacencies ([](#adjacencymonitoring)), the loss of the
RREP will cause the last router which
regenerated the RREP to blacklist the router which did not receive it.
Later, a timeout occurs at RREQ_Gen, and a
new RREQ MAY be regenerated. If the new RREQ arrives via the blacklisted
router, it will be ignored, but will likely
discover a different path toward TargAddr."
Looks good to me.
“the address of the router” — which
address, in case it has many?
I think that you want to be *very* specific
here, and say “the IP address of the
interface over which the received message
was sent”.
Here, and through-and-through the
document, of course.
O.K. That would be fine.
"ip address of the interface" - but the interface could have many IP
addresses...?
I've currently got this:
"RteMsg.IPSourceAddress (an address of the router from which the AdvRte was
received) "
I think its clear enough that its the source IP address from the RteMsg.
For AODVv2, I don't think this matters, and would not affect
interoperability. Nevertheless, reveling in the joy of design, we might
want to devise a deterministic algorithm for source IP address selection if
there are any remaining ambiguities in the document.
That had me do a double-take. Sounds like
“so that it contains multiple unconfirmed
routes” is the objective ;)
I think that you mean “add an entry to the
routing set, but do not remove existing
entries”?
I think it is O.K. as written, but maybe could be clarified further...
now says:
"If all matching routing table entries have State set to Unconfirmed,
AdvRte SHOULD be added to the routing table. This may result in multiple
Unconfirmed routes to the same address. In this case, the best potential
route from the set of Unconfirmed routes SHOULD be used to forward future
RREPs. If the link to the next hop is bidirectional, and the Unconfirmed
route becomes valid, any remaining Unconfirmed routes which would not offer
improvement SHOULD be expunged."
Perhaps we need to sayy the same in the RREP section - that we should
choose the best cost unconfirmed route to OrigAddr as next hop?
O.K.
Is this an RFC2119-term, or not?
SHOULD — what are the consequences, if
this is not done?
The consequences are that some data flows would experience additional cost
that could have been avoided.
Not sure why this needs explaining, I would have thought it was obvious.
Currently we say:
"* If AdvRte is better, it SHOULD be used to update the routing table
because it offers improvement. If it is not used to update the existing
route, the existing non-optimal route will continue to be used.
* If AdvRte is equal in cost and Route is Valid, AdvRte MAY be used to
update the routing table but will offer no improvement.
* If AdvRte is worse and Route is valid, AdvRte MUST NOT be used to
update the routing table because it does not offer any improvement.
* If AdvRte is not better (i.e., it is worse or equal) but Route is
Invalid, AdvRte SHOULD be used
to update the routing table because it can safely repair the
existing Invalid route. "
Yes, it is obvious, and the existing text seems fine to me.
Same seq# and same “cost”, intuitively the
reason why an entry exists already is (for
example) a random event of one copy
having hit a queue slightly less filled at a
given moment?
That is a good possibility.
I didnt quite understand this comment. One copy of what? either way, if
seqnum and cost are the same, theres no improvement to be gained by
updating anything, is there?
I think the comment is about having multiple paths therefore multiple
queues therefore additional effective bandwidth. We could write
specification for that purpose, but I'd rather not do it before Last Call.
VM: Still dont understand. The route entry exists already because we
already installed it. The message we are now processing is a duplicate I
guess, giving us exactly the same route information, but we made the
decision to always process route info first, then decide if it's redundant
and not regenerate the message. I dont really know where queues fit in.
SHOULD NOT — what are the
consequences, if this is done?
A packet might be delivered sooner, but at a higher cost of mis-delivery.
"since the link may be uni-directional and packet losses may occur."
should we always use "bidirectional" or "not bidirectional" or is it ok to
mix uni-directional and bidirectional? Thinking of one of Lotte's comments
before about how she would search through the document for mentions of a
keyword to look at how to implement.
I think that sometimes "not bidirectional" will detract from readability.
Could you describe how that is done? You
talk about “associated timers” and such,
which presumably are recorded
somewhere?
Perhaps cross reference the sections describing more details about these.
Is the question about how it fulfils a route discovery?? thats where the
pointer is pointing, not to the timer bit. I'm not sure how it's unclear.
I'm not either. Maybe it's a request to specify the process of
"association" by which timers are "associated". Anyway I think it's
already clear.
I am wondering if that is a MAY or it is a
MUST; if it allows incoming information to
be assessed for freshness, then not
keeping it around sounds like a potentially
bad thing?
It shouldn't be a MUST because we ought to be able to expunge it to make
more room if needed. Perhaps "SHOULD".
I think I've said MUST, and separated the memory contraint bit to below.
Hopefully thats not seen as a conflict.
Not clear about this; maybe I need to see the new text...
VM: OK here it is:
Active
: <vspace/>If Route.State is Active and the route is not timed (i.e., if
Route.ExpirationTime is MAX_TIME), Route.State MUST become Idle if Route is
not used to forward IP packets within ACTIVE_INTERVAL. Route.State for a
timed route (i.e., Route.ExpirationTime is not equal to MAX_TIME) remains
Active until its expiration time, after which it MUST become Invalid.
Idle
: <vspace/>If Route.State is Idle, and the route is used to forward an IP
packet, Route.State MUST become Active. If the route is not used to forward
an IP packet within MAX_IDLETIME, Route.State MUST become Invalid.
Invalid
: <vspace/>If Route.State is Invalid, the route MUST be maintained until
MAX_SEQNUM_LIFETIME after Route.LastSeqNumUpdate, after which it MUST be
expunged. Route.SeqNum is used to classify future information about
Route.Address as stale or fresh.
Unconfirmed
: <vspace/>If Route.State is Unconfirmed, the route MUST become Idle when
an adjacency with Route.NextHop is confirmed, or MUST be expunged if the
neighbor is blacklisted, or at MAX_SEQNUM_LIFETIME after
Route.LastSeqNumUpdate.
and lower:
Memory constrained devices MAY choose to expunge routes from the AODVv2
route table before Route.ExpirationTime, but
MUST adhere to the following rules:
* An Active route MUST NOT be expunged, as this will result in generation
of a Route Error message followed by
a necessary Route Request to re-establish the route.
* An Idle route SHOULD NOT be expunged, as the route is still valid for
forwarding IP traffic, and if deleted,
this could result in dropped IP packets and a Route Request could be
generated to re-establish the route.
* Any Invalid route MAY be expunged; least recently used Invalid routes
SHOULD be expunged first, since
these are less likely to be reused.
* An Unconfirmed route MUST NOT be expunged if it was installed within
the last RREQ_WAIT_TIME, because it
may correspond to a route discovery in progress. A Route Reply message
might be received which needs to
use the Route.NextHop information. Otherwise, it MAY be expunged.
2) Otherwise, if the route is not actively
used, this accomplishes simply to go from
MAX_SEQNUM_LIFETIME+MAX_IDLETIME
to MAX_SEQNUM_LIFETIME — correct?
Actually, MAX_SEQNUM_LIFETIME is measured from the last time the SeqNum is
updated, not the last use of the route.
I didnt really understand what Thomas was saying here.
Needs clarification....
Given that RERR is pronounced “Arr Eie Arr
Arr”, isn’t that “an RERR”?
O.K.
feels wrong, really depends how you read it, I expend to "route error" in
my head, but did this anyway, throughout for RREQ, RREP, RREP_Ack and RERR.
This is a recurring problem. There's a style guide rule about it
somewhere...
Also, that strikes me as a policy decision,
which really is not for the routing protocol to
make, but for the network operator — it is
not hard to thin up situations where this
proposed policy would be a constraint.
Any technical reasons why this policy
decision is enforced?
I do not think this is a policy decision. But if there is such a
situation it should be discussed.
well if we got a packet forwarded to us and we didnt have a route, should
we request one? I dont think so. this would open us up to an attack if
someone sent us tons of traffic to forward and we didnt have a route, so we
sent tons of RREQ messages. We should only request routes for our clients.
Doesnt make sense to learn half a route does it? Also we shouldnt be given
packets to forward if we didnt advertise a route, in any case. Something is
wrong if we did.
I basically agree with you on this, except that there is a concept of local
repair that we should get back to at some point in the future.
VM: local repair would be triggered by losing an active route, not by an IP
packet arriving that we can't forward.
Cheers for your comments Charlie. I now appreciate the time that went into
them! Oh my goodness that took forever!
Yes, it's very time consuming. Thank you so much for blasting through it
as well!
Regards,
Charlie P.
Regards,
Vicky.
Other related posts:
