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

[Tom Taylor <[e-mail]>]

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.

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