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

[Alexandru Petrescu]

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"
> wrote:

Hello Mikael,

Please see my responses embedded below...

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825  (office)
Tel: +1 (971) 330 6025  (mobile)

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

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


(included mbo...@ietf.org  and also changed
subject to something more
appropriate)

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

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


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

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

Moving the duplication into the IP layer ensures uninformed decisions.


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

[Adrian P Stephens]

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.




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 

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

[Alexandru Petrescu]

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




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[james woodyatt]

On Aug 12, 2015, at 21:35, Henning Rogge hro...@gmail.com wrote:
 On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch to...@isi.edu wrote:
 DAD is also needed to detect duplicates due to host misconfiguration,
 such as when a cloned MAC is added to the same network or when addresses
 are duplicated by other means (e.g., DHCPv6 misconfiguration).
 
 I couldn't confirm, but isn't this also not a local decision? I.e., if
 DAD fails you might end up with a duplicate address even when you set
 your IP addresses based on the burned-in MAC because others could select
 the same address randomly (I didn't see how that was avoided by the
 self-assignment algorithm).
 
 If you have a duplicate MAC then DAD will not safe you... you cannot
 communicate anyways because of a layer-2 problem.

Yes, and DAD also has logic that limits the damage on the entire network when 
hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
operation on the interface SHOULD be disabled.

It’s worth noting that the presence of network sleep proxies can make this 
recommendation problematic. It would be better to disable the whole interface 
only when the actual L2 address is discovered to be duplicated, not just the 
link-local IPv6 address w/ embedded EUI-64 IID, which would allow DAD failures 
with sleep proxies on link-local addresses to be treated like a DAD failure 
with a sleep proxy on any other address. Alas, earwax.

—james

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

On 8/13/2015 10:59 AM, james woodyatt wrote:
 On Aug 12, 2015, at 21:35, Henning Rogge hro...@gmail.com
 mailto:hro...@gmail.com wrote:
...
 If you have a duplicate MAC then DAD will not safe you... you cannot
 communicate anyways because of a layer-2 problem.
 
 Yes, and DAD also has logic that limits the damage on the entire network
 when hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

Also, a duplicate L2 is a problem at L2 only when both L2s are on the
same L2 subnet. It's entirely possible that the two L2s are on different
L2 subnets but on the same L3 subnet.

E.g., consider point-to-point links to the router. No reason to care
about the L2s at all (interface is all you need to determine the remote
end), but nodes that self-address using identical L2s would create
identical L3's.

Joe

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

On 8/12/2015 12:39 PM, Henning Rogge wrote:
 On Wed, Aug 12, 2015 at 8:23 PM, Joe Touch to...@isi.edu wrote:
 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.
 
 Luckily DAD is mostly needed for randomized IPv6 addresses... if you
 use the MAC address for generating the IP you are either fine or you
 have a MAC level collision, which means you have an unsolvable
 problem.

DAD is also needed to detect duplicates due to host misconfiguration,
such as when a cloned MAC is added to the same network or when addresses
are duplicated by other means (e.g., DHCPv6 misconfiguration).

I couldn't confirm, but isn't this also not a local decision? I.e., if
DAD fails you might end up with a duplicate address even when you set
your IP addresses based on the burned-in MAC because others could select
the same address randomly (I didn't see how that was avoided by the
self-assignment algorithm).

Joe

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mikael Abrahamsson]

On Thu, 13 Aug 2015, Henning Rogge wrote:

If you have a duplicate MAC then DAD will not safe you... you cannot 
communicate anyways because of a layer-2 problem.


Well, you can share the same L3 network but not share the same L2 network 
(and do proxy-ND between them). But yes, you're basically correct.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Henning Rogge]

On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch to...@isi.edu wrote:
 DAD is also needed to detect duplicates due to host misconfiguration,
 such as when a cloned MAC is added to the same network or when addresses
 are duplicated by other means (e.g., DHCPv6 misconfiguration).

 I couldn't confirm, but isn't this also not a local decision? I.e., if
 DAD fails you might end up with a duplicate address even when you set
 your IP addresses based on the burned-in MAC because others could select
 the same address randomly (I didn't see how that was avoided by the
 self-assignment algorithm).

