Am 13.04.2016 um 17:02 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
Hello Lotte,
One item of follow-up below...
On 4/13/2016 6:39 AM, Lotte Steenbrink wrote:
(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)
As I understand it, we decided on queueing things, limiting transmission to
{1/CONTROL_TRAFFIC_LIMIT}, and discarding messages when the queue was full.
Is there more to be done?
The problem is with the word „approaching“, not the definition of „limit“.
This is being discussed in the thread „[aodvv2-discuss] Re: Justin's
review“. Vicky and Stan made some really good points, but I don’t think
we’ve reached a conclusion… I’ve bumped that thread now so we can hopefully
resolve the issue soon.
Given the new method of simply discarding messages when the queue is full,
there is no longer any "approaching". Queue full ==> discard a message if
another one arrives. The message to discard is defined by the AODVv2
priority scheme. Nothing to approach.
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 do not see what issues could be caused. Under some metrics, we
absolutely DO want to pick the smallest metric even if just for long enough
to send a few bytes. This is application dependent, not in the bailiwick
of AODVv2.
Maybe the minimum time should be „long enough to send a few bytes“ then? To
avoid situations where the route has expired already when the message
arrives at the next hop? (But then again, how much time would that be? Seems
highly dependent on computation power, transport medium etc)
It really seems to me that we don't want to define a minimum. It is
reasonable to assume that people defining these parameters are not idiots.
Who would define a route to be valid for a microsecond?
(THere needs to be some sort of table which is updated with timer
associated with this AckReq JWD TODO)
What is the current status of this? Has anything been written?
Nope. I think we could use our new RERR Table for this– if we add a field
RerrMsg.AckReqTimer (which is empty if no ackreq was included), which is set
to CurrentTime + RREP_Ack_SENT_TIMEOUT, we know when a RREP_Ack is too late
(or was never received). I everybody on board with this? If so, I’ll add
some text.
I don't understand why AckReq is associated with RERR…?
Regards,
Charlie P.
