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 protected] <mailto:[email protected]>> 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 protected]
<mailto:[email protected]>] On Behalf Of Mikael
Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: [email protected] <mailto:[email protected]>; Dan
Romascanu ([email protected] <mailto:[email protected]>); Glenn
Parsons; [email protected] <mailto:[email protected]>; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11
(included [email protected] <mailto:[email protected]> 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 protected]
<mailto:[email protected]>] On
> Behalf Of Mikael Abrahamsson
> Sent: 10 August 2015 08:32
> To: Stephens, Adrian P
> Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler;
> [email protected] <mailto:[email protected]>; Dan
Romascanu ([email protected] <mailto:[email protected]>); 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 protected]
<mailto:[email protected]>
>
> _______________________________________________
> ieee-ietf-coord mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>
--
Mikael Abrahamsson email: [email protected] <mailto:[email protected]>
_______________________________________________
ieee-ietf-coord mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
