Hi Vicky, hi everyone,
Am 15.04.2016 um 21:44 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
I finally found some time to go through everything marked with a JWD TODO
from Lotte's email on 4th April. I know there have already been some
comments, so I apologise if I am re-iterating things that have already been
updated!
I've listed all the TODOs I found (although there's a couple I haven't
commented on).
Here goes.....
Valid route
A route that can be used for forwarding. (the deleted part should be
defined in Route Error Generation section JWD TODO: why there? If you hink
it's a bit too verbose at that place, Local Route Set {#rte} has an in-depth
definition what a valid route is and isn't )
I agree, the extra explanation doesn't need to go here. The deleted bit was:
which has been confirmed as having a bidirectional link to the next hop, and
has not timed out or been made invalid by a route error.
"Local Route Set" is the right place for this information, and the
explanation already there is fine. I vote to remove this bit from the
Terminology, and not insert anywhere else. If the reader wants extra info,
maybe include a reference to "Local Route Set" section with the terminology
entries for Valid route and Invalid route, e.g. "Further information can be
found in Section __“.
---
Unreachable Address
An address reported in a Route Error message. (the deleted part should
be defined in Route Error Generation section JWD TODO)
The deleted part was:
either the address on a LocalRoute which became Invalid, or the destination
address of an IP packet that could not be forwarded because a valid
LocalRoute to the destination is not known, and will not be requested.
I think this got added based on some previous comments, but I agree it is
unnecessary in Terminology. I think the RERR Generation section is already
pretty clear on what to use for "unreachable address" and all the
circumstances involved. I vote to remove the bit Justin suggested, and not
insert it anywhere else.
---
3. Applicability Statement
(Wireless properties of the network is not mentioned at all and this is quite
important as I’m pretty sure AODVv2 for used in a wired network would be a
bad idea JWD TODO)
How about changing the first sentence from:
The AODVv2 routing protocol is a reactive routing protocol.
to:
The AODVv2 routing protocol is a reactive routing protocol intended for use
in mobile ad hoc wireless networks.
---
AODVv2 is designed for stub or disconnected mobile ad hoc networks, i.e.,
non-transit networks or those not connected to the internet. AODVv2 can,
however, be configured to perform gateway functions when attached to external
networks, as discussed in Section 9. (some mention of limitations of the
provided approach is required. No default gateways, drawbacks/overhead of
using AODVv2 network to connect to the Internet using provided approach JWD
TODO)
---
AODVv2 provides for message integrity and security against replay attacks by
using integrity check values, timestamps and sequence numbers, as described
in Section 13. If security associations can be established, encryption can
be used for AODVv2 messages to ensure that only trusted routers participate
in routing operations.
(There is an issue with trust being limited to single hops and no way to
verify information more than one hop away JWD TODO)
Ongoing discussion.
---
AODVv2 supports routers with multiple interfaces and multiple IP addresses
per interface. (this should be disallowed as it can form non valid routes
with uni-directional links JWD TODO)
I think that it can form non-valid routes with unidirectional links, *if*
multiple interfaces use the same IP address (and I think we included an
interface identifier and some rules about which interface a message should be
sent on, to get around this issue). I think our statement is now valid.
---
4.2. Router Client Table
What’s the difference between a table and a list why are we using one over
the other?JWD TODO)
Are we renaming as much as possible to be Sets? This could easily be Router
Client Set. Also we have InterfaceSet, we could have Neighbor Set, we have
Local Route Set, can change to Multicast Route Message Set and RERR Set.
---
5. Metrics: (consider adding a maximum single hop value JWD TODO)
What was the consensus on this, before the discussion erupted into a number
of metric issues? It would exclude poor links from route discovery,
potentially with route discovery failing even though a route did exist. I
vote not to have a maximum single hop value, i.e. no maximum link cost.
---
6.3. Neighbor Table Update
If an RREP_Ack is not received within the expected time (what is the expected
time? list the entry we are checking assuming in the Multicast Route Message
Tablet? outline it. JWD TODO: The MRMT is not the right place, but I'm nt
sure if we're descrivng timers for this anywhere? shoud we?)
Version 14 now says: "within RREP_Ack_SENT_TIMEOUT" but doesn't refer to how
we know this time is up. The RREP we are expecting to be acked would be in
the MRMT, wouldnt it, since it would have been multicast?
So we would be testing "If an RREP_Ack is not received in response to a
multicast RREP, within RREP_Ack_SENT_TIMEOUT of the time the RREP was sent,"
and if we need to be more explicit "within RREP_Ack_SENT_TIMEOUT of the
Timestamp of the Multicast Route Message Entry corresponding to the RREP,"...
but that is hideously wordy.
Also I guess we need to state that there should be a timer running, so that
when it expires we can set the neighbor as blacklisted. Do timers need their
own list? That's too implementation specific, surely?
---
When a link to a neighbor is determined to be broken, the NeighborTable entry
SHOULD be removed.(What does this mean? How would one determine a link to a
neighbor to be broken….suggest removing it JWD TODO)
I guess this is an external signal. Do we remove this statement, or expand it
further? e.g. "If a link to a neighbor is determined to be broken according
to a signal from an external process..." I think its useful to indicate when
an entry would be deleted.
Otherwise, do we keep the entry forever, in case the link ever becomes
bidirectional?
---
Lowest priority SHOULD be given to RERR messages generated in response to
RREP messages which cannot be regenerated. In this case the route request
will be retried at a later point.
(It’s not clear to me how this priority works. Do the messages just get
dropped when tsome threshold for max number of messages is reached? Is there
some queuing method because if their isn’t I don’t see how priority would
work at all, as the choices are drop or send. This whole section seems out
of place as we have’t talked about generating messages. I’d suggest moving or
removing JWD DONE partially ([master e9927a8] redo priority definition))
Did we decide that when we hit a certain limit, we then remove queued
messages of lower priorities, so that we can instead queue messages of higher
priorities? And if the queue is full of higher priority messages, drop (or
avoid creation of) any new messages?
e.g. some suggested text ready for comments/criticisms.
"To implement the congestion control, a queue length is set. If the queue is
full, in order to queue a new message, a message of lower priority must be
removed from the queue. If this is not possible, the new message MUST be
discarded. The queue should be sorted in order of message priority."
Or is there a less "this is how you MUST implement it" sort of statement we
could use instead like "its up to an implentor to decide if and how to do
this?“
---
RREQ_Gen awaits reception of a Route Reply message (RREP) containing a route
toward TargAddr. (is there some table that lists routes that are being waited
on? JWD TODO)
Is it enough that the RREQ message will still be in the MRMT?
Is it better to slightly re-write, maybe like this: "RREQ_Gen awaits
reception of a Route Reply message (RREP) corresponding to the RREQ. This
RREP contains a route toward TargAddr, which is installed at RREQ_Gen,
completing the route discovery procedure."
Similar to above...do we need to state explicitly that there should be a
timer running, so that when it expires we can retry the route discovery? Do
timers need their own list? That's too implementation specific, surely?
---
7.1.3. RREQ Regeneration
There might be a problem with very short validity times on very low metric
routes in that they will be selected regardless of the time. Not a problem
but something that could cause issues. Perhaps some minimum time should be
mandated. JWD TODO)
I'm happy either way. I think Charlie mentioned it in a recent email too. If
we mandate a minimum time, what should it be? This then needs to be mentioned
throughout the draft in multiple generation/regeneration sections, stating
that the message should not be regenerated if the validity time is less than
the minimum.
---
7.1.1. RREQ Generation
and all generation/regeneration sections
If the limit for the rate of AODVv2 control message generation has
been reached, no message SHOULD be generated. If approaching the
limit, the message should be sent if the priorities in Section 6.5
allow it.
(There is no defined behavior here. Approaching the limit? Section 6.5
outlines which messages are more important but now how to decide to allow
them to be transmitted or not. JWD TODO)
Fixed as above?
---
7.2.3. RREP Regeneration
The router MAY choose not to regenerate the RREP, in the same way it MAY
choose not to regenerate an RREQ (see Section 7.1.3), though this could
decrease connectivity in the network or result in non-optimal paths.
(This seems like a bad idea to do on the reverse path. It would be a good
way to attack a network Forward RREQ and drop all RREP. JWD DONE?)
If there is a router which doesnt forward a RREP, but does send back an Ack
toward TargAddr, then the next hop router would not blacklist this router.
And the RREP doesnt reach RREQ_Gen, so a new RREQ will go out and the same
will happen again. RREQ_Gen will eventually give up.
If we state that a router which doesnt forward a message must not send
acknowledgements, and that if you forward a RREQ you MUST forward a
corresponding RREP, that fixes it, right? Except for if you have reached your
congestion limit in between these two events? But then something crazy is
going on anyway. Hopefully on the retry the congestion has reduced? Or, on
the retry the RREQ probably wouldnt be forwarded by this router, therefore
would discover another path.
I think I agree with Justin. If we receive a RREP it pretty much means we
sent the RREQ, so we should do our best to regenerate the RREP. Let's not
allow "The router MAY choose not to regenerate the RREP"….
---
7.2.3. RREP Regeneration
4. If the link to the next hop router toward OrigAddr is not known
to be bidirectional, include the AckReq with the address of the
intended next hop router
(THere needs to be some sort of table which is updated with timer associated
with this AckReq JWD TODO)
In this case the RREP was multicast, so should be in the MRMT, along with a
timestamp.
Same as above...do we need to state explicitly that there should be a timer
running, so that when it expires we can set the neighbor as blacklisted? Do
timers need their own list? That's too implementation specific, surely?
---
7.3.2. RREP_Ack Reception
Upon receiving an RREP_Ack, an AODVv2 router performs the following steps:
1. Update the Neighbor Table according to Section 6.3
* If the sender has Neighbor.State set to Blacklisted after the
update, ignore this RREQ for further processing.
(Shouldn’t this check come before updating? The only way the Neighbor.State
is set to Blacklisted is that its already Blacklisted and there is no need to
update the Neighbor Table. JWD TODO)
I think 6.3 says whether to update the state from blacklisted (if the reset
time has been reached). Because otherwise we didnt specifically mandate a
timer which updates that entry to stop the neighbour being blacklisted. The
fact that the neighbor *remains* blacklisted after checking the reset time,
that is what's important in step 1.
---
8.1.2. Message TLV Block
and all other message TLV block sections
An RREQ contains no Message TLVs.
(this ins’t mandatory, right? Just AODVv2 doesn’t define any message TLVs for
use with RREQ JWD TODO?)
Did we suggest updating to something like "This draft specifies/requires no
Message TLVs for this message type“?
---
8.3.3. Address Block
An RREP_Ack contains no Address Block.
(Mandatory or just not defined? Guessing mandatory on this one. JWD TODO)
Any address block would be ignored by the current draft. Again something like
"This draft requires no Address Block for this message type"?
Same for the Address Block TLV Block for the RREP_Ack.
---
When a LocalRoute is expunged, any precursor list associated with it MUST
also be expunged.
(I feel like this is underspecified and would be better served in a separate
document like Intermediate RREP. Is there anything wrong with leaving the
behavior required a MAY and describing that behavior in another draft? JWD
TODO)
Are we ok to remove extensions to future separate drafts?
To enable precursor lists, maybe we need something in RERR
generation/regeneration sections to state that a RERR "SHOULD" be multicast,
rather than MUST (for the RERR without PktSource). This allows other ways of
sending the RERR (such as unicast to specific precursors), according to RFC
2119's meaning of SHOULD, I think?
To enable expanding rings multicast we either need to reintroduce
msg-hop-limit and msg-hop-count, or define a new hop_count TLV.
Then I think where we have statements like "MAY decide not to regenerate the
RREQ", this covers the use of expanding rings multicast as an extension.
For iRREP, we already have an extension draft. I'm hazy on the details, is
there anything we need to state in our draft to allow this extension?
For message aggregation delay, that's a 5444 option. That's probably
something we would configure in whatever multiplexer we might use. Not sure
its worth writing an extension for AODVv2 for that.
---
(is MAX_SEQNUM_LIFETIME the only parameter which MUST be configured the same
across the network? JWD TODO: yes?)
Other timers are active interval, max idletime, max blacklist time, rtemsg
entry time, rreq wait time, rrep ack sent timeout and rreq holddown time.
I'd say ACTIVE_INTERVAL and MAX_IDLETIME should be configured the same across
the network too...just because if they affect one hop in an established
route, they affect all hops.
Charlie wrote the bit about what happens if constants are different on
different routers, I think this got pasted from there (11.2). Should we do
the same for timers? Seems like common sense really:
- Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will
invalidate routes more quickly and free resources used to maintain them. This
can affect bursty traffic flows which have quiet periods longer than
ACTIVE_INTERVAL + MAX_IDLETIME. A route which has timed out due to perceived
inactivity is not reported. When the bursty traffic resumes, it would cause a
RERR to be generated, and the traffic itself would be dropped. This route
would be removed from all upstream routers, even if those upstream routers
had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route discovery
would be required to re-establish the route, causing extra routing protocol
traffic and disturbance to the bursty traffic.
- Routers with lower values for MAX_BLACKLIST_TIME would allow neighboring
routers to participate in route discovery sooner than routers with higher
values. This could result in failed route discoveries if un-blacklisted links
are still uni-directional. Since RREQs are retried, this would not affect
success of route discovery unless this value was so small as to un-blacklist
the router before the RREQ is retried. This value need not be consistent
across the network since it is used for maintaining a 1-hop blacklist.
However it MUST be greater than RREQ_WAIT_TIME.
[and probably a good idea to be at least a multiple of RREQ_WAIT_TIME?]
- Routers with lower values for RERR_TIMEOUT may create more RERR messages
than routers with higher values. This value should be large enough that a
RERR will reach all routers using the route reported within it before the
timer expires, so that no further data traffic will arrive, and no duplicated
RERR messages will be generated.
- Routers with lower values for RteMsg_ENTRY_TIME may not consider received
redundant multicast route messages as redundant, and may regenerate these
messages unnecessarily.
- Routers with lower values for RREQ_WAIT_TIME may send more frequent RREQ
messages and wrongly determine that a route does not exist, if the delay in
receiving an RREP is greater than this interval.
- Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly determine
links to neighbors to be unidirectional if an RREP_Ack is delayed longer than
this timeout.
- Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed route
discoveries sooner than routers with higher values. This may be an advantage
if the network topology is frequently changing, or may unnecessarily cause
more routing protocol traffic.
---
o RREP_RETRIES: Routers with lower values are more likely to
blacklist neighbors when there is a
Um... where did the rest of this sentence go? Must be my fault! Draft 11 says
this:
RREP_RETRIES: Nodes with lower values are more likely to blacklist
neighbors when there is a temporary fluctuation in link quality.
---
Now for the RFC5444 usage draft…!
Kind regards,
Vicky.
