Subject: Re: [ieee-ietf-coord] [homenet] Despair

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Aug 2015 07:47:17 +0000

Hi Mikael,

I agree that we need a more focused dialog. I am copying to your message the IEEE 802 - IETF coordination list. FYI - this is a team of IETF and IEEE 802 experts that includes but is not limited to the ADs who work on issues that require coordination between the IETF and the IEEE on the lines described by RFC 7241. Folks who are interested to join this activity - please write to me. You should also know Dorothy Stanley who is the liaison manager of IEEE 802.11 to the IETF. Let us see what other participants in IEEE 802 have to say about this before we discuss how we can best proceed. 

Regards,

Dan

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Thursday, August 06, 2015 9:45 AM
> To: Glenn Parsons
> Cc: Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); Homenet; Eric
> Gray; Romascanu, Dan (Dan)
> Subject: RE: [homenet] Despair
> 
> On Thu, 6 Aug 2015, Glenn Parsons wrote:
> 
> > As I indicated in another thread, the right place to start a discussion on this
> would be in the IETF-IEEE 802 coordination that Dan leads.
> >
> > While this issue may be solved be current work underway (and included in
> the coordination), perhaps a clearer problem statement would help us to
> ensure that is the case.
> 
> There are documents that talk about multicast from a power efficiency
> standpoint:
> 
> https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00
> 
> Slide 2 of
> http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf 
> pretty much sums it up, most of IETF protocols are designed around multicast
> being as reliable as unicast. IPv6 relies on this. On 802.11 this isn't the case.
> Slide 5 describes how this works in 802.11.
> 
> The fact that multicast and broadcast is unreliable (not ACKed) on 802.11 is
> from what I can see the major cause of the unreliability problem that the
> mesh wifi networking protocols are trying to solve by basically only using
> multicast for discovery.
> 
> The whole question is whether this should be fixed by 802.11 or if the IETF
> needs to (basically) abandon multicast/unicast, or if the IETF should develop
> a multicast->unicast replication mechanism for wifi (there is work in this area
> going on).
> 
> Personally, I think 802.11 needs to fix multicast/unicast so it's reliable, or get
> back the IETF and say it can't be fixed and then the IETF can continue the
> work on multicast reduction (or workaround) even harder.
> 
> I find the current approach of (basically) individuals within the IETF working
> on multicast reduction without (as far as I can see) any dialogue with 802.11
> to be a non-optimal way of solving the problems we're seeing.
> 
> --
> Mikael Abrahamsson    email: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 6 Aug 2015 10:01:29 -0400

I think there are some problems with slide 5 of the references
presentation. Although I am active in IEEE 802.11 this is not
particularly my area of expertise. I'm sure Dorothy will correct me if
I'm wrong:

- The claim that the AP must retransmit multi-destination frames as
the "lowest possible" rate seems a bit misleading. Beacons (AP
originated station discovery frames) should be sent at the lowest rate
the AP is configured to use and Probes (station originated AP
discovery frames) should be sent with the lowest rate the station is
configured to use. Multi-destination data need only be sent at the
lowest rate needed for the worst of the associated stations, although
an AP could send slower if it wanted to, which still uses less air
time than serially unicasting since you would have to send it at that
slow rate anyway to that worst station. In any case, none of these is
the "lowest possible" rate, which I assume means the
slowest/most-robust modulation defined in the 802.11 standard.

- 802.11 does have a feature called GCR -- Groupcast With Retries,
which was part of the 802.11aa amendment, although it is not widely
implemented. It includes such features as a way for the AP to send
several multi-destination frames and then, using unicast, to poll
associated stations for a bit map of which of those frames they
correctly received (BlockAck) and a feature for the AP to
spontaneously transmit a multi-destination frame more than once
without causing confusion for improved reliability.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> _______________________________________________
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: Dorothy Stanley <[email-masked]>
Date: Thu, 6 Aug 2015 14:55:13 +0000

Hi Dan,

Thanks for forwarding this.

a) I agree with Donald's comments below.

b) 802.11 also defines a Proxy Neighbor Discovery capability, and the mechanism for an AP to 
advertise that it provides this service. This is starting to be implemented (part of
Wi-Fi Alliance Passpoint certification) but is not widely deployed.

c) 802.11 defines a Directed Multicast service (multicast to unicast conversion). 
This is not widely implemented. 

d) Additionally, most if not all AP vendors implement multicast - unicast conversion and use it as they see the need for it.

e) This topic seems in need of a richer dialogue, possible steps include:
- develop a presentation describing the problem(s). http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf is a start. 
- present in 802.11. The next 802.11 meeting is September 13-18 in Bangkok. 
Alternatively, we can set up a teleconference with 10 day notice.

Dorothy

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Thursday, August 06, 2015 7:01 AM
To: Romascanu, Dan (Dan)
Cc: Mikael Abrahamsson; Glenn Parsons; Toerless Eckert (eckert); Dorothy Stanley; [email-masked]; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

I think there are some problems with slide 5 of the references presentation. Although I am active in IEEE 802.11 this is not particularly my area of expertise. I'm sure Dorothy will correct me if I'm wrong:

- The claim that the AP must retransmit multi-destination frames as the "lowest possible" rate seems a bit misleading. Beacons (AP originated station discovery frames) should be sent at the lowest rate the AP is configured to use and Probes (station originated AP discovery frames) should be sent with the lowest rate the station is configured to use. Multi-destination data need only be sent at the lowest rate needed for the worst of the associated stations, although an AP could send slower if it wanted to, which still uses less air time than serially unicasting since you would have to send it at that slow rate anyway to that worst station. In any case, none of these is the "lowest possible" rate, which I assume means the slowest/most-robust modulation defined in the 802.11 standard.

- 802.11 does have a feature called GCR -- Groupcast With Retries, which was part of the 802.11aa amendment, although it is not widely implemented. It includes such features as a way for the AP to send several multi-destination frames and then, using unicast, to poll associated stations for a bit map of which of those frames they correctly received (BlockAck) and a feature for the AP to spontaneously transmit a multi-destination frame more than once without causing confusion for improved reliability.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
>> Cc: Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); 
>> Homenet; Eric Gray; Romascanu, Dan (Dan)
>> the coordination), perhaps a clearer problem statement would help us 
>> to ensure that is the case.
>>
>> http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast
>> _issues-pptx.pdf pretty much sums it up, most of IETF protocols are 
>> designed around multicast being as reliable as unicast. IPv6 relies 
>> on this. On 802.11 this isn't the case.
>> The fact that multicast and broadcast is unreliable (not ACKed) on 
>> 802.11 is from what I can see the major cause of the unreliability 
>> problem that the mesh wifi networking protocols are trying to solve 
>> by basically only using multicast for discovery.
>>
>> The whole question is whether this should be fixed by 802.11 or if 
>> the IETF needs to (basically) abandon multicast/unicast, or if the 
>> IETF should develop a multicast->unicast replication mechanism for 
>> wifi (there is work in this area going on).
>>
>> Personally, I think 802.11 needs to fix multicast/unicast so it's 
>> reliable, or get back the IETF and say it can't be fixed and then the 
>> IETF can continue the work on multicast reduction (or workaround) even harder.
>>
>> I find the current approach of (basically) individuals within the 
>> IETF working on multicast reduction without (as far as I can see) any 
>> dialogue with 802.11 to be a non-optimal way of solving the problems we're seeing.
>>
>> --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Aug 2015 15:29:02 +0000

I could not agree more.

It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and then complain to IEEE that in fact it is not.

IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for the lack of a highly scalable Multicast service always ends up broadcasted over the whole fabric.

When Wi-Fi is confused with Ethernet and the whole multi link becomes a single layer 2 fabric, we create a crisis that will not be solved by imputing the responsibility on the other SDO.

A solution was developed in IoT were even less multicast was acceptable. 

That solution builds a multi link subnet where the Ethernet fabric is a single L2 domain but packets are routed to the wireless edges so the multicast domain is effectively split.

The mechanism is simple and proven. The AP becomes a router and Wireless devices register their IP addresses to the router very much as a STA registers its MAC address at the association time. 

6LoWPAN ND (RFC 6775) is effectively a L3 association, which is indeed the appropriate mechanism for Wi-Fi.

Based on that registration, the AP/Router can proxy ND and filter unwanted multicast. 

We have running code for that proxy on Cisco IOS routers. It is derived from earlier (shipping, widely deployed) efforts that learn the registration by snooping, but that approach yields all sorts of issues and proprietary tricks.

My suggestion is to finally recognize that Wi-Fi is not Ethernet, in particular from the perspective of multicast, and provide the appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone router discussed above is one candidate solution.

Pascal

> Le 6 août 2015 à 16:26, Mikael Abrahamsson <[email-masked]> a écrit :
> 
>> On Thu, 6 Aug 2015, Eric Gray wrote:
>> 
>> It strikes me as something of a mistake generally to assume that multicast is as reliable as
>> unicast.
>> 
>> Unicast reliability depends on the mechanism(s) used to ensure reliability.  Unicast traffic
>> tends to get lost every now and then.
> 
> Nobody doubts that packets get lost, but the general tendency since IP networking was invented, was that multicast delivery of packets wasn't especially worse than unicast. Packets get lost, but generally less than 1% get lost, and multicast and unicast are affected equally.
> 
>> All the same factors that affect unicast packet delivery also affect delivery of each packet with multicast.  Hence multicast reliability should be worse than unicast reliability by an amount roughly proportional to the amount of packet replication necessary to support it.
> 
> Hm, care to elaborate? That seems a lot worse than my experience in deploying networks would tell me.
> 
>> Each replicated packet is as likely to be lost as any unicast packet. Loss of one or more packets should be expected to be more likely with multiple packets than with a single packet.
> 
> But it's still only a single packet per link.
> 
>> Multicast reliability, even when considered at the link level and assuming replication is not required in transmission of multicast packets onto the link itself, is only slightly better.  As full-duplex, point-to-point connectivity becomes increasingly likely (fat yellow cables are relatively rare any more), data replication still occurs - just not at the level where a router sending packets onto the link is likely to be aware of it.
> 
> Correct, as of 20 years ago or something we do not use 10base5 so L2 devices do L2 replication.
> 
>> Hence it is interesting in this discussion that we are talking about an assumption that seems
>> broken at the start.
>> 
>> Have I missed something?
> 
> Well, 802.11 treats multicast (and broadcast) packets as a second rate citizen, I am not aware of any other L1/L2 technology that does this. 3GPP uses basically a point-to-point tunnel, so unicast and multicast is treated in very similar fashion without multicast being at a disadvantage.
> 
> So IETF needs to sit down and work out a strategy on how its protocols should work going forward, if everybody who designs protocols in the IETF should be told that multicast and broadcast "doesn't work properly", and act accordingly.
> 
> What probably needs to happen is that over time, the IETF should try to use less multicast, but on the other hand, 802.11 really needs to make sure that multicast works a lot better than it does today.
> 
> -- 
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 08:21:35 +0200 (CEST)

On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote:

> It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and 
> then complain to IEEE that in fact it is not.

This is an interesting viewpoint. IETF isn't "using wifi as if it was 
Ethernet". The customers who buy Wifi products buy it and run IP over it, 
expecting it should work (because that's what the advertising says). IP 
has been designed for wired ethernet (and Wifi carries ethernet frames). 
As far as I can tell, 802.11 never told the IETF that it wouldn't support 
multicast (really).

I'd say IETF isn't saying "IP works great over Wifi" (it doesn't really 
make any claims for any L1 or L2). However, I see producers of Wifi 
equipment saying that their products are great for using to connect to the 
Internet, which is saying "Wifi is great for IP".

> IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for 
> the lack of a highly scalable Multicast service always ends up 
> broadcasted over the whole fabric.
>
> When Wi-Fi is confused with Ethernet and the whole multi link becomes a 
> single layer 2 fabric, we create a crisis that will not be solved by 
> imputing the responsibility on the other SDO.

Which is exactly why I said that both SDOs need to do something. However, 
since IP was "first" I think that 802.11 should have come to IETF a long 
time ago and said that it couldn't do multicast. Basically, what I 
interpret you're saying is that Wifi in its current form isn't suited to 
carry IP the way IP has been designed, for a long time. That would be news 
for a lot of people.

> My suggestion is to finally recognize that Wi-Fi is not Ethernet, in 
> particular from the perspective of multicast, and provide the 
> appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone 
> router discussed above is one candidate solution.

It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less 
of it).

But what I hear here is that your opinion is that 802.11 doesn't need to 
change, but the IETF needs to change for IP to work over Wifi. I'd really 
appreciate some kind of official agreement from each SDOs who should do 
what. If the long-term technical solution is that the IETF should change 
L3 to basically avoid broadcast and multicast, then that's fine, as long 
as this is agreed upon by both parties.

However, I do think that 802.11 needs to point out to its members that if 
they don't implement assured multicast replication, IP doesn't work 
properly. Then they can decide what should be done in the short term, 
because changing IP will take quite a while.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 09:02:29 +0200 (CEST)

On Thu, 6 Aug 2015, Dorothy Stanley wrote:

> d) Additionally, most if not all AP vendors implement multicast - 
> unicast conversion and use it as they see the need for it.

Just for clarification, do you mean "enterprise AP vendors" or do you 
really mean "most if not all AP vendors" across the entire range? Can you 
give an example of a sub-100USD residential consumer wifi-router/AP that 
implements this?

---

From: Teco Boot <[email-masked]>
Date: Fri, 7 Aug 2015 09:22:40 +0200

I remember non-transitive on faulty 10Base2. And lack of good multicast in FR and ATM.

There is a lot of IEEE802.11 stuff that works great for large scale WISP and enterprises, but is not available in open source or cheap home routers. At my WLC enabled home, I have most of the 802.11 optimizations on my WiFi infrastructure and on my mobile gear. It has other non-standardized optimizations, such as proxy-ARP.

On voting:
  IP on WiFi: +1 for RFC 5415 & 5416. 0 to -1 for TRILL, SDN and LISP (although these have my interest).
  RP: +1 for babel. Small, simple, cheap, does what is needed. IMHO there is no choice, IS-IS will not be adopted in the 10$ market.

So what I would like to see is CapWap support in OpenWRT, with HNCP for autoconfiguration.
And babel as replacement for the proprietary AP mesh protocols, also on enterprise class AP's.

Teco

> Op 7 aug. 2015, om 08:21 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
> 
> This is an interesting viewpoint. IETF isn't "using wifi as if it was Ethernet". The customers who buy Wifi products buy it and run IP over it, expecting it should work (because that's what the advertising says). IP has been designed for wired ethernet (and Wifi carries ethernet frames). As far as I can tell, 802.11 never told the IETF that it wouldn't support multicast (really).
> 
> I'd say IETF isn't saying "IP works great over Wifi" (it doesn't really make any claims for any L1 or L2). However, I see producers of Wifi equipment saying that their products are great for using to connect to the Internet, which is saying "Wifi is great for IP".
> 
> Which is exactly why I said that both SDOs need to do something. However, since IP was "first" I think that 802.11 should have come to IETF a long time ago and said that it couldn't do multicast. Basically, what I interpret you're saying is that Wifi in its current form isn't suited to carry IP the way IP has been designed, for a long time. That would be news for a lot of people.
> 
> It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less of it).
> 
> But what I hear here is that your opinion is that 802.11 doesn't need to change, but the IETF needs to change for IP to work over Wifi. I'd really appreciate some kind of official agreement from each SDOs who should do what. If the long-term technical solution is that the IETF should change L3 to basically avoid broadcast and multicast, then that's fine, as long as this is agreed upon by both parties.
> 
> However, I do think that 802.11 needs to point out to its members that if they don't implement assured multicast replication, IP doesn't work properly. Then they can decide what should be done in the short term, because changing IP will take quite a while.
> 
> --

---

From: Steven Barth <[email-masked]>
Date: Fri, 07 Aug 2015 09:36:34 +0200

>give an example of a sub-100USD residential consumer wifi-router/AP

OpenWrt does and we have kernel patches in our repo and have that enabled by default but I am not sure if vendors who fork us chose to dis- or enable it. So can't say if any off the shelve ones do out of the box.

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 7 Aug 2015 10:44:12 -0400

Are you suggesting that IEEE and IETF send liaison letters to each other
when they begin crafting new protocols? This could possibly be useful
assuming anyone acted on it. The more likely scenario is for each SDO to
send an liaison saying ³Hey we just spent x years designing our new
protocol y, please take a look and see if your protocols both past and
present will function efficiently over it.²

In my experience there seems to be very little overlap between engineers
working in the IEEE and those working in the IETF. My company for example
has exactly zero overlap. IPv6 Multicast over IEEE 802.11 seems to be a
good example of how more interaction would be immensely useful early on in
the protocol development process. I¹m not sure there is a fix here, but it
would definitely be useful for both SDOs to keep in mind each others
protocols for interoperability purposes instead of just pointing to the
other to fix their protocols.

Customers

Jason

>because changing IP will take quite a while.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Aug 2015 04:14:06 +1200

On 08/08/2015 02:44, Weil, Jason wrote:
> when they begin crafting new protocols? 

Actually such a mechanism has existed for 15 years or so: the infamous
[email-masked] list, which I invented. It's a closed list (at this
point I forget why, but I imagine some SDOs have a complex about it)
populated by various liaisons. The theory was for SDOs to notify each
other about possibly overlapping new work in a more simple way than a
formal liaison statement. Because it's closed, I have no idea whether
there's any recent traffic.

> This could possibly be useful

... with a P.S. apologising for having forgotten to mention it x years
ago on the new-work list. Yes, that's exactly what has happened before
now.

    Brian

---

From: Dorothy Stanley <[email-masked]>
Date: Fri, 7 Aug 2015 17:24:35 +0000

I meant "enterprise AP vendors". 

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Friday, August 07, 2015 12:02 AM
To: Dorothy Stanley
Cc: Donald Eastlake; Romascanu, Dan (Dan); Glenn Parsons; Toerless Eckert (eckert); [email-masked]; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray
Subject: RE: [ieee-ietf-coord] [homenet] Despair

> unicast conversion and use it as they see the need for it.

Just for clarification, do you mean "enterprise AP vendors" or do you really mean "most if not all AP vendors" across the entire range? Can you give an example of a sub-100USD residential consumer wifi-router/AP that implements this?

---

From: Geoff Thompson <[email-masked]>
Date: Fri, 7 Aug 2015 11:09:25 -0700

What you are suggesting here is heresy.
You are saying that the basic assumption made 35 years ago,
Layering,
doesn't work.
What a surprise.
It is not only true for WiFi,
we are confronting the same problem with higher layers and applications wanting to send/receive precise timing information over the network and that capability not being supported by Ethernet.

The bottom line is that the layering that was defined so many years ago by the pioneers was imperfect.
In particular, it was highly imperfect in putting forth what was not defined in the layering model that we all have used (MoL).
It is no surprise (to me, at least) that we are running into trouble as IP over 802 is now being called upon to take over the entire communications space that was formerly occupied by the switched and decimated low-noise, low-loss links of the hard-wired and legacy telephony networks.

To that end, it has never been clear to me that you can effectively use a screwdriver to pound nails.

Geoff Thompson
"The wishes of Marketing have remarkably little to do with the laws of Physics"

> On Aug 7, 2015, at 7:44 AMPDT, Weil, Jason <[email-masked]> wrote:
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 7 Aug 2015 15:49:35 -0400

[email-masked] is alive & used for coordination and information.  We
also coordinate specifically with the IEEE on items of mutual interest
several times a year.
On Aug 7, 2015 12:13 PM, "Brian E Carpenter" <[email-masked]>
wrote:

> > This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> >

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 8 Aug 2015 07:32:21 +0200 (CEST)

On Sat, 8 Aug 2015, Pat (Patricia) Thaler wrote:

> No one is saying that 802.11 can't do multicast. It does do multicast, 
> but with more loss than the protocols sending multicast may assume or be 
> able to accommodate. As I understand the presentation that kicked off 
> this discussion, this becomes an issue since IPv6 relies more on 
> multicast.  While IP came first, IPv6 didn't.

Not only IPv6, but a lot of other protocols as well such as routing 
protocols, and content carried over multicast transport.

And well, I'd venture to say that basic 802.11 doesn't do multicast in any 
true sense of the word, I have yet to hear about anyone using 802.11 for 
instance for multicast IP video streaming. People have tried, quickly 
discovered it didn't work (for any sensible level of work, multiple 
percent packet loss doesn't count as "work" in a packet data network), and 
moved to wires instead.

> Increasing use of low power devices that have times when they "sleep" 
> and therefore miss multicasts contributes to the problem. But low power 
> use for battery or low-energy source based devices is essential. It 
> isn't going away. (Wired devices sleep to save energy too but they are 
> generally less power constrained so they are able to go into a less deep 
> sleep and can wake to receive traffic.)  And even when wireless devices 
> don't sleep, they experience varying connectivity due to movement.
>
> Pointing fingers isn't going to help this. We need to get together and 
> see what can be done to improve the situation.

Sounds good to me. I just want things to be clear to everybody since there 
is obviously a significant crowd here in the IETF that thinks multicast 
will work just fine on "all" packet transports. So 802.11 and IETF needs 
to figure out who should do what, either IETF needs to do less multicast 
in its protocols, or a workaround needs to be created to handle wifi 
networks so multicast works (done by the IETF), or 802.11 needs to fix so 
unicast and multicast works very much the same on 802.11 and then IETF 
doesn't need to change much, at least not for existing protocols.

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Sat, 8 Aug 2015 00:07:33 +0000

No one is saying that 802.11 can't do multicast. It does do multicast, but with more loss than the protocols sending multicast may assume or be able to accommodate. As I understand the presentation that kicked off this discussion, this becomes an issue since IPv6 relies more on multicast.  While IP came first, IPv6 didn't.  

Increasing use of low power devices that have times when they "sleep" and therefore miss multicasts contributes to the problem. But low power use for battery or low-energy source based devices is essential. It isn't going away. (Wired devices sleep to save energy too but they are generally less power constrained so they are able to go into a less deep sleep and can wake to receive traffic.)  And even when wireless devices don't sleep, they experience varying connectivity due to movement.

Pointing fingers isn't going to help this. We need to get together and see what can be done to improve the situation. 

Regards,
Pat

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Sat, 8 Aug 2015 00:24:03 +0000

As Alia points out, because of increasing areas where there was overlap between our work, we started coordinating more closely a few years ago.  We maintain a list of areas that we have identified as benefiting from  coordination.

We have teleconference meetings 3 times a year which include a discussion of new work for both groups. Rather than sending liaison letters back and forth, this gives the opportunity to have a brief discussion about what the new work is and whether it is something that should be added to the coordination list.

We also have the ieee-ietf-coord mailing list to discuss issues or new topics as they arise.

Regards,
Pat

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, August 07, 2015 12:50 PM
To: Brian E Carpenter
Cc: Pascal Thubert (pthubert); Toerless Eckert (eckert); [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Weil, Jason; Homenet; Eric Gray; Acee Lindem (acee); Mikael Abrahamsson
Subject: Re: [ieee-ietf-coord] New work in other SDOs [was Despair]

[email-masked]<mailto:[email-masked]> is alive & used for coordination and information.  We also coordinate specifically with the IEEE on items of mutual interest several times a year.
On Aug 7, 2015 12:13 PM, "Brian E Carpenter" <[email-masked]<mailto:[email-masked]>> wrote:

[email-masked]<mailto:[email-masked]> list, which I invented. It's a closed list (at this

    Brian

> On 8/7/15, 2:21 AM, "Mikael Abrahamsson" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 09:32:06 +0200 (CEST)

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?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 10:34:06 +0200 (CEST)

On Mon, 10 Aug 2015, Henning Rogge wrote:

> On Mon, Aug 10, 2015 at 9:32 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> 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.
>>
> Excuse me, multicast ACKs on 802.11?
>
> I know that some implementations/stacks split up multicast into
> several unicasts (which will then be acked and will have
> retransmissions), but I have yet to hear about multicast ACKs in the
> IEEE 802.11 standard.

Donald Eastlake posted this a few days ago:

"- 802.11 does have a feature called GCR -- Groupcast With Retries,
which was part of the 802.11aa amendment, although it is not widely
implemented. It includes such features as a way for the AP to send
several multi-destination frames and then, using unicast, to poll
associated stations for a bit map of which of those frames they
correctly received (BlockAck) and a feature for the AP to
spontaneously transmit a multi-destination frame more than once
without causing confusion for improved reliability."

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 08:43:07 +0000

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:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 08:32
To: Stephens, Adrian P
Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

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?

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 05:50:11 +0000

Hello all,

Let me summarise some of the characteristics of the 802.11 standard related to multicast:
1.  The basic "packet error rate" (before Ack) designed to is 10% in the case of unicast.   This is a very broad statement and almost so
simplistic as to be misleading.    Errors are composed of 1) collisions, 2) interference,  3) rate/MCS adaptation
errors,  4) sudden changes in the radio environment such as shadowing.   The residual error for unicast is less because of the retry mechanism.

2. Multicast is generally sent at a  low "basic" (one intended to be receivable by all STAs in the AP's network) rate.   This improves reliability in some of the error causes cited above, but not all. 

3. Multicast is generally not acknowledged.

4. Multicast may be buffered when power-savers are present.  An AP may discard buffered traffic due to internal resource constraints.  Buffered multicast traffic is generally delivered once per DTIM,  which is a configurable multiple of the beacon interval.
Note that the asymmetry of the buffering times might cause an AP to discard more buffered multicast traffic than unicast.  Whether it does is something I don't know,  I'm just mentioning it as a possibility.

5. When multicast is delivered using the DTIM mechanism,   a whole sequence of buffered multicast frames are transmitted using a "SIFS" gap (i.e. uninterruptable).   This reduces the probability of individual packet collision from nearby STAs.

6. The STAs associated with an AP may exhibit different reliabilities receiving multicast traffic.   Those on the edge of the AP's network will receive at lower power.  More subtly,  they may be closer to 802.11 interferers that cannot receive from the AP,  and therefore do not honour any of the protection mechanisms that might be used by the AP.

The bottom line of operating in an unlicensed medium is that nothing is predictable and there are absolutely no guarantees.

The standard contains mechanisms to improve the reliability of multicast and remove it from the DTIM buffering mechanism.

Implementations can do a multicast to unicast translation.  The standard does not support this,  but it does not prevent
it either.

The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard.
I can make time on the 802.11 meeting agenda to discuss the topic.   Dorothy Stanley is 802.11's liaison to IETF,  so if folks did
want to contribute to a discussion document,  I suggest they work with her.   Our next meeting is September 13-18.
(http://www.ieee802.org/11/Meetings/Meeting_Plan.html)

Yours sincerely,
 
Adrian P STEPHENS
Chair, IEEE 802.11 Working Group

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Pat (Patricia) Thaler
Sent: 08 August 2015 01:08
To: Mikael Abrahamsson; Pascal Thubert (pthubert)
Cc: Toerless Eckert (eckert); [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Thursday, August 06, 2015 11:22 PM
To: Pascal Thubert (pthubert)
Cc: Toerless Eckert (eckert); Alia Atlas; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; [email-masked]; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote:

> It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet 
> and then complain to IEEE that in fact it is not.

This is an interesting viewpoint. IETF isn't "using wifi as if it was Ethernet". The customers who buy Wifi products buy it and run IP over it, expecting it should work (because that's what the advertising says). IP has been designed for wired ethernet (and Wifi carries ethernet frames). 
As far as I can tell, 802.11 never told the IETF that it wouldn't support multicast (really).

> IPv6 over Ethernet makes heavy use of multicast over Ethernet, which 
> for the lack of a highly scalable Multicast service always ends up 
> When Wi-Fi is confused with Ethernet and the whole multi link becomes 
> a single layer 2 fabric, we create a crisis that will not be solved by 

But what I hear here is that your opinion is that 802.11 doesn't need to change, but the IETF needs to change for IP to work over Wifi. I'd really appreciate some kind of official agreement from each SDOs who should do what. If the long-term technical solution is that the IETF should change
L3 to basically avoid broadcast and multicast, then that's fine, as long as this is agreed upon by both parties.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:04:08 +0900

We also need to remember that from the perspective of battery-operated
devices, multicast is attractive because it's cheaper to receive
unacknowledged multicast than to receive acknowledged unicast (which
requires the hardware to transmit).

On Sat, Aug 8, 2015 at 9:07 AM, Pat (Patricia) Thaler <[email-masked]>
wrote:

> No one is saying that 802.11 can't do multicast. It does do multicast, but
> with more loss than the protocols sending multicast may assume or be able
> to accommodate. As I understand the presentation that kicked off this
> discussion, this becomes an issue since IPv6 relies more on multicast.
> While IP came first, IPv6 didn't.
>
> Increasing use of low power devices that have times when they "sleep" and
> therefore miss multicasts contributes to the problem. But low power use for
> battery or low-energy source based devices is essential. It isn't going
> away. (Wired devices sleep to save energy too but they are generally less
> power constrained so they are able to go into a less deep sleep and can
> wake to receive traffic.)  And even when wireless devices don't sleep, they
> experience varying connectivity due to movement.
>
> Pointing fingers isn't going to help this. We need to get together and see
> what can be done to improve the situation.
>
> Regards,
> Pat
>
> Cc: Toerless Eckert (eckert); Alia Atlas; Dan Romascanu (
> [email-masked]); Glenn Parsons; Homenet; [email-masked];
> Acee Lindem (acee); Eric Gray

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 10:28:15 +0200

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 10:42:40 +0200

> without causing confusion for improved reliability."

Okay...

this is quite new and I am not sure it will solve all the multicast
problems for 802.11. Neighbor discovery (both IPv6 and routing
protocol) has potentially to deal with a lot of neighbors, some of
them not even known to the transmitter. It also feels like a lot of
consumed airtime to replace a multicast with a multicast and one
unicast for each known neighbor. This could be dozens of media
accesses.

Henning Rogge

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 02:15:20 -0700

This is a nice start for what i'd call poblem 2): making
multipoint delivery of serious amount of data to more receivers more
reliable.  Would love to understand if there is any definition of how
this would or could be used for actual IP multicast, eg: where
is the definition of using IGMP membership reports to
track receivers, automatically define a GCR etc. pp ?? I'd be surprised
if 802.11 would elevate to that level... Maybe thats something we could/should do ?

But yes, this is not solution to problem 1) which is about IP signaling
protocols that currently rely on multicast. We should target something
that has a lower set of requirements against APs (like worst possible AP
needs to work for us), and we probably want to take more care of
battery. (I say probably because i still haven't seen good simple but persuasive
numbers for wifi-multicast vs. real world batery drain, so i am operation on a
faith base only here which i don't particularily like. )

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 11:26:49 +0200 (CEST)

(included [email-masked] 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.

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.

>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).

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?

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 09:39:43 +0000

Hello Mikael,

Please see my responses embedded below...

Best Regards,
 
Adrian P STEPHENS

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; [email-masked]; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11

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>

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:

> Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>
> Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; 
> [email-masked]; Dan Romascanu ([email-masked]); Glenn 
> Parsons; Homenet; Eric Gray

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 10:05:54 +0000

Hello Mikael

> 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.

Many products do that. But then people immediately think about sending unicast only to those who need the packet. Good idea isn't it? 

The basic APs will apply rules like 'oh, we do not expect a router on Wi-Fi so let's drop all RS towards wireless'. Hardcoded in the box.
Clearly, a behavior like this that is not backed by a standard, appears to be working, well, until it is no more, and at worse people may 'learn' that they cannot have routers over Wi-Fi. Damn.

More advanced and expensive devices will learn addresses from snooping various protocols and devising their own way of figuring which address (unicast, multicast) which STA is listening to. 
But a DAD may easily be missed and a state may not be created when it should have. A protocol may be misinterpreted, some bug, some new version of the protocol. A state may be kept for too long and may cause denial of service.

Because none of that is standard, different special sauces from different vendors will cause interoperation issues. Think about the impact of firewalls that we have suffered over the years, applied to the network operation down to the basic protocols.

Vendor-specific magic heuristics about how to play with snooped state that are deployed today will have unpredictable effects on new protocols in the future that expect standard behavior from deployed boxes. 

Add to that new host behaviors like rapid renewal of IP addresses for privacy reasons and you see that the good idea above was the recipe to first shoot oneself in the foot and then all the way up.

> 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).

Such a thing is just untrue. IP works on any link, it has to. That's why we do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11.
As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it.

> 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".
> 

That is not my conception of IP. That would be Inter-Some-Net protocol now.

> 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.

Not All protocols, just IP basic things like ND, and then use IP multicast routing even in a ML subnet.
For ND, it is already done for 802.15.4, RFC 6775, will need some additional stuff to make it generic Wi-Foo.

> sense and when it doesn't.

This also has already started with the efficient ND work at 6MAN and many drafts from design team members.

Cheers,

Pascal

> 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.
> 
> > " 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?"
> >
> > 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
> >> The question in my mind is whether this discussion thread is uncovering
> any new requirements for the 802.11 standard.
> >
> > 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?
> >
> > --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 12:09:26 +0200 (CEST)

> Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You are getting more than you are paying for :0).

I don't see how it's relevant that the spectrum is free? Even if this was 
done in a licensed spectrum I would still get 10% packet loss because 
multicast isn't ACKed, right?

> Moving the duplication into the IP layer ensures uninformed decisions.

That's my opinion as well. Thanks for confirming it.

> 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.

Well, since it seems 802.11 has mechanisms to make multicast delivery 
decently reliable, it seems it would be suited if the implementation 
actually included that mechanism. If it's omitted by the implementor, it's 
not. Currently I have no idea if my home network includes GCR or not. I 
also don't know if GCR needs client support.

> If has,  after all,  already done this twice.

What do you mean "specially"? What I've been bringing up is not to treat 
it specially, it's to treat it so that it works similarily to unicast. 
>From my point of view, without the GCR or similar mechanism, multicast is 
treated specially, ie it's being treated worse than unicast.

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

I have no history on this kind of subject, someone who has been involved 
in 802.11 perhaps could make an educated guess and share an opinion on 
what might be the path that has the best odds to succeed?

http://eprints.networks.imdea.org/275/1/L.%20Eznarriaga-MsC%20Thesis-September%202011.pdf

Btw, could you confirm that GCR in 802.11aa is something that is needed in 
both AP and clients to work? It seems like it would need to be. How widely 
implemented is it in clients? Is this a hardware issue or driver issue? 
Does the operating system need to support it as well?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 12:15:58 +0200 (CEST)

> As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it.

Yes, but what about when multicast is there but it's less reliable 
compared to unicast? Is this also IPs problem?

Again, if if's IPs problem then if 802.11 would just clearly state that 
this is the case, then we have a way forward. I just hope 802.11 
understand that it'll see a lot more unicast coming its way and be 
prepared to handle it.

> This also has already started with the efficient ND work at 6MAN and many drafts from design team members.

Remember to get IETF chair to say this and give this as a clear 
directional statement how things should be done going forward, just the 
same way it's been said regarding security and encryption. I have little 
problem with this approach as long as we have consensus that this is the 
way things should be done.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 03:26:59 -0700

Pascal:

> Clearly, a behavior like this that is not backed by a standard, appears to be working, well, until it is no more, and at worse people may 'learn' that they cannot have routers over Wi-Fi. Damn.

Do we have a hall of shame somewhere for such behavior ? Would like to know
what AP to avoid ;-)

> But a DAD may easily be missed and a state may not be created when it should have. A protocol may be misinterpreted, some bug, some new version of the protocol. A state may be kept for too long and…

Right. That multicast to unicast conversion is all non-standard, and at it's
best most likely only working (well?) for actual media streaming, not signaling.

> As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it.

Right... if it can. But its a bit a question what device-model we want to
expect. I fear that the worst possible device model is something like
a homenet router with an L3 interface that is bridged by a featureless L2
switch chip onto multiple wired ports, one of which is connecting to a
bad L2 WiFi-AP. On the othrer hand is the homenet AP where the IPv6 layer
can query per-client WiFi information from L2. So, which device model
do we want to build out a solution for ?

Btw: my answer: I wish we could move the industry to the latter, but i fear
for early adoption we need to support the first too.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 10:43:56 +0000

> >> statement that multicast is an integral part of IP networking, and if
> >> a medium doesn't support delivering multicast frames in a similarily
> > Such a thing is just untrue. IP works on any link, it has to. That's why we
> do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11.
> > As for protocols that rely on IP multicast, it's IP's problem. If the
> underlying link layer does not have multicast, it is IP's responsibility to
> emulate it.
> 
> Yes, but what about when multicast is there but it's less reliable compared
> to unicast? Is this also IPs problem?

Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 mechanisms or not.

If not, a router learns from MLD the state it needs to figure to which devices it should copy a given packet.

For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea. 

Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is routed. Many LLNs work like this. Why should Wi-Fi be an exception?

> 
> Again, if if's IPs problem then if 802.11 would just clearly state that this is
> the case, then we have a way forward. I just hope 802.11 understand that
> it'll see a lot more unicast coming its way and be prepared to handle it.
 
I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does not seem to work either. 

The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join the effort so we do the job right.

Cheers,

Pascal

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 13:03:08 +0200 (CEST)

> Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 mechanisms or not.

Ok, so am I interpreting you correctly that there are three profiles for 
L1/L2 mediums:

1. Multicast works approximately the same way as unicast (packet loss)
2. Multicast works worse than unicast and should be minimized
3. Multicast not supported

So what we're missing is taking into account the #2 profile in the IETF, 
because so far we've only really understood that #1 and #3 exists?

> For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea.

But I keep hearing from the 802.11 experts (at least they seem to be) that 
there are 802.11 mechanisms that seem to make multicast work well enough 
and that there are power upsides to using multicast?

> Rather, a good idea could be to build a multilink subnet with APs that 
> are also routers to serve the wireless edge, whereby the Ethernet 
> backbone can rely on L2 broadcast while the wireless edge is routed. 
> Many LLNs work like this. Why should Wi-Fi be an exception?

Well, I am not wireless expert, I don't know if it makes more sense to 
treat each device to its own subnet and thus send RAs to each and every 
one of them as needed, or if it makes sense to have some kind of multicast 
mechanism and make sure that they all get this multicast packet in a 
shared subnet. Your suggestion seems perfectly fine for me from an IP 
point of view, actually I prefer that option as well. Basically each host 
has its own /64.

> I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE 
> to do an immensely scalable L2 multicast support so that Solicited Node 
> Multicast appears so cool on a switched fabric? Does not seem to work 
> either.
>
> The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo 
> in general which would be my take. And then the IETF has to decide if it 
> wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may 
> join the effort so we do the job right.

Are there more types of profiles we need? Does it make more sense to send 
a multicast packet if there are more (or less) than X nodes in a subnet, 
send unicast to each and every one of them if it's less (or more) than Y. 
Should each individual device be able to say what it prefers in case we're 
mixing battery powered devices and wired devices in the same place?

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 09:30:01 +0000

Hello all,

“it's cheaper to receive unacknowledged multicast than to receive acknowledged unicast (which requires the hardware to transmit)”
I’m afraid this is not necessarily so.
The rate at which multicast is sent is usually a “basic” rate – such as 24 Mbps.
The rate at which unicast is received might be 250 Mbps.   So, depending on the length of data,  and the relative
platform power consumptions of tx vs rx vs idle vs asleep,  unicast may or may not be a lower power consumption.

Best Regards,

Adrian P STEPHENS

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 10 August 2015 09:04
To: Pat (Patricia) Thaler
Cc: Pascal Thubert (pthubert); Toerless Eckert (eckert); [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray; Mikael Abrahamsson
Subject: Re: [ieee-ietf-coord] [homenet] Despair

We also need to remember that from the perspective of battery-operated devices, multicast is attractive because it's cheaper to receive unacknowledged multicast than to receive acknowledged unicast (which requires the hardware to transmit).

On Sat, Aug 8, 2015 at 9:07 AM, Pat (Patricia) Thaler <[email-masked]<mailto:[email-masked]>> wrote:
No one is saying that 802.11 can't do multicast. It does do multicast, but with more loss than the protocols sending multicast may assume or be able to accommodate. As I understand the presentation that kicked off this discussion, this becomes an issue since IPv6 relies more on multicast.  While IP came first, IPv6 didn't.

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mikael Abrahamsson
Sent: Thursday, August 06, 2015 11:22 PM
To: Pascal Thubert (pthubert)
Cc: Toerless Eckert (eckert); Alia Atlas; Dan Romascanu ([email-masked]<mailto:[email-masked]>); Glenn Parsons; Homenet; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

[email-masked]<mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 18:33:01 +0900

Sure, but for small packets, it's pretty unlikely that unicast would be
cheaper. An RA will likely only be 100 or 200 bytes.

On Mon, Aug 10, 2015 at 6:30 PM, Stephens, Adrian P <
[email-masked]> wrote:

> Hello all,
>
>
>
> “it's cheaper to receive unacknowledged multicast than to receive
> acknowledged unicast (which requires the hardware to transmit)”
>
> *From:* ieee-ietf-coord [mailto:[email-masked]] *On
> Behalf Of *Lorenzo Colitti
> *Sent:* 10 August 2015 09:04
> *To:* Pat (Patricia) Thaler
> *Cc:* Pascal Thubert (pthubert); Toerless Eckert (eckert);
> Parsons; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray; Mikael
> Abrahamsson
>
> *Subject:* Re: [ieee-ietf-coord] [homenet] Despair
>
>
>
> On Sat, Aug 8, 2015 at 9:07 AM, Pat (Patricia) Thaler <
> [email-masked]> wrote:
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 13:19:16 +0200

> cheaper. An RA will likely only be 100 or 200 bytes.

First 802.11 has aggregation, so it is possible to combine the unicast
media access with other outgoing unicasts.

There is also multi-user MIMO coming, which means a AP can talk to
several other stations simultaneously.

Both factors can make multiple short unicast frames more efficient
than a single multicast, but only the linklayer has enough information
to decide this.

Henning Rogge

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 11:36:59 +0000

Unsure about your profile, Mikael. Ethernet would be a #2 by now, only things like sat-links could still be  #1s. So the work would really be to figure out what to do with the varieties of your #2. My question is rather whether IP over 802.11 should be operated like IP over Ethernet or like IP over 802.15.4.

Trouble is, some multicast ore more important than others. E.g. you miss an RA, usually no harm done, wait for the next or RS to force one. You missed a DAD, the protocol failed. If we start retrying DADs, we make the broadcast situation even worse. So to your point about energy, Wi-Foo may decide to broadcast some messages, unicast others multiple times, and at some point change the IP protocols so that the protocols operate differently. 

The IETF already made these steps for 802.15.4. RAs are still broadcasted but DAD was changed to be reliable and unicast-based.

The multilink subnet is not one /64 per wireless device as you indicate. That model certainly works too, and was deployed, but with it,  a set of 64 bits identifies and routes to a device, so we are mostly back to a world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 32.

The multilink subnet is a single large subnet encompassing the whole ESS, Ethernet  + Wi-Fi. It is really a Layer-3 ESS, based on the same ideas as the Layer-2 is.

In that model, the association of a wireless device associates the IP unicast and multicast addresses with the MAC address, and the AP acts as a router and performs proxy ND over the Ethernet backbone on behalf of the wireless devices. That way, the ND NS are never multicast over the wireless. In practice, the association of IP addresses should be done as part of ND, and that is what RFC 6775 does.
 
Cheers,

Pascal

Cheers,

Pascal

> Sent: lundi 10 août 2015 13:03
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; Dan Romascanu ([email-masked])
> <[email-masked]>; Stephens, Adrian P
> <[email-masked]>; Glenn Parsons
> <[email-masked]>; [email-masked]; Homenet
> <[email-masked]>; Eric Gray <[email-masked]>
> Subject: RE: [ieee-ietf-coord] Multicast on 802.11
> 
> 1. Multicast works approximately the same way as unicast (packet loss) 2.
> Multicast works worse than unicast and should be minimized 3. Multicast
> not supported
> 
> there are 802.11 mechanisms that seem to make multicast work well
> enough and that there are power upsides to using multicast?
> 
> Well, I am not wireless expert, I don't know if it makes more sense to treat
> each device to its own subnet and thus send RAs to each and every one of
> them as needed, or if it makes sense to have some kind of multicast
> mechanism and make sure that they all get this multicast packet in a shared
> subnet. Your suggestion seems perfectly fine for me from an IP point of
> view, actually I prefer that option as well. Basically each host has its own
> /64.
> 
> > I'd hate this, IEEE telling IETF what to do. Just like IETF telling
> > IEEE to do an immensely scalable L2 multicast support so that
> > Solicited Node Multicast appears so cool on a switched fabric? Does
> > not seem to work either.
> >
> > The IETF has to decide if it wants to design IP over 802.11 - or
> > Wi-Foo in general which would be my take. And then the IETF has to
> > decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE
> > people may join the effort so we do the job right.
> 
> a multicast packet if there are more (or less) than X nodes in a subnet, send
> unicast to each and every one of them if it's less (or more) than Y.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 13:54:26 +0200 (CEST)

On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:

> Unsure about your profile, Mikael. Ethernet would be a #2 by now, only 
> things like sat-links could still be #1s. So the work would really be to

I don't agree, wired ethernet is still #1 if you ask me.

> figure out what to do with the varieties of your #2. My question is 
> rather whether IP over 802.11 should be operated like IP over Ethernet 
> or like IP over 802.15.4.

That is a good question.

> The multilink subnet is not one /64 per wireless device as you indicate. 
> That model certainly works too, and was deployed, but with it, a set of 
> 64 bits identifies and routes to a device, so we are mostly back to a 
> world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 
> 32.
>
> The multilink subnet is a single large subnet encompassing the whole 
> ESS, Ethernet + Wi-Fi. It is really a Layer-3 ESS, based on the same 
> ideas as the Layer-2 is.
>
> In that model, the association of a wireless device associates the IP 
> unicast and multicast addresses with the MAC address, and the AP acts as 
> a router and performs proxy ND over the Ethernet backbone on behalf of 
> the wireless devices. That way, the ND NS are never multicast over the 
> wireless. In practice, the association of IP addresses should be done as 
> part of ND, and that is what RFC 6775 does.

Ok, thanks for explaining what you meant in more detail. I think I got it 
now.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 16:01:17 +0200

Henning Rogge

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Mon, 10 Aug 2015 18:41:42 +0000

There are potentially ways of addressing higher loss rates for multicast that should be explored before going to replicated unicast.

>...  I have yet to hear about anyone using 802.11 for 
> percent packet loss doesn't count as "work" in a packet data network,) and
> moved to wires instead. ...

There are different use cases with different requirements on the underlying network. The needs and constraints of video streaming are different than those of protocols such as ND (neighbor discovery). The solutions that work for one may not apply to the other. 

For example, I can think of approaches to the problem:
> If you miss a couple of consecutive RAs in IPv6, you abandon your prefix 
> and your default route.
which wouldn't apply at all to video streaming. On the other hand, potentially work done in DetNet could help with video streaming but might not be a good fit for the use of multicast to maintain IPv6.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 10 Aug 2015 14:48:49 -0400

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" <[email-masked]>
wrote:

> Cc: [email-masked]; Dan Romascanu ([email-masked]); Glenn
> Parsons; [email-masked]; Homenet; Eric Gray
> Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You
> are getting more than you are paying for :0).
>
>
> 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
> 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>
>
>
>
> 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".
>
> > " For me, it seems these 802.11 broadcast/multicast ACK functions should
> > The second is certification.  This is the not-so-simple task of
> persuading a sufficient number of WiFi-Alliance members

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 10 Aug 2015 20:05:11 +0200

> Such a thing is just untrue. IP works on any link, it has to. That's why
> we do IP over Foo.

Agreed, IP is supposed to work on anything from 10Gb/s fiber to carrier
pigeons.  The market has chosen, IP has eaten all of the protocols that
required special support from the link layer.  If a link layer doesn't
fit, we design an adaptation shim (I'm looking at you, ARCNET).

However, this doesn't prevent us from giving advice to link layer
designers for best IP performance.  RFC 3819 (BCP 89) has the following to
say:

   Subnetworks using shared channels (e.g., radio LANs, Ethernets) are
   especially suitable for native multicasting, and their designers
   should make every effort to support it.

Since RFC 3819 is mostly concerned about avoiding receiving unwanted
multicast, it doesn't say anything about the performance of multicast
itself.  Is an update needed?

-- Juliusz

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2015 19:58:16 -0500

On Aug 10, 2015, at 1:05 PM, Juliusz Chroboczek <[email-masked]> wrote:

> multicast,

I don't know why you would get that impression. I helped write that section (as noted in sec 19). Native L2 multicast should be supported exactly because it's useful to IP, as noted here:

---
Multicasting is considerably more efficient when a subnetwork explicitly supports it.
---

Joe

> it doesn't say anything about the performance of multicast

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 11 Aug 2015 11:00:36 -0500

On Fri, Aug 7, 2015 at 7:24 PM, Pat (Patricia) Thaler <[email-masked]>
wrote:

> As Alia points out, because of increasing areas where there was overlap
> between our work, we started coordinating more closely a few years ago.  We
> maintain a list of areas that we have identified as benefiting from
>  coordination.
>
>
>
> We have teleconference meetings 3 times a year which include a discussion
> of new work for both groups. Rather than sending liaison letters back and
> forth, this gives the opportunity to have a brief discussion about what the
> new work is and whether it is something that should be added to the
> coordination list.
>
>
>

I might also immodestly point out that the IAB and IEEE 802 recently
revised the document that describes the relationship between IEEE 802 and
the IETF. It's http://tools.ietf.org/html/rfc7241, and describes a fair
amount of what's being explained in this thread.

And one of the reasons for doing the revision was that not many people
actively participate in both SDOs on the same topic at the same time.

Spencer

> Behalf Of *Alia Atlas
> *Sent:* Friday, August 07, 2015 12:50 PM
> *To:* Brian E Carpenter
> Parsons; Weil, Jason; Homenet; Eric Gray; Acee Lindem (acee); Mikael
> Abrahamsson
> *Subject:* Re: [ieee-ietf-coord] New work in other SDOs [was Despair]
>
>
>
> >>> and
> >>> for

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:08:27 -0700

> If not, a router learns from MLD the state it needs to figure to which devices it should copy a given packet.

Well, the problem with WiFI is that L2 multicast  are useful under some
conditions and not useful under others. And the conditions are more
complex than boolean ;-)

> For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea. 

Pretty sure you don't mean that. If you would eliminate ALL multicast, you
didn't have discovery of new devices.

> Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is…

Thats why i asked what device model we need. Don't think i got an
answer for that though. L3 homenet APs would be lovely. But will it
be sufficient to ONLY support those theoretical devices in homenet ?

> I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does…

Sure.

> The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet.…

Getting IPv6 link signaling work with WiFi sucking L2 multicast
is just a bit of work in the L2 IPv6 protocols that can be done
IMHO without botrhering IEEE. Getting streaming multicast work 
best requires more L2 awareness and it doesn't seem homenet
is interested in thast anyhow, so i think we're only going to get
a solution for the L2 IPv6 signaling piece realistically in the
IETF alone.

Cheers
    toerless

---

From: Alia Atlas <[email-masked]>
Date: Tue, 11 Aug 2015 12:15:49 -0400

Can we please remove [email-masked] from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a
good time to interact,
but I think this conversation is really not the point of that list.

It's already cc'd to mboned and homenet...

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert <[email-masked]> wrote:

> > For Wi-Fi, there is no multicast support and it is sufficiently clear
> now that relying on broadcast is not a good idea.
>
> are also routers to serve the wireless edge, whereby the Ethernet backbone
> can rely on L2 broadcast while the wireless edge is routed. Many LLNs work
> like this. Why should Wi-Fi be an exception?
>
> wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join
> the effort so we do the job right.
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:28:54 -0700

> 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…

When replacing multicast with unicast its not necessary to replicate,
you can instead use different protocol mechanisms too, eg: client/server
communications. Especailly wrt to the p2p duplicate address detection.

> between unicast and multicast.

For the signaling that IPv6 needs it looks like a lot of waste of
complex L2 tracking (like those protected GCR's) to create reliability.

> Moving the duplication into the IP layer ensures uninformed decisions.

Yes, but only about optimizations unnecessary for signaling. Which is
why i said we should be more specific about what use of multicast
we're talking about: signaling or media. They need different
solution approaches IMHO.

> 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…

Yeah, that doesn't work.

> 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 a…

Yes, for IPv6 L2 signaling.

> 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.

That too.

Cheers
    Toerless

> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 11 Aug 2015 19:34:18 +0200

I'm removing from CC the people who I know are on Homenet, please do the
same with the other lists.

> I don't know why you would get that impression. I helped write that
> section (as noted in sec 19). Native L2 multicast should be supported
> exactly because it's useful to IP, as noted here:
> 
> ---

Perhaps I misread this section, but the impression I get is that it is
concerned about avoiding waking nodes and avoiding duplicate
transmissions.  I doesn't read like the authors are thinking about
networks where multicast has higher packet loss and lower throughput than
unicast, which is what concerns us here.

I'd love to be proved wrong.

-- Juliusz

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 13:59:15 -0700

On 8/11/2015 10:34 AM, Juliusz Chroboczek wrote:
> Perhaps I misread this section, 

Are you referring to RFC3819?

> but the impression I get is that it is
> transmissions.

This is incorrect. The section is basically saying "IP works better when
L2 supports multicast so L3 (IP) doesn't have to emulate it".

The assumption is that L2 will do a reasonably good and efficient job of
multicast/broadcast - certainly better than L3 or other layers would.

> I doesn't read like the authors are thinking about

The point of that section is that IP is more complex when it has to
emulate something that L2 doesn't provide. If it's more efficient to
implement L2 multicast via serial copy than by shared channels, that's
L2's decision.

The point of the RFC is to NOT make this the job of L3. L3 is a bad
place to support multicast or broadcast on subnets.

Joe

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 21:44:24 +0000

RE: RFC3819

> multicast/broadcast - certainly better than L3 or other layers would.

What I think Juliuz is trying to point out is that the RFC doesn't talk about how good the performance of L2 multicast needs to be - for instance in terms of BER/packet loss. It does talk about the impact of BER on TCP throughput, but not on multicast. 

How good an error rate do the IPv6 related multicasts need?

Adrian summarized the causes of packet loss:
"1.  The basic "packet error rate" (before Ack) designed to is 10% in the case of unicast.   This is a very broad statement and almost so
simplistic as to be misleading.    Errors are composed of 1) collisions, 2) interference,  3) rate/MCS adaptation
errors,  4) sudden changes in the radio environment such as shadowing.   The residual error for unicast is less because of the retry mechanism.

...." 

If it takes two missed RAs to decide that you aren't connected to the router any more, that has about a 1% chance of happening with a 10% packet error rate (though the multicast error rate is probably somewhat better since it is sent at the lower rate). This assumes that the error probability for the two RAs is independent; they occur far enough apart in time that this doesn't seem unreasonable. 
 
Why does it take two lost RAs rather than one? Presumably because the protocol assumes that sometimes an RA is lost, just not with as high a probability as 10%.

1% seems high - how good does it need to be for acceptable behavior? One could improve the behavior by adjusting parameters so that more than 2 had to be lost. Of course there is a tension between bandwidth for multicast heartbeats, wanting to detect reasonably quickly that the device is no longer on the subnet (e.g. because it is mobile), and not losing the context unnecessarily.

Without guidance on how good the multicast packet loss rate should be, it is difficult to define the best solution .

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 21:46:43 +0000

I think it is useful for [email-masked]<mailto:[email-masked]> to be in the conversation. Some of the participants in the discussion are on that reflector and I don’t know that they are on homenet or mboned.

Pat

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, August 11, 2015 9:16 AM
To: Toerless Eckert
Cc: [email-masked]; Homenet; [email-masked]
Subject: Re: [ieee-ietf-coord] [homenet] Multicast on 802.11

Can we please remove [email-masked]<mailto:[email-masked]> from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a good time to interact,
but I think this conversation is really not the point of that list.

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Sure.

Cheers
    toerless

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:54:01 -0700

On 8/11/2015 2:44 PM, Pat (Patricia) Thaler wrote:
> What I think Juliuz is trying to point out is that the RFC doesn't
> talk about how good the performance of L2 multicast needs to be -
> for instance in terms of BER/packet loss. It does talk about the
> impact of BER on TCP throughput, but not on multicast.

Agreed.

> How good an error rate do the IPv6 related multicasts need?

I would expect that depends on the use, e.g., DAD would be different
than streaming multimedia.

> If it takes two missed RAs to decide that you aren't connected to
> the router any more, that has about a 1% chance of happening with a 10%
> packet error rate (though the multicast error rate is probably
> somewhat better since it is sent at the lower rate). This assumes that
> the error probability for the two RAs is independent; they occur far
> enough apart in time that this doesn't seem unreasonable.
> 
> Why does it take two lost RAs rather than one? Presumably because
> the protocol assumes that sometimes an RA is lost, just not with as
> high a probability as 10%.
> 
> 1% seems high - how good does it need to be for acceptable behavior? 
> One could improve the behavior by adjusting parameters so that more
> than2 had to be lost. Of course there is a tension between bandwidth
> formulticast heartbeats, wanting to detect reasonably quickly that
> thedevice is no longer on the subnet (e.g. because it is mobile), and
> notlosing the context unnecessarily.
> 
> Without guidance on how good the multicast packet loss rate should
> be, it is difficult to define the best solution .

While I agree with your conclusion, what's the alternative if there is
no L2 multicast?

I think you're arguing for more specific guidance on acceptable packet
loss rates for various uses of multicast, but that might be out of scope
for RFC3819 (even as a -bis). I gave it a quick scan, and as I checked
(and recall) RFC3819 doesn't make specific recommendations on BER for
unicast either. It says that the BER needed depends on the use, and that
can affect the efficiency of L3. The same is true for multicast, but
that doc is not the place for a specific recommendation.

Joe

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 22:32:35 +0000

Joe, 

I'm mainly concerned in this discussion on what error rate is needed for acceptable performance of the protocols that support IPv6 - e.g. DAD, RA. Streaming multimedia is a separate discussion since different solutions might apply to it. 

> While I agree with your conclusion, what's the alternative if there is

802.11 does have L2 multicast. It just doesn't provide for L2 ack and retry for L2 multicast (at least in its basic form, there is a recent optional extension for that) so the packet loss can be higher than that for unicast.

> that doc is not the place for a specific recommendation.

I don't think advice on that would be out of place as "Advice for Internet Subnetwork Designers" if it is what is needed to make IPv6 work well. People here have expressed consternation that 802.11 doesn't have good enough performance for that, but how can you expect subnets to provide that performance  when the need hasn't been included in the advice.

Even if the number doesn't get put into an RFC3819-bis, it would be useful to have a number so that solutions can be examined.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 12 Aug 2015 07:31:27 +0000

On 12/08/15 07:51, "homenet on behalf of Henning Rogge"
<[email-masked] on behalf of [email-masked]> wrote:
>
>The problem is we are dealing with more and more wireless devices, so
>the medium starts to become congested more easily.
>
>0.1% - 1% packet loss (not frame loss) is possible for unicast, but
>0.1% multicast packet loss is unrealistic.

Some empirical measurements done on large WLAN are worse than those
numbers: range of 10% to 20% of mcast packets lost...

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Aug 2015 10:42:24 -0700

Hi

> numbers: range of 10% to 20% of mcast packets lost...

In this case I guess there might be such a big loss for unicast at the
radio layer (or what you call it) as well. It's just that there is
retransmission for lost unicast. The long delay may become an issue for TCP
and unicast streaming though.

Stig

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 11:23:29 -0700

On 8/11/2015 3:32 PM, Pat (Patricia) Thaler wrote:
> Joe, 
> 
> I'm mainly concerned in this discussion on what error rate is needed
> for acceptable performance of the protocols that support IPv6 - e.g.
> DAD, RA. Streaming multimedia is a separate discussion since different
> solutions might apply to it. 

Sure.

> 802.11 does have L2 multicast. It just doesn't provide for L2 ack 
> and retry for L2 multicast (at least in its basic form, there is a
> recent optional extension for that) so the packet loss can be higher
> than that for unicast.

Understood, but again, what's the alternative?

> I don't think advice on that would be out of place as "Advice for
> Internet Subnetwork Designers" if it is what is needed to make IPv6 work
> well. People here have expressed consternation that 802.11 doesn't have
> good enough performance for that, but how can you expect subnets to
> provide that performance when the need hasn't been included in the advice.

That's true, but specific protocol behaviors do address this issue
already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs.

DAD is a "negative information" protocol, i.e., a lossy link can give a
false positive. This issue is already addressed Sec 4.4 of RFC 4429: the
effect of L2 losses can be mitigated by recommending a different value
for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this
parameter might need to be defaulted to a different value for particular
link types, and such might need to be the case for 802.11.

> Even if the number doesn't get put into an RFC3819-bis, it would be
> useful to have a number so that solutions can be examined.

For this protocol mechanism, the numbers are a relationship:

	L2 mcast loss rate vs. DupAddrDetectTransmits value

IMO, it'd be a lot easier to increase DupAddrDetectTransmits than to
assume 802.11 would lower the L2 mcast loss rate.

Joe

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Aug 2015 16:17:15 +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:[email-masked]] On Behalf Of Alia Atlas
Sent: lundi 10 août 2015 20:49
To: Adrian P Stephens <[email-masked]>
Cc: [email-masked]; Dan Romascanu ([email-masked]) <[email-masked]>; Glenn Parsons <[email-masked]>; [email-masked]; Homenet <[email-masked]>; Mikael Abrahamsson <[email-masked]>; Eric Gray <[email-masked]>
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" <[email-masked]<mailto:[email-masked]>> wrote:
Hello Mikael,

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)

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

(included [email-masked]<mailto:[email-masked]> and also changed subject to something more
appropriate)

[Adrian P Stephens]

[Adrian P Stephens]

[Adrian P Stephens]

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

> [email-masked]<mailto:[email-masked]>; Dan Romascanu ([email-masked]<mailto:[email-masked]>); Glenn