[Mobopts] Re: [multimob] ID Update: Multicast Mobility in MIPv6

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 15 November 2007 16:44 UTC

Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishp3-00089g-9V; Thu, 15 Nov 2007 11:44:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishp1-00085R-5y for mobopts@irtf.org; Thu, 15 Nov 2007 11:44:07 -0500
Received: from mail2.is.haw-hamburg.de ([141.22.192.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ishox-0004aL-R4 for mobopts@irtf.org; Thu, 15 Nov 2007 11:44:07 -0500
Received: from mailgate.informatik.haw-hamburg.de (isis.informatik.haw-hamburg.de [141.22.10.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.is.haw-hamburg.de (Postfix) with ESMTP id D2A6558E08; Thu, 15 Nov 2007 17:44:01 +0100 (CET)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01606-01-7; Thu, 15 Nov 2007 17:44:01 +0100 (CET)
Received: from [192.168.178.22] (e178149127.adsl.alicedsl.de [85.178.149.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 657863C00223; Thu, 15 Nov 2007 17:44:00 +0100 (CET)
Message-ID: <473C774E.60704@informatik.haw-hamburg.de>
Date: Thu, 15 Nov 2007 17:43:58 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Romdhani, Imed" <I.Romdhani@napier.ac.uk>
References: <735F04A99D358E468A16EDB64FC04555051E95B9@EVS1.napier-mail.napier.ac.uk>
In-Reply-To: <735F04A99D358E468A16EDB64FC04555051E95B9@EVS1.napier-mail.napier.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
X-Virus-Scanned: ClamAV at mailgate.haw-hamburg.de
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: multimob@ietf.org, "mobopts@irtf.org" <mobopts@irtf.org>
Subject: [Mobopts] Re: [multimob] ID Update: Multicast Mobility in MIPv6
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org

Dear Imed,

thanks for your comments, please see inline:

Romdhani, Imed wrote:

> First, I have to congratulate you on the excellence of your new Multicast Mobility draft. The new version is well organised and very comprehensive.
> 
Many thanks :-)

> I have just finished reading it! The unique comment that comes to my mind is that you have introduced in a separate sub-section (5.2.2) some solutions to address problems of MLD tardy leave notification in wireless links and fast multicast packet forwarding prior to handover, but you missed to highlight in depth these problems in Section 2.2. 
> 
Yes, you are right: this is a lapse, we will add this.

> Other membership problem aspects may deserve to be highlighted. In other words, adjusting the MLD Query interval should not be just limited to address tardy leave and backup forwarding issues, but also to solve the processing overhead caused to an MN that is already member of a multicast group and who may not be in move. I do believe that the HA or MLD proxy agent has to implement listener node table (you stated this in your draft) and slow down sending MLD Query message to MNs that have already joined a multicast group in order to save their battery power and isolate the negative side effect join/leave activity caused by fixed members who may be attached to the HA or MLD proxy agent. In fact, any attempt from a local member to leave multicast groups or exclude some multicast sources that may be on interest to an MN that is away, will cause new MLD Query messages to be flooded to the MN in order to defend his membership (i.e. case of bi-directional subscription). If the HA
/MLD proxy is mobile multicast aware, it can prevent the MN from such unnecessary overhead. Different solutions have been proposed in the literature review, which we summarised in the attached paper "Adaptive Multicast Membership Management for Mobile Multicast Receivers".
> 
Paper: http://dx.doi.org/10.1109/WIMOB.2006.1696354

Yes, you point to the general restrictability of MLD Queries on 
Point-to-Point links. This equally applies, when the MN receives 
multicast data via a bi-directional tunnel with the HA.

These MLD debates we mention only briefly, because they are somewhat 
obvious at the one hand, and like a "red rag" for the multicast 
community on the other. As far as I know, the number of suggested MLD 
changes / subtypes for all kinds of special cases are countless.

More importantly: Bi-directional tunneling is a minimal, 
mobility-agnostic workaround. Efforts on multicast mobility should 
concentrate on devising better solutions, preferably free of encapsulation.

Btw: In your paper you propose solutions, which avoid multicast 
deployment in end system domains with the help of MLD proxies.

Our perspective (and believe ;)) is quite on the opposite site:

   o End system domains rather do show multicast deployment - the 
deployment (and scaling) problem lies in the core. A good discussion of 
this perspective you can find in the sigcomm06 paper of Ratnasamy et 
al.: "Revisiting IP Multicast"
http://sigcomm06.stanford.edu/discussion-beta/showpaper.php?paper_id=2

   o The benefit of multicast deployment in end system domains is much 
larger due to layer 2 multipoint distribution than in the core. This is 
even more relevant in wireless domains, and thus highly desirable to 
achieve within the mobility regime.

> Finally, as part of the Future Steps, it may be interesting to cover the mobility impact on upper TCP/IP layers (transport, session, etc.). Probably related multicast protocols need to be enhanced and adapted to handle mobile devices.
> 

Well, there is no TCP with multicast and the application layer is quite 
manyfold. In general, we tried to discuss the effects, i.e., loss, delay 
and jitter as apparent on the (stateless) transport layer and its 
effects on the widespread, sensitive applications such as voice or video.

There could be issues with reliability extensions, SRM, MRT etc., we 
believe. However, this is probably beyond the scope of this document, it 
  bears the danger of doubling its length ;)

Do you agree?

Best regards,

thomas

> -----Original Message-----
> From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] 
> Sent: 08 November 2007 08:11
> To: mobopts@irtf.org; multimob@ietf.org
> Subject: [multimob] ID Update: Multicast Mobility in MIPv6
> 
> Dear all,
> 
> we just updated the problem statement ID:
> 
>   "Multicast Mobility in MIPv6: Problem Statement and Brief Survey"
> 
> Abstract
> 
>     In this document we discuss current mobility extensions to IP layer
>     multicast solutions. Problems arising from mobile group communication
>     in general, in the case of multicast listener mobility and for mobile
>     Any Source Multicast as well as Source Specific Multicast senders are
>     documented. Characteristic aspects of multicast routing and
>     deployment issues for fixed IPv6 networks are summarized. The
>     principal approaches to the multicast mobility problems are outlined
>     subsequently. In addition to providing a comprehensive exploration of
>     the mobile multicast problem and solution space, this document
>     attempts to outline a conceptual roadmap for initial steps in
>     standardization for the use of future mobile multicast protocol
>     designers.
> 
> It's already on the ID directory:
> 
> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-02
> 
> 
> This version includes new secions on document scope and future steps, 
> extensions on L2 aspects, many editorial changes and accounts for the 
> large number of feedbacks and reviews we have received at and after the 
> Chicago meeting.
> 
> The document convergence process appears pretty matured ... we will be 
> very happy to receive your comments and work towards finalization.
> 
> 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

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts