Re: [multrans] Section 4.5. "Combination of ASM and SSM Modes" in the Problem Statement

[Jacni Qin <[e-mail]>]

Hi Tom,

On Wed, Jun 8, 2011 at 12:32 AM, Tom Taylor <[e-mail]> wrote:

> My major point is that you are trying to achieve tree optimization. ASM
> is just a means to that end. There could be other solutions. So it
> certainly doesn't belong in the title of the section.
>
> If you are looking for use cases, I have more pressing ones for you to
> consider. True ASM, as for videoconferencing, is one of them.


Jacni>: FYI, as stated in the scope section, this kind of service is out of
the scope.


Cheers,
Jacni


>
>
> On 07/06/2011 9:48 AM, [e-mail] wrote:
>
>> 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 [e-mail]
>> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multrans
>