[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
- [Mobopts] Review of draft-irtf-mobopts-mpa-framew… Christian Vogt
- [Mobopts] Re: Review of draft-irtf-mobopts-mpa-fr… Ashutosh Dutta
- [Mobopts] Re: Review of draft-irtf-mobopts-mpa-fr… Ashutosh Dutta