If you have a duplicate MAC then DAD will not safe you... you cannot
communicate anyways because of a layer-2 problem.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Toerless Eckert (eckert)]

What you mention is for media streaming, and the wifi problem is primarily 
burst loss. Correcting that is expensive, whether its done at l2 or higher 
layer. Our signaling protocols can easily be fixed to live with even higher 
loss at lower cost. Thats why i am suggesting to separate solution space 
between signalling and media.




Sent from my Samsung Captivate Glide on ATT

Mikael Abrahamsson swm...@swm.pp.se wrote:
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.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Eric Vyncke (evyncke)]

On 12/08/15 07:51, homenet on behalf of Henning Rogge
homenet-boun...@ietf.org on behalf of hro...@gmail.com 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...

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mikael Abrahamsson]

On Wed, 12 Aug 2015, Henning Rogge wrote:


0.1% multicast packet loss is unrealistic.


I found this interesting document:

https://hal.archives-ouvertes.fr/tel-00919403/document

In 2.4 there is a lot of text about different ways of making multicast 
(more) reliable.


From what I can see, the control plane (for instance RA/ND/ARP etc) (this 
does not include video transmission) of IP based protocols have the 
following requirements for its broadcast/multicast packets (from now on I 
will only say multicast):


Multicast packets should be delivered with less than 1% packet loss 
Multicast packets should be delivered within 200-500ms (for instance DAD 
requires answer within 1s)


This would indicate to me that 802.11 could do the following to achieve a 
compromise between power, packet loss etc:


If the multicast packet is to be sent to X receivers or fewer, turn them 
into L2 unicast, and send them individually (tradeoff between sending X 
packets and using a lower rate multicast). X could be 2-4 or something?


Send IP control plane multicast packets at an interval, for instance 
250ms, so stations can sleep in between.


Send multiple packets at the above interval if there are multiple ones 
queued up, use BNAK for retransmits, potentially turning 
to-be-retransmitted multicast packets into unicast (re)transmits to send 
to individual stations that didn't receive the multicasted packet(s).


(I don't know if this is already being done) Stations should send IP 
multicast packets to the AP in L2 unicast so the AP can then send it as 
multicast using above mechanism, including queuing it for multiple 
delivery.


Thoughts?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

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.

 While I agree with your conclusion, what's the alternative if there is
 no L2 multicast?
 
 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 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.
 
 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Henning Rogge]

On Wed, Aug 12, 2015 at 8:23 PM, Joe Touch to...@isi.edu wrote:
 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.

Luckily DAD is mostly needed for randomized IPv6 addresses... if you
use the MAC address for generating the IP you are either fine or you
have a MAC level collision, which means you have an unsolvable
problem.

(it gets even worse on 802.11 IBSS/Adhoc mode)

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

On 8/12/2015 1:12 AM, Mikael Abrahamsson wrote:
 Multicast packets should be delivered with less than 1% packet loss
 Multicast packets should be delivered within 200-500ms (for instance DAD
 requires answer within 1s)

That assumes default DAD configuration, and I already noted that this is
clearly not appropriate for existing 802.11 links based on the recently
reported loss rates.

I.e., DAD doesn't have specific requirements; it has a *relationship* of
its configuration to the link properties.

Joe

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Pat (Patricia) Thaler]

I think it is useful for 
ieee-ietf-co...@ietf.orgmailto:ieee-ietf-co...@ietf.org 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:ieee-ietf-coord-boun...@ietf.org] On Behalf Of 
Alia Atlas
Sent: Tuesday, August 11, 2015 9:16 AM
To: Toerless Eckert
Cc: mbo...@ietf.org; Homenet; ieee-ietf-co...@ietf.org
Subject: Re: [ieee-ietf-coord] [homenet] Multicast on 802.11

Can we please remove ieee-ietf-co...@ietf.orgmailto:ieee-ietf-co...@ietf.org 
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 
eck...@cisco.commailto:eck...@cisco.com wrote:
On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert) wrote:
 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.

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 routed. Many LLNs work like 
 this. Why should Wi-Fi be an exception?

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 ?

  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.

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. IEEE people may join the 
 effort so we do the job right.

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

___
homenet mailing list
homenet@ietf.orgmailto:homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

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

 Since RFC 3819 is mostly concerned about avoiding receiving unwanted
 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.
 ---

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

On 8/11/2015 10:34 AM, Juliusz Chroboczek wrote:
 I'm removing from CC the people who I know are on Homenet, please do the
 same with the other lists.
 
 Since RFC 3819 is mostly concerned about avoiding receiving unwanted
 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.
 ---
 
 Perhaps I misread this section, 

Are you referring to RFC3819?

 but the impression I get is that it is
 concerned about avoiding waking nodes and avoiding duplicate
 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
 networks where multicast has higher packet loss and lower throughput than
 unicast, which is what concerns us here.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Pat (Patricia) Thaler]

RE: RFC3819

 The assumption is that L2 will do a reasonably good and efficient job of
 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.

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. 
 

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 .

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Pat (Patricia) Thaler]

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
 no L2 multicast?

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.

 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.

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Toerless Eckert]

Sure... 
But don't look at me, i don't remember i added that Cc:, i added mboned ;-))

On Tue, Aug 11, 2015 at 12:15:49PM -0400, Alia Atlas wrote:
 Can we please remove ieee-ietf-co...@ietf.org 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 eck...@cisco.com wrote:
 
  On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert) wrote:
   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.
 
  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 routed. Many LLNs work
  like this. Why should Wi-Fi be an exception?
 
  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 ?
 
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.
 
  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. IEEE people may join
  the effort so we do the job right.
 
  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
 
  ___
  homenet mailing list
  homenet@ietf.org
  https://www.ietf.org/mailman/listinfo/homenet
 

-- 
---
Toerless Eckert, eck...@cisco.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Toerless Eckert]

On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert) wrote:
 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.

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 routed. Many LLNs work like 
 this. Why should Wi-Fi be an exception?

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 ?

  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. 

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. IEEE people may join the 
 effort so we do the job right.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Alia Atlas]

Can we please remove ieee-ietf-co...@ietf.org 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 eck...@cisco.com wrote:

 On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert) wrote:
  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.

 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 routed. Many LLNs work
 like this. Why should Wi-Fi be an exception?

 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 ?

   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.

 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. IEEE people may join
 the effort so we do the job right.

 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

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Alia Atlas]

https://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 may be
of interest in understanding some of the issues with IPv6 and wifi.

Regards,
Alia

On Tue, Aug 11, 2015 at 12:30 PM, Toerless Eckert eck...@cisco.com wrote:

 Sure...
 But don't look at me, i don't remember i added that Cc:, i added mboned
 ;-))

 On Tue, Aug 11, 2015 at 12:15:49PM -0400, Alia Atlas wrote:
  Can we please remove ieee-ietf-co...@ietf.org 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 eck...@cisco.com
 wrote:
 
   On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert)
 wrote:
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.
  
   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 routed. Many LLNs
 work
   like this. Why should Wi-Fi be an exception?
  
   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 ?
  
 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.
  
   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. IEEE people may
 join
   the effort so we do the job right.
  
   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
  
   ___
   homenet mailing list
   homenet@ietf.org
   https://www.ietf.org/mailman/listinfo/homenet
  

 --
 ---
 Toerless Eckert, eck...@cisco.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

On 8/11/2015 2:44 PM, Pat (Patricia) Thaler wrote:
 RE: RFC3819
 
 The assumption is that L2 will do a reasonably good and efficient job of
 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.

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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Henning Rogge]

On Wed, Aug 12, 2015 at 7:17 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 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.

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.

Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mikael Abrahamsson]

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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Joe Touch]

On Aug 10, 2015, at 1:05 PM, Juliusz Chroboczek 
j...@pps.univ-paris-diderot.fr wrote:

 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,

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
 itself.  Is an update needed?
 
 -- Juliusz
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Stephens, Adrian P]

Hello Mikael,

Please see my responses embedded below...

Best Regards,
 
Adrian P STEPHENS
 
Tel: +44 (1793) 404825 (office)
Tel: +1 (971) 330 6025 (mobile)
 
--
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

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


(included mbo...@ietf.org and also changed subject to something more
appropriate)

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

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


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

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

Moving the duplication into the IP layer ensures uninformed decisions.


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

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



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

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

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

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

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

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

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

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


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

 Hello Mikael,

  For me, it seems these 802.11 broadcast/multicast ACK functions should be 
 mandatory to implement if the device wants to support IPv4 and IPv6 
 networks.

 How do we achieve this?

 There are two routes to mandatory.   The standard can indicate something is 
 mandatory if you support
 a particular feature.

 The second is certification.  This is the not-so-simple task of persuading a 
 sufficient number of WiFi-Alliance members
 that it is in their economic interest to support the feature 

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

[Mikael Abrahamsson]

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


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


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?


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.



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.


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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Pascal Thubert (pthubert)]

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mikael Abrahamsson]

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


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


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?



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.


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

 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


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.



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


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.


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?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Toerless Eckert]

Pascal:




On Mon, Aug 10, 2015 at 10:05:54AM +, Pascal Thubert (pthubert) wrote:
 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.

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

 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.

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.

 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.

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

  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.
 
 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.
 
  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.
 
 This also has already started with the efficient ND work at 6MAN and many 
 drafts from design team members.


 
 Cheers,
 
 Pascal
 
  
  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?
  
  On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
  
   Hello Mikael,
  
For me, it seems these 802.11 broadcast/multicast ACK functions
  should be mandatory to implement if the device wants to support IPv4
  and IPv6 networks.
  
   How do we achieve this?
  
   There are two routes to mandatory.   The standard can indicate
  something is mandatory if you support
   a particular feature.
  
   The second is certification.  This is the not-so-simple task of 
   persuading a
  sufficient number of WiFi-Alliance members
   that it is in their economic interest to support the feature that a
  certification program can be created.   Even, given a
   certification,  the market will still decide whether that is relevant or 
   not.
  
  
   Best Regards,
  
   Adrian P STEPHENS
  
   Tel: +44 (1793) 404825 (office)
   Tel: +1 (971) 330 6025 (mobile)
  
   --
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
  
   -Original Message-
   From: ieee-ietf-coord [mailto:ieee-ietf-coord-boun...@ietf.org] On
   Behalf Of Mikael Abrahamsson
   Sent: 10 August 2015 08:32
   To: Stephens, Adrian P
   Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler;
   ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com); Glenn
   Parsons; Homenet; Eric Gray
   Subject: Re: [ieee-ietf-coord] [homenet] Despair
  
   On Mon, 10 Aug 2015, Stephens, Adrian P wrote:
  
   The question in my mind is whether this discussion thread is uncovering
  any new requirements for the 802.11 standard.
  
   Thanks for the summary, it seems correct.
  
   It might not need new 

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

[Pascal Thubert (pthubert)]

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.


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

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.

 
 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.
 

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

 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.

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.

 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.

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

Cheers,

Pascal

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

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

[Mikael Abrahamsson]

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


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?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ray Bellis]

Folks, please trim your cc: lists - you're exceeding the limit that
Mailman permits and I don't intend to increase it (nor pass through any
messages already blocked as a result).

thanks,

Ray

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mikael Abrahamsson]

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.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Pascal Thubert (pthubert)]

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

 -Original Message-
 From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
 Sent: lundi 10 août 2015 13:03
 To: Pascal Thubert (pthubert) pthub...@cisco.com
 Cc: ieee-ietf-co...@ietf.org; Dan Romascanu (droma...@avaya.com)
 droma...@avaya.com; Stephens, Adrian P
 adrian.p.steph...@intel.com; Glenn Parsons
 glenn.pars...@ericsson.com; mbo...@ietf.org; Homenet
 homenet@ietf.org; Eric Gray eric.g...@ericsson.com
 Subject: RE: [ieee-ietf-coord] Multicast on 802.11
 
 On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:
 
  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?
 
 --
 Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet