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 protected]
On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan)
<[email protected]> 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 protected]] 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 protected]
_______________________________________________ ieee-ietf-coord
mailing list [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
