Hi all,
Am 03.04.2016 um 17:08 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:Everything Vicky says sounds really reasonable to me. However, I’m not quite
Hi all,
My opinion is that when the queue is full of high priority messages we'd have
to start dropping new messages until there was less congestion. I'm not sure
about declaring the link to be down and restarting. This is congestion in
terms of AODVv2 control packets, not necessarily real congestion on the link.
We'd still probably be forwarding data on any routes we advertised. I would
have thought the limit on AODVv2 messages would be chosen so that there was
still plenty of capacity to send data traffic.
Dropping packets would affect route discoveries or error reports in progress,
but I think it should catch up since the potential damage caused is minimised
by the priorities we decided (see my email earlier today). One unfortunate
thing is that if a router is unable to send acks, that router might get
blacklisted by others, which there isn't much we can do about. That router
would get excluded from route discovery for a while. Maybe longer than it
would take to recover from the queuing of control packets. ..
Kind regards,
Vicky.
On 3 Apr 2016 09:52, "Stan Ratliff" <ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx>> wrote:
Lotte,
On Sun, Apr 3, 2016 at 8:41 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi Stan, hi all,
Am 01.04.2016 um 22:49 schrieb Stan Ratliff <ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx>>:
On Fri, Apr 1, 2016 at 4:36 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,
Am 22.03.2016 um 20:55 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxxI’ve merged it like so:
<mailto:vmercieca0@xxxxxxxxx>>:
Sounds like a good way to incorporate it :-)
o 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.
o 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.
o Third priority SHOULD be given to RREP messages in order that
RREQs do not time out.
o Fourth priority should be given to RREQ messages.
"should" or "SHOULD"?
o Fifth priority should be given to RERR messages for newly
invalidated routes.
same question - "should" or "SHOULD“?
whoops, sorry about that, corrected it now.
o 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.
*However*, that doesn’t solve the „approaching the limit“ wording Justin
complained about all over the draft (see (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)
etc)
We now have a priority system, but how is „approaching the limit“ defined?
And do we really need it? If we take it out, we’d be left with text that
says „if you have more messages than you can send, chuck these out first
until things are back to a manageable state“, which could be enough? There’s
always still room for more fancy approaches if the bare-bones one isn’t
enough.
JMO, but I think the key here is whether "approaching the limit" is an
interoperability issue - if I code "approaching the limit" one way, and you
code it another, do our AODVv2 routers still interoperate? Seamlessly? Or do
"odd things" start to happen?
Another approach is to dump the "approaching the limit" verbiage, and
replace it with something that says "if you have more messages than you can
send, queue them up to <blah> messages, prioritizing them as above. When
<blah> is exceeded, then <what now?>." In other words, there is no
"approaching the limit", just "here's what happens when you *hit* the limit,
and by the way, the limit is N." Oh - and if the limit can be configured, do
*all* AODVv2 routers need the same definition? Or, can some operate with a
different limit than others?
Yeah, I like that better. Do you have any suggestions as to what the <what
now?> part should be? Everything I’m coming up with right now seems overly
complicated and a pain to implement (and bad for constrained devices) :(
Well, as I understand, that would put us in a position where we've (a)
dropped traffic, and {b} queued some number of high-priority traffic, which
isn't get sent out on a link... if queue depth is hit, I don't see much of an
alternative to declaring the link as down, cleaning up routes via the next
hop, and waiting for some more RREQs to come waffling by.
Other opinions?
Regards,
Stan
Regards,
Lotte
Regards,
Stan
Best regards,
Lotte
Vicky
On 22 Mar 2016 17:46, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi Vicky,
Am 20.03.2016 um 13:04 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>>:
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.
I like that list. If it’s okay I’d merge it with the priority list though,
so that it says „message type x should be of priority y, but there’s no
point sending it if it’s older than z“?
Is that all really implementation detail though,
It is, but I think it’s helpful advice, isn’t it?
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.
mhm… true...
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.
yup. (and because there’s no point in establishing new routes in an already
overloaded network/ through an overwhelmed router?)
Regards,
Lotte
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
