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:
> 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.
> >
> >
> >
> >
> > 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 <dtha...@microsoft.com> 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: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> >>> Mark Smith
> >>> Sent: Thursday, March 28, 2013 8:22 PM
> >>> To: 6...@ietf.org
> >>> 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: "internet-dra...@ietf.org" <internet-dra...@ietf.org>
> >>> > To: markzzzsm...@yahoo.com.au
> >>> > 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
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>_______________________________________________
> >>MBONED mailing list
> >>mbo...@ietf.org
> >>https://www.ietf.org/mailman/listinfo/mboned
> >>
> >
> >
> >
> _______________________________________________
> MBONED mailing list
> mbo...@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
--
---
Toerless Eckert, eck...@cisco.com
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
