Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

"Dearlove, Christopher (UK)" <> Wed, 04 January 2017 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF5BB128DF6 for <>; Wed, 4 Jan 2017 02:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.019
X-Spam-Status: No, score=-10.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uyxNyMUuo0Rn for <>; Wed, 4 Jan 2017 02:10:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 931F712711D for <>; Wed, 4 Jan 2017 02:10:16 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.33,458,1477958400"; d="scan'208,217"; a="48389624"
Received: from unknown (HELO ([]) by with ESMTP; 04 Jan 2017 10:10:13 +0000
X-IronPort-AV: E=Sophos;i="5.33,458,1477958400"; d="scan'208,217";a="149926662"
Received: from ([]) by with ESMTP; 04 Jan 2017 10:10:13 +0000
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 4 Jan 2017 10:10:13 +0000
From: "Dearlove, Christopher (UK)" <>
To: Jiazi Yi <>, "Peter S Lau (peterlau)" <>
Thread-Topic: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"
Thread-Index: AQHSZeN4eitj+utMfUKMGDE1x3UIoaEoCDCAgAAKmOA=
Date: Wed, 4 Jan 2017 10:10:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A9158GLKXM0003vGREEN_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jan 2017 10:10:19 -0000

There some immediate retrograde steps compared to existing protocols: fixed message format (making adding new information to be used by the protocol hard), forwarding by blind flooding (hence scalability issues), and no security (an example of something that to add would require a changed format). The rather peculiar link metric (in effect) that mixes hop count, time and battery power leads to many questions (and while not simply hop count is likely to be a backward step in flexibility). There’s a rather unusual message body that is not used by this protocol but said to be for the application, which is a bit of a layering issue. GPS is included with no indication how to use and hence no indication why it is there. They are also underspecified in terms of format information (and for GPS at least even size of field). There’s quite a lot underspecified, such as route determination, and there’s no consideration of how the acknowledgements are used - and even what the meaning of acknowledgements in what must be (but is not so described) as a local broadcast/multicast message (with potentially unknown recipients). I don’t see any handling of the problems that link asymmetry produces. I’d have issues over timing parameters and their management (these being not reflected in the message). And in a proposed IETF protocol, I don’t see any IP addresses. That it hasn’t even caught up with the existence of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested that RFC 3626 (and hence, no doubt, RFC 7181) is too complex. That may or may not be so (there are reasons for the added complexity in RFC 7181, which need to be understood before deciding whether you need them) and there thus may or may not be a space for a lightweight proactive protocol, but this is not that protocol in current or foreseeable evolutionary form.

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories

T:  +44 (0)1245 242194  |  E:<>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.<>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [] On Behalf Of Jiazi Yi
Sent: 04 January 2017 09:08
To: Peter S Lau (peterlau)
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<>df>.
If you feel the email is suspicious, please follow this process<>df>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Dear Peter,

Thanks very much for your draft.

Looking at the overview section:

   TRP is a table-driven proactive data forwarding protocol and at the
   same time allows users to announce their presence to the network.  A
   node, wishing to be contacted, periodically broadcasts control
   messages about itself to the network.  A node, receiving control
   messages, caches an optimal path to each of the originators of the
   control messages.

Could you please briefly introduce what’s the difference between TRP and other proactive protocols like OLSR(v2)?

Especially, it would be very helpful for the readers to understand by providing a bit more text about the mechanism of the protocol in the overview.



On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <<>> wrote:

Dear manet Working Group:

I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-refresh-00". for the WG to consider.

Peter Lau

Peter Lau
The University of Memphis
Electrical and Computer Engineering
manet mailing list<>

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.