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

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

Hi Thomas,

just for clarification, please, see below some additional comments

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

I see that the scenario (a) could contain the scenario (b); in other 
words, the scenario (b) can be seen as a particular case of scenario 
(a).

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

Right, but note that the flow is not permanent, it crosses temporally 
the mobile access network just to deliver asap the multicast content to 
the MN after a handover.

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

I think that pMAG-assisted handover would take just (RTT(nMAG-LMA)/2) 
because it is not required any message in the direction nMAG -> LMA. 
The encapsulated multicast flow goes follows the direction LMA -> nMAG 
withou any previous signalling message in the reverse direction.

> Now I hopefully have met your draft entirely ;)
>

Thanks again for your comments

> Best wishes & hope to see you in Hiroshima,
>
> Thomas

Best regards,

Luis