Re: [manet] Reactive Protocol Situation

"JP Vasseur (jvasseur)" <jvasseur@cisco.com> Thu, 01 November 2012 19:27 UTC

Return-Path: <jvasseur@cisco.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 461C621F94BB for <manet@ietfa.amsl.com>; Thu, 1 Nov 2012 12:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.411
X-Spam-Level:
X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7hYB2XQbXS1 for <manet@ietfa.amsl.com>; Thu, 1 Nov 2012 12:27:12 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E645621F94B4 for <manet@ietf.org>; Thu, 1 Nov 2012 12:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7475; q=dns/txt; s=iport; t=1351798032; x=1353007632; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kbhp40WkGo3d/Jta2hiQFhv/EjZpcYG30Vt9l+aOrfs=; b=bYJfY4oukaXgYQ1ldl5eXxQpHOxhNWdvq4SbXdw6rcmk4uTcvCZbClpr JjyjuX09mPHcSISc3VZgNm0doqD5hMwFP5k3VqEioHr2RgsIkeKRyCm4x +qhvv6pO7CFd3aEAATgsVmqRxhpff9+uTw9c+x557HQa5F7PXEGEW4m2P A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAH7MklCtJXG9/2dsb2JhbABEw3GBCIIeAQEBAwEBAQEPAVsLBQsCAQgiHQcnCxQRAgQOBQgah14GC5xToCsEi3uFWmEDiCWcK4Frgm+BZBce
X-IronPort-AV: E=Sophos; i="4.80,695,1344211200"; d="scan'208,217"; a="137919738"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 01 Nov 2012 19:27:11 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA1JRBja001053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Nov 2012 19:27:11 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 14:27:11 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: Ulrich Herberg <ulrich@herberg.name>
Thread-Topic: [manet] Reactive Protocol Situation
Thread-Index: AQHNt7TLLPVi/cSo/ES1hdb7zda62w==
Date: Thu, 01 Nov 2012 19:27:10 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722049B35@xmb-rcd-x02.cisco.com>
References: <1351705729.64800.YahooMailNeo@web160603.mail.bf1.yahoo.com> <FA314EE2-78D3-4A70-B6CF-0389DF05078F@cisco.com> <03B78081B371D44390ED6E7BADBB4A77220465DF@xmb-rcd-x02.cisco.com> <3D320804-EE40-42FB-BF08-3F662B3F9542@axelcdv.com> <AB2A99F1-5B51-415D-BEC0-57360AF0391F@cs.stanford.edu> <B31EEDDDB8ED7E4A93FDF12A4EECD30D24FB5D11@GLKXM0002V.GREENLNK.net> <6C031880-6176-491E-B822-CCE6B8B586FC@cs.stanford.edu> <CAK=bVC_BKU09PpNk8r75rkq3EaQjzbbRiewSTqBie+8Xc51A3w@mail.gmail.com>
In-Reply-To: <CAK=bVC_BKU09PpNk8r75rkq3EaQjzbbRiewSTqBie+8Xc51A3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.90.251]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001
x-tm-as-result: No--48.845000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722049B35xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>, "<manet@ietf.org> List" <manet@ietf.org>, "Bo Berry (boberry)" <boberry@cisco.com>
Subject: Re: [manet] Reactive Protocol Situation
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: Thu, 01 Nov 2012 19:27:13 -0000

Indeed - we're diverging from the original question.

On Nov 1, 2012, at 6:12 PM, Ulrich Herberg wrote:

Hi Phil,

maybe we should open a separate email thread about RPL and draft-clausen-lln-rpl-experiences (and probably not in this WG).

Best
Ulrich

On Thu, Nov 1, 2012 at 9:45 AM, Philip Levis <pal@cs.stanford.edu<mailto:pal@cs.stanford.edu>> wrote:
On Nov 1, 2012, at 9:27 AM, Dearlove, Christopher (UK) wrote:

> They can be good evidence of the failure of protocols ;)
>
> But what is clear to me is that one important issue (and another of my posts is attempting to both be more precise, as well as going elsewhere) is the handling of unidirectional links. So any good evidence needs to consider those.

Since communication in wireless is rarely binary, I think the more common term is asymmetric links. I'm confused; I don't believe that unit disc models capture asymmetric links. Is the implied statement that RPL doesn't properly handle asymmetric links but LOADng does? I think this came up in draft-clausen-lln-rpl-experiences and there was some discussion on the ROLL list about it. The neighbor set in RPL is defined in 8.2.1:

"First, the candidate neighbor set is a subset of the nodes that can be reached via link-local multicast."

then in DIO processing (8.2.3.1) it reads:

"As DIO messages are received from candidate neighbors, the neighbors may be promoted to DODAG parents by following the rules of DODAG discovery as described in Section 8.2."

I want to be clear here; I haven't read deeply about LOADng, thought about it much, or experimented with it at all. So I have zero to say about LOADng's strengths and weaknesses.

But just because somebody publishes (and republishes) a draft saying something doesn't mean it's true. There are, in my opinion, some very valid points in draft-clausen-lln-rpl-experiences that relate to fundamental design decisions in RPL. For example, I think that the issues raised about the state requirements of floating DODAGs and RPL message fragmentation are valid and reasonable and something we need to look at.

However, there are others that are the result of naive mistakes anyone can make when implementing any wireless routing protocol, such as link asymmetry and protocol convergence. Unfortunately the draft doesn't distinguish the two. Implementing a protocol poorly then saying it doesn't work isn't particularly meaningful. As I said in Paris, I thought the draft is valuable because it outlines many of the basic mistakes one makes the first time you try implementing a wireless routing protocol.

Phil
_______________________________________________
manet mailing list
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet