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

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

Hi Luis,

Luis M. Contreras wrote:

> 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:
>
Yes, sorry: Actually the mix was between your draft and the mail of 
Guang and Juan Carlos.

I will try to clarify below, where useful.

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

Yes, we certainly agree that the LMA needs forwarding information - 
however, they need not be MN/receiver-specific, as  in general multicast 
routers do not need receiver-specific states.

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

I tried to question this statement, because its implications remained 
unclear to me. If you just assume that operators may deny service 
without AAA, then we agree. The general scenario is that multicast 
operations follow unicast binding.
If you however imply to exclude mcast services from inter-domain 
transfer, then your assumption most likely is beyond general believe.


>>> 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.
> 
I don't think so, but I may not have understood your section 6 correctly.

In section 6.1 you state "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."

There are essentially two ways to deal with this setup:

  a) Direct multicast routing as previously proposed in 
[draft-sijeon-multimob-mms-pmip6-00].
     This would not be new and has had several discussions on the list.

  b) A dedicated uplink to *one* LMA that serves for all multicast. This 
was my point of
     discussion and arguments have been extended in my previous mail to 
Guang and Juan Carlos.

So I'm still not sure which scenario you have in mind - however, 
arguments are given about both.

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

Yes, sure, as RtrSol and RtrAdv is done. The difference on a shared link 
would be the number of answers: A general query (as of RFC 3810) may be 
answered by all nodes on that link. With point-to-point air links, there 
is of course only one answer and the waste (in case of no active 
subscription) is about 50 octets.


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

O.K., this again depends on your routing scenario (I previously asked 
about). However, even if the pMAG acts as multicast router, traffic 
normally arrives from outside the mobile access network and thus crosses 
it three times.

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

Mhmm, are you sure this is faster? MLD querying can be quick (with 
appropriate timers) and in parallel to Binding updates, so the time 
needed for multicast traffic to arrive does not really exceed 
RTT(nMAG-LMA). In your approach, I would calculate RTT(nMAG-LMA), as 
well, as traffic needs to arrive at the nMAG from LMA after a Binding 
Update. Buffering at the LMA may avoid packet loss in both scenarios.

Now I hopefully have met your draft entirely ;)

Best wishes & hope to see you in Hiroshima,

Thomas
-- 

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] °