Re: [multimob] IGMP/MLD Proxy at the MAG

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Mon, 07 December 2009 07:51 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D042528C127 for <multimob@core3.amsl.com>; Sun, 6 Dec 2009 23:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.111
X-Spam-Level: **
X-Spam-Status: No, score=2.111 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCWh0Hr-YKzu for <multimob@core3.amsl.com>; Sun, 6 Dec 2009 23:51:15 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 170A828C123 for <multimob@ietf.org>; Sun, 6 Dec 2009 23:51:15 -0800 (PST)
Received: from localhost (dhcp-143-254.sfc.wide.ad.jp [203.178.143.254]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 89C6F4CFD2; Mon, 7 Dec 2009 16:50:59 +0900 (JST)
Date: Mon, 07 Dec 2009 16:50:58 +0900
Message-Id: <20091207.165058.223254814.asaeda@sfc.wide.ad.jp>
To: luisc@it.uc3m.es
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es>
References: <20091203191024.9lwy7wrvokgkow8s@webcartero01.uc3m.es> <20091205.151420.60711179.asaeda@sfc.wide.ad.jp> <20091205124522.4q9osw00w0s8wck8@webcartero01.uc3m.es>
X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: isoto@it.uc3m.es, multimob@ietf.org
Subject: Re: [multimob] IGMP/MLD Proxy at the MAG
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 07:51:15 -0000

> > We are trying to tune some MLD timer value to *reduce* this join
> > latency (a few seconds or more?) without protocol modification at this
> > stage, but it does not *eliminate* or effectively reduce the latency.
> 
> I think the method we propose in draft-contreras-multimob-msd-00 to
> support the MN handover by temporally redirecting the current
> multicast flow (subscribed by the MN) from pMAG to nMAG till
> (normal or tuned) subscription renewal can effectively reduce the
> latency in the reception of the multicast content once the MN is
> attached to nMAG, at the cost of more bandwidth temporally in the
> core network, as well as some other inefficiencies (temporal
> routing ineficiency, MTU reduction, etc). I think it is something
> we have to trade off.

I took a glance at section 7 in your draft.
I'm sorry, but I cannot imagine that your idea mentioned in this
section does not require any protocol modification. Or it seems to me
that some original implementation is required. No?
Is it obvious that every function you propose is implemented by an
ordinal PMIP implementation (i.e. only with standard spec)?

For instance, regarding pMAG-assisted handover, you say; "the pMAG can
be able to temporally forward via the LMA a copy of the multicast
content within an unicast flow towards the new location of the MN,
brahbrah", but is this a common behavior of rfc5213 compliant MAG?

Regards,
--
Hitoshi Asaeda