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

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 05 Dec 2011 10:50:18 +0100

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.

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

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

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.

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/

---

From: <[email-masked]>
Date: Mon, 5 Dec 2011 12:10:52 +0100

Hello,

Thanks for the review. Please see inline.

Pierrick

> -----Message d'origine-----
> De : Jong-Hyouk Lee [mailto:[email-masked]]
> Envoyé : lundi 5 décembre 2011 10:50
> À : SEITE Pierrick RD-RESA-REN; mext
> Objet : Comments on "draft-seite-mext-dma-00"
> 
> Dear authors,
> 

Actually, the solution applies to network based mobility management. The I-D describes the deployment of PMIPv6 in a distributed fashion.

> session initiator, but the CN could be. 

Right, we have still to address incoming communications.

The data packet forwarding must
> instance, authors should address conflicts over ingress filtering

Agreed.

> 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
> communication session maintaining vs. new session establishment.

Actually, I'm not sure to understand your point...

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

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 05 Dec 2011 13:16:08 +0100

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.

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