Re: [MEXT] Comments on "draft-seite-mext-dma-00"

Jong-Hyouk Lee <jong-hyouk.lee@inria.fr> Mon, 05 December 2011 12:16 UTC

Return-Path: <jong-hyouk.lee@inria.fr>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5723921F8B82 for <mext@ietfa.amsl.com>; Mon, 5 Dec 2011 04:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WMMpeQBw8CU for <mext@ietfa.amsl.com>; Mon, 5 Dec 2011 04:16:11 -0800 (PST)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 751C221F8B03 for <mext@ietf.org>; Mon, 5 Dec 2011 04:16:10 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.71,298,1320620400"; d="scan'208,217"; a="133985657"
Received: from dhcp-rocq-134.inria.fr (HELO [128.93.62.134]) ([128.93.62.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 05 Dec 2011 13:16:08 +0100
Message-ID: <4EDCB608.6000309@inria.fr>
Date: Mon, 05 Dec 2011 13:16:08 +0100
From: Jong-Hyouk Lee <jong-hyouk.lee@inria.fr>
Organization: INRIA, France
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: pierrick.seite@orange.com
References: <4EDC93DA.6030309@inria.fr> <843DA8228A1BA74CA31FB4E111A5C46202127D29@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202127D29@ftrdmel0.rd.francetelecom.fr>
Content-Type: multipart/alternative; boundary="------------070908040300070306010708"
Cc: mext@ietf.org
Subject: Re: [MEXT] Comments on "draft-seite-mext-dma-00"
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2011 12:16:12 -0000

Dear Pierrick,

thanks for your prompt response. Let me explain a little bit more about 
the fourth point "cost in handovers: continuous communication session 
maintaining vs. new session establishment".

I thought that the proposed scheme would possibly provide an adaptive 
communication session handling depending on session contexts, MN's 
characteristics, and network configuration, but as you replied, the 
proposed scheme in the draft do not support this (and you do not 
consider it even). However, it is worth thinking of it. Suppose MN1 is a 
mobile node having a heavy communication session with its CN. Then, for 
MN1, in some cases, it's better to re-establish the heavy communication 
session with the new address at the new access network; this should 
reduce tunneling overhead, but it is all depending on the session's 
context (e.g., session type, breakable or not, etc), MN's 
characteristics (e.g., MN's type, mobility rate, etc) and network 
configuration (wireless signaling range, inter-MAG congestion status, etc).

In addition, regarding the separation of the control plane and data 
plane, thanks to your explanation, it's clear to me. But, it should be 
written in the draft to make it clearer...I suppose.

Cheers.


On 12/05/2011 12:10 PM, pierrick.seite@orange.com wrote:
> Hello,
>
> Thanks for the review. Please see inline.
>
> Pierrick
>
>> -----Message d'origine-----
>> De : Jong-Hyouk Lee [mailto:jong-hyouk.lee@inria.fr]
>> Envoyé : lundi 5 décembre 2011 10:50
>> À : SEITE Pierrick RD-RESA-REN; mext
>> Objet : Comments on "draft-seite-mext-dma-00"
>>
>> Dear authors,
>>
>> I read the draft "draft-seite-mext-dma-00" and have comments/questions:
>>
>> 1. The mobility support described in the draft seems for client
>> mobility. In other words, it's hard to apply the suggested dynamic
>> mobility anchoring scheme into a node dedicated for continuous services
>> to clients.
> Actually, the solution applies to network based mobility management. The I-D describes the deployment of PMIPv6 in a distributed fashion.
>
>> 2. In the suggested dynamic mobility anchoring scheme, data packets of a
>> communication session established in a previous access network (MAR1) is
>> forwarded from MAR1 to the current MAR. This data packet forwarding must
>> be continuous as the address used in the communication session is
>> continuously used. Note that the MN is not only the communication
>> session initiator, but the CN could be.
> Right, we have still to address incoming communications.
>
> The data packet forwarding must
>> impact the whole network performance as the session duration is longer,
>> session is heavier, or mobility is higher.
>>
>> 3. Since the suggested dynamic mobility anchoring scheme allows the MN
>> to send/receive data packets having different network prefix compared
>> with that of the current access network, I'm not sure if the suggested
>> one properly works in existing network security mechanisms. For
>> instance, authors should address conflicts over ingress filtering
>> mechanisms.
>>
> Agreed.
>
>> 4. Since the suggested dynamic mobility anchoring scheme allows the MN
>> to establish a communication session with its CN via a new address
>> obtained in a new network. In other words, 1) the MN establishes its
>> communication session with the CN via HoA1 at MAR1; 2) when the MN moves
>> to MAR2, it possibly establishes a new communication session with the CN
>> via HoA2 at MAR2 in order to avoid the overhead of data packet
>> forwarding. This means that even if the MN wants to keep the same
>> communication session with the CN, it must be re-establishes, i.e.,
>> making a new communication session with the CN.
> No, in that case session continuity is ensures as per PMIP where MAR1 and MAR2 play respectively the LMA and MAG role.
>
> In addition, making the
>> new communication session requires security operations again between the
>> MN and CN. Authors should think the cost in handovers: continuous
>> communication session maintaining vs. new session establishment.
>>
> Actually, I'm not sure to understand your point...
>
>> 5. Could you describe little bit more about the entity storing the
>> session DB for all MNs? Hummm...we're talking about DMM,
> but the entity is a centralized entity in an architectural view; all MARs contacts for
>> MN's session information.
>>
> Here we are going on the separation of the control plane and data plane. The data plane is distributed while a part of the data plane is centralized for localization purpose.  Several approaches are possible and have been described in http://tools.ietf.org/html/draft-yokota-dmm-scenario-00: fully distribution and partially distribution are both possible. With Fully distributed MM, both control and data planes are distributed while partial distribution focuses on distribution on the data plane (arguing that The volume of data traffic is much higher than that of control traffic). MN's localisation is an issue in fully distributed mobility architectures; DHT or flooding are possible solutions but control/data plane separation allows more simple localization scheme. I think it is worth considering control/data plane separation in a first approach, while I agree that the fully distribution is more optimal.
>
>> Thanks.
>>
>> --
>> IMARA Team, INRIA, France
>> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>>
>> #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
>> #webpage: http://sites.google.com/site/hurryon/

-- 
IMARA Team, INRIA, France Jong-Hyouk Lee, living somewhere between 
/dev/null and /dev/random #email: hurryon (at) gmail.com || 
jong-hyouk.lee (at) inria.fr #webpage: http://sites.google.com/site/hurryon/