Re: [6lo] [homenet] [ieee-ietf-coord] Multicast on 802.11

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 14 August 2015 16:17 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F241A8759; Fri, 14 Aug 2015 09:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qu_6c2XP9O8; Fri, 14 Aug 2015 09:17:19 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623191A873D; Fri, 14 Aug 2015 09:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36952; q=dns/txt; s=iport; t=1439569040; x=1440778640; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iWPA7F1EyUC/Q2gfCLh011HKH82l8TceVdWvkXMwgaU=; b=ftXtpa8gIYoIdFplPtjP5DUz0TeUXonJkH//TSQcLesrQYOiP0Xzd4Ow iKyIrdFgmr3WUIY+BZhThpXtbAoXnBWgOcV+NSewJUM8hqiCeoeE19Uzt UKv2x8Zufruz9Xg0HHu8jI0i67ue0MtO75Kcqo0Fgg2R7tOBa5mXiCbp4 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DSAgARFM5V/4sNJK1aA4JOTVRpBoMeumQBCYFrAQuFdwIcgS04FAEBAQEBAQGBCoQjAQEBAwEBAQEgCj8CAgYDBQcEAgEIDgMEAQEBChYHAwICAiULFAkIAgQBDQUIE4gLCA25WZYyAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLU4QmCgcBIAYHCQsMBAYBBgyCVy+BFAWHHoVHiDYBhQOHaYFJhCuDGY0vg2cmg31xAYEECRcjgQQBAQE
X-IronPort-AV: E=Sophos; i="5.15,678,1432598400"; d="scan'208,217"; a="24314440"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2015 16:17:19 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7EGHHDr005604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2015 16:17:17 GMT
Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 14 Aug 2015 11:17:16 -0500
Received: from xhc-aln-x11.cisco.com (173.36.12.85) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 14 Aug 2015 11:17:16 -0500
Received: from xmb-rcd-x01.cisco.com ([169.254.1.17]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0248.002; Fri, 14 Aug 2015 11:17:16 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alia Atlas <akatlas@gmail.com>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [homenet] [ieee-ietf-coord] Multicast on 802.11
Thread-Index: AQHQ1qyvVLw3egqGr0C71g6NTqoffg==
Date: Fri, 14 Aug 2015 16:17:15 +0000
Deferred-Delivery: Fri, 14 Aug 2015 16:16:46 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD84A00D431@xmb-rcd-x01.cisco.com>
References: <71B55498-B383-4B31-928A-15CF9585889B@steffann.nl> <alpine.DEB.2.02.1508051950240.11810@uplift.swm.pp.se> <CAG4d1rfRn2+Fed18ATcM_oOwb+Zxi_gGSZd12dfw2sKdUdp2kA@mail.gmail.com> <FB888096-FD36-4E89-B022-30B8393BCB1B@cisco.com> <CAG4d1rf3BGkf96s4CJKSSyKKPq9ACWEwJN82V8yE6E2bMi9gbg@mail.gmail.com> <2BBEF519D867E04EA729626C246A978714E94F49@eusaamb101.ericsson.se> <alpine.DEB.2.02.1508060829510.11810@uplift.swm.pp.se> <48E1A67CB9CA044EADFEAB87D814BFF6448A40E6@eusaamb107.ericsson.se> <alpine.DEB.2.02.1508061556360.11810@uplift.swm.pp.se> <C36C59A1-D3FC-467F-9011-62D838A651BD@cisco.com> <alpine.DEB.2.02.1508070807541.11810@uplift.swm.pp.se> <EB9B93801780FD4CA165E0FBCB3C3E672B3999EB@SJEXCHMB09.corp.ad.broadcom.com> <CEDE66C6AFB89142B27DD067951D040C3EF631BE@IRSMSX102.ger.corp.intel.com> <alpine.DEB.2.02.1508100924000.11810@uplift.swm.pp.se> <CEDE66C6AFB89142B27DD067951D040C3EF6399F@IRSMSX102.ger.corp.intel.com> <alpine.DEB.2.02.1508101109220.11810@uplift.swm.pp.se> <CEDE66C6AFB89142B27DD067951D040C3EF64169@IRSMSX102.ger.corp.intel.com> <CAG4d1rftg4fQaWk2-3b7QWpuDNeDoyTKoAc3b5ZJtgP8FAO=Og@mail.gmail.com>
In-Reply-To: <CAG4d1rftg4fQaWk2-3b7QWpuDNeDoyTKoAc3b5ZJtgP8FAO=Og@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.73.116]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84A00D431xmbrcdx01ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6lo/bByHXfxt5FN1NE49RoUJ1TEqx-0>
X-Mailman-Approved-At: Fri, 14 Aug 2015 11:45:25 -0700
Cc: "ieee-ietf-coord@ietf.org" <ieee-ietf-coord@ietf.org>, "Dan Romascanu (dromasca@avaya.com)" <dromasca@avaya.com>, Adrian P Stephens <Adrian.P.Stephens@intel.com>, Glenn Parsons <glenn.parsons@ericsson.com>, "mboned@ietf.org" <mboned@ietf.org>, Homenet <homenet@ietf.org>, Eric Gray <eric.gray@ericsson.com>, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [6lo] [homenet] [ieee-ietf-coord] Multicast on 802.11
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2015 16:17:23 -0000

Hello Alia:

The solution space has been explored in the context of WPANs (802.15.4, BTLE…) and there is certainly value in extending this to WLANs. We have running code that was tested between vendors (twice already) at 6TiSCH plug fests and is scheduled for official plugtest in Berlin next year.

The solution splits the broadcast domain by making the hybrid wired/wireless network a MultiLink Subnet. ND operations on the wireless links derives from RFC 6775 and the use of multicast for ND is dramatically reduced. Backbone routers perform proxy ND operations to integrate with the wired backbone. The overall design is pretty much an echo at layer-3 of the association process that was designed for 802.11 and that is much more suitable to wireless than IPv6 ND’s multicast-based operations.

I just updated the (years old, used to be a 6LowPAN WG doc from which RFC 6775 actually derives) backbone router draft. The problems is summarized by referencing other drafts from Andrew, Eric, Erik, Samita, and others, and I detailed the protocol operations as my memory and a crude code lookup tells me it is implemented. It is broadly correct but there are devils in the details and we’ll need to refine as usual.


URL:            https://www.ietf.org/internet-drafts/draft-thubert-6lo-backbone-router-00.txt

Htmlized:       https://tools.ietf.org/html/draft-thubert-6lo-backbone-router-00

Take care,

Pascal

From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: lundi 10 août 2015 20:49
To: Adrian P Stephens <Adrian.P.Stephens@intel.com>
Cc: ieee-ietf-coord@ietf.org; Dan Romascanu (dromasca@avaya.com) <dromasca@avaya.com>; Glenn Parsons <glenn.parsons@ericsson.com>; mboned@ietf.org; Homenet <homenet@ietf.org>; Mikael Abrahamsson <swmike@swm.pp.se>; Eric Gray <eric.gray@ericsson.com>
Subject: Re: [homenet] [ieee-ietf-coord] Multicast on 802.11


Hi Adrian,

I am encouraging those interested to wrote a draft indicating the observed issues and perhaps exploring the solution space.   I assume that's what you would need to start having a meaningful discussion on reasonable options.

Thanks,
Alia
On Aug 10, 2015 5:41 AM, "Stephens, Adrian P" <Adrian.P.Stephens@intel.com<mailto:Adrian.P.Stephens@intel.com>> wrote:
Hello Mikael,

Please see my responses embedded below...

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825<tel:%2B44%20%281793%29%20404825> (office)
Tel: +1 (971) 330 6025<tel:%2B1%20%28971%29%20330%206025> (mobile)

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

-----Original Message-----
From: ieee-ietf-coord [mailto:ieee-ietf-coord-bounces@ietf.org<mailto:ieee-ietf-coord-bounces@ietf.org>] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: ieee-ietf-coord@ietf.org<mailto:ieee-ietf-coord@ietf.org>; Dan Romascanu (dromasca@avaya.com<mailto:dromasca@avaya.com>); Glenn Parsons; mboned@ietf.org<mailto:mboned@ietf.org>; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11


(included mboned@ietf.org<mailto:mboned@ietf.org> and also changed subject to something more
appropriate)

As far as I can tell, so far people have told IETF it's their job to reduce multicast to make IP based protocol "work" on 802.11 media. That's at least what I have been seeing. Considering the reactions from other parties, it seems the "multicast sucks on 802.11" is something 802.11 hasn't heard of before.

[Adrian P Stephens]
This problem is nothing new.  We know about the relative performance of multicast vs unicast.
Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You are getting more than you are paying for :0).


The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a lot of nodes.

