Subject: Re: [multimob] FW: comments on the BOF proposal

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Oct 2007 08:52:28 -0700 (PDT)

Dear all,
  Based on the comments below, we will update the charter and post the version online soon.
  Those who are writing drafts for Multimob, 00 draft submission deadline is more than a month away but please submit your draft earlier and make sure to announce it and have it discussed on the mailing list.

Regards,

Behcet & Suresh

----- Original Message ----
From: Thomas C. Schmidt <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: [email-masked]
Sent: Monday, October 1, 2007 2:21:42 AM
Subject: Re: [multimob] FW: comments on the BOF proposal

Hi,

please see comments inline:

Jari Arkko wrote:

>> "IGMPv3/MLDv2 is originally defined for wired networks with shared
>> links. In mobile envorinments, the link is point-to-point. Also mobile
>> nodes have to save battery by entering into the dormant mode. Dormant
>> mode operation needs to be supported. There are also concerns related
>> to the latency of joins and leaves that IGMPv3/MLDv2 provides. The
>> latency needs to be minimized. In Multimob these issues will be
>> addressed and IGMPv3/MLDv2 for mobile environments will be standardized."
>>
>> So what is being proposed here?  Documenting already
>> implemented/deployed fast join/fast leave extensions?  Increasing the
>> timer values to support dormant mode?  The first item is not mobility
>> specific and the fate of these two solutions should not be tied
>> together (e.g., I'd be interested in working with fast leave/join but
>> not dormant mode stuff).
>>
At first, the prerequisites should be revised: The statement "In mobile 
envorinments, the link is point-to-point." is not generally valid.

Fast join/leave extensions of IGMPv3/MLDv2 tend to raise debates - so 
there might be demands to clarify/document/work out protocol enhancements.

As for the dormant mode: I guess the timescales of IGMPv3/MLDv2 and 
dormant mode invocation at mobile devices are quite distinct - so I have 
doubts about relevant issues here.

>> "- In route optimization (RO) mode, a mobile node can communicate
>> directly with the corresponding node (CN) without going through its
>> home agent. RO mode establisment with the multicast source node as CN
>> will be investigated. A problem statement will first be developed and
>> any solution space possibilities will be explored and the solution
>> will be standardized."
>>
>> I don't understand how this applies.  The current BOF proposal
>> restricts itself to receiver mobility.  However, multicast sources
>> just send out their data, they have no knowledge of receivers. Adding
>> such knowledge goes against this principle (there has been one attempt
>> in the past but it was discontinued due to lack of interest [1]), and
>> I do not see what the source could do about it (certainly tunneling
>> from source to MNs is even less scalable than today).
>>

There is an emerging problem statement from IRTF/mobopts, which 
discusses these subjects:
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

An immediate transfer of MIPv6 RO to multicast is of course beyond 
reach. However, there are proposals around that improve multicast source 
mobility without relying on receiver knowledge.

>> As such I would be comfortable with this direction of work only if
>> modifications at the multicast source were explicitly out of scope.
>>

I don't see the evidence of the emphasis here: In an end-to-end 
signaling scheme, why should a multicast-aware mobility stack not modify 
sender behavior? If this is handled in a router-agnostic fashion, no 
fundamental difference to related protocols (e.g., MIPv6) occurs to me?

Nevertheless you are right: A working group dealing with receiver 
mobility, only, is unaffected by any of these issues.

>> "It is also a goal of the new working group to possibly standardize an
>> agent based solution to reduce time delay and overhead effort e.g. on
>> path re-construction. Both traffic and movement characteristic based
>> and local agent based approaches to deciding on bidirectional
>> tunnelling or remote subscription will be considered."
>>
>> What does 'agent based solution' refer to?  Without prior knowledge of
>> the work it's not clear, but it doesn't sound good if it would mean
>> changes to multicast routing protocols.
>>

Mobile multicast protocols, which are assisted by some sort of 
mobility-aware route entity, commonly are referred to as "agent based".
Examples would be extensions to HMIPv6 or FMIPv6, where a MAP or the ARs 
play the role of "agents". There are many more such agent functions 
suggested, so one likes to summarize these under one term.

>> As a general comment about the whole BOF proposal, maybe it would be
>> best to spell out outright that modifications to (non-mobility
>> related) multicast routers and multicast routing protocols are out of
>> scope.
>>

:-) This will steer work within the realm of deployability.

Conversely, there are tough parts in the mobile multicast regime and to 
me it would make a lot of sense, if mobility related thinking will be 
injected into future mcast routing protocol development - bi-dir PIM may 
be a good starting point here.

Thomas

-- 

° 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

_______________________________________________
multimob mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimob

_______________________________________________
multimob mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimob

---

From: "Von-Hugo, Dirk" <[email-masked]>
Date: Mon, 15 Oct 2007 09:20:37 +0200

Dear all,

just to inform you that my already announced draft is now officially
available at
http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt
<http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.tx
t> 

Agent-based multicast support for moving networks (NEMO)

Best regards

Dirk