Re: [Roll] Interest in opportunistic routing?
Simon Duquennoy <simonduq@sics.se> Mon, 10 March 2014 23:06 UTC
Return-Path: <simon.duquennoy@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB73B1A0527 for <roll@ietfa.amsl.com>; Mon, 10 Mar 2014 16:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msOm0Kx_bclL for <roll@ietfa.amsl.com>; Mon, 10 Mar 2014 16:06:01 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB91A0515 for <roll@ietf.org>; Mon, 10 Mar 2014 16:06:00 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id lh14so5775904vcb.34 for <roll@ietf.org>; Mon, 10 Mar 2014 16:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=my6PgYYm6/9VyKCDlWmHuEPwIelOT8wv8q8rYvSTwSg=; b=mqMBOyv1OPPiTAXT7hw3EtQxhKJSvp7WTPDOd/Lz2cF7HZtMq0j6b6DXrl5FZE2iMH jDaD54okq6pvoaJFKZcuVvorhEMw0TEgpUlvq3AhbSnENvAUqw9zeS0p5Y8AwbLYMPSh hB86m9IAycBNpIlkzx7/al0V+rzVaxnOSBNMaIxHr9B5cxjZd0JyPXiEdzOlSQpxFlvm ofIPkTYzjhCQ9aN/S17m6NRAAytLxX9Duat/CAK1qc3ZCjLTVpPrkbc6O9diGq0IapBa wlhuO6AjzxZ1WGuSCc6ZyA2HZGDDF5c/XJfMXOq/tQCAraGqyR38xljnK5nhpyGryRmW baEw==
MIME-Version: 1.0
X-Received: by 10.58.90.99 with SMTP id bv3mr71465veb.34.1394492754934; Mon, 10 Mar 2014 16:05:54 -0700 (PDT)
Sender: simon.duquennoy@gmail.com
Received: by 10.220.150.209 with HTTP; Mon, 10 Mar 2014 16:05:51 -0700 (PDT)
In-Reply-To: <CF439157.2A293%d.sturek@att.net>
References: <CAMxvJtKqhSMpFE5pP42h-Dt3_zCLnJ8WWochjjg7TOCO8kMQVg@mail.gmail.com> <19299.1394195834@sandelman.ca> <CAMxvJtKjw0k-3=Q1f5KUFwYweC_Vu6Gr4N=z8LHEL3toMhaigw@mail.gmail.com> <e5daccc8a5d4490e8cf21cd48ad4bc73@CO1PR04MB553.namprd04.prod.outlook.com> <CAMxvJtJUQwrMKYcVPw_1OKqSjf8xv7yvmJXeT9Ph6iuMd0gm7w@mail.gmail.com> <399f072257c74492866cccc01d025dee@CO1PR04MB553.namprd04.prod.outlook.com> <CAMxvJtLKhS=DV=O57xXyNz0RyXOej3kQm=er3M8UFcWG7t15eQ@mail.gmail.com> <CF439157.2A293%d.sturek@att.net>
Date: Tue, 11 Mar 2014 00:05:51 +0100
X-Google-Sender-Auth: aSSFfuJ5DEU7-oAAvFBAZ1bbn8s
Message-ID: <CAMxvJt+tXb+UvnMbP_8NBsQ5JxoMw1q1OeXU+TG6Lf1ORbZfyA@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/related; boundary="089e01182b8e4d28ac04f448a5a5"
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ERw8IyCqMoJuBldlzDxp8kzBYEs
Subject: Re: [Roll] Interest in opportunistic routing?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 23:06:04 -0000
Hi Don, Yes, definitely. If your devices are always on then anycast is much more complex than acked broadcast. Our opportunistic extension is primarily targeting radio duty cycled networks. In always-on networks, you would need an agreement procedure to achieve anycast, such as that used by ExOr [1] with WiFi. Best regards, Simon [1] http://pdos.csail.mit.edu/papers/roofnet:exor-sigcomm05/roofnet_exor-sigcomm05.pdf On Mon, Mar 10, 2014 at 11:58 PM, Don Sturek <d.sturek@att.net> wrote: > Hi Simon, > > I think Matt's question might be in the context of an AMI application > where most of the devices are powered. I think in that use case that > setting the AR field as you indicated would not work well. > > Don > > > > From: Simon Duquennoy <simonduq@sics.se> > Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org> > Date: Monday, March 10, 2014 3:49 PM > To: Routing Over Low power and Lossy networks <roll@ietf.org> > Subject: Re: [Roll] Interest in opportunistic routing? > > The context is a network where nodes are duty cycled, and when you > transmit anycast frame, either: > * in most cases, only one node receives the frame and sends an ACK; > * in some cases, several nodes receive the same frame and send an ACK > (after macSIFSPeriod). This results in occasional duplicate forwarding but > as discussed before this is tolerated by the protocol. Note that several > ACK frames sent simultaneously are not a problem, the sender will typically > be able to decode the frame through constructive interference (c.f. > backcast [1], a concept that's been already re-validated by many including > us, in various contexts) > > [1] http://conferences.sigcomm.org/hotnets/2008/papers/4.pdf > > Best, > Simon > > On Mon, Mar 10, 2014 at 10:18 PM, Gillmore, Matthew < > Matthew.Gillmore@itron.com> wrote: > >> Simon, >> >> >> >> Not sure how that's possible because in 802.15.4-2011 it states >> >> >> >> *5.1.6.4 Use of acknowledgments and retransmissions* >> >> A data or MAC command frame shall be sent with the AR field set >> appropriately for the frame. A beacon or >> >> acknowledgment frame shall always be sent with the AR field set to >> indicate no acknowledgment requested. >> >> Similarly, any frame that is broadcast shall be sent with its AR field >> set to indicate no acknowledgment >> >> requested. >> >> >> >> Even if this restriction wasn't in place, broadcasting with the AR bit >> set is not a good idea because any devices that hears the broadcast will >> respond within *macSIFSPeriod *will cause a flood. >> >> >> >> >> >> [image: Description: >> http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]<https://www.itron.com/> >> >> *Matthew Gillmore* >> >> Strategic Standards Architect, Office of the CTO >> Mobile: +1.517.745.7350 >> Knowledge to Shape Your Future >> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg]<http://www.facebook.com/ItronInc> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg]<http://www.linkedin.com/company/7550?trk=null> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg]<http://www.youtube.com/itronsmartmedia> >> >> >> >> >> >> *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Simon >> Duquennoy >> *Sent:* Monday, March 10, 2014 10:46 AM >> *To:* Routing Over Low power and Lossy networks >> *Subject:* Re: [Roll] Interest in opportunistic routing? >> >> >> >> Hi Matt, >> >> >> >> The context where anycast is some sort of acked broadcast is with radio >> duty cycling, in particular low-power listening. In this context, >> broadcasting consists in repeated transmissions for an entire sleep period >> so that all neighbors wake up once and get the frame. What we do is we set >> the ACK bit and we stop the broadcast transmission upon receiving an ACK >> from any neighbor (c.f. fig 2 in the paper). The concept can be applied >> (with some adaptations) to different duty cycling solutions including >> 802.11 PSM, 802.15.4 CSL, RIT or TSCH. >> >> >> >> Thanks, >> >> Simon >> >> >> >> >> >> On Mon, Mar 10, 2014 at 3:16 PM, Gillmore, Matthew < >> Matthew.Gillmore@itron.com> wrote: >> >> Simon, >> >> >> >> In 802.15.4, setting the AR bit for acknowledgements on a broadcast is >> not a good idea because the network would be flooded with ACKS. >> >> >> >> Matt >> >> >> >> [image: Description: >> http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]<https://www.itron.com/> >> >> *Matthew Gillmore* >> >> Strategic Standards Architect, Office of the CTO >> Mobile: +1.517.745.7350 >> Knowledge to Shape Your Future >> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg]<http://www.facebook.com/ItronInc> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg]<http://www.linkedin.com/company/7550?trk=null> >> [image: Description: >> http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg]<http://www.youtube.com/itronsmartmedia> >> >> >> >> >> >> *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Simon >> Duquennoy >> *Sent:* Friday, March 07, 2014 8:47 AM >> *To:* Routing Over Low power and Lossy networks >> *Subject:* Re: [Roll] Interest in opportunistic routing? >> >> >> >> On Fri, Mar 7, 2014 at 1:37 PM, Michael Richardson <mcr+ietf@sandelman.ca> >> wrote: >> >> >> Simon Duquennoy <simonduq@sics.se> wrote: >> > We have designed an opportunistic extension of RPL, where the basic >> idea is to >> > exploit all links of the DODAG rather than the tree defined by >> links to >> > preferred parents. We do this using anycast: transmissions are >> intended either >> > (upwards) to any parent or (downwards) to any child having the >> destination >> > below in the DODAG. >> >> This is very interesting. >> >> > We have a working prototype [1] in Contiki that we evaluated >> thoroughly in a >> > 135-node testbed [2]. In a 4-min packet interval data collection, >> we increase >> > the reliability of RPL from 97.4 to 99.5%, while halving the >> latency (below >> > 0.5s) and radio duty cycle (below 0.5%). >> >> > If there is interest, we can come up with a simplified version of >> the design >> > presented in the paper, and propose a way to integrate it in RPL >> through only a >> > few minor additions. To be more specific, the simplified version >> would use the >> > existing RPL routing tables rather than Bloom filters, and would be >> MAC-layer >> > agnostic (the only assumption being that the MAC layer supports >> > anycast). >> >> I'm not familliar with the concept of anycast at layer-2. >> I think that ethernet supports this, but that actually one would have the >> multicast bit set. I think that you'd have to do the same thing on >> 802.11. >> I guess that 15.4 has a specific support for this, or is just a choice of >> a >> particular unicast mac? >> >> >> >> Dear Michael, all, >> >> >> >> There is no specific support for anycast in 802.15.4, but the standard >> MAC layers can easily be used for anycast (often by setting >> multicast/broadcast + ACK bits). >> >> I've see prototypes for 802.15.4 beacon-enabled [1], for a 15.4e RIT-like >> MAC [2], and for a CSL-like MAC (our own implementation uses ContikiMAC, >> which is similar CSL). >> >> Should also be possible with 15.4 TSCH or even 802.11 PSM. >> >> Doing this on an always-on link like ethernet or traditional 802.11 is >> more tricky because you need an agreement procedure so that only one >> neighbor that received the packet forwards it. There exist solutions for >> WiFi, such as ExOR [3], which introduced opportunistic for 802.11 back in >> 2005. I don't think we want to go into this though; I'd rather simply >> stipulate that anycast is required at the MAC layer and possibly give some >> hints on how to support it on the most common MAC protocols. >> >> >> >> Best, >> >> Simon >> >> >> >> [1] >> http://clarinet.u-strasbg.fr/~theoleyre/uploads/Publis/pavkovic11rpl.pdf >> >> [2] http://www.ti5.tuhh.de/publications/2012/EWSN12_Orinoco.pdf >> >> [3] http://en.wikipedia.org/wiki/ExOR_(wireless_network_protocol) >> >> >> >> >> -- >> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > _______________________________________________ Roll mailing list > Roll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > >
![http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]<https://www.itron.com/>](http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]%3Chttps://www.itron.com/%3E){kind=link}
![http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron>](http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]%3Chttp://twitter.com/#!/itron%3E){kind=link}
![http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg]<http://www.facebook.com/ItronInc>](http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg]%3Chttp://www.facebook.com/ItronInc%3E){kind=link}
![http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg]<http://www.linkedin.com/company/7550?trk=null>](http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg]%3Chttp://www.linkedin.com/company/7550?trk=null%3E){kind=link}
![http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg]<http://www.youtube.com/itronsmartmedia>](http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg]%3Chttp://www.youtube.com/itronsmartmedia%3E){kind=link}
- [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Michael Richardson
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Pascal Thubert (pthubert)
- Re: [Roll] Interest in opportunistic routing? Pascal Thubert (pthubert)
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Ines Robles
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Ines Robles
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Gillmore, Matthew
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Gillmore, Matthew
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy
- Re: [Roll] Interest in opportunistic routing? Don Sturek
- Re: [Roll] Interest in opportunistic routing? Simon Duquennoy