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

Dave Thaler <dthaler@microsoft.com> Fri, 29 March 2013 20:55 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54021F900B; Fri, 29 Mar 2013 13:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level:
X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jvCY+aO92Iv; Fri, 29 Mar 2013 13:55:44 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1D09C21F8FFB; Fri, 29 Mar 2013 13:55:37 -0700 (PDT)
Received: from BN1AFFO11FD025.protection.gbl (10.58.52.203) by BN1BFFO11HUB012.protection.gbl (10.58.53.122) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 29 Mar 2013 20:55:36 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD025.mail.protection.outlook.com (10.58.52.85) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 29 Mar 2013 20:55:34 +0000
Received: from TK5EX14MBXC264.redmond.corp.microsoft.com ([169.254.1.147]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 29 Mar 2013 20:55:22 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Mark Smith <markzzzsmith@yahoo.com.au>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
Thread-Index: AQHOLEbBhGcMf7SEYEaquPa3Oodmxpi9JP9Q
Date: Fri, 29 Mar 2013 20:55:21 +0000
Message-ID: <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com>
References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com>
In-Reply-To: <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.78]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377424002)(189002)(13464002)(51704002)(377454001)(65816001)(50986001)(47446002)(49866001)(20776003)(47776003)(47976001)(50466001)(74502001)(16406001)(33656001)(47736001)(74662001)(31966008)(69226001)(79102001)(55846006)(51856001)(63696002)(5343655001)(15202345001)(4396001)(80022001)(81342001)(54316002)(23756002)(59766001)(56816002)(56776001)(53806001)(76482001)(54356001)(77982001)(46102001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB012; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0800C0C167
Cc: "mboned@ietf.org" <mboned@ietf.org>
Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 20:55:45 -0000

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-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Mark Smith
> Sent: Thursday, March 28, 2013 8:22 PM
> To: 6man@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-drafts@ietf.org" <internet-drafts@ietf.org>
> > To: markzzzsmith@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
> --------------------------------------------------------------------