Re: [Mobopts] [multimob] moving forward?

["Thomas C. Schmidt" <schmidt at informatik.haw-hamburg.de>]

Hi Suresh & Behcet,

just some quick comments on your new ID:

  * first of all the obvious: this is not exactly hitting the basic 
problems identified in the Vancouver meeting. So the question would be, 
why do you propose to proceed otherwise?

  * second I'm thinking about the ID itself: Mobile multicast always 
faces the problems of two complex worlds, mobility & multicast. Very 
easily one is tempted to come up with a neat solution, which then turns 
out to be in conflict with either one of the two paradigms. In cutting 
the problem space short, there is significant danger of turning away 
from those problems, which are hidden but harmful.

Some more details:

  * In your sample scenario (figure 1) you seem to draw a layer2-only
    handover. In this case, the problem reduces to the MIH-context
    transfer problem (cf. section 4.3 in [1]).

  * The statement "When a mobile node joins a multicast group, it
    uses its home address to do so." (sect. 4.2) is not generally true.
    For Mcast listeners I would rather suspect the opposite, the use of
    CoA as the more common use case.

*  The statement
    "The currently available multicast protocols were designed based on
    the receivers being fixed nodes with large processing capacities.
    [...] They also potentially involve extensive computation
    capabilities on the nodes." (sect. 4.)
    appears generally wrong to my ears. Actually, 'normal' multicast
    admits a rather lightweight interface at the client side - it's a
    UDP socket option. I haven't measure system resources, but an MLDv1
    Mcast socket poses probably less load than a TCP socket.
    It is about zero as compared to a full-screen H.264 decoder :-)

  * A repeat on MLD-light: This cuts off the selective exclude, which
    addresses basically a layer 2 issue. Routers in SSM do have
    source-selective group membership tables anyway, but switches do not.
    This does not seem mobility-related, as a wireless L2 operates on a
    shared medium - thus an exclude of selective receivers would not save
    bandwidth.

  * Another word about the MLD problem: To my understanding, there are
    two established mechanisms, the explicit host tracking and the
    attendance mode, which solve the (rather minor) issues. Per-host
    tracking is discussed as an option in RFC 3810, attendance today is
    implemented for IPTV on the application layer together with a fast
    (video) frame recovery (cf. section 5.2.4 in [1]).

[1] http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-03


Elsewise: What are the plans for Philadelphia? We might find the time to 
write down some solution draft from the pipe ... at least we can 
contribute in a meeting: any specific plans?

Cheers & best regards,

Thomas


Suresh Krishnan wrote:
> Hi Jari,
>    Behcet and I wrote a condensed problem statement document that 
> discusses the basic problems we would like to solve in multimob. We 
> would like to use the document to get feedback from interested people in 
> Philly. After these discussions we would like to decide on the way 
> forward. i.e. prioritizing the work items. The document is available at
> 
> http://tools.ietf.org/id/draft-sarikaya-multimob-ps-00.txt
> 
> Thanks
> Suresh
> 
> Jari Arkko wrote:
>> Folks,
>>
>> Its been a while since something happened on this front.
>>
>> I talked to Rajeev yesterday and I would like to suggest that if you are
>> still interested in this problem, you start working on solutions. Some
>> potential topics include tweaking MLD parameter recommendations for
>> wireless links and building new protocol machinery for home agents to
>> "aggregate" multicast traffic sent to mobile nodes.
>>
>> Without high quality proposals, this work is not going to move forward.
>> I would suggest that the interested people gather in hallways at
>> Philadelphia and start working on proposals. If you need rooms I can
>> give you one. When you have something for IETF-72, some of it might be
>> appropriate for AD sponsored documents in the IETF, some might be food
>> for discussion in MOBOPTS, etc.
>>
>> Jari
>>
>>
>> _______________________________________________
>> multimob mailing list
>> multimob at ietf.org
>> http://www.ietf.org/mailman/listinfo/multimob
> 
> _______________________________________________
> multimob mailing list
> multimob at ietf.org
> http://www.ietf.org/mailman/listinfo/multimob

-- 

° Prof. Dr. Thomas C. Schmidt
° HAW Hamburg, Dept. Informatik
° University of Applied Sciences
° Berliner Tor 7, D 20099 Hamburg
° Germany, Fon: +49-40-42875-8157
° http://www.informatik.haw-hamburg.de/~schmidt
_______________________________________________
Mobopts mailing list
Mobopts at ietf.org
http://www.ietf.org/mailman/listinfo/mobopts