Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Apr 2013 10:33:12 -0500

Hi Mark,

On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith <[email-masked]>wrote:

> Hi Behcet,
>
> Thanks for your review and comments.
>
>
>
> >________________________________
> > From: Behcet Sarikaya <[email-masked]>
> >To: Dave Thaler <[email-masked]>
> >Cc: Mark Smith <[email-masked]>; "[email-masked]" <
> [email-masked]>; "[email-masked]" <[email-masked]>
> >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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Apr 2013 16:55:09 +0000

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.

So, yes, it is a fairly good idea to study how multicast delivery could be accomplished by a series of unicast transmission.

-- Christian Huitema

From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Monday, April 1, 2013 8:33 AM
To: Mark Smith
Cc: [email-masked]; [email-masked]; 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-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

> From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
>To: Dave Thaler <[email-masked]<mailto:[email-masked]>>
>Cc: Mark Smith <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>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.
>

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Apr 2013 12:17:49 -0500

Bonjour Christian,

On Mon, Apr 1, 2013 at 11:55 AM, Christian Huitema <[email-masked]>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-masked] [mailto:[email-masked]] *On Behalf
> Of *Behcet Sarikaya
> *Sent:* Monday, April 1, 2013 8:33 AM
> *To:* Mark Smith
> *Cc:* [email-masked]; [email-masked]; 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-masked]>
> wrote:****
>
> Hi Behcet,
>
> of Multicast"****
> >****
> useful or necessary.****
> >** **
>  ** **
>  ****
>  >** **
>  ** **
> ** **
>  ****
> >****
> >I'll have a read.****
>  ** **
> point-to-point link on an important shared links like 802.11.****
>
> Actually there are other ways of doing that, mainly in Layer 2.  ****
>
>  >
> >****
> >****
>  ** **
> Well, you preached your case quite well.****
>
> delivery with copying  to cope with this problem.****
>
> Let this be well understood.****
>
> I would suggest changing 802.11 multicast though.****
>
> on neighbor discovery cash.****
>
> I think it is rather strange.****
>
> Another point is that point to point link is another solution.****
>
> Regards,****
>
> Behcet****
>
> ** **
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Apr 2013 18:18:25 +0000

> As far as I know, the operators prefer native multicast for IPTV applications, for a good reason.
 
There are two solutions today: multicast all the way, from the source to the various destinations; and, unicast all the way. The multicast solution suffers from very poor performance on the 802.11 network. The unicast solution prevents bandwidth optimization in the distribution network. The "best" solution would combine unicast on 802.11 networks and multicast on the distribution network. That requires protocol changes, so that an 802.11 node that subscribes to a multicast group effectively gets unicast delivery from the wireless router, while the wireless router gets multicast delivery from the network router. That's what Mark's draft is attempting to define. That seems like a fine project.

Of course that's not an easy project, and there are many details that need to get solved. For example, allowing multicast delivery to arrive over unicast addresses may well have some interesting security implications. Then there is the matter of "multiplying" the multicast packets, which is prone to create instant congestion in the router. Then there is the decision logic on when to choose multicast versus unicast delivery. Oh, and doing all that without an explosion in complexity...

Of course, we can observe that unicast delivery can be implemented today using end-to-end procedures. Makes you really wonder whether the right way to optimize bandwidth for multicast content delivery is a new version of IP forwarding standards, or instead some form of compression on the distribution links.

-- Christian Huitema

---

From: Stig Venaas <[email-masked]>
Date: Mon, 01 Apr 2013 11:33:38 -0700

Hi

Interesting draft. I need to think more about it, but I have a
comment below.

