Hello folks,
Some follow-up below:
On 4/15/2016 12:44 PM, Victoria Mercieca wrote:
/
/
---
/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.
/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.
