[Mobopts] Review of draft-irtf-mobopts-mpa-framework-00

Christian Vogt <christian.vogt@nomadiclab.com> Wed, 24 October 2007 15:29 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 1IkiB2-00021q-JI; Wed, 24 Oct 2007 11:29:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiB1-0001tY-IQ for mobopts@irtf.org; Wed, 24 Oct 2007 11:29:47 -0400
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkiAu-0002Ev-GK for mobopts@irtf.org; Wed, 24 Oct 2007 11:29:47 -0400
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E1D161EF369; Wed, 24 Oct 2007 18:29:23 +0300 (EEST)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 42CCD1EF364; Wed, 24 Oct 2007 18:29:17 +0300 (EEST)
Message-ID: <471F6490.2010700@nomadiclab.com>
Date: Wed, 24 Oct 2007 17:28:16 +0200
From: Christian Vogt <christian.vogt@nomadiclab.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Mobopts <mobopts@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: ktaniuchi@tari.toshiba.com, William Arbaugh <waa@cs.umd.edu>, vfajardo@tari.toshiba.com, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: [Mobopts] Review of draft-irtf-mobopts-mpa-framework-00
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

Folks,

Ashutosh asked me to take a look at
draft-irtf-mobopts-mpa-framework-00, which I am happy to do.

Draft-irtf-mobopts-mpa-framework-00 specifies a framework 
for efficient and secure handovers of mobile hosts between 
administrative separate networks.  This includes a 
pre-authentication of the mobile hosts to one or more 
candidate networks.  The framework is generic in that it is 
independent of the authentication mechanism and mobility 
protocol.

A strength of this framework is that it is based on security
relationships between a mobile host and different networks,
whereas it does not depend on trust or security
relationships between administrative separate networks.
This is an advantage in terms of deployment scalability, in
particular in a more and more heterogeneous Internet.

The draft is of good editorial quality.  It also describes
related work and clearly explains how it differs from that.

Below some more specific technical comments:

- One meta-question I have is why the proactive handover
tunnel connects the mobile host's old point of attachment
with the new access router, and not the mobile host's new
point of attachment with the old access router.  In most
cases, this may not make a difference.  But if the signal
strength on the old link is fading quickly, it would be
advantageous to have the mobile host connect to the new
point of attachment as early as possible.  E.g., F-MIPv6
follows the latter approach and may hence work better when
the overlap between the old and new point of attachment is
small.

- Section 1.1 lists end-to-end delay as a performance
requirement and cites ITU-T G.114 (One-Way Transmission
Time).  The transmission time is not directly related to
mobility management, however, unless you consider
propagation stretches that arise from tunneling, such as in
case of the proactive handover tunnel.

- Section 1.1:

> During a mobile's handover, transient traffic cannot
> reach the mobile and this contributes to the jitter as
> well.

Transient traffic during a handover is lost, whereas jitter
considers the deviation in inter-arrival times of
successfully delivered packets.  So the loss of transient 
traffic during a handover does not contribute to jitter.  I 
would rephrase this.

> According to ETSI TR 101 [ETSI], a normal voice 
> conversation can tolerate up to 2% packet loss.

This value is, to my knowledge, the mean packet loss
probability that can be repaired by loss concealment
techniques.  The value hence does not apply to the handover
case, which is special in that the packet loss probability
is 100% for a short period.  Total packet loss cannot be
repaired by loss concealment techniques -- although some
techniques /attempt/ to repair it by repeating the last
received voice frame several times with decreasing volume.

A more appropriate metric than the average packet loss
probability would be the handover delay (i.e., for how long
there is a packet loss of 100%).  The handover delay is the 
time during which the user does not hear anything. 
Unfortunately, ITU has to my knowledge never developed a 
recommendations on what the maximum handover delay should be.

- Figure 1:  Connection between access routers misses in
domain B.  L2 switch in domain B is not labeled.

- Section 6.3:  Maybe you should add some recommendations on 
who eagerly the mobile host should pre-authenticate with 
different candidate networks.  These recommendations should 
optimally consider the mobile host's policies, signaling 
overhead, and handover robustness.

This is a valuable contribution.  Go ahead and publish once 
Rajeev and William give you green light! :-)

Ciao,
- Christian




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