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

[Behcet Sarikaya <[e-mail]>]

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

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



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
>    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:
> > Hi Behcet,
> >
> > Thanks for your review and comments.
> >
> >
> >
> > >________________________________
> > > From: Behcet Sarikaya <[e-mail]>
> > >To: Dave Thaler <[e-mail]>
> > >Cc: Mark Smith <[e-mail]>; "[e-mail]" <
> [e-mail]>; "[e-mail]" <[e-mail]>
> > >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.
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > >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.
> > >
> > >
> > >Thanks very much,
> > >Mark.
> > >
> > >
> > >
> > >Regards,
> > >
> > >Behcet
> > >
> > >
> > >
> > >
> > >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of
> > >>> Mark Smith
> > >>> Sent: Thursday, March 28, 2013 8:22 PM
> > >>> To: [e-mail]
> > >>> 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: "[e-mail]" <[e-mail]>
> > >>> > To: [e-mail]
> > >>> > 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
> > >>> >
> > >>> --------------------------------------------------------------------
> > >>> IETF IPv6 working group mailing list
> > >>> [e-mail]
> > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > >>> --------------------------------------------------------------------
> > >>_______________________________________________
> > >>MBONED mailing list
> > >>[e-mail]
> > >>https://www.ietf.org/mailman/listinfo/mboned
> > >>
> > >
> > >
> > >
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
>
> --
> ---
> Toerless Eckert, [e-mail]
> Cisco NSSTG Systems & Technology Architecture
> SDN: Let me play with the network, mommy!
>
>