Hello folks,
I agree with Vicky's analysis, and also with the observation that it's
not important for interoperability but instead for performance improvement.
Regards,
Charlie P.
On 3/20/2016 5:04 AM, Victoria Mercieca wrote:
Hi Lotte,
I guess when the messages become stale, they could be deleted from the queue...as there would be no point sending them. We would have to note at what time they were put in the queue, and use the corresponding timeouts -
* for a queued RREQ, there's no point sending it if the time for an
expected RREP has been reached, because AODVv2 itself would create
a new RREQ and add it to the queue.
* for a queued RREP, there's no point sending it if the time for an
expected RREP has been reached, because receivers of this delayed
RREP would ignore it. (Although, since RREP_Gen doesnt know when
the RREQ was generated, it might still send this with a delay that
means RREQ_Gen would ignore it)
* for a queued RREP_Ack there's no point sending if the time for an
expected RREP_Ack has been reached, as RREP_Gen would ignore it
(again, we dont know exactly when that timer expires on RREP_Gen
so we might allow this RREP_Ack to be sent with enough delay that
it would get ignored)
* for a queued RERR, the only time it would be pointless to send is
if the reported route was re-established before the RERR was sent.
In that case the new route should have a greater seqnum and this
route from the RERR would be ignored by a receiver. For further
optimisation, its possible that when a route is installed you
could go through any queued RERRs to see if they still need sending.
Is that all really implementation detail though, would it cause interoperability issues? Is it enough to say "you should limit the rate of message generation, aiming for a maximum of CONTROL_TRAFFIC_LIMIT, and (to help you out) here are the priorities...whether you want to discard messages or queue them in priority order, whether you only take action when the limit is reached, or when its close to being reached, that's up to you."..? I suppose if some routers decided to discard messages rather than queue them, it would affect protocol operation, but so would the huge amount of messages being flooded across the network which caused it to reach the limit anyway.
When the control message limit is reached, we want to give the network a chance to recover, so if some messages were dropped and only the important ones (e.g. RREPs and RREP_Acks) sent, then we are relying on RREQ retries at a later point to deal with the fact we discarded some RREQs in that period. I think thats why RREQ ended up lower down in the priorities, because we know there are retries.
Kind regards,
Vicky.
On Fri, Mar 18, 2016 at 7:11 PM, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,
Am 10.03.2016 um 15:48 schrieb John Dowdell
<john.dowdell486@xxxxxxxxx <mailto:john.dowdell486@xxxxxxxxx>>:
<snip>
+1
(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)
This is a good point. In order to be clear, we need to say
that there is a queue of messages and then use the priority
mechanism to discard low-priority queued messages. Or,
perhaps better, we can say that messages are not sent more
frequently than one message per (1 / CONTROL_TRAFFIC_LIMIT)th
of a second, and then the queue is reordered based on priority.
Any objections? If not I'll craft some text that says that.
Thanks. I think it represents a nice improvement.
Quick followup to that one:
I changed the text to:
To avoid congestion, each AODVv2 router's rate of message
generation SHOULD be limited (CONTROL_TRAFFIC_LIMIT) and
administratively
configurable. Messages SHOULD NOT be sent more frequently than one
message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second. If this
threshold is reached, messages MUST be sent based on their priority:
* Highest priority SHOULD be given to RREP_Ack messages. This
allows links between routers to be confirmed as bidirectional and
avoids undesired blacklisting of next hop routers.
* Second priority SHOULD be given to RERR messages for
undeliverable IP packets. This avoids repeated forwarding of
packets over broken routes that are still in use by other routers.
* Third priority SHOULD be given to RREP messages in order that
RREQs do not time out.
* Fourth priority should be given to RREQ messages.
* Fifth priority should be given to RERR messages for newly
invalidated routes.
* 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.
, but I don’t think I got the beginning quite right. What I’m
stumbling over is the „reordering based on priority“ thing:
if we’re doing something like:
while CONTROL_TRAFFIC_LIMIT reached:
reorder(queue)
send(queue.getHighestPrio())
we might *only* send RREP_Acks and RREPs, while other message
types are never sent. This might als mean that (then stale)
RREP_Acks are sent, while fresh RREQs are discarded?
Additionally, note that I’ve reworded the bullet points to improve
clarity and conciseness. I hope I preserved their meaning! (any
comments very welcome)
Also, while I understand Justin’s point that it is confusing to
talk about message sending before message generation, but it
follows the general structure of the document and I don’t really
see where else this paragraph belongs.
Cheers,
Lotte
