Re: [Roll] [manet] Working group re-charter ideas (meeting summary)

"Pascal Thubert (pthubert)" <> Thu, 02 April 2015 07:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6FF6B1A89FC; Thu, 2 Apr 2015 00:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vrQ8df48hhTI; Thu, 2 Apr 2015 00:53:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1DF81A8997; Thu, 2 Apr 2015 00:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4065; q=dns/txt; s=iport; t=1427961202; x=1429170802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2q7z1n5hDTgJ8BgbnX30l9wIyS2rcOy4KplVzoOAUMw=; b=bKwwCHSP2IYh3QbbI2WJfVA5xY292CZrirnQunMj+bThKBp8F/bO5VDC jI37exPNt8TYmSA+CtTCEJIfYf7LVI/C/37dWHRig21DuLDadTf8nuKkZ DS9NMI8y5W4O1y1Bs8VBvo1fX3bdKxgmmz96ZTYmJl72Zv2LbEG3qyrpC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,509,1422921600"; d="scan'208";a="775824"
Received: from ([]) by with ESMTP; 02 Apr 2015 07:53:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t327rLkA032175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 07:53:21 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 02:53:21 -0500
From: "Pascal Thubert (pthubert)" <>
To: Juliusz Chroboczek <>
Thread-Topic: [manet] Working group re-charter ideas (meeting summary)
Date: Thu, 2 Apr 2015 07:53:20 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: ROLL WG <>, "" <>
Subject: Re: [Roll] [manet] Working group re-charter ideas (meeting summary)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Apr 2015 07:53:24 -0000

I disagree with the terms in your mail pretty much as much as I agree with your designs, Juliusz...

There are literally hundreds of papers that reference RPL, from Google scholar.

There are deployed networks of thousands of nodes, and they behave even better than expected.

But what hurts even more is your misunderstanding of the technology:

RPL inherits from the same roots as Babel, DSDV and DUAL/EIGRP, though RPL adds technology to cope with harsher constraints and multiple types of links that neither Babel nor any of the common ancestry has.

You do not seem to have fully realized how similar Babel is to RPL. Consider this: RPL's sequenced advertisement is called the iteration of an instance; so the process of microloop avoidance in Babel is effectively the same as what RPL calls a global recovery. Both protocols inherit DUAL's feasibility condition. But RPL adds the capability to make local repair which provides a service of freezing akin to the the diffusion algorithm but adapted to LLN and MANET. 

Even more, RPL adds a capability to stretch the rules, and a capability to delay the repairs so as to reduce the control overhead in Lower Power and mobile use cases. To enable these - arguably optional - features, RPL adds the capability to instrument packets beyond hop limit to detect loops and trigger repairs.

Saying the RPL does not work in MANET environment is a gross misrepresentation. RPL derives from early MANEMO work, which was MANET for NEMO, and it was fully demonstrated in that space. RPL works fine in MANET for the same reasons Babel will. And RPL probably works a lot better because it can:
- cope with all sorts of radios with objective functions 
- allow a trade off of routing stretch vs control plane overhead 
- address memory constraints 
- natively support interconnection with LLNs
- freeze a zone and perform local repairs
- support multiple exits. RPL's instances avoid the need for source/destination routing altogether

All in all I remain to be convinced that Babel is much, much, anything. In my view, it is a great approach but I will need more details to find novelty vs. an existing proposed std RFC that is RFC 6550. You will need to demonstrate that novelty to get a new work approved. We went through that in the first phase of ROLL. And I would be interested in bringing back that novelty in RPL.

On the side there are multiple implementations of RPL. Some on constrained devices. 2 on Linux, one of them at least running on OpenWRT (Unstrung). We even have one running on various network OS'es that Cisco ships in its big irons, and applicable from gigE to virtual links.

All in all, there's a lot of misconceptions that a discussion over a whiteboard could help clarify. I'm certainly willing to learn more from Babel and I trust that you'd need some catching up on RPL before you can discuss it decently, which sadly was not the case in this mail.

I would be glad to meet anytime. We are almost next door...



Le 1 avr. 2015 à 23:41, Juliusz Chroboczek <> a écrit :

>> Any contribution you'd want to make to ROLL? This is probably the place
>> where the ideas you defend in Babel were most successful...
> I hope you are not comparing RPL's proactive subset to Babel.  Babel is
> a much, much more refined and complete protocol.
> Which is okay, since RPL's proactive subset is designed to work in
> a stable network with a single DODAG.  Babel is aimed at a completely
> different space -- which is why it has redundant routing tables, attempts
> stability in the presence of variable metrics, has strong loop avoidance
> properties, and includes blackhole resolution.
> By the way -- I've tried to find experimental data on RPL, and couldn't
> find any (perhaps I haven't tried hard enough).  Could you send me some
> references, perhaps by private mail?
> -- Juliusz