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

["Luis M. Contreras" <[e-mail]>]

Hi Thomas,

thanks for reviewing the draft and give some comments.

Despite some of them mix concepts and ideas coming from 
draft-zuniga-multimob-smspmip-00, I will try to clarify those referring 
totally to draft-contreras-multimob-msd-00. Please, see my comments 
below:

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

With this text I try to say that, regarding multicast traffic, the LMA 
does not know initially which content is subscribed by each MN because 
it is not the first hop router for the MN. The LMA requires some 
information to correctly deliver any multicast content to the MN 
subscribing it. In an scenario where the MAG acts as MLD proxy and the 
LMA acts as multicast router, the MAG provides a (summarized) view of 
the MN subscriptions. In any other scenario, some other mechanism is 
needed to transfer MN multicast status to the LMA. In this way, for 
instance draft-krishnan-multimob-pmip6basicmcast-solution-00 proposes 
to tunnel towards LMA the MLD messages originated by MNs. I do not 
prejudge the validity of the LMA to forward the multicast traffic, I 
just highlight that it needs additional information to do that because 
it is not the firs-hop router as seen by the MNs, as any other 
multicast router in a multicast enabled network.

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

What I mean with that sentence is that the MN should be registered 
before requesting (in case the multicast service was not initiated in 
the past) or receiving (in case the multicast service was already 
requested) the multicast traffic. This is a way of ignoring MN's MLD 
signalling for an MN entering the network, or in the period comprised 
between a detachment and an re-attachment events (in other words, MLD 
signalling is ignored once the PBU/PBA messages are interexchanged 
between MAG and LMA). If we don't ignore such signalling e.g. during 
handover events, some inconsistencies could appear related to the 
multicast traffic.
Furthermore, from a network operator point of view, I guess any 
operator would like to register in advance any user to be serviced, 
mainly to bill it accordingly to the network use.

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

I think you mix terms of draft-zuniga-multimob-smspmip-00 and 
draft-contreras-multimob-msd-00.

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

I think you mix terms of draft-zuniga-multimob-smspmip-00 and 
draft-contreras-multimob-msd-00.

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

I think you mix terms of draft-zuniga-multimob-smspmip-00 and 
draft-contreras-multimob-msd-00 (no reference is done to MTU in my 
draft).

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

I agree it is necessary to evaluate the impact. It could be negligible, 
of course, but it is a fact that it wastes radio resources. Note that 
the MLD query is done for every MN entering a MAG domain, not only 
those with active subscription.

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

I take your point, I think it needs further ellaboration to understand 
well the impacts in the network and in the protocols.

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

Not exactly. The pMAG can play the role of MLD proxy or the role of 
multicast router. In the later case the flow will be:

mcast source ==> pMAG ==> LMA ==> nMAG ==> MN

In the former, in case of the LMA is the multicast router, the scenario 
will be as you described, but in a generic way the flow will be:

mcast source ===> multicast router ==> pMAG ==> LMA ==> nMAG ==> MN

>> So I wonder what the benefit of this "recurved flow" solution should be?
>>

The main benefit is an immediate delivery of the multicast flow. The MN 
will have the flow just after registration in nMAG. Further 
improvements to the zig-zag delivery can be expected with protocols 
extensions/modifications. By now, the zig-zag is the price to pay for 
immediate delivery of the multicast traffic.

>> 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!
>>

I think you refer to draft-zuniga-multimob-smspmip-00.

>> Hope I hit some of your open points.
>>
>> Best regards,
>>
>> Thomas
>>

Thanks again for your comments.

Best regards,

Luis