Subject: Re: [homenet] 802.11 is just fine for IPv6 [was: Despair]

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 1 Sep 2015 13:21:21 +0200

Le 07/08/2015 09:36, Juliusz Chroboczek a écrit :
>> 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.
>
> That's an overstatement.  IPv6 works just fine over 802.11,

IPv6 works fine over 802.11 but it is not documented.

IPv6 works fine over 802.3 Ethernet and _is_ documented - RFC 2464.

There is an adaptation layer between 802.3 and 802.11 that is ignored in
general.  The only place where that is described is an old draft I
co-auhtored earlier that I need to update.

> it just suffers from increased multicast packet loss and lower rate.
> I don't think there's anything in the IPv6 architecture that requires
> (link-local) multicast performance to match unicast performance.

There is something in the IPv6 multicast architecture that requires the 
link-layer to be multicast-capable.  That thing is the link-layer 
multicast address (replacing the earlier link-layer broadcast address).

IPv6 does not work on EThernet-like links which do not support 
link-layer multicast addresses.

(I use the term "link-layer", not "link-local", on purpose).

> While it would be nice to have better multicast performance, I don't
> think it's productive to be overly alarmist ("IPv6 obsolete before it
> gets deployed, according to IETF spokesperson.  News at eleven.").

_more_ news at eleven :-)

Alex

>
> -- Juliusz
>
> _______________________________________________ homenet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 1 Sep 2015 13:50:03 +0200

Le 12/08/2015 07:17, Mikael Abrahamsson a écrit :
> On Tue, 11 Aug 2015, Pat (Patricia) Thaler wrote:
>
>> Without guidance on how good the multicast packet loss rate should be,
>> it is difficult to define the best solution .
>
> I'd say most applications people actually use start behaving very badly
> around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really
> get affected etc. I'd imagine most people I interact with that design
> protocols design protocols have in their mind that the packet loss rate
> is around this level, not higher.
>
> So for me, the "contract" that 802.11 needs to fulfil for the IETF not
> to start looking into changing IP for 802.11, is for 802.11 networks to
> deliver broadcast and multicast packets with around 0.1% packet loss (or
> less) as a design goal for normal operations.

In addition to treating 'multicast' in terms of delivery, reading as 
'multi-media', I think we should think of multicast in terms of a 
mechanisms, as well.

The mechanisms to build multicast paths are essential prior to 
delivering multimedia data in an efficient manner.

The mechanisms include multicast tree building protocols, filtering, and 
more.

I believe that IETF has a rich set of multicast mechanisms, whereas IEEE 
only has filters.  I may be wrong though.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 1 Sep 2015 13:53:21 +0200

Donald,

Thanks for the mentioning of 802.11aa, GCR, and transmission rates to
multi-destination.

Other than these delivery mechanisms, is there something at IEEE 802.11
about building paths to be used for delivery?

I am thinking of a potential IEEE 802.11 Management Frame which
expresses interest in joining multicast groups (akin to an IP MLD
REPORT) - does such thing exist?

Alex

Le 06/08/2015 16:01, Donald Eastlake a écrit :
> 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:
>> 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]
>>
>> _______________________________________________ ieee-ietf-coord
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 1 Sep 2015 13:56:58 +0200

There is a WG item in v6ops WG which tells the Access Point should 
unicast RAs to battery-powered Clients rather than multicasting it, 
because the observation is that it consumes power on the smartphone.

That's an observation reflected in more places.

The solution space is the following:
- practice recommendation to turn-off 'multicast' on WiFi.
- L2 multicast mechanisms using filters.
- L2 multicast mechanisms using messages.

There is nothing else in that space.

Alex

Le 10/08/2015 20:48, Alia Atlas a écrit :
> 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,
>
>     Please see my responses embedded below...
>
>     Best Regards,
>
>     Adrian P STEPHENS
>
>     Tel: +44 (1793) 404825 <tel:%2B44%20%281793%29%20404825> (office)
>     Tel: +1 (971) 330 6025 <tel:%2B1%20%28971%29%20330%206025> (mobile)
>
>     ----------------------------------------------
>     Intel Corporation (UK) Limited
>     Registered No. 1134945 (England)
>     Registered Office: Pipers Way, Swindon SN3 1RJ
>     VAT No: 860 2173 47
>
>     -----Original Message-----
>     From: ieee-ietf-coord [mailto:[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)
>
>     As far as I can tell, so far people have told IETF it's their job to
>     reduce multicast to make IP based protocol "work" on 802.11 media.
>     That's at least what I have been seeing. Considering the reactions
>     from other parties, it seems the "multicast sucks on 802.11" is
>     something 802.11 hasn't heard of before.
>
>     [Adrian P Stephens]
>     This problem is nothing new.  We know about the relative performance
>     of multicast vs unicast.
>     Saying it "sucks" is not very helpful.   Unlicensed spectrum is
>     free.  You are getting more than you are paying for :0).
>
>
>     The only thing IETF can do is to use less multicast, and the obvious
>     way of solving it is to just replicate into unicast. This seems like
>     a suboptimal way to work around the problem if there are a lot of nodes.
>
>     [Adrian P Stephens]
>     The technical solution is surely to add a class of service
>     specification to multicast packs that indicates their sensitivity to
>     loss.
>     The point is that the AP is in possession of a lot of data about
>     individual nodes that may help it make an informed decision
>     between unicast and multicast.
>
>     Moving the duplication into the IP layer ensures uninformed decisions.
>
>
>      >From what I read below, one way out of this is the IETF making a clear
>     statement that multicast is an integral part of IP networking, and
>     if a medium doesn't support delivering multicast frames in a
>     similarily reliable fashion to unicast, it's not suited to carrying
>     IP based protocols (or any other protocol that uses L2
>     broadcast/multicast).
>
>     [Adrian P Stephens]
>     <irony type="british; very-subtle">
>     I'm guessing you will be the first to turn off the 802.11 networking
>     on your devices when the IETF makes such a statement.
>     </irony>
>
>
>
>     It seems to me that there are a few paths that the IETF could go:
>
>     Write an RFC stating requirements on L1/L2 protocols when it comes
>     to unicast, multicast and broadcast handling of packets. This could
>     include options for mechanisms that turned multicast/broadcast into
>     unicast that certain medias could have as requirements. Then IEEE
>     could create a device profile that would fulfil these requirements,
>     possibly add a certification, and then try to get market pressure to
>     require devices to support this profile. The IETF wouldn't change
>     its mind about how multicast is used in its protocols after this,
>     but just say "this is the reality, please deal with it when you
>     create L1/L2 that's supposed to carry IP".
>
>     Or the IETF could just say that this seems like a lost cause,
>     multicast/broadcast doesn't seem to work on some L1/L2, and start
>     working on techniques that minimizes broadcast/multicast and change
>     all the protocols to reflect this new reality.
>
>     Something in the middle, but anyway changing the requirements on
>     IETF protocols to avoid using multicast if it can, documenting where
>     it makes sense and when it doesn't.
>
>     Right now what I am seeing is that there are people who are lobbying
>     to do away with multicast as much as possible because they see that
>     in reality it's not reliable on the devices they have tested it on.
>
>     What are the odds that 802.11 could agree on a device profile for
>     "IP use"
>     that would include reliable multicast delivery, and one that there
>     is reasonable belief that this would gain significant market adoption?
>     [Adrian P Stephens]
>     As I indicated in my earlier post,  there are multiple actors here.
>     The odds are pretty good that 802.11 will respond to a clear
>     requirement to handle multicast specially.
>     If has,  after all,  already done this twice.
>
>     What are the odds that the WFA will create a new certification?
>     What are the odds that it is successful in the market?
>
>     These are presently unknowns,  and will remain that way until tried.
>
>
>     On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
>
>      > Hello Mikael,
>      >
>      > " For me, it seems these 802.11 broadcast/multicast ACK functions
>     should be "mandatory" to implement if the device wants to support
>     IPv4 and IPv6 networks.
>      >
>      > How do we achieve this?"
>      >
>      > There are two routes to "mandatory".   The standard can indicate
>     something is mandatory if you support
>      > a particular feature.
>      >
>      > The second is certification.  This is the not-so-simple task of
>     persuading a sufficient number of WiFi-Alliance members
>      > that it is in their economic interest to support the feature that
>     a certification program can be created.   Even, given a
>      > certification,  the market will still decide whether that is
>     relevant or not.
>      >
>      >
>      > Best Regards,
>      >
>      > Adrian P STEPHENS
>      >
>      > Tel: +44 (1793) 404825 (office)
>      > Tel: +1 (971) 330 6025 (mobile)
>      >
>      > ----------------------------------------------
>      > Intel Corporation (UK) Limited
>      > Registered No. 1134945 (England)
>      > Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>      >
>      > -----Original Message-----
>      > From: ieee-ietf-coord [mailto:[email-masked]
>     <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] <mailto:[email-masked]>; Dan
>     Romascanu ([email-masked] <mailto:[email-masked]>); Glenn
>      > Parsons; Homenet; Eric Gray
>      > Subject: Re: [ieee-ietf-coord] [homenet] Despair
>      >
>      > On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
>      >
>      >> The question in my mind is whether this discussion thread is
>     uncovering any new requirements for the 802.11 standard.
>      >
>      > Thanks for the summary, it seems correct.
>      >
>      > It might not need new 802.11 standards, but we still have an
>     operational problem in that it seems some of these standards are not
>     universally implemented by 802.11 based device vendors.
>      >
>      > IETF standards generally assume that multicast and unicast are
>     delivered with a similar level of packetloss (which is low).
>      >
>      > Not all 802.11 implementations have the multicast ACK mechanism
>     implemented, thus it would seem that multicast will be less likely
>     to get delivered to the recipient over these 802.11 implementations.
>      >
>      > For me, it seems these 802.11 broadcast/multicast ACK functions
>     should be "mandatory" to implement if the device wants to support
>     IPv4 and IPv6 networks.
>      >
>      > How do we achieve this?
>      >
>      > --
>      > Mikael Abrahamsson    email: [email-masked]
>     <mailto:[email-masked]>
>      >
>      > _______________________________________________
>      > ieee-ietf-coord mailing list
>      > [email-masked] <mailto:[email-masked]>
>     --
>     Mikael Abrahamsson    email: [email-masked] <mailto:[email-masked]>
>
>     _______________________________________________
>     ieee-ietf-coord mailing list
>     [email-masked] <mailto:[email-masked]>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>