[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
- [Mobopts] Delay Analysis for Handoffs with Mobile… Christian Vogt
- [Mobopts] Re: [Mip6] Delay Analysis for Handoffs … Thomas C Schmidt
- [Mobopts] Re: [Mip6] Delay Analysis for Handoffs … Christian Vogt
- Re: [Mobopts] Delay Analysis for Handoffs with Mo… Theodoros Pagtzis
- [Mobopts] Re: [Mip6] Delay Analysis for Handoffs … Thomas C Schmidt
- Re: [Mobopts] Delay Analysis for Handoffs with Mo… Christian Vogt
- [Mobopts] Re: [Mip6] Delay Analysis for Handoffs … Christian Vogt