[aodvv2-discuss] Re: FW: Combined follow-up for previous proposals in December to close issues

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Tue, 27 Jan 2015 13:48:18 -0800

Hello Vicky,

I agree with your observations -- and wonder how we could have
missed the first one!

I guess we could have the default to be that RERR invalidates all
routes to the destination regardless of metric type.  But we could
keep the ability to invalidate specific metric types, which would be
valuable for loss of QoS, for instance.

Regards,
Charlie P.


On 1/27/2015 1:31 AM, Victoria Mercieca wrote:


In quick reply to the proposals in this thread:

On issue 46, the text suggested says "If an application tries to send a packet, and the route is available, the packet has to wait until the route is available." Should be "If an application tries to send a packet, and the route is not available,the packet has to wait until the route is available."

On issue 10, I didn't really understand the comment that "Metrics for anything other than hop-count would essentially trigger unicast RERR messages anyway and there would be little gain from the aggregation." My original thought when I read the draft was that if the broken routes have multiple MetricTypes, there would be a RERR per MetricType. But - if the route to A with hop-count Metricis down, is the route to A with latency Metric going to still be available? If a link is broken, all routes using it are down, regardless of MetricType. It would be unnecessary to report once for each MetricType. This makes me think MetricType doesn't need to be included in the RERR at all. When processing a received RERR, all routes matching the address and prefix would be marked as broken, for all MetricTypes. The current information on processing a RERR (Section 9.4) doesn't mention MetricType anyway. Related to this - If no route exists to forward a packet, I think the RERR that is sent does not contain a MetricType.

On issue 23/24, I've written up the steps for creating/receiving/regenerating each message (except RREP_ACK at this point), steps for evaluating incoming routing information, and checking for redundant RREQs. I've tried to make it all very clear, organising everything mentioned in the draft currently, but it still needs checking and a couple of questions answered before it's complete.

Also in the new RREP_ACK text Lotte has written in Section 9.5, there's a few mentions to RREQ which I thought might have meant RREP, unless the AckReq can be used in other messages besides RREP? I think the RREP_ACK message generation and handling bits should be in Section 8 after the RREP section, but the "AckReq/RREP_ACK Cycle" bits should be in 6.2, which is about ensuring bidirectional connectivity. Section 8 might need renaming though. Appendix B4 also needs updating.

On issue 32, I have a concern that if multicast packets are suppressed, this may result in a non-optimal route, or in the worst case, no route, being found.


I mentioned the document I have written with step-by-step instructions/pseudo-code for issues 23/24. I've also got a document with comments about the draft that was released on 30th December. Both documents are currently in Word format with some highlighting. Let me know how best to discuss the questions I have and send these to you.

Regards,
Vicky.



