Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00
"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> Mon, 11 November 2013 12:19 UTC
Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829E11E8163 for <manet@ietfa.amsl.com>; Mon, 11 Nov 2013 04:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.476
X-Spam-Level:
X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHdSOzxvO2Sl for <manet@ietfa.amsl.com>; Mon, 11 Nov 2013 04:19:17 -0800 (PST)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 546C921E80EC for <manet@ietf.org>; Mon, 11 Nov 2013 04:19:15 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,677,1378854000"; d="scan'208";a="327049855"
Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 Nov 2013 12:19:14 +0000
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
X-IronPort-AV: E=Sophos;i="4.93,677,1378854000"; d="scan'208";a="35167877"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 11 Nov 2013 12:19:14 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.93]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 11 Nov 2013 12:19:14 +0000
To: Jiazi Yi <yi.jiazi@gmail.com>, MANET IETF <manet@ietf.org>
Thread-Topic: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00
Thread-Index: AQHO3s74SeO9iNSjmE+jHuG3TyZOb5of7+xw
Date: Mon, 11 Nov 2013 12:19:14 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D3DC149C6@GLKXM0002V.GREENLNK.net>
References: <5280BB8E.6000906@gmail.com>
In-Reply-To: <5280BB8E.6000906@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2013 12:19:21 -0000
This is entirely optional, so MAY and RECOMMENDED are the right strength. The removed MPRs do not add redundancy, as suggested, as they are useless. The whole point is to remove MPRs that will never be used. (They will never be used because there is always a shorter path than any using them directly.) For discussion details, see the metrics rationale draft. As to complexity, it's a tradeoff. If you don't like the complexity, don't do it. It won't make any difference to performance, it will just save a bit of message size and work at the other end of the link. As noted, some of this is in the rationale document, and there's no point repeating that unnecessarily. But we should take a look at what may or may not be clear. Thanks for your comments on that. Incidentally, top of my list is checking the specific definition of when MPRs can be dropped, for correctness and completeness (based on the rationale word explanation of when MPRs can be dropped). Anyone who does that and confirms they've done it (especially with something more than just "done it") would be definitely appreciated. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi Sent: 11 November 2013 11:12 To: MANET IETF Subject: [manet] review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi, I had a review of draft-dearlove-manet-olsrv2-rmpr-optimization-00. Here are some comments (or some of them, I would rather call questions :) 1. In Section 4: Routing MPR Selection ... then x_1 to x_n may be removed from the set of routing MPRs, if selected. ... The first note: I think we should use RFC2119 term "MAY" here? In fact, this is the part that confuses me most. As the only "action" described in the draft, the use of "may" without further explanation when this action should be taken or not is too vague. In the end of the section, another "RECOMMENDED" is used. Therefore, if I put them together, it is something like "It is RECOMMENDED that one MAY do foo, bar..." 2. If x_1, x_2 ... x_n are the largest set with corresponding y_1, y_2, ... y_n. Should we check all the subsets {x_i} of x_1, ... x_n with the criteria d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m belong to subset of x_1, ... x_n? If so, we probably will have a lot combinations to check in a dense network. If not, the criteria seems to be too harsh to be actually "triggered"? 3. Should this be applied to all types of metrics? A potential affects of this draft is that, we can probably have more "hops" around the neighborhood of the original router, i.e., there is higher possibility of interference. In some of metrics, the interference is not much considered (because it is hard to measure). Will it be a problem if we introduce more transmission in some scenarios? 4. We have a "Willingness" value to "represents the router's willingness to be selected as an MPR." Should this need to be considered also? What about if x_0 has low willingness, while the others x_1, ... x_n have higher willingness? 5. In some scenarios, we probably want to have certain redundancy in MPR in some lossy scenarios? sincerely Jiazi _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************
- [manet] review of draft-dearlove-manet-olsrv2-rmp… Jiazi Yi
- Re: [manet] review of draft-dearlove-manet-olsrv2… Jiazi Yi
- Re: [manet] review of draft-dearlove-manet-olsrv2… Dearlove, Christopher (UK)
- Re: [manet] review of draft-dearlove-manet-olsrv2… Dearlove, Christopher (UK)
- Re: [manet] review of draft-dearlove-manet-olsrv2… Dearlove, Christopher (UK)