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

Christian Vogt <chvogt@tm.uka.de> Mon, 16 January 2006 07:40 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 1EyOy8-0000vU-TT; Mon, 16 Jan 2006 02:40:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyOy6-0000uP-0D; Mon, 16 Jan 2006 02:39:58 -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 CAA19827; Mon, 16 Jan 2006 02:38:33 -0500 (EST)
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX194y3HCdnkp2b3vbNzjFm1G5v3rQ9+BU2s=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyP5y-0006Dk-Dv; Mon, 16 Jan 2006 02:48:07 -0500
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyOxz-0002qP-Tx; Mon, 16 Jan 2006 08:39:54 +0100
Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7B29886BB; Mon, 16 Jan 2006 08:39:51 +0100 (CET)
Message-ID: <43CB4DC7.7030600@tm.uka.de>
Date: Mon, 16 Jan 2006 08:39:51 +0100
From: Christian Vogt <chvogt@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: schmidt@fhtw-berlin.de
References: <43C7A215.1040804@tm.uka.de> <43C91C45.3090909@fhtw-berlin.de> <43CA50C7.1000206@tm.uka.de> <43CA6387.8080306@fhtw-berlin.de>
In-Reply-To: <43CA6387.8080306@fhtw-berlin.de>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -6.1 (------)
X-Spam-Status: No
X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.7 AWL AWL: From: address is in the auto white-list
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
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
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 Thomas.

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

Yes, in particular with respect to the reliability of movement 
predictions, which you are considering in [1].  This is definitely an 
interesting issue, albeit it is the link-layer folks that must 
eventually solve it.

I would also assume that the reliability of predictions strongly depends 
on the access technology.  E.g., in GSM, you have bidirectional 
measurements that you can take into account.  This is not necessarily 
true for other link layers, such as IEEE 802.11.

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

Zero handoff delay, at the IP layer, is indeed possible only when 
certain assumptions hold.  And as discussed in section 7.1 of [2], this 
is not always the case.  However, end-to-end proactivity can perform 
better than reactive approaches even when conditions are sub-optimal.

To exemplify this, let's consider the packet-propagation latencies on 
the old path versus the new path during a proactively managed handoff: 
If the new path is longer, the mobile node may have to wait for packets 
after it has switched links (subsequent to receiving a Binding 
Acknowledgment on the old link).  If the new path is shorter, some 
packets may already be lost on the new link before the mobile node 
arrives there.  But in both cases, the blackout time is usually shorter 
than in a pure reactive approach.

Anyway, all this is discussed in more detail in [2].

- Christian

[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

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/


Thomas C Schmidt wrote:
> 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