[Adrian P Stephens]
The technical solution is surely to add a class of service specification to multicast packs that indicates their sensitivity to loss.
The point is that the AP is in possession of a lot of data about individual nodes that may help it make an informed decision
between unicast and multicast.

Moving the duplication into the IP layer ensures uninformed decisions.


>From what I read below, one way out of this is the IETF making a clear
statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast).

[Adrian P Stephens]
<irony type="british; very-subtle">
I'm guessing you will be the first to turn off the 802.11 networking on your devices when the IETF makes such a statement.
</irony>



It seems to me that there are a few paths that the IETF could go:

Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast into unicast that certain medias could have as requirements. Then IEEE could create a device profile that would fulfil these requirements, possibly add a certification, and then try to get market pressure to require devices to support this profile. The IETF wouldn't change its mind about how multicast is used in its protocols after this, but just say "this is the reality, please deal with it when you create L1/L2 that's supposed to carry IP".

Or the IETF could just say that this seems like a lost cause, multicast/broadcast doesn't seem to work on some L1/L2, and start working on techniques that minimizes broadcast/multicast and change all the protocols to reflect this new reality.

Something in the middle, but anyway changing the requirements on IETF protocols to avoid using multicast if it can, documenting where it makes sense and when it doesn't.

Right now what I am seeing is that there are people who are lobbying to do away with multicast as much as possible because they see that in reality it's not reliable on the devices they have tested it on.

What are the odds that 802.11 could agree on a device profile for "IP use"
that would include reliable multicast delivery, and one that there is reasonable belief that this would gain significant market adoption?
[Adrian P Stephens]
As I indicated in my earlier post,  there are multiple actors here.
The odds are pretty good that 802.11 will respond to a clear requirement to handle multicast specially.
If has,  after all,  already done this twice.

What are the odds that the WFA will create a new certification?
What are the odds that it is successful in the market?

These are presently unknowns,  and will remain that way until tried.


On Mon, 10 Aug 2015, Stephens, Adrian P wrote:

> Hello Mikael,
>
> " For me, it seems these 802.11 broadcast/multicast ACK functions should be "mandatory" to implement if the device wants to support IPv4 and IPv6 networks.
>
> How do we achieve this?"
>
> There are two routes to "mandatory".   The standard can indicate something is mandatory if you support
> a particular feature.
>
> The second is certification.  This is the not-so-simple task of persuading a sufficient number of WiFi-Alliance members
> that it is in their economic interest to support the feature that a certification program can be created.   Even, given a
> certification,  the market will still decide whether that is relevant or not.
>
>
> Best Regards,
>
> Adrian P STEPHENS
>
> Tel: +44 (1793) 404825 (office)
> Tel: +1 (971) 330 6025 (mobile)
>
> ----------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>
> -----Original Message-----
> From: ieee-ietf-coord [mailto:ieee-ietf-coord-bounces@ietf.org<mailto:ieee-ietf-coord-bounces@ietf.org>] On
> Behalf Of Mikael Abrahamsson
> Sent: 10 August 2015 08:32
> To: Stephens, Adrian P
> Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler;
> ieee-ietf-coord@ietf.org<mailto:ieee-ietf-coord@ietf.org>; Dan Romascanu (dromasca@avaya.com<mailto:dromasca@avaya.com>); Glenn
> Parsons; Homenet; Eric Gray
> Subject: Re: [ieee-ietf-coord] [homenet] Despair
>
> On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
>
>> The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard.
>
> Thanks for the summary, it seems correct.
>
> It might not need new 802.11 standards, but we still have an operational problem in that it seems some of these standards are not universally implemented by 802.11 based device vendors.
>
> IETF standards generally assume that multicast and unicast are delivered with a similar level of packetloss (which is low).
>
> Not all 802.11 implementations have the multicast ACK mechanism implemented, thus it would seem that multicast will be less likely to get delivered to the recipient over these 802.11 implementations.
>
> For me, it seems these 802.11 broadcast/multicast ACK functions should be "mandatory" to implement if the device wants to support IPv4 and IPv6 networks.
>
> How do we achieve this?
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se<mailto:swmike@swm.pp.se>
>
> _______________________________________________
> ieee-ietf-coord mailing list
> ieee-ietf-coord@ietf.org<mailto:ieee-ietf-coord@ietf.org>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>

--
Mikael Abrahamsson    email: swmike@swm.pp.se<mailto:swmike@swm.pp.se>

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