On 3/29/2013 2:52 AM, Mark Smith wrote:
> Hi Carsten,
>
> Thanks very much for your review and comments.
>
>
> ----- Original Message -----
>> From: Carsten Bormann <[email-masked]>
>> To: Mark Smith <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>> Sent: Friday, 29 March 2013 7:21 PM
>> Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
>>
>> Hi Mark,
>>
>> interesting draft.  I'm interested in this from a 6LoWPAN perspective --
>> everything we can do to get rid of multicasts is very good for 6LoWPANs.
>>
>> I don't understand how you think NUD would work with this (3.2) -- are you
>> saying that the multicast emitter actively runs NUD to the targets?
>>
>
> Yes. NUD is performed on the link-local addresses used as the source addresses for the MLDv2 messages.
>
> Originally when I was thinking about this, I thought that might be one of the things that would need to be changed. However, when I reviewed the part of RFC3810 (MLDv2) related to MLD Report source addresses, I came across the following in 5.2.13, "Source Addresses for Reports":
>
>     On the other hand, routers MUST silently discard a message that is
>     not sent with a valid link-local address, without taking any action
>     on the contents of the packet.  Thus, a Report is discarded if the
>     router cannot identify the source address of the packet as belonging
>     to a link connected to the interface on which the packet was
>     received.  A Report sent with the unspecified address is also
>     discarded by the router.  This enhances security, as unidentified
>     reporting nodes cannot influence the state of the MLDv2 router(s).
>
> It seems to me that the only way to be sure a MLDv2 source link-local address is valid and belongs to the link is to test it's existence, which is of course what neighbor discovery does using an NS/NA transaction. So the existing ND neighor presence discovery mechanism can, and I think the above implies should be used to determine MLDv2 link-local source address validity, and therefore the ND NUD mechanism can then be used to determine when the neighbor disappears, and therefore link-layer unicasting of mulicast IPv6 should stop for that now absent listener.
>
> (Out of interest, I checked to see if this sort of link-local address validity checking is being performed by Linux and one of the BSDs (I can't remember which one). Neither of them did, all they checked was that the source address of the MLDv2 report was a link-local address. So they're vulnerable to MLDv2 reports with spoofed, non-existent link-local addresses ...)

I'm not at all surprised it's not checked. But note that even if such
a check is in place, there is a certain risk of spoofing. It's not that
hard to guess some valid link-local addresses. E.g. if SLAAC, just look
at the global addresses used. I'm wondering a bit if we should have, or
maybe still should, use hop limit 255 for MLDv2.

Stig

>> MLDv2 is a protocol that runs between multicast listeners and multicast routers.
>> How do you handle multicast emitters that aren't multicast routers?
>>
>
> The main use case scenario I've been thinking about is multicast IPTV over a carrier network, towards a residential customer, where the last hop in the customer's home is 802.11, and where the multicast performance problems appear. So the multicast source servers would be wired, and on segments where the volumes of multicast traffic didn't impact link performance.
>
> My main overriding goals were to avoid changes to the end-hosts, leaving changes to be made to the multicast router's behaviour (e.g. residential CPE), and to reduce the number of multicasts as much as possible, but not eliminate them. Low levels of multicast on 802.11 works ok, it's the high levels that cause problems.
>
> If a host implementation can be changed, then it could implement the procedures I've described. It could listen to the MLDv2 reports (as non-Querier multicast routers do), do neighbor discovery/NUD on the MLDv2 source link-local addresses, and then proceed to link-layer unicast the multicast IPv6 traffic to its on-link neighbors.
>
>> How do you wean MLDv2 itself off multicast?  (Now that would be my holy grail.
>> We didn't get around to do this in RFC 6775 -- we didn't think we'd
>> have to, since we were addressing a subnet where subnet-multicast doesn't
>> work at all.)  Maybe efficient-ND could do something here.
>>
>
> I've put a little bit of thought into this. If you're able to change the host and the router implementations, then I've thought might be able to eliminate multicasts by treating the broadcast/multicast link as a Non-Broadcast Multi-Access link, and then use RFC2491, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" methods. Briefly looking at it, it does mention how to handle the SMDS link layer, and my understanding is that was a connectionless (rather than a connection oriented) NBMA link-layer, so treating 802.11 or 802.3 as an NMBA link could probably use the NBMA IPv6 techniques used for SMDS.
>
> Regards,
> Mark.
>
>> Grüße, Carsten
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 1 Apr 2013 20:06:58 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Huitema

> There are two solutions today: multicast all the way, from the source
> to the various destinations; and, unicast all the way. The multicast
> solution suffers from very poor performance on the 802.11 network. The
> unicast solution prevents bandwidth optimization in the distribution
> network. The "best" solution would combine unicast on 802.11 networks
> and multicast on the distribution network. That requires protocol
> changes, so that an 802.11 node that subscribes to a multicast group
> effectively gets unicast delivery from the wireless router, while the
> wireless router gets multicast delivery from the network router. That's
> what Mark's draft is attempting to define. That seems like a fine
> project.

Agree. I thought the proposal was to retain the IP header as is, i.e. a Class D destination address, but to use the unique MAC address at layer 2 (RFC 6085). To find the individual MAC address, I thought the plan was to use the source IP in the IGMP join, and then find the MAC the old fashioned way.

Seems like a useful workaround. I think it should be in IETF's scope.

Bert

---

From: Mark Smith <[email-masked]>
Date: Mon, 1 Apr 2013 13:39:24 -0700 (PDT)

Hi,

(I'm reading and having a think about other people's emails, but this one is easy to respond to)

----- Original Message -----
> From: "Manfredi, Albert E" <[email-masked]>
> To: Christian Huitema <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tuesday, 2 April 2013 7:06 AM
> Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
> 
> Agree. I thought the proposal was to retain the IP header as is, i.e. a Class D 
> destination address, but to use the unique MAC address at layer 2 (RFC 6085). To 
> find the individual MAC address, I thought the plan was to use the source IP in 
> the IGMP join, and then find the MAC the old fashioned way.
> 

Yes, that is exactly what I'm proposing.

It would only require changes on the multicast sender, and it is only combining the functions of MLDv2 and ND to determine the link-layer unicast address so that it can be used for link-layer unicast delivery of the IPv6 multicast packets (i.e. the IPv6 multicast packet is exactly as originally sent, the link-layer frame is no different either, other than having a unicast destination address). Initially it appeared that there would not be any changes required to either MLDv2 or ND to support this (which is why I haven't got any RFC2119 words in the ID), although Carsten has pointed out that a minor change would need to be made to ND so that NUD is used to track the presence of the neighbors for which multicast traffic is being link-layer unicast to. 

Best regards,
Mark.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 1 Apr 2013 13:26:59 -0700

On Fri, Mar 29, 2013 at 08:55:21PM +0000, Dave Thaler wrote:
> http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast 
> is work we did back in 2000 on this same topic.   At the time, the draft is written from 
> the perspective of the 6to4 NBMA link, but the topic was discussed (specifically by those
> in the acknowledgements section, and to a lesser extent by the ngtrans WG as a whole)
> as being more generally applicable.
> 
> There wasn't significant interest at the time and so the work was dropped
> rather than updating the spec to use generic language.

I have forgotten everything about it ;-)
> 
> The same concept as in the above was however then used in 2001 in
> http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast
> (still specific to a particular link type though), which after 11 years is now in the IESG :)
> 
> The most relevant WG is MBoneD.

Right ;-) finally. Alas, the AMT solution requires changes to the receiver host,
so the solution proposed in Marks draft is easier to deploy for the purpose it has.

Cheers
    Toerless

> -Dave
> > Mark Smith
> > Sent: Thursday, March 28, 2013 8:22 PM
> > To: [email-masked]
> > Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
> > 
> > Hi,
> > 
> > The following is inspired by some work I did in around 2010/2011 on a
> > multicast TV service, where residential customers with Wifi networks
> > suffered from performance problems, and had to be advised to buy
> > ethernet over power devices if they couldn't run wired ethernet to the STB
> > attached to their TV.
> > 
> > I've done some experiments on my home wifi network, using VLC, and
> > switching between multicast and unicast IPv6 to test the concept. The wifi
> > performance issues disappear when the video is delivered via unicast UDP.
> > (If people want to play with VLC and IPv6 multicast, email me off-list, as there
> > are a few issues e.g. the GUI doesn't accept some of the IPv6 multicast
> > parameters that the command line does).
> > 
> > I think there is a possibility the technique could also be applied to
> > IGMPv3/ARP, although it depends on whether ARP has been implemented
> > in a similar manner to IPv6 ND (e.g. an ARP equivalent to NUD). My
> > understanding is that Linux has implemented ARP this way. I'll do some more
> > research to verify this.
> > 
> > I though I'd post it to see if there is merit in the idea and it is worth spending
> > more of my time on. I looked for a IETF group more suitable to this, but didn't
> > seem to be able to find one. If there is one, please let me know.
> > 
> > Review and comments most appreciated.
> > 
> > Thanks very much,
> > Mark.
> > 
> > 
> > ----- Forwarded Message -----
> > > From: "[email-masked]" <[email-masked]>
> > > To: [email-masked]
> > > Cc:
> > > Sent: Friday, 29 March 2013 1:45 PM
> > > Subject: New Version Notification for
> > > draft-smith-mldv2-link-unicast-00.txt
> > >
> > >
> > > A new version of I-D, draft-smith-mldv2-link-unicast-00.txt
> > > has been successfully submitted by Mark Smith and posted to the IETF
> > > repository.
> > >
> > > Filename:     draft-smith-mldv2-link-unicast
> > > Revision:     00
> > > Title:         MLDv2 Procedures for Link-Layer Unicast Delivery of
> > > Multicast
> > > IPv6
> > > Creation date:     2013-03-29
> > > Group:         Individual Submission
> > > Number of pages: 7
> > > URL:
> > > http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00.
> > > txt
> > > Status:
> > > http://datatracker.ietf.org/doc/draft-smith-mldv2-link-unicast
> > > Htmlized:
> > > http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00
> > >
> > >
> > > Abstract:
> > >    Some multi-access link-layer technologies typically not provide
> > > good
> > >    IPv6 multicast performance, using link-layer multicasts, when the
> > >    volume of multicast traffic is significant.  It would be possible
> > > to
> > >    replicate and then link-layer unicast multicast IPv6 traffic to
> > >    interested listeners to overcome these link-layer performance
> > >    limitations.  This memo describes MLDv2 and IPv6 neighbor discovery
> > >    procedures to support link-layer unicast delivery of multicast IPv6
> > >    traffic.
> > >
> > >
> > >
> > >
> > >
> > > The IETF Secretariat
> > >
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 1 Apr 2013 13:56:21 -0700

Bunch of comments...

1. What Mark is proposing is being done AFAIK in a variety of products on the market,
   for example as the "multicast to unicast" eleement of Cisco VideoStream 
   and i think other vendors do this as well. Not sure about IPv6 though, i've only seen
   it in IPv4.

2. I am always getting annoyed when IPv6 bigots oops: fans unnecessarily constraining
   solutions to IPv6 only even though they equally apply to IPv4 and, in the case
   of IP multicast when its clear that the mayority of use for a while will still be
   IPv4. Its already bad enough that RFC6085 was written only for IPv6 instead of
   for IPv4 and IPv6. It would be lovely if Marks draft could be modified to cover
   both IPv4 and IPv6. I can't remember that RFC6085 was given for review to MBoned,
   or else i'd hae made that comment for it as well. But see 1: in practice existing
   IPv4 host stacks will wwell receive DMAC-unicast IP multicast packets due to the
   fundamental separation of L3 and L2 in the architecture of most host stacks.

3. I think a key eleemnt of the draft that should be made more clear in the description is
   that this mechanism is meant to be incrementally dpeloyable such that the mayority
   of devices on the (wireless) L2 domain do not have to be changed at all, and that
   the only expection against them is 2. (RFC6085 or equivalent for IPv4).

   To achieve this, the only requirement is to run IGMPv3/MLDv2, inhibit MLDv1/IGMPv1v2,
   and a device that wants to send multicast as unicast into the L2 domain needs to
   perform explicit tracking of the membership reports to know whom to send unicast copies to. 

   And then there are optimizations such as RFC4861 which should be optional.

   But having said all this, the fact that this can be done as a local implementation
   optimization in a device sending IP multicast into the L2 domain (whether thats
   a router, switch, host or whatever), it also means that this mechanism does not
   need to change any protocol signaling, and therefore the question is whether this
   can be standards track or just be informational.

4. I don't particularily think that the operating models presented and the first
   sentence of the abstract are correct. Sending L2 (wireless) multicast has a lot of
   benefits, and it has a lot of downsides. It totally depends on what you try to achieve.

   It is clear that 802.11 is particularily challenged with native L2 multicast because
   they never defined a good resilience scheme as for unicast but so far not for multicast.
   Hopefully this will get fixed sometime. As long as thats not the case we definitely
   have to tke this into account as a constraint, but it would be good to explain the
   situation correctly in the doc.

   Wrt. the operational model, i could easily see that one wold start out with unicasting,
   but then change over to multicasting for a particular group/channel when the
   total number of receivers tracked and bandwidth sent over the group/channel is too large.
   You may also limit IP multicast to a particular bitrate, so if a specific receiver
   can not support that bitrate, it would need to get unicast, and then that unicast
   might need to be rate-limited so that the receiver downspeeds (assuming it is
   using ALC which it really should). I am not aware if any product embodies 
   this dyanmicac switching, i am just saying it sounds logical to me ;-)

   So, given how many policies there could be to improve behavior of multicast over
   wireless, i think it would be more appropriate to make this draft informational
   and collect/document/discss these possible policies. Its not as if a specific individual
   policy seems to be ubiquoutously preferrable, and given how its all local policy on the
   device sending into the wireless L2, it doesn't seem to be the right place for a
   standard track doc. Going informational does hopefully not make a difference for 
   this doc being useful, because whether its standards track or not, customers will hopefully 
   put it into RFPs against their wireless equipment. Which also means its a good idea
   in these type of documents to give sticky names to individual functions such as
   different type of policies or optimizations, so customes in RFPs can refer to those
   sticky names (or section numbers).

5. Not being really a protocol extension but logically device-local improvements with
   a bunch of policies possible makes it also a good candidate for MBoned as opposed to a
   protocol group (i think... ).

Cheers
    Toerless

   tracking of 
   that it is consisting purely of mechanisms that the accss-point type device in a

On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote:
> >Cc: Mark Smith <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
> >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler <[email-masked]> wrote:
> >

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Apr 2013 00:21:05 +0200

On Apr 1, 2013, at 22:56, Toerless Eckert <[email-masked]> wrote:

>   Hopefully this will get fixed sometime.

In a MIMO world, the performance gap between unicast and (indiscriminate) multicast is likely to grow instead of shrink over time.

Another little observation:

Fixing this at the adaptation layer (i.e., where IP packets are mapped into L2) is suboptimal, because you may not have visibility into the number of member stations per AP.  Once you have a few dozen on an AP, it may make sense to switch back to multicast.  For that AP!  At the adaptation layer, you only see the bridged 802 network, so you don't know how many stations share an AP, and it is difficult to send multicast to one AP and multi-unicast to another.  It seems really hard to optimize this.  Once you have 802.11 (without any per-AP hacks) in your bridged 802 network, you probably want to do 6085 globally.

Pet peeve: We like to make things too "transparent", and then wonder how they break horribly when you no longer can see what you are doing.
-> http://en.wikipedia.org/wiki/Leaky_abstraction

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Apr 2013 08:35:42 +0200

On Apr 2, 2013, at 03:48, Toerless Eckert <[email-masked]> wrote:

> Why should an AP not be able to convert multicast->unicast.

Oh sure.  I haven't checked 802.11 if its four-address structure actually might make this work without any change at the adaptation layer or above.  Hacking the destination address visible at the MAC layer API may be a bit heavy, but might still work (what do we know about the implementation status of RFC 6508 or its IPv4 equivalent?).  Hey, this might even be supported by snooping a bit in the 6CIO option that indicates RFC 6508 is implemented...

So please go ahead and build product :-)

Mark's problem of course is that he would like to make this work with commodity consumer APs.

> All it would ahve
> to do is IGMPv3 snooping to know the clients connected to it. And it does know the
> per-client bitrate, aka: how far or how close a client is.

Yes, the AP (or controller) knows all that is needed to do this well.

> I guess the one things that not possible is to send the smae multicast group/channel
> in both multicast and unicast from the same AP because that would potentially create
> persistent duplicates.

Once you send multicast, you already have wasted the resources.
However, a multi-unicast could serve as a fill-in for the losses (e.g., for a station more remote from the AP).
Is getting lots of duplicates going to cause a problem?

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 1 Apr 2013 18:48:36 -0700

Why should an AP not be able to convert multicast->unicast. All it would ahve
to do is IGMPv3 snooping to know the clients connected to it. And it does know the
per-client bitrate, aka: how far or how close a client is.

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 2 Apr 2013 20:00:17 +1100

Indeed, an 802.11 AP should be able to do this without breaking 802.11.
 However, there are probably wider cases where unicast fanout is worth
doing.

BTW, it's a common misconception that 802.11 transmit rates have something
to do with range; actually, they're only very weakly correlated with range,
because other selection effects dominate first.  Still, that's not
particularly relevant to the present discussion.  What is relevant is that
multicast selects very low rates and is not aggregatable, which wastes
transmitter shots; an AP can easily have 100x more unicast throughput than
multicast.

On Tue, Apr 2, 2013 at 5:35 PM, Carsten Bormann <[email-masked]> wrote:

> Oh sure.  I haven't checked 802.11 if its four-address structure actually
> might make this work without any change at the adaptation layer or above.
>  Hacking the destination address visible at the MAC layer API may be a bit
> heavy, but might still work (what do we know about the implementation
> status of RFC 6508 or its IPv4 equivalent?).  Hey, this might even be
> supported by snooping a bit in the 6CIO option that indicates RFC 6508 is
> implemented...
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Apr 2013 12:03:19 -0500

On Mon, Apr 1, 2013 at 3:56 PM, Toerless Eckert <[email-masked]> wrote:

>    for IPv4 and IPv6.

I explained why already: it was for PMIPv6 which needed to have
point-to-point link on 802.11.

For the rest of this very long message,

