Subject: [Mip6] Mobile IPv6 handoff latency... (timeout)

From: Warodom Werapun <[email-masked]>
Date: Sat, 26 Mar 2005 17:15:34 +0700

I'd like to know mobile IPv6 handoff latency specifiation?
   
    I mean, a mobile node moves from a base station to another base 
station completely within second. <-  What is this second?  500 msec, 
1000 msec? more?

-- 
Warodom  Werapun

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Thomas Schmidt <[email-masked]>
Date: Sat, 26 Mar 2005 20:02:31 +0100

Hi Warodom,

> station completely within second. <-  What is this second?  500 msec, 

The absolute time values mainly depend on the network topology, the
roundtrip times between MN , HA and CN. If all is close by and fast
movement detection is assured (< 10 ms, say), then MIPv6 handoff may
complete very well below 100 ms.

If the distance MN <-> HA is large, say 200 ms RTT, handover will take
500 ms for the least. And may be much more in disadvantaguous circumstances.

regards,

thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 26 Mar 2005 20:36:50 +0100

> I'd like to know mobile IPv6 handoff latency specifiation?

The spec rfc3775 does not specify any latency constraints for the handoff.

> station completely within second. <-  What is this second?  500 msec,

Well, a second is precisely 1000msec.

But, as the previous post says, Mobile IPv6 binding cache update depends
on the RTT between HA, MN and CN.  Also, this latency is at least as
large as the underlying link-layer technology handover latency, and
depends on the processing power of the MN too.

You're saying "base station" so that sounds to me like GSM/GPRS or
similar, and moving between two such base stations does not involve
change in CoA, so no Mobile IPv6 handover latency at all.  I do not know
the link-layer latency for GSM/GPRS handovers between Base Stations.

If you were saying "Access Point" then I'd have guessed you refer to
802.11b.  In this case the typical attachment time (using ASSOCIATE 
message, not RE-ASSOCIATE) is in the range 50ms-90ms with a typical 
802.11b Access Point and a Ghz Intel computer with onboard or PCMCIA 
802.11b.  Note that in other cases than GHz Intel computer this 
link-layer latency can be much larger than 50ms-90ms.

So unless one is more precise in the question (name of link-layer?, 
topology at network-layer?, MN processing power?) I don't think one can 
get any precise answer for the Mobile IPv6 handover latency.

And, why do you ask?

Alex

---

From: Jari Arkko <[email-masked]>
Date: Sun, 27 Mar 2005 08:34:18 +0300

Handoff latency depends on a number of environmental factors.
Not just related to Mobile IPv6! A good overview of overall stack
latency issuesin a 802.11 case can be found from

http://www.drizzle.com/~aboba/IEEE/11-04-0377-01-frfh-analysis-roaming-techniques.ppt

Note that this considers full functionality, not just pure non-secured
802.11. Typically, in commercial deployments you'd want the L2 security
turned on. And since you are mobile, pre-configured WEP keys are
unlikely to work for you.

If you look at this, you'll realize that there's a lot of latency around
the whole stack. Fortunately, there are optimization attemps trying
to reduce delays for, I believe, each individual part of the protocols
that you need in a movement. For instance, in IETF we have discussed
optimistic DAD, better DNA procedures, and some schemes for
reducing Mobile IPv6 related delays.

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 27 Mar 2005 20:31:09 +0200

Thanks for the reference, after scanning the slides I must say I'm
surprised by the number of environmental factors...

I'm also surprised that no presentation/paper I've seen until now talks
about the MN's actual processing power being an important factor in
handover latency.

The MN's processing power is an essential factor in handover latency.
For example, for a inter-subnet handover set of DHCP message exchanges
the latency constantly stays around 1s (measured with Ethereal), but
measuring the time of the successful dhclient command with the Unix time
command gives ranges from 2s to 6s.  The difference can only be due to
the processing of different kernel and userspace data structures,
syncing, etc, on the MN.

Potentially, for optimizing handover latency there are bigger
opportunities at software level and at topology-design level.  Looking
at measurement figures, I can say that optimizing protocol design can
have less of an impact than the two previously mentioned factors, just
an oppinion.

Alex

Jari Arkko wrote:
> Handoff latency depends on a number of environmental factors. Not 
> just related to Mobile IPv6! A good overview of overall stack latency
>  issuesin a 802.11 case can be found from
> 
> Note that this considers full functionality, not just pure 
> non-secured 802.11. Typically, in commercial deployments you'd want 
> the L2 security turned on. And since you are mobile, pre-configured 
> WEP keys are unlikely to work for you.
> 
> If you look at this, you'll realize that there's a lot of latency 
> around the whole stack. Fortunately, there are optimization attemps 
> trying to reduce delays for, I believe, each individual part of the 
> protocols that you need in a movement. For instance, in IETF we have 
> discussed optimistic DAD, better DNA procedures, and some schemes for

---

From: Thomas Schmidt <[email-masked]>
Date: Mon, 28 Mar 2005 00:49:35 +0200

Hi,

> the processing of different kernel and userspace data structures,
This all sounds rather suprising to me: Standard Linux scheduling 
granularity (10 ms) in our experiments turned out to be the limiting 
factor, even on old machines (PII-233 or so). In reducing this clock 
tick we saw perfect alignment of handover signalling to the enforced 
scheduler. Using the MIPL IP stack we did not see significant artificial 
software delays, neither on the packet level nor on the application layer.

To our understanding the significant delays in MIPv6 arise from its 
strong topology dependence. Exactly this observation tells us, why 
HMIPv6 and FMIPv6 should be considered.

The discussion of Layer 2 handovers, of course, is a different topic: we 
cannot expect MIPv6 to outperform L2 delays. L2 issues should be 
resolved where they originate ;)

Cheers,

thomas