Re: [multimob] Comparing the proposals for basic multicast support

["Thomas C. Schmidt" <[e-mail]>]

Dear Guang,

indeed, you are right. I got confused with the large number of upcoming
documents :-(, which all exhibit a large overlap in the proposed design
space.

What I was referring to is draft draft-contreras-multimob-msd-00.txt, see
http://www.ietf.org/id/draft-contreras-multimob-msd-00.txt

by Luis M. Contreras, Carlos J. Bernardos, and Ignacio Soto of UC3M.

So everything I wrote applies to the above document and not to your draft.

Sorry for the confusion - that was just a mistake.

To make up for the confusion, I'll try to do a review on your draft asap ;)

Thanks & best regards,

Thomas

Lu, Guang wrote:
> Dear Thomas, 
> 
> I read through your comments and quotes from the draft. It seems to me
> that you are referring to another draft that was submitted recently,
> except that the dedicated multicast LMA is proposed in our draft. Here
> is the link of our draft. 
> 
> http://tools.ietf.org/html/draft-zuniga-multimob-smspmip-00
> 
> Could you please verify it? 
> 
> Best Regards,
> Guang
> 
> 
> -----Original Message-----
> From: Thomas C. Schmidt [mailto:[e-mail]] 
> Sent: Friday, October 23, 2009 7:43 PM
> To: Lu, Guang
> Cc: Stig Venaas; [e-mail]
> Subject: Re: [multimob] Comparing the proposals for basic multicast
> support
> 
> Dear Guang and Juan Carlos,
> 
> we've read your draft and thought about it. Here are our comments:
> 
> On the overall, we read your draft as a review on existing PMIPv6 
> multicast extensions that include some additional modifications and some
> 
> inexact generalizations. In summary it appears like an exploration of a 
> possible design space - is this what you intended?
> 
> Further on, you sketch several concurrent multicast mobility solutions, 
> but this procedure is not well reflected in your document structure. So 
> it is somewhat hard to sort out what statement belongs to which approach
> 
> under consideration.
> 
> Finally, this work is grounded on the problems analyzed and 
> characterized in
> [I-D.irtf-mobopts-mmcastv6-ps]
>                Schmidt, T.C., Waehlisch, M., Fairhurst, G.,
>                "Multicast Mobility in MIPv6: Problem Statement and Brief
> 
> Survey",
>                draft-irtf-mobopts-mmcastv6-ps-09 (work in progress), 
> October 2009,
> 
> as well as on the discussions initiated by the problem statement work. 
> So IMO it makes a lot of sense to give reference to the state of work 
> you rely on.
> 
> In detail:
> 
> In section 3 you state
> "In order to manage multicast traffic terminated on an MN, the LMA would
> 
> need to keep the multicast status for every MN subscribing to a
> content."
> This seems as wrong as it is for any multicast router in a multicast 
> enabled network. PMIP does not change the world here.
> 
> Section 4 (first paragraph):
> 
> You require that any MN requests multicast services only after it has 
> registered within a specific PMIP domain. This - aside from technical 
> questions - appears odd to me: If a user watches IPTV on some train 
> station (fixed network) and intends to continue while boarding the train
> 
> (PMIP domain), and does so while later changing into another train of a 
> different company (a new PMIP domain), there are no obvious reasons why 
> this should not work.
> 
> Section 5:
> 
> You state "the LMA will not play any specific role in the multicast 
> traffic management"
> This is inconsistent with solutions you describe later, e.g., a 
> multicast-specific dedicated LMA ...
> 
> Section 6.1:
> 
> You describe a scenario, where MAGs have an uplink to one dedicated 
> multicast-specific LMA: "In this draft, just one MLD proxy instance is 
> considered to be running in the MAG, and as consequence, just one 
> interface can be defined as upstream interface."
> 
> A corresponding deployment would be as follows: Operators have a PMIP 
> (unicast) domain and add (and statically pre-configure at MAGs) an 
> additional multicast LMA that serves all groups. This is a set-up not 
> considered so far, but may be feasible for operators???
> 
> ==> Operator comments should debate on that.
> 
> Section 6.2:
> 
> You write "... In that case, the multicast distribution tree could be 
> extended over the
>     tunnel between MAG and LMA, once that tunnel has been set up."
> 
> Below you state that no MTU issues arise. This is inconsistent.
> 
> Section 7.1.:
> 
> You emphasize that an MLD general query at the MAG wasts resources. We 
> would debate that and argue that it is negligible. Keeping in mind that 
> PMIP operates on router solicitations / router advertisements, an MLD 
> query (which could run in parallel) does by no means bend the resource 
> consumption of an MN on handover.
> 
> Section 7.2.:
> 
> You rely on an autonomous context transfer mechanism between MAGs. 
> Thereby you refer to a context transfer in 
> [draft-sijeon-multimob-mms-pmip6] which is not well defined, and later 
> to RFC 4067. IMHO the problem is not solved that easily. PMIP defines an
> 
> explicit context transfer for "MN's policy profile" that does not cover 
> multicast. RFC 4067 is an abstract protocol that does not define 
> explicit messaging for multicast context transfer. So I don't see that 
> the current specs do allow for multicast context transfer without any 
> protocol extensions. Rather, an indication is given on "what to do in 
> future work" - which we perfectly agreed upon. This work however is out 
> of scope from the charter for now.
> 
> Section 7.3.:
> 
> You propose an pMAG-assisted handover in the following way: pMAG 
> receives multicast traffic via the LMA, then forwards traffic to nMAg 
> via the LMA again. This leads to a traffic flow of the form:
> 
>     mcast source ===> LMA ==> pMAG ==> LMA ==> nMAG ==> MN,
> 
> which is of obvious Zig-Zag form. The already published solutions 
> propose a direct flow via a tunnel (which is quickly erected), and are 
> thus much more efficient.
> 
> So I wonder what the benefit of this "recurved flow" solution should be?
> 
> Finally you state below: "Enhanced mobility depends on the availability 
> of handover triggers,..." - I wonder how this relates to your draft and 
> the problem? L2 triggers are beneficial for the base handover 
> management, but multicast operations sit on top of it. As described in 
> the problem statement, you cannot expect multicast to be faster than 
> L2/L3 attachment, but the issue of protocol design is to define 
> solutions that are not significantly slower!
> 
> Hope I hit some of your open points.
> 
> Best regards,
> 
> Thomas
> 
> Lu, Guang wrote:
>> Hello all,
>>
>> Below you will find some more information about our draft: 
>> http://tools.ietf.org/html/draft-zuniga-multimob-smspmip-00 
>>
>> We will be glad to present this proposal at the meeting, and please
> let
>> us know if you have any questions or comments.
>>
>>
>> [Summary] 
>> The draft discusses how multicast services and mobility can be
> supported
>> using the current Proxy Mobile IPv6, IGMP/MLD protocols. The draft
>> consists of three parts: 
>> *	First, the draft describes scenarios to initiate multicast
>> services, and inter-MAG mobility using one LMA
>> *	Second, the draft proposes an improved multicast support using a
>> dedicated LMA for multicast services
>> *	Third, the draft discusses enhanced multicast mobility support
>> utilizing handover triggers  
>>
>> Pros: 
>> The draft covers both the basic and improved solutions using the
> current
>> protocols. 
>> The basic multicast support (section 3) can work independently as a
>> solution. 
>> The use of dedicated multicast LMA (section 4) solves the issue of
>> duplicate subscription and multicast traffic redundancy.  
>> In addition, the draft discusses various methods to enhance multicast
>> mobility and MLD/IGMP (section 5&6). 
>>  
>> Cons:
>> Enhanced mobility depends on the availability of handover triggers,
> and
>> exchange of information between PMIPv6 nodes.
>>
>> [What is the additional functionality required of MAGs and LMAs]
>> MAG is the multicast proxy, and LMA as multicast router (or proxy), as
>> defined in RFC 4605.
>>
>> [Bandwidth usage] 
>> The proposed dedicated multicast LMA approach can largely reduce
> traffic
>> redundancy and bandwidth usage.
>>
>> [MTU, with various tunneling techniques, MTU may be an issue]
>> The draft does not affect the MTU issue.
>>
>> [Handover]
>> The draft discusses how multicast mobility can be supported for
>> inter-MAG handover, using procedures defined in PMIPv6.  
>>
>>
>> Best regards,
>>
>> Guang and Juan Carlos
>>
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Stig Venaas
>> Sent: Friday, October 16, 2009 5:11 PM
>> To: [e-mail]
>> Subject: [multimob] Comparing the proposals for basic multicast
> support
>> I think we need to get some discussion started on the various
>> proposals for basic multicast support. Basically the proposals
>> that are aimed at fulfilling our first charter milestone:
>>
>>      Nov 2009 - Initial version of a document explaining the use
>>      of multicast in PMIPv6
>>
>> Here is what I would like to see from people that are submitting
>> proposals they believe are candidates for this milestone.
>>
>> o You should request a slot and present it in Hiroshima. If there
>>    are drafts where none of the authors can be present, please let
>>    us know. To request a slot, email Behcet and me.
>>
>> o Please soon send an email to the list summarising your proposal,
>>    and its pros and cons.
>>
>> When describing the proposal, I think it could be interesting
>> to hear how it deals with some of the following points:
>>
>> o What is the additional functionality required of MAGs and LMAs
>>
>> o Bandwidth usage (e.g. if multiple nodes join the same groups)
>>
>> o MTU, with various tunneling techniques, MTU may be an issue
>>
>> o Handover, within a MAG, between MAGs
>>
>> o Can a MN source multicast? (I'm not sure whether this is a
>>    requirement, but nice to have IMO)
>>
>> I guess there are other points I haven't thought of. I would
>> be interested to hear what else.
>>
>> I hope by doing this, we can get some data points to better
>> compare the proposals, and get some good discussion started
>> before we meet in Hiroshima.
>>
>> Stig
>>
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multimob
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multimob


-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °