Re: Multicast PS to requirements

Hi,

Agreed.

Regards,
Sérgio

On 12/04/2012 06:28 PM, h chan wrote:
>
> Instead of "especially," we can change to "for example." Non-optimal 
> routes can take place in other cases too.
>
> H Anthony Chan
>
> *From:*[email protected] [mailto:[email protected]] *On Behalf 
> Of *LUIS MIGUEL CONTRERAS MURILLO
> *Sent:* Wednesday, November 21, 2012 2:38 AM
> *To:* Sérgio Figueiredo; [email protected]
> *Subject:* Re: [DMM] Multicast PS to requirements
>
> Thanks Sergio, Seil,
>
> Just a final comment. For PS1, not sure if the word "especially" in 
> the sentence "The problem is especially manifested ..." should be removed.
>
> Regards,
>
> Luis
>
> *De:*[email protected] [mailto:[email protected]] *En nombre de 
> *Sérgio Figueiredo
> *Enviado el:* miércoles, 21 de noviembre de 2012 0:21
> *Para:* [email protected]
> *Asunto:* Re: [DMM] Multicast PS to requirements
>
> Hi Luis,
>
> A few more comments on this inline:
>
> Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
>
>     Hi Anthony,
>
>     some comments in line
>
>     Best regards,
>
>     Luis
>
>     *De:*[email protected] <mailto:[email protected]>
>     [mailto:[email protected]] *En nombre de *h chan
>     *Enviado el:* martes, 20 de noviembre de 2012 18:51
>     *Para:* Sérgio Figueiredo; [email protected] <mailto:[email protected]>
>     *Asunto:* [DMM] Multicast PS to requirements
>
>     Let us also use another thread to check for consensus of the PS
>     from multimob.
>
>     PS1 (revised): Non-optimal routes
>
>     Routing via a centralized anchor often results in a longer route.
>     The problem is especially manifested when accessing a local server
>     or servers of a Content Delivery Network (CDN), *or when receiving
>     / sending IP multicast packets*.
>
>     */[Luis>>] This is correct if the multicast content is locally
>     available. However this could not be always the case for multicast
>     listeners, for a number of reasons (for instance, conflict in the
>     multicast address allocation between the Home Network and the DMM
>     domain). /*
>
> [SF] Sure, and the same applies to "accessing a local server a CDN" - 
> it is implicit that the content is locally available. But it can be 
> improved as "when receiving locally available IP multicast or sending 
> IP multicast".
>
> PS6: Duplicate multicast traffic
>
> IP multicast distribution over architectures using IP mobility 
> solutions  may lead to convergence of duplicated multicast 
> subscriptions towards the tunnel's downstream entity (e.g. MAG in 
> PMIPv6).  Concretely, when multicast subscription for individual 
> mobile nodes is coupled with mobility tunnels, duplicate multicast 
> subscription(s) is prone to be received through different upstream 
> paths. This problem is potentially more severe in a distributed 
> mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
> *//*
>
> */[Luis>>] This seems not to be a problem of the IP mobility solutions 
> handling multicast traffic with mobility tunnels in general, but a 
> problem of considering several upstream paths ending on the same 
> mobility access router as a consequence of extending tunnels from 
> previousMAR to newMAR to forward the multicast traffic./*
>
> [SF] Exactly. Which is more than likely to happen in a DMM solution, 
> where all "mobility entities" may act as "mobility access routers", 
> and, after mobility, we want to take advantage of the tunnel for the 
> subscription. In those cases, care must be taken in order to not 
> greatly magnify convergence problem observed e.g. in RFC6224.
>
> Regards,
> Sérgio
>
> H Anthony Chan
>
> *From:*[email protected] <mailto:[email protected]> 
> [mailto:[email protected]] *On Behalf Of *Sérgio Figueiredo
> *Sent:* Monday, November 19, 2012 5:24 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [DMM] Multicast requirements
>
> Hi Anthony,
>
> Thank you for trying to progress on this matter. I mostly agree with 
> your analysis.
>
> As for the question you posed, first I would like to exactly 
> understand what you mean with "multicast distribution scenario" in 
> "DMM solutions should enable multicast services which are compatible 
> with multicast distribution scenario, etc.". It seems like there is no 
> major difference between this and the "DMM solutions should enable 
> solutions to support multicast services." requirement? Aren't both 
> expressing the need to enable multicast in a DMM solution?
>
> As you stated, "neglecting" the requirement 7.1 we proposed, leads to 
> the PSs you referred.  So, while 7.2 and 7.3 express the need for DMM 
> solutions to allow deployment of multicast services, 7.1 concerns  
> "how" IP multicast should be enabled in order to avoid the 
> aforementioned PSs. The usage of the word "flexible"is explained by:
>
> "This flexibility enables different IP multicast flows with respect to 
> a mobile host to be managed (e.g., subscribed, received and/or 
> transmitted) using multiple endpoints".
>
> In other words, compatibility with "multicast distribution scenario" 
> doesn't necessarily avoid PS1 and PS6.
>
> Thank you and best regards,
> Sérgio
>
> On 11/19/2012 10:28 PM, h chan wrote:
>
>     There are 3 proposals for multicast requirements. Before comparing
>     these proposals, let us understand what are the problems first.
>     Two problem statements have been proposed:
>
>     PS1 (revised): Non-optimal routes
>
>     Routing via a centralized anchor often results in a longer route.
>     The problem is especially manifested when accessing a local server
>     or servers of a Content Delivery Network (CDN), *or when receiving
>     / sending IP multicast packets*.
>
>     PS6: Duplicate multicast traffic
>
>     IP multicast distribution over architectures using IP mobility
>     solutions  may lead to convergence of duplicated multicast
>     subscriptions towards the tunnel's downstream entity (e.g. MAG in
>     PMIPv6). Concretely, when multicast subscription for individual
>     mobile nodes is coupled with mobility tunnels, duplicate multicast
>     subscription(s) is prone to be received through different upstream
>     paths. This problem is potentially more severe in a distributed
>     mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>     Then, let us see whether all the 3 REQ proposals have the same
>     intention. In the following, I rephrase them to highlight their
>     similarities.
>
>     REQ7.1: Flexible multicast distribution
>
>     DMM solutions should be compatible with flexible multicast
>     distribution scenario. Etc.
>
>     The Motivation is to allow flexibility in (enable) multicast
>     solutions to solve the problems PS1 and PS6 as explained in use
>     cases already presented and discussed in multimob wg.
>
>     REQ7.2:
>
>     DMM solutions should enable solutions to support multicast traffic.
>
>     (Original wording was "The DMM (unicast) solution MUST be
>     specified in such a way that it can be extended to also support
>     multicast traffic." I rephrase it to highlight the similarity with
>     the other proposals and also changed the must to should.)
>
>     REQ7.3:
>
>     DMM solutions should enable solutions to support multicast services.
>
>     Original wording was "DMM solutions should support multicast
>     services ... etc. Given that it is the scope of multimob and not
>     dmm wg to provide the multicast solution, I think "support" here
>     means "enable" solutions to be developed (by multimob).
>
>     Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to
>     enable multicast services. Yet the explanation in REQ7.1 seems to
>     indicate not just to enable any one multicast solution but also
>     needs the flexibility in multicast solution. Not all multicast
>     solutions are the same. Some of them results in PS1 or PS6.
>
>     Are there any are essential differences between:
>
>     In REQ7.1, DMM solutions should be compatible with flexible
>     multicast distribution scenario, etc.
>
>     Versus
>
>     DMM solutions should enable multicast services which are
>     compatible with multicast distribution scenario, etc.
>
>     H Anthony Chan
>
>     *From:*[email protected] <mailto:[email protected]>
>     [mailto:[email protected]] *On Behalf Of *Seil Jeon
>     *Sent:* Monday, November 19, 2012 5:15 AM
>     *To:* [email protected] <mailto:[email protected]>
>     *Cc:* [email protected] <mailto:[email protected]>
>     *Subject:* Re: [DMM] Multicast requirements
>
>     Hi Pierrick,
>
>     I've many times thought about your question. I would say how
>     effectively should we deploy/support multicast over distributed
>     mobility rather than distributed mobile multicast. As a result,
>     you can find this deployment use case and gap analysis at
>     http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03
>     presented in multimob several times.
>
>     In unicast DMM, main innovation is to distribute the anchor
>     function at many access routers from single core. Following
>     architectural concept of DMM, flexible multicast distribution is
>     one of multicast requirement resulted from the draft described above.
>
>     REQ8: Flexible multicast distribution
>
>     "DMM solutions SHOULD be compatible with flexible multicast
>     distribution scenarios. This flexibility enables different IP
>     multicast flows with respect to a mobile host to be managed (e.g.,
>     subscribed, received and/or transmitted) using multiple endpoints".
>
>     Motivation: The motivation for this requirement is to enable
>     flexibility in multicast distribution. The multicast solution may
>     therefore avoid having multicast-capable access routers being
>     restricted to manage all IP multicast traffic relative to a host
>     via a single endpoint (e.g. regular or tunnel interface), which
>     would lead to the problems described in PS1 and PS6.
>
>     PS6: Duplicate multicast traffic
>
>     IP multicast distribution over architectures using IP mobility
>     solutions  may lead to convergence of duplicated multicast
>     subscriptions towards the tunnel's downstream entity (e.g. MAG in
>     PMIPv6).  Concretely, when multicast subscription for individual
>     mobile nodes is coupled with mobility tunnels, duplicate multicast
>     subscription(s) is prone to be received through different upstream
>     paths. This problem is potentially more severe in a distributed
>     mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03].
>
>     Regards,
>
>     Seil
>
>     *From:*[email protected]
>     <mailto:[email protected]> [mailto:[email protected]]
>     *Sent:* Monday, November 19, 2012 8:55 AM
>     *To:* '[email protected] <mailto:[email protected]>';
>     [email protected] <mailto:[email protected]>;
>     [email protected]
>     <mailto:[email protected]>
>     *Cc:* [email protected] <mailto:[email protected]>
>     *Subject:* RE: [DMM] Multicast requirements
>
>     Hi all,
>
>     I tend to agree with Georgious, however I still do not figure out
>     what is the use-case for distributed mobile multicast (other than
>     academic considerations)? Can someone give concrete example?
>
>     I haven't real all messages from this thread. So, maybe I missed
>     important points.
>
>     BR,
>
>     Pierrick
>
>     *De :*[email protected] <mailto:[email protected]>
>     [mailto:[email protected]] *De la part de*
>     [email protected] <mailto:[email protected]>
>     *Envoyé :* samedi 17 novembre 2012 13:01
>     *À :* [email protected] <mailto:[email protected]>;
>     [email protected]
>     <mailto:[email protected]>
>     *Cc :* [email protected] <mailto:[email protected]>
>     *Objet :* Re: [DMM] Multicast requirements
>
>     Hi all,
>
>     I also agree that the DMM solution should somehow consider
>     muticast deployment. However, I do not thnk that the DMM WG is the
>     right WG to provide the multicast based DMM solution!
>
>     One alternative solution will be to have a multicast requirement
>     that emphasizes the need of having extensibility hooks
>     (possibilities) that can be used later on by the multimob WG to
>     provide a
>
>     a multicast enabled DMM solution!
>
>     So a requirement that specifies something like the following could
>     be used for this purpose:
>
>     "The DMM (unicast) solution MUST be specified in such a way that
>     it can be extended to also support multicast traffic."
>
>     Best regards,
>
>     Georgios
>
>     ------------------------------------------------------------------------
>
>     *Van:*[email protected] <mailto:[email protected]>
>     [[email protected] <mailto:[email protected]>] namens Seil
>     Jeon [[email protected] <mailto:[email protected]>]
>     *Verzonden:* vrijdag 16 november 2012 22:25
>     *To:* 'Zuniga, Juan Carlos'
>     *Cc:* [email protected] <mailto:[email protected]>
>     *Onderwerp:* Re: [DMM] Multicast requirements
>
>     Hi Juan,
>
>     I've been looked at changed flow of your proposed text but sorry
>     now that my
>     comment is posted.
>     At first time, I couldn't make sure however, on hearing Stig's
>     description,
>     it seems quite reasonable at the first step, not giving any
>     restrictions but
>     leaving some-specific for the DMM solution it does not support
>     multicast.
>
>     On the other hand, it remains at a basic stage for the DMM solution to
>     support multicast.
>     So I think additional requirements need to be made for the DMM
>     solution,
>     accordingly. But of course, this should not also give any specific
>     limitation and restriction but should be made towards the
>     direction not
>     limiting the benefits provided by distributed deployment.
>
>     I hope to get more comments on this.
>
>     Regards,
>
>     Seil
>
>
>     -----Original Message-----
>     From: [email protected] <mailto:[email protected]>
>     [mailto:[email protected]] On Behalf Of
>     Zuniga, Juan Carlos
>     Sent: Friday, November 16, 2012 8:14 PM
>     To: Stig Venaas; [email protected] <mailto:[email protected]>
>     Subject: Re: [DMM] Multicast requirements
>
>
>     > -----Original Message-----
>     > From: Stig Venaas [mailto:[email protected]]
>     > Sent: Friday, November 16, 2012 3:01 PM
>     > To: jouni korhonen
>     > Cc: [email protected] <mailto:[email protected]>; Zuniga, Juan
>     Carlos; Konstantinos Pentikousis;
>     > Peter McCann; [email protected] <mailto:[email protected]>
>     > Subject: Re: [DMM] Multicast requirements
>     >
>     > On 11/15/2012 3:17 AM, jouni korhonen wrote:
>     > >
>     > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote:
>     > >
>     > >>
>     > >> I think we are reading too much into multicast and unicast should
>     be
>     > >> designed in an integrated manner.
>     > >>
>     > >> The fact is that multicast is considered as an area of
>     > specialization,
>     > >> it requires knowledge of very different protocols than we are
>     > >> accustomed to in mobility.
>     > >
>     > > "Requirement: DMM solutions SHOULD support multicast services.
>     If a
>     > specific DMM solution does not support multicast services, an
>     > explanation MUST be provided."
>     >
>     > This sounds good to me.
>     >
>     > The main thing I want to achieve is what was describes as
>     motivation
>     > earlier in this thread. Multicast should at least be considered
>     when
>     > looking into DMM solutions, and not just an afterthought once the
>     > solution is decided.
>     >
>     > Stig
>
>     [JCZ] I fully agree with this. That was the intention of the
>     proposed text.
>
>     Regards,
>
>     Juan Carlos
>
>     >
>     > > To me that reads basically "do not break foundations for multicast
>     > unless you have a valid & documented reason for it".  If we look
>     e.g.
>     > into RFC625 multicast wording that is there very briefly but
>     gives a
>     > hint to a developer where to head to. That is the level I would
>     expect
>     > DMM documents should aim to.
>     > >
>     > > - Jouni
>     > >
>     > >
>     > >> Let dmm deal with its current charter that does not include a
>     word
>     > of
>     > >> multicast and if everything goes well we can come back and
>     discuss
>     > dmm
>     > >> multicast.
>     > >>
>     > >> Regards,
>     > >>
>     > >> Behcet
>
>     _______________________________________________
>     dmm mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/dmm
>
>     _______________________________________________
>     dmm mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/dmm
>
>     _________________________________________________________________________________________________________________________
>
>       
>
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
>     France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>       
>
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>
>     they should not be distributed, used or copied without authorisation.
>
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>
>     As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
>
>     Thank you.
>
>
>
>     _______________________________________________
>
>     dmm mailing list
>
>     [email protected]  <mailto:[email protected]>
>
>     https://www.ietf.org/mailman/listinfo/dmm
>
> ------------------------------------------------------------------------
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>
> _______________________________________________
> dmm mailing list
> [email protected]  <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dmm
>
> ------------------------------------------------------------------------
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm