Re: [multrans] Section 4.5. "Combination of ASM and SSM Modes" in the Problem Statement
<christian.jacquenet@orange-ftgroup.com> Tue, 07 June 2011 13:48 UTC
Return-Path: <christian.jacquenet@orange-ftgroup.com>
X-Original-To: multrans@ietfa.amsl.com
Delivered-To: multrans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 3526E11E80E7 for <multrans@ietfa.amsl.com>;
Tue, 7 Jun 2011 06:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1,
UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LIGDjS43I0J for
<multrans@ietfa.amsl.com>; Tue, 7 Jun 2011 06:48:53 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com
[193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0412611E808E for
<multrans@ietf.org>; Tue, 7 Jun 2011 06:48:52 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by
omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7A51F264221;
Tue, 7 Jun 2011 15:48:51 +0200 (CEST)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by
omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5F4C54C06D;
Tue, 7 Jun 2011 15:48:51 +0200 (CEST)
Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.8]) by
PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi;
Tue, 7 Jun 2011 15:48:51 +0200
From: <christian.jacquenet@orange-ftgroup.com>
To: Tom Taylor <tom111.taylor@bell.net>,
"multrans@ietf.org" <multrans@ietf.org>
Date: Tue, 7 Jun 2011 15:48:50 +0200
Thread-Topic: [multrans] Section 4.5. "Combination of ASM and SSM Modes" in
the Problem Statement
Thread-Index: AcwlFezZkUWI5ZI8QwyWkY/mD1y0UwAAp5ZQ
Message-ID: <21066_1307454531_4DEE2C43_21066_5490_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AEEF0FACA@PUEXCB1C.nanterre.francetelecom.fr>
References: <BLU0-SMTP705FC414D1C22816F7CAE9D8630@phx.gbl>
In-Reply-To: <BLU0-SMTP705FC414D1C22816F7CAE9D8630@phx.gbl>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379,
Antispam-Data: 2011.6.7.123315
Subject: Re: [multrans] Section 4.5. "Combination of ASM and SSM Modes" in
the Problem Statement
X-BeenThere: multrans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss the work of IPv4-IPv6 multicast." <multrans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multrans>,
<mailto:multrans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multrans>
List-Post: <mailto:multrans@ietf.org>
List-Help: <mailto:multrans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multrans>,
<mailto:multrans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2011 13:48:54 -0000
Tom, Please see inline. [snip] Section 4.5 is really talking about multicast sub-tree optimization, achieved by taking advantage of the fact that there are multiple sources, each with its own tree to start with. ASM is just a speculative approach to the method of achieving this. It's not full ASM anyway, since there is no intention to treat the IPv4 sources as receivers. CJ: ASM does not necessarily assume the source/receiver heuristic. It's about shared trees whose root happens to be a router of the multicast network. Nothing prevents you from using ASM to deliver live TV broadcasting for example. I assume that the optimization criterion is to reduce the aggregate capacity required to carry the flows through the IPv6 network. I don't know whether the intended algorithm is meant to operate dynamically each time a receiver requests a multicast stream, or is meant to operate offline given the stable positions of the sources, at least. In any event, this sounds like an interesting research project, but I don't think it's a suitable topic for the Problem Statement. CJ: well, if you consider the case where service provider #1 operates the IPv4 multicast domain in a SSM fashion and (access) service provider #2 decides to operate the IPv6 multicast domain in an ASM fashion for some reason, I think it may be an interesting research project (although I don't really get what your above notion of intended algorithm is about), but it can surely be a possible use case, especially in wholesale or deregulated access environments. This is why I still think the section is worth the elaboration. Cheers, Christian. My vote is to drop the section. Tom Taylor _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ********************************************************************************
- [multrans] Section 4.5. "Combination of ASM and S… Tom Taylor
- Re: [multrans] Section 4.5. "Combination of ASM a… christian.jacquenet
- Re: [multrans] Section 4.5. "Combination of ASM a… Tom Taylor
- Re: [multrans] Section 4.5. "Combination of ASM a… Jacni Qin