Subject: [multimob] moving forward?

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Feb 2008 17:04:15 +0100

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
[email-masked]
http://www.ietf.org/mailman/listinfo/multimob

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Feb 2008 18:44:32 -0500

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 24 Feb 2008 21:39:12 +0100

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

-- 

° 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]
http://www.ietf.org/mailman/listinfo/multimob

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 24 Feb 2008 17:04:55 -0500

Hi Thomas,
   Thanks for the comments. Please see responses inline.

> why do you propose to proceed otherwise?

This document is just an attempt to have a high level view of the 
problem space. This document has no official standing at all (nor will 
it ever). It will be used to gauge interest in what problems people are 
interested in solving right now. There was no such understanding (of 
what to do) achieved in Vancouver. The other problem statement drafts 
(including yours) will be the ones that will define the precise problems 
to be solved.

> from those problems, which are hidden but harmful.

Agree. But do you see anything in the draft that suggests doing so?

> Some more details:

This draft was not designed to be a detailed problem statement. I would 
like the other problem statement drafts to cover the details. Other than 
the details, do you agree that the problems listed in this document 
cover the problem space?

> contribute in a meeting: any specific plans?

Jari has offered us a room to meet in Philly. I would really love to see 
  some solution drafts.

Thanks
Suresh

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Feb 2008 01:01:52 +0100

Hi Suresh,

Suresh Krishnan wrote:

>> problems identified in the Vancouver meeting. So the question would 
>> be, why do you propose to proceed otherwise?
> 
> interested in solving right now. 
...

Fine, we can continue discussions in Philadelphia.
>> 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.
> 
It sort of cuts the problems short ... it could give the impression that 
one could escape from the context. That was my concern.

> the details, do you agree that the problems listed in this document 
Well, it misses at first the very fundamental problem of seamless, 
time-constrained handover for mobile nodes ;)

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

Fine. Let's see what can be done. At least we should start working on 
solutions ... Jari is right in the sense that we must start to get them 
done.

Best wishes,

thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 25 Feb 2008 20:28:09 +0900 (JST)

> "aggregate" multicast traffic sent to mobile nodes.

Sorry, maybe it's my misreading.
Jari showed independent topics, which are "MLD related issue" and
"multicast traffic aggregation via HA", I guess.
I'm currently working on the former topic.
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/multimob

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Feb 2008 14:46:32 +0200

I have tentatively allocated you the IESG breakout room for Wed 13:00 -
15:00 (location tbd). The goal of giving you a room would be to allow
the document authors and other key participants to work together towards
updated documents, improved common understanding of what you want to do
etc. This is not intended as a BOF or Bar-BOF replacement.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Feb 2008 10:05:17 +0200

Hitoshi,

> I'm currently working on the former topic.

Good.

Jari