Hi Mark,
On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith <markzzzsm...@yahoo.com.au>wrote: > Hi Behcet, > > Thanks for your review and comments. > > > > >________________________________ > > From: Behcet Sarikaya <sarikaya2...@gmail.com> > >To: Dave Thaler <dtha...@microsoft.com> > >Cc: Mark Smith <markzzzsm...@yahoo.com.au>; "6...@ietf.org" < > 6...@ietf.org>; "mbo...@ietf.org" <mbo...@ietf.org> > >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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