yes, this is an application issue and I don't see why IETF should enter
into this domain.

Behcet

> It would be lovely if Marks draft could be modified to cover
> > >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.
> > >
> > >
> > >
> > >
> > >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
> > >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

---

From: Mark Smith <[email-masked]>
Date: Mon, 8 Apr 2013 14:30:10 -0700 (PDT)

Hi Toerless,

Sorry not to get back to you sooner, a bit time constrained at the moment.

----- Original Message -----
> From: Toerless Eckert <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; Dave Thaler <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tuesday, 2 April 2013 7:56 AM

That's good to know, I'd say it shows the idea is both feasible, useful and deployable.

I found the following, which was a reasonable overview:

http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/ps10325/white_paper_c11-577721.html

Dale Carder also pointed off list that Aruba Networks do the same thing (under Dynamic Multicast Optimization):

http://www.arubanetworks.com/vrd/80211nnetworksvrd/wwhelp/wwhimpl/common/html/wwhelp.htm#href=Chap4_AdaptRadioMgmt.html&single=true

>    fundamental separation of L3 and L2 in the architecture of most host stacks.

I initially limited the topic to IPv6, because I knew IPv6 had the functions necessary i.e. MLDv2 and IPv6 ND NUD. That being said, Carston has since pointed out that RFC4861 says that NUD is only supposed to be done for unicast traffic, but not multicast traffic. That would be talking about layer 3 unicast vs layer 3 multicast. To accommodate the use of NUD for what is proposed here, RFC4861 would have to be slightly updated to apply NUD to link-layer unicast of layer 3 multicast.

As for IPv4, that was something I was going to investigate. IGMPv3 would support this, the missing bit is an ARP equivalent of NUD. As far as I'm aware (although I haven't done much research yet), there is no RFC that specifies "ARP NUD". I have found that RFC1122 "2.3.2.1  ARP Cache Validation" does specify that Unicast polling of a neighbor using point-to-point ARPs can be use to check ARP cache entry validity. Also in passing I've noticed that Linux's implementation of ARP seems to use the states that it's IPv6 ND implementation uses, but I haven't yet verified that the behaviour is exactly the same. In other words, I think it is highly likely it can be applied to IPv4, but I wanted to see if "ARP NUD" was both permitted and also described somewhere. The follow on question is whether that description would have updated similarly to RFC4861.

> 3. I think a key eleemnt of the draft that should be made more clear in the 

> description is

I've realised through the discussion over the last few days that I need to separate out and make more clear some of these points. This first version was mainly to "throw it at the wall and see if it sticks."

The reason I though to use NUD to track the presence of the neighbors was that neighbor presence discovery is necessary to resolve the layer 2 information for the link-local MLDv2 source addresses, and NUD was tracking and verifying individual neighbors independently.

By default, MLDv2 general queries are only sent around every 2 minutes, and there isn't any reliability for that and the responses, meaning that if a query isn't received due to packet loss, or any of the reports are lost due to packet loss, the next opportunity to discover continued listener presence is in around 2 minutes time. So in the case of a single packet being lost, that might mean traffic is being sent to a non-existent listener for up to 4 minutes, which I think is getting a bit too close to the typical 5 minute aging of learned MAC addresses in switches. 

NUD will probe by default around every 30 seconds, and if it gets no response, will retransmit the probe around once a second. So it'd be much quicker and more reliable at detecting that the listener has disappeared than using MLDv2 General Queries. As MLDv2 General Queries are going to occur anyway, one optimisation that has occurred to me is that the corresponding reports from the listeners could be used as the evidence to Neighbor Discovery that the listener still exists, as a General Query and the corresponding reports are a two way transaction. The NUD probe could then be delayed for another 30 seconds. One drawback of this idea though would be that it would start roughly synchronising when NUD probes to all the listeners starts.

So I think using NUD (perhaps with MLDv2 GQ/Report hints) would be a better mechanism to use to track listener presence.

>    can be standards track or just be informational.

I'd think standards track due to the minor change required to RFC4861.

I'm not sure what happens with IPv4, as I haven't found an RFC describing "ARP NUD".

>    benefits, and it has a lot of downsides. It totally depends on what you try 

That's why I used "may".

Link layer multicasts should be used when they're better than what I've described. However, when link-layer multicasts are not going to perform as well as replication and link-layer unicasts, or when some of the other differences of replication and link-layer unicast are beneficial (i.e., better data confidentiality, better battery life on mobile devices like tablets, smartphones etc.), then what is described could be used.

The operating models were really just to highlight that not only could it be done on a per-group basis, but might also be useful to adopt for all groups on an interface, which may be a useful default model for an 802.11 interface.

>    situation correctly in the doc.

While I agree the doc is light on referenced evidence, I think it still describes the situation correctly, because I've done experiments of my own, and have seen bad multicast video over wifi, and have seen multicast traffic impact unicast performance. 

>    total number of receivers tracked and bandwidth sent over the group/channel 

I can't think of a situation when falling back to multicast after using replicated link-layer unicast would be useful. I consider what I've described to be an alternative to link-layer multicast, to be used when either it is either known or likely from the outset that link-layer multicast will be inadequate, or when replication and link-layer unicast provides some useful advantages over link-layer multicast. Falling back to link-layer multicast wouldn't solve the replication and link-layer unicast performance problems if they've occurred (otherwise, use multicast in the first place), or would eliminate the useful advantages that replication and link-layer unicast provided.

I know it is possible to tune 802.11 to provide better multicast performance, however I understand that that tuning requires changing settings on all of the AP clients, as well as possibly on the AP, and if one new client which isn't tuned joins the link, performance drops back to before any tuning took place. This tuning would be beyond the capability of most residential home users.

Another thought I've had is that as wired switches are doing this type of packet replication and effectively link-layer unicasting out their individual ports, perhaps in the future the hardware doing this could also be adapted to increase the performance of replication and link-layer unicasting over 802.11.

>    this dyanmicac switching, i am just saying it sounds logical to me ;-)

This generally sounds to me to be above layer 3 (and the interface to layer 2) and be in the domain of either things like RSVP, or applications/protocols that already provide reliable multicast, mainly because I think it is necessary for the receiver to indicate to the sender success or failure of packet delivery.

It could be done also be done on a link layer level, and I understand that 802.11 probably has enough mechanisms to be able to do this (e.g. acknowledgements and retransmissions). However, while 802.11 is the most likely use case for what I've described, I think there are benefits in keeping it generic, and applicable to any current or future link-layers which support both multicast and unicast transmission. For example, multicast over wired ethernet is (usually?) going to outperform replication and link-layer unicast (although, as a few people have pointed out off-list, switches are in effect doing replicating and link unicasting to emulate broadcast/multicast behaviour), however the other benefits may mean it is preferable to use what I've described instead of link-layer multicast.

>    protocol group (i think... ).

Thanks again.

Best regards,
Mark.

>>  >________________________________
>>  > From: Behcet Sarikaya <[email-masked]>
>>  >To: Dave Thaler <[email-masked]> 
>>  >Cc: Mark Smith <[email-masked]>; 
> "[email-masked]" <[email-masked]>; "[email-masked]" 
> <[email-masked]> 
>>  >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 
>>  >
>>  >
>>  >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 
>>  >
>>  >
>>  >
>>  >
>>  > I suggest you take a look at 
>>  >on Netext for PMIPv6.
>>  >
>>  >
>>  >I'll have a read.
>>  >
>>  >I believe that we should use multicast delivery as much as possible on 
>>  >
>>  >
>>  >
>>  >
>>  >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
>>  >
>>  >
>>  >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, 
>>  >
>>  >
>>  >Thanks very much,
>>  >Mark.
>>  >
>>  >
>>  >
>>  >Regards,
>>  >
>>  >Behcet
>>  >
>>  >
>>  >
>>  >
>>  >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler 
> <[email-masked]> wrote:
>>  >
>>  >http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast
>>  >>is work we did back in 2000 on this same topic.   At the time, the 
> draft is written from
>>  >>the perspective of the 6to4 NBMA link, but the topic was discussed 
> (specifically by those
>>  >>in the acknowledgements section, and to a lesser extent by the 
> ngtrans WG as a whole)
>>  >>as being more generally applicable.
>>  >>
>>  >>There wasn't significant interest at the time and so the work 
> was dropped
>>  >>rather than updating the spec to use generic language.
>>  >>
>>  >>The same concept as in the above was however then used in 2001 in
>>  >>http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast
>>  >>(still specific to a particular link type though), which after 11 
> years is now in the IESG :)
>>  >>
>>  >>The most relevant WG is MBoneD.
>>  >>
>>  >>-Dave
>>  >>
>>  >>
>>  >>> -----Original Message-----
>>  >>> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
>>  >>> Mark Smith
>>  >>> Sent: Thursday, March 28, 2013 8:22 PM
>>  >>> To: [email-masked]
>>  >>> Subject: "MLDv2 Procedures for Link-Layer Unicast 
> Delivery of Multicast"
>>  >>>
>>  >>> Hi,
>>  >>>
>>  >>> The following is inspired by some work I did in around 
> 2010/2011 on a
>>  >>> multicast TV service, where residential customers with Wifi 
> networks
>>  >>> suffered from performance problems, and had to be advised to 
> buy
>>  >>> ethernet over power devices if they couldn't run wired 
> ethernet to the STB
>>  >>> attached to their TV.
>>  >>>
>>  >>> I've done some experiments on my home wifi network, using 
> VLC, and
>>  >>> switching between multicast and unicast IPv6 to test the 
> concept. The wifi
>>  >>> performance issues disappear when the video is delivered via 
> unicast UDP.
>>  >>> (If people want to play with VLC and IPv6 multicast, email me 
> off-list, as there
>>  >>> are a few issues e.g. the GUI doesn't accept some of the 
> IPv6 multicast
>>  >>> parameters that the command line does).
>>  >>>
>>  >>> I think there is a possibility the technique could also be 
> applied to
>>  >>> IGMPv3/ARP, although it depends on whether ARP has been 
> implemented
>>  >>> in a similar manner to IPv6 ND (e.g. an ARP equivalent to 
> NUD). My
>>  >>> understanding is that Linux has implemented ARP this way. 
> I'll do some more
>>  >>> research to verify this.
>>  >>>
>>  >>> I though I'd post it to see if there is merit in the idea 
> and it is worth spending
>>  >>> more of my time on. I looked for a IETF group more suitable to 
> this, but didn't
>>  >>> seem to be able to find one. If there is one, please let me 
> know.
>>  >>>
>>  >>> Review and comments most appreciated.
>>  >>>
>>  >>> Thanks very much,
>>  >>> Mark.
>>  >>>
>>  >>>
>>  >>> ----- Forwarded Message -----
>>  >>> > From: "[email-masked]" 
> <[email-masked]>
>>  >>> > To: [email-masked]
>>  >>> > Cc:
>>  >>> > Sent: Friday, 29 March 2013 1:45 PM
>>  >>> > Subject: New Version Notification for
>>  >>> > draft-smith-mldv2-link-unicast-00.txt
>>  >>> >
>>  >>> >
>>  >>> > A new version of I-D, 
>>  >>> > has been successfully submitted by Mark Smith and posted 
> to the IETF
>>  >>> > repository.
>>  >>> >
>>  >>> > Filename:     draft-smith-mldv2-link-unicast
>>  >>> > Revision:     00
>>  >>> > Title:         MLDv2 Procedures for Link-Layer Unicast 
> Delivery of
>>  >>> > Multicast
>>  >>> > IPv6
>>  >>> > Creation date:     2013-03-29
>>  >>> > Group:         Individual Submission
>>  >>> > Number of pages: 7
>>  >>> > URL:
>>  >>> > 
>>  >>> > txt
>>  >>> > Status:
>>  >>> > 
>>  >>> > Htmlized:
>>  >>> > 
>>  >>> >
>>  >>> >
>>  >>> > Abstract:
>>  >>> >    Some multi-access link-layer technologies typically 
> not provide
>>  >>> > good
>>  >>> >    IPv6 multicast performance, using link-layer 
> multicasts, when the
>>  >>> >    volume of multicast traffic is significant.  It would 
> be possible
>>  >>> > to
>>  >>> >    replicate and then link-layer unicast multicast IPv6 
> traffic to
>>  >>> >    interested listeners to overcome these link-layer 
> performance
>>  >>> >    limitations.  This memo describes MLDv2 and IPv6 
> neighbor discovery
>>  >>> >    procedures to support link-layer unicast delivery of 
> multicast IPv6
>>  >>> >    traffic.
>>  >>> >
>>  >>> >
>>  >>> >
>>  >>> >
>>  >>> >
>>  >>> > The IETF Secretariat
>>  >>> >
>>  >>> 
>>  >>> IETF IPv6 working group mailing list
>>  >>> [email-masked]
>>  >>> Administrative Requests: 
> https://www.ietf.org/mailman/listinfo/ipv6
>>  >>> 
>>  >>_______________________________________________
>>  >>MBONED mailing list
>>  >>[email-masked]
>>  >>https://www.ietf.org/mailman/listinfo/mboned
>>  >>
>>  >
>>  >
>>  >