[Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization

Thomas C Schmidt <schmidt@fhtw-berlin.de> Sun, 15 January 2006 15:16 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9c3-0001pX-Hq; Sun, 15 Jan 2006 10:16:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9bw-0001lM-Da; Sun, 15 Jan 2006 10:16:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29460; Sun, 15 Jan 2006 10:14:37 -0500 (EST)
Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey9Rl-0000zk-Cj; Sun, 15 Jan 2006 10:05:34 -0500
Received: from e178178094.adsl.alicedsl.de ([85.178.178.94] helo=[192.168.178.20]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Ey9Ju-000C1V-Jq; Sun, 15 Jan 2006 15:57:26 +0100
Message-ID: <43CA6387.8080306@fhtw-berlin.de>
Date: Sun, 15 Jan 2006 16:00:23 +0100
From: Thomas C Schmidt <schmidt@fhtw-berlin.de>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Vogt <chvogt@tm.uka.de>
References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> <43CA50C7.1000206@tm.uka.de>
In-Reply-To: <43CA50C7.1000206@tm.uka.de>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: Mip6 <mip6@ietf.org>, Mipshop <mipshop@ietf.org>, Mobopts <mobopts@irtf.org>
Subject: [Mobopts] Re: [Mip6] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: schmidt@fhtw-berlin.de
List-Id: IP 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>
Sender: mobopts-bounces@irtf.org
Errors-To: mobopts-bounces@irtf.org

Hi Christian,

the mailinglist seems to be gone for the weekend ... so this is very 
private ...


Christian Vogt wrote:

> While your results [1] on FMIPv6 and HMIPv6 shed light on the
> performance of proactivity in combination with local mobility
> optimizations and are as such undoubtedly very important, I do not
> necessarily consent with your statement that those results can be
> conveyed to the end-to-end mobility management that we have been
> analyzing [2].
> 

I perfectly agree with your characterisation. I did'nt mean to say that 
both approaches are the same. What I tried to suggest is that there 
might be some lessons to be learned from [1] for your work.

 From an abstract point of view the approaches of FMIPv6 (predictive 
part) and proactive end-to-end mobility management agree in hiding 
update delays by advancing handover negotiations on the basis of 
predictions.

Beside problems with the reliability of predictions they both rely on 
timing issues: negotiations have to be successfully completed for the 
schemes to work. You are addressing this issue in section 7.1 of [2], 
but what we would like to contribute as the essence of [1] reads:

There are three different timescales, one defined by the HO scheme + 
Internet topology, another by the L2 technologie and the third by the 
actual movement of the mobile user. They are fairly independent of each 
other.

It may as well happen that the degree of coincidence required by your 
scheme corresponds to a quite narrow regime in phase space, which is 
hardly ever met. Thus it is *possible* that the fascinating perspective 
of zero update delay is just a conceptual result, which basically does 
not hold in reality. Details of course are subject to a thorough 
analysis, which you will probably do.

Best regards,

thomas

> [1] http://www.informatik.haw-hamburg.de/~schmidt/papers/telesys05.pdf
> [2]
> http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf
> 

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