Bonjour Christian,
On Mon, Apr 1, 2013 at 11:55 AM, Christian Huitema <[email protected]>wrote: > Behcet,**** > > ** ** > > If you want to change 802.11 multicast, you ought to do that in the IEEE > 802.11 working groups, not in the IETF. As far as we are concerned, 802.11 > specifications are a constraint. **** > > ** ** > > It is a fact that multicast over 802.11 is very inefficient, and not > appropriate for multicast high volumes to few receivers. When the number of > intended recipients is small, it is much more efficient to send individual > copies to each recipient than to try to use the 802.11 multicast service. > There is probably a case to be made that if the number of recipient is very > large multicast becomes a better solution, but I suspect that this very > large number is too large for practical applications.**** > > ** > As far as I know, the operators prefer native multicast for IPTV applications, for a good reason. It seem like this is the application that Mark has in mind. ** > > So, yes, it is a fairly good idea to study how multicast delivery could be > accomplished by a series of unicast transmission.**** > > ** > Sure, I am not against investigations, studies, research. I am all for it. Behcet > ** > > -- Christian Huitema**** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Behcet Sarikaya > *Sent:* Monday, April 1, 2013 8:33 AM > *To:* Mark Smith > *Cc:* [email protected]; [email protected]; Dave Thaler > > *Subject:* Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast"**** > > ** ** > > Hi Mark,**** > > ** ** > > On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith <[email protected]> > wrote:**** > > Hi Behcet, > > Thanks for your review and comments. > > > > >________________________________ > > From: Behcet Sarikaya <[email protected]> > >To: Dave Thaler <[email protected]> > >Cc: Mark Smith <[email protected]>; "[email protected]" < > [email protected]>; "[email protected]" <[email protected]> > >Sent: Saturday, 30 March 2013 8:33 AM > >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast"**** > > > > > > >Hi Mark, > > > >I read your draft. > >First of all I think you misunderstood RFC 6085 and based on a wrong > assumption you developed your solution. > > > >**** > > >What specifically do you think I've misunderstood? I was involved in some > of the conversations about that RFC while it was an ID, and all I think it > really is fundamentally saying is that an IPv6 packet with a multicast IPv6 > destination address isn't required to have a link-layer multicast > destination address - it can be a link-layer unicast destination address if > useful or necessary.**** > > >** ** > > ** ** > > Really, because I think no one knows how the ID became an RFC. > **** > > >** ** > > ** ** > > ** ** > > **** > > > > > > > I suggest you take a look at > http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 > >on Netext for PMIPv6. > > > >**** > > >I'll have a read.**** > > ** ** > > But more importantly, it was aimed to solve PMIPv6 problem of establishing > point-to-point link on an important shared links like 802.11.**** > > Actually there are other ways of doing that, mainly in Layer 2. **** > > > > >I believe that we should use multicast delivery as much as possible on > the downlink if the link is a shared link. > > > > > > > >**** > > >I agree with using multicast as much as possible to reduce duplicate > packets sent over the network. The proposal here is to use packet > replication and link-layer unicasts when doing so would either exceed the > performance of link-layer multicast and/or overcome the negative effects of > link-layer multicast, such as when larger volumes of multicast traffic > impact unicast performance on the same link. Both of these issues occur on > 802.11 links when there volume of multicast traffic is in the order of a > few megabits (or less, I've been testing with around 2.5 Mbps of video) > > > > > >The main use case I've been thinking about (which I'll make more obvious > in the next revision), is a multicast IPTV service scenario towards a > residential customer, where the residential customer has a 802.11 network > in their home rather than a wired one. IPv6 multicast/link-layer multicast > would be used all the way from the multicast source servers, across the > service provider network, up until the CPE in the residential customers' > homes, gaining the efficiencies of multicast. However, the CPE in the > customer's house would then use IPv6 multicast/link-layer unicast of the > IPTV traffic over the 802.11 link to the customers end-hosts, saving them > having to put in wired infrastructure, or resorting to buying ethernet over > power devices to make their power cabling their wired infrastructure. Note > that there is still a low level of link-layer multicast traffic in the > customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is > not eliminating > link-layer multicasts, just reducing them where possible and where useful. > > > > > >That's not to say this proposal is only useful in an 802.11 scenario. It > could be used in any scenario where packet replication and link-layer > unicasting would provide useful benefits over link-layer multicasts. It > generally increases the data confidentiality of the multicast IPv6 traffic, > and may help increase battery life of some devices. > >**** > > ** ** > > Well, you preached your case quite well.**** > > But the main problem is with 802.11 multicast which uses the lowest > bandwidth channel. So you are proposing to change multicast to unicast > delivery with copying to cope with this problem.**** > > Let this be well understood.**** > > I would suggest changing 802.11 multicast though.**** > > Also, I have concerns on the copying: it seems like copying will be based > on neighbor discovery cash.**** > > I think it is rather strange.**** > > Another point is that point to point link is another solution.**** > > Regards,**** > > Behcet**** > > ** ** >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