On Tue, Jan 27, 2015 at 8:00 AM, Victoria Mercieca <victoria.mercieca@xxxxxxxxxxxxx <mailto:victoria.mercieca@xxxxxxxxxxxxx>> wrote:



    -----Original Message-----

    From: "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx
    <mailto:charles.perkins@xxxxxxxxxxxxx>>
    Sent: 26 January 2015 22:08
    To: aodvv2-discuss@xxxxxxxxxxxxx <mailto:aodvv2-discuss@xxxxxxxxxxxxx>
    Subject: [aodvv2-discuss] Combined follow-up for previous
    proposals in December to close issues


    Hello folks,

    Please let me know if there are any objections to these proposals,
    some of which have been revised after the meeting on Friday.

    On 1/21/2015 1:37 PM, Charlie Perkins wrote:
    >
    >
    > ============================================================
    >
    > [manet] #2: Terminology for reactive protocol document
    >
    > Close this issue with a request for more specific comments
    > about particular terms or definitions.

    Unchanged.

    >
    > ============================================================
    >
    > [manet] #10: Reporting multiple broken routes whose metric types are
    > different
    >
    >
    > Reject the proposal suggested in the issue text, and
    > close the issue including the following discussion:
    >
    > "Metrics for anything other than hop-count would essentially
    > trigger unicast RERR messages anyway and there would be little
    > gain from the aggregation."

    Unchanged.

    > ============================================================
    >
    > [manet] #16: The Reactive Protocol Duplicate Suppression Table
    >
    > Suggest the following resolution on the mailing list in order
    > to solicit comments:
    >
    > 'Put all AODVv2 messages into the duplicate suppression table.
    >  The change is easy, but involves replacing "RREQ" with
    >  "AODVv2 message" in a number of places.'

    Unchanged.

    >
    > ============================================================
    >
    > [manet] #24 (aodvv2): Ordering of processing instructions
    >
    > Close the issue with a request for people to append relevant
    > comments to issue #23 instead of this issue.

    Unchanged.

    >
    > ============================================================
    >
    > [manet] #27 (aodvv2): Processing AckReq
    >
    > Recent drafts have included the requested clarification.
    > >    To avoid repeated failure of Route Discovery, an AODVv2 router
    > >    (HandlingRtr) handling a RREP message MUST attempt to verify
    > >    connectivity towards RREQ_Gen.  This MAY be done by
    including the
    > >    Acknowledgement Request (AckReq) data element in the RREP.
    In reply
    > >    to an AckReq, an RREP_ACK message message MUST be sent.
    >
    > With this clarification, we can close this issue.

    This is unchanged, but see below...

    >
    >
    >
    > ============================================================
    >
    > [manet] #30 (aodvv2): Use of word "node"
    >
    > Close the issue with the following text for the resolution:
    >
    >
    > 'The uses of "node" in the document have been checked, and many
    >  were changed to "addr" instead as noted in previous emails.
    >  More specific terminology has been used where appropriate.'

    This is unchanged.


    >
    >
    > ============================================================
    >
    > [manet] #31 (aodvv2): Suitability for implementation on commodity OS
    >
    > Close this issue and redirect comments to issue #46.

    This is unchanged.



    > ============================================================
    >
    > [manet] #32 (aodvv2): Multicast transmission
    >
    >
    > Stan proposes:
    > "Implementations are free to choose their own heuristics for
    >  reducing multicast overhead."
    >
    > Lotte makes a refined proposal:
    > "Implementations are free to choose their own heuristics, for
    >  reducing multicast overhead. One example for this is [RFC6621]."
    >
    > Charlie makes a refined proposal:
    > "Implementations are free to choose their own heuristics for
    >  reducing multicast overhead. Some methods for doing so are
    >  described in [RFC6621]."
    >
    > If this is O.K., can I make the change and then suggest closure
    > on the [manet] mailing list?

    This is unchanged.
    >
    > ============================================================
    >
    >
    > #46 (aodvv2): What is needed from IP and ICMP
    >
    > Write an appendix with the following text:
    > >
    > >     AODVv2 needs the following:
    > >
    > >         information that IP routes are requested
    > >         information that packets are flowing
    > >         the ability to queue packets.
    > >
    > > Tautologically, a reactive protocol reacts when a route is needed.
    > One might say that a route is requested when an application tries to
    > send a packet. The fundamental concept of reactive routing is to
    avoid
    > creating routes that are not needed, and the way that has been
    used to
    > know whether a route is needed is when an application tries to
    send a
    > packet.
    > > If an application tries to send a packet, and the route is
    > available, the packet has to wait until the route is available.
    >
    > Suggest this on the mailing list as a proper resolution.

    This is unchanged.
    >
    > ============================================================
    >
    > [manet] #34 (aodvv2): Section 13 must be removed
    >
    > Lotte says:
    >
    > ------------------------------------------------------------
    > I don't think we should close this yet. In my opinion, Thomas has a
    > point.
    > At least Section 13.5 needs to be specified way more clearly (I've
    > tried to write down my comments about that earlier here: [1]). Its
    > relationship to AckReq needs to be stated clearly, and, in case
    AckReq
    > depend on RREP_ACK (which it seems to, judging from some
    comments that
    > surfaced after my review on the ML), I wonder if it should be in the
    > "optional" section at all.
    >
    > IMHO, we should only close this issue after we've gone through each
    > point, have possibly improved it and can argue why it should be
    kept,
    > and why it is well specified. However, I'd like to ask Thomas
    what the
    > "known problems in common deployment topologies" are exactly.
    > ---------------------------------------------------------------
    >
    > O.K.  Can we do this on Friday?

    Our discussion was to mandate implementation of RREP_ACK with
    an additional field to make sure that a response packet was indeed
    the response to the AckReq which was included in the RREP.
      So, propose this to the mailing list but do not suggest to close the
    issue pending further discussion.

    ============================================================

    Tomorrow I will write up resolutions for as many of the other
    issues as
    I can,
    and if there is no objection I would like to send the above
    resolutions
    to the mailing list.

    Regards,
    Charlie P.






Other related posts: