On Mon, Aug 10, 2015 at 09:39:43AM +0000, Stephens, Adrian P wrote:
> 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.
When replacing multicast with unicast its not necessary to replicate,
you can instead use different protocol mechanisms too, eg: client/server
communications. Especailly wrt to the p2p duplicate address detection.
> [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.
For the signaling that IPv6 needs it looks like a lot of waste of
complex L2 tracking (like those protected GCR's) to create reliability.
> Moving the duplication into the IP layer ensures uninformed decisions.
Yes, but only about optimizations unnecessary for signaling. Which is
why i said we should be more specific about what use of multicast
we're talking about: signaling or media. They need different
solution approaches IMHO.
> 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".
Yeah, that doesn't work.
> Or the IETF could just say that this seems like a lost cause,
> multicast/broadcast doesn't seem to work on some L1/L2, and start working on
> techniques that minimizes broadcast/multicast and change all the protocols to
> reflect this new reality.
Yes, for IPv6 L2 signaling.
> Something in the middle, but anyway changing the requirements on IETF
> protocols to avoid using multicast if it can, documenting where it makes
> sense and when it doesn't.
That too.
Cheers
Toerless
> 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]] On
> > Behalf Of Mikael Abrahamsson
> > Sent: 10 August 2015 08:32
> > To: Stephens, Adrian P
> > Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler;
> > [email protected]; Dan Romascanu ([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]
> >
> > _______________________________________________
> > ieee-ietf-coord mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
> >
>
> --
> Mikael Abrahamsson email: [email protected]
>
> _______________________________________________
> MBONED mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mboned
--
---
Toerless Eckert, [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
