[aodvv2-discuss] Re: [manet] AODVv2 comments

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 20 Aug 2015 10:47:01 -0700


Hello Vicky,

Two minor revisions to your suggested text below:

On 8/20/2015 1:27 AM, Victoria Mercieca wrote:





Section 6.4 page 23 para 4 using [RFC 3561] in this way as a
SHOULD makes it a normative reference, which is a downref, and
it’s buried somewhere in that reference without an indication.
Should be pulled out and included in this document.

We will reword to avoid the apparent downref. Do you have a
suggestion for this?

It now says this:
"To reduce congestion in a network, repeated
attempts at route discovery for a particular target address SHOULD
utilize the binary exponential backoff used in [RFC3561]. If the
requested route is not learned within RREQ_WAIT_TIME of sending the
first RREQ, RREQ_Gen sends a new RREQ. The wait time for the RREP
corresponding to the second RREQ is 2 * RREQ_WAIT_TIME. If the
requested route is not learned within this time period, another RREQ
MAY be sent, up to a total of DISCOVERY_ATTEMPTS_MAX. For each
additional attempt, the waiting time for the RREP is multiplied by 2,
so that the time conforms to a binary exponential backoff."

Perhaps slightly better to move the citation to the end of the paragraph, maintaining the same information:

"To reduce congestion in a network, repeated
attempts at route discovery for a particular target address SHOULD
utilize the binary exponential backoff as follows. If the
requested route is not learned within RREQ_WAIT_TIME of sending the
first RREQ, RREQ_Gen sends a new RREQ. The wait time for the RREP
corresponding to the second RREQ is 2 * RREQ_WAIT_TIME. If the
requested route is not learned within this time period, another RREQ
MAY be sent, up to a total of DISCOVERY_ATTEMPTS_MAX. For each
additional attempt, the waiting time for the RREP is multiplied
by 2,
so that the time conforms to a binary exponential backoff. This
is the
same backoff as used in [RFC3561]"

actually it says:
"remains Active until its expiration time, after which it MUST become Invalid. "
This is true. Then, when it's invalid, it MAY be expunged...the memory constraint bit is in a lower paragraph now, not to confuse things.

This is O.K.

Under Invalid:
"If Route.State is Invalid, the route MUST be maintained until MAX_SEQNUM_LIFETIME after Route.LastSeqNumUpdate, after which it MUST be expunged. Route.SeqNum is used to classify future information about Route.Address as stale or fresh."
Keeping the separation, hopefully making it very clear.

This does not allow Invalid routes to be expunged. I think the first MUST has to be changed to a SHOULD.

I am sending the email to the list with this second part omitted. We can send it later if you agree with my suggestion to use SHOULD. I don't think Chris will mind if we add more follow-up a little later.


Regards,
Charlie P.

Other related posts: