Subject: RE: [Mipshop] Re: Problem Statements for FMIPv6 (was: User experi ence VoIP over WiFi)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 24 Aug 2005 14:48:31 -0500

All,
I have a rather ignorant question on this topic - the goal of FMIPv6 is to improve "network layer" handoff latency; similarly, the IEEE protocols (802.11 and 802.16, etc.) have goals of improving "link layer" handoff latency. Why would we try to address the link layer improvements at a network layer protocol? Or, maybe that was not the point and I missed it. 

Adding link layer information such as signal strength in the PrRtAdv seems quite odd and difficult to do. I know that several implementations of 802.11 already have such infrastructure support at L2 for the station to figure out relative signal strengths, etc to make handoff decisions. 

So, I guess I am wondering why the L2 probe time issue should be part of the problem statement for FMIPv6 in any way. 

Sorry if I totally missed the point. 

Regards,
Vidya

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wassim Haddad
> Sent: Wednesday, August 24, 2005 2:26 PM
> To: Petrescu Alexandru-AAP021
> Cc: [email-masked]; [email-masked]; Rajeev Koodli
> Subject: [Mipshop] Re: Problem Statements for FMIPv6 (was: 
> User experience VoIP over WiFi)
> 
> 
> On Wed, 24 Aug 2005, Alexandru Petrescu wrote:
> 
> > Wassim Haddad wrote:
> >
> > > On Tue, 23 Aug 2005, Alexandru Petrescu wrote:
> > >
> > >
> > >> If long "probing phase" is the main motivator, then the 
> meaningful 
> > >> way to address it is probably to use the RtSolPr and PrRtAdv 
> > >> (because they provide the link-layer info) and thus the "probe 
> > >> phase" lapse is eliminated.
> > >
> > >
> > > => IMHO, using the RtSol/PrRTAdv... messages is not enough. To 
> > > address the latency due to the probe phase, the MN needs 
> to know the 
> > > active channels and the corresponding signal strenght so 
> that it can
> > > *quickly* make a decision (e.g., based on a minimum 
> signal strenght 
> > > threshold). Otherwise, it will have to scan all listed channels. 
> > > Since the signal strenght depends on the MN's location, 
> sending such 
> > > info in the messages you cited is not useful.
> >
> > I think we're getting too deep into 802.11 stuff here.
> 
> => I think we have a serious problem which needs to be solved.
> 
> > Let me explain, I was describing in terms of IP.
> >
> > An application on linux that returns the list of available 
> ESSIDs and 
> > MACs of neighouring APs is iwscan.  It may take a few 
> seconds for it 
> > to return all available MACs and ESSIDs.  The application 
> that is used 
> > to attach to a certain ESSID is iwconfig.  This takes 90ms 
> to attach 
> > to a designated ESSID or MAC.  So, if PrRtAdv provides the MAC 
> > addresses of neighbouring APs (which it does today) and if signal 
> > strength could be obtained from same PrRtAdv (which it does not do 
> > today), then the mobile could take only 90ms to attach to 
> the new AP, 
> > as opposed to first calling iwscan and then iwconfig.
> 
> => IMHO, the signal strenght cannot be sent by the PrRtAdv 
> because it depends on the MN's current location. For the 
> active probe phase (no need to talk about the passive one), 
> you have basically two timers: "MinChannelTime" and 
> "MaxChannelTime". If the MN does not get anything on one 
> channel before the timer reaches "MinChannelTime" then it 
> will move to scan the next channel. Otherwise, it will wait 
> till the "MaxChannelTime" then processes all received probe 
> response(s) and move to the next channel. Suggested optimal 
> values are approximately 6.5 ms for MinChannelTime and 11 ms 
> for MaxChannelTime.
> 
> Providing the list of AP_IDs via the PrRtAdv does not prevent 
> the MN from going through the probe phase after the detection 
> phase because it needs to know the signals strenght and the 
> total delay to get out of this phase depends on the load but 
> seems to always be unacceptable for real time applications.
> 
> > So, I was equating your mentioning of the "probe phase" with the 
> > "iwscan" tool.  I may have been wrong.
> >
> > If I was wrong assuming "probe phase" is "iwscan" then 
> FMIPv6 should 
> > have a more precise model of what "probe phase" is and why 
> is it slow.
> 
> => Agree. I am wondering actually why/how combining the 
> infrastructure mode and the adhoc mode cannot solve this 
> issue (and FMIPv6 won't be needed in this case...). Does this 
> make sense?
> 
> > I also don't think that IP-layer messages (FMIPv6) can 
> optimize in any 
> > way some stuff that happens at link-layer, in the traditional 
> > link-layer agnostic manner.
> 
> => IMHO, "can" or "cannot" is another story. I am just saying (now
> repeating) that with or without FMIPv6 there is a serious 
> problem on the link layer, which can preclude the delivery of 
> what FMIPv6 has been designed to do.
> 
> 
> Regards,
> 
> Wassim H.
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Aug 2005 15:00:43 +0200

Narayanan Vidya-CVN065 wrote:
> All, I have a rather ignorant question on this topic - the goal of
> FMIPv6 is to improve "network layer" handoff latency; similarly, the
> IEEE protocols (802.11 and 802.16, etc.) have goals of improving
> "link layer" handoff latency. Why would we try to address the link
> layer improvements at a network layer protocol? Or, maybe that was
> not the point and I missed it.

It was unclear to me too.

What I see when measuring is that link-layer attachment times take an
average 90ms on various PCMCIA cards on 1GHz laptops.

I also see that an RTT on 802.11b is 3ms.  IP address autoconf thus
takes maybe 10ms (RS/RA, DAD).

Both these steps are sequenced in a critical path.

What FMIPv6 tries to do (and what can do) is to reduce that 2nd step,
address-autoconf.

Logical conclusion is that FMIPv6 may offer a 10% increase in
performance (10% "faster" handovers) and no more.

This seems little incentive for developping and implementing.

So I was thinking that if FMIPv6 were able to reduce the 1st step too,
namely link-layer attachment time, then gains in speed would be more
than just 10%.  But it seems FMIPv6 does not and can not address
link-layer attachment times, as per my current understanding.

Alex

> 
> Adding link layer information such as signal strength in the PrRtAdv 
> seems quite odd and difficult to do. I know that several
> implementations of 802.11 already have such infrastructure support at
> L2 for the station to figure out relative signal strengths, etc to
> make handoff decisions.
> 
> So, I guess I am wondering why the L2 probe time issue should be part
> of the problem statement for FMIPv6 in any way.
> 
> Regards, Vidya
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Wassim Haddad Sent:
>> Wednesday, August 24, 2005 2:26 PM To: Petrescu Alexandru-AAP021 
>> Subject: [Mipshop] Re: Problem Statements for FMIPv6 (was: User
>> experience VoIP over WiFi)
>> 
>> 
>>>>> (because they provide the link-layer info) and thus the
>>>>> "probe phase" lapse is eliminated.
>>>> 
>>>> 
>>>> threshold). Otherwise, it will have to scan all listed
>>>> channels. Since the signal strenght depends on the MN's
>>>> location,
>> sending such
>>>  strength could be obtained from same PrRtAdv (which it does not
>>> do today), then the mobile could take only 90ms to attach to
>> the new AP,
>> => IMHO, the signal strenght cannot be sent by the PrRtAdv because
>> it depends on the MN's current location. For the active probe phase
>> (no need to talk about the passive one), you have basically two
>> timers: "MinChannelTime" and "MaxChannelTime". If the MN does not
>> get anything on one channel before the timer reaches
>> "MinChannelTime" then it will move to scan the next channel.
>> Otherwise, it will wait till the "MaxChannelTime" then processes
>> all received probe response(s) and move to the next channel.
>> Suggested optimal values are approximately 6.5 ms for
>> MinChannelTime and 11 ms for MaxChannelTime.
>> 
>> Providing the list of AP_IDs via the PrRtAdv does not prevent the
>> MN from going through the probe phase after the detection phase
>> because it needs to know the signals strenght and the total delay
>> to get out of this phase depends on the load but seems to always be
>> unacceptable for real time applications.
>> 
>> infrastructure mode and the adhoc mode cannot solve this issue (and
>> FMIPv6 won't be needed in this case...). Does this make sense?
>> 
>> repeating) that with or without FMIPv6 there is a serious problem
>> on the link layer, which can preclude the delivery of what FMIPv6
>> has been designed to do.
>> 
>> 
>> Regards,
>> 
>> Wassim H.
>> 
>> 
>> 
>> _______________________________________________ Mipshop mailing
>> list [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Aug 2005 17:22:14 +0300

Hello Alexandru,

>average 90ms on various PCMCIA cards on 1GHz laptops.
Some cards are better.

>What FMIPv6 tries to do (and what can do) is to reduce that 2nd step,
Along with helping to create a tunnel for delivering packets
that might otherwise get dropped.

Furthermore, I think the true value of FMIPv6 is more easily
seen in a larger context where the signaling enables context
transfer as part of the same packet stream.

>performance (10% "faster" handovers) and no more.
For the average hardware you measure.  But what about somebody
who wants to build a system with better hardware?  They would see
substantial benefit.

>link-layer attachment times, as per my current understanding.
It is not within the natural domain of FMIPv6 to fix media-access
problems.  So I reckon I agree with you on this point.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Aug 2005 17:29:14 +0200

Hello Charlie,

Charles E. Perkins wrote:
>> What I see when measuring is that link-layer attachment times take
>>  an average 90ms on various PCMCIA cards on 1GHz laptops.
>> 
>> 
> Some cards are better.

:-) right...  Do we have an idea of how better are they?  Do we have a
name, an open source driver?  A measurement of their link-layer
attachment time?  Sorry for insisting on this, but measurements are good
to identify what is "slow", why, and what is "fast".

>> What FMIPv6 tries to do (and what can do) is to reduce that 2nd 
>> step, address-autoconf.
>> 
>> 
> Along with helping to create a tunnel for delivering packets that 
> might otherwise get dropped.

Certainly.  But not to be forgotten that it's only packets in one
direction (the ones from PAR to MN).  The packets from MN will stay
within MN until link is up.

Packets saved at PAR are very good news for a user listening/watching a
video stream on MN (but not VoIP).  And then again experiments show that
a typical non-interactive video-stream is not at all interrupted by
link-layer or Mobile IP handovers, because of buffers that are typically
employed at CN and MN.

> Furthermore, I think the true value of FMIPv6 is more easily seen in
>  a larger context where the signaling enables context transfer as
> part of the same packet stream.

That is probably worth exploring, especially when transferring security
contexts.

> For the average hardware you measure.  But what about somebody who 
> wants to build a system with better hardware?  They would see 
> substantial benefit.

Certainly they'd see a benefit, especially if their link-layer
attachment time is below 10ms.  In that case, FMIPv6 would help gaining
50% of the total critical path.  But things may not be that obvious
because the IP autoconf time may be reduced too.  Off-the-shelf
new 802.11 links are claiming higher bandwidths.  E.g. 2, 5, 11, 54, 108
Mbps.  With higher bandwidths come shorter IP address autoconfiguration
times too.

So, if 802.11b attachment is 90ms and RTT is 3ms, then probably
802.11abg-mimo attachment is 10ms but RTT is 300us (because 108Mbps is
10 times more than 11MBps).  So with 802.11abg-mimo the ratio between
attachment and RTT would be the same as with 802.11b, so then again
FMIPv6 would only give 10% faster.

This may look as a pessimistic speculation on my part, I stand corrected
if anyone differs.

So let's learn from the builders of the better hardware systems what are
their link-layer attachment times and RTTs, so we can better identify
what to optimize.

draft-ohba-mobopts-mpa-implementation-01.txt indicates that in their
testbed 802.11b L2 handoff is averaging 4ms.  That is a very strong
statement, IMHO, compared to my 90ms.  If most people have 802.11b
handovers in the order of 4ms then my measurements may be very wrong.

>> So I was thinking that if FMIPv6 were able to reduce the 1st step 
>> too, namely link-layer attachment time, then gains in speed would 
>> be more than just 10%.  But it seems FMIPv6 does not and can not 
>> address link-layer attachment times, as per my current 
>> understanding.
>> 
>> 

We agree at least on this.

Alex

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Aug 2005 17:40:50 -0400

> handovers in the order of 4ms then my measurements may be very wrong.

The L2 handoff time could be larger than 4msec with a large RTT in
WLAN, and the RTT can vary depending on SNR.  But your 90msec looks
like containing other factors like unoptimized WLAN chipset/driver or
with use of 802.1X authentication, etc.

> > problems.  So I reckon I agree with you on this point.

Actually network-layer can help reduce the link-layer attachment delay
during handover, when establishing a link-layer security association
as well as resource allocation is also part of link-layer attachment.
IEEE 802.11r is for optimizing this latency *within an 802.11 ESS*.
But if 802.11 handover is across ESSes, then 802.11r does not help and
some network-layer optimization for link-layer attachment would be
needed (e.g., use of media-independent pre-authentication with
bootstrapping link-layer security).  Please see section 5.9 of
draft-ohba-mobopts-mpa-framework-01.txt for details.

Yoshihiro Ohba

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 26 Aug 2005 05:10:21 +0100

> with use of 802.1X authentication, etc.

It certainly does not contain unoptimized chipset and driver. I 
challenge ANYBODY that claims a fast L2 handoff over WLAN to show us 
their evidence and above all their experimental conditions.

The 4, 10 or 90ms are provided in the masses with some serious 
conditions missing from the experiments they have conducted. To this 
end, I am in partial agreement with statements from both Wassim, Alexandru.

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Aug 2005 15:07:19 +0200

Yoshihiro Ohba wrote:
>> 802.11abg-mimo attachment is 10ms but RTT is 300us (because 108Mbps
>>  is 10 times more than 11MBps).  So with 802.11abg-mimo the ratio 
>> between attachment and RTT would be the same as with 802.11b, so 
>> then again FMIPv6 would only give 10% faster.
>> 
>> This may look as a pessimistic speculation on my part, I stand 
>> corrected if anyone differs.
>> 
>> So let's learn from the builders of the better hardware systems 
>> what are their link-layer attachment times and RTTs, so we can 
>> better identify what to optimize.
>> 
>> draft-ohba-mobopts-mpa-implementation-01.txt indicates that in 
>> their testbed 802.11b L2 handoff is averaging 4ms.  That is a very 
>> strong statement, IMHO, compared to my 90ms.  If most people have 
>> 802.11b handovers in the order of 4ms then my measurements may be 
>> very wrong.
> 
> 
> WLAN, and the RTT can vary depending on SNR.

Yoshihiro, I agree L2 handoff time could be larger than 4msec with a
large RTT in WLAN, and the RTT can vary depending on the SN ratio.

What I'm pointing out is that I can't have link-layer attachment time
(as exposed by iwconfig) below than 90ms.  I can provide more details
about the measurements conditions later, if still necessary.

On another hand, would it it possible to describe the conditions of
measuring the 4ms 802.11b L2 handoff time mentioned in the draft?

Were the 4ms measured with the iwconfig tool? ("time iwconfig")
Were the measurements of a PCMCIA 802.11b card?

> But your 90msec looks like containing other factors like unoptimized 
> WLAN chipset/driver or with use of 802.1X authentication, etc.

I wouldn't rule out WLAN chipset/driver and I'll identify them later and
post here.

However, I'm sure 802.1x authentication was not used.  What was used was
WEP encryption.  But measurements with and without WEP encryption gave
same link-layer attachment times.

>>>> So I was thinking that if FMIPv6 were able to reduce the 1st 
>>>> step too, namely link-layer attachment time, then gains in 
>>>> speed would be more than just 10%.  But it seems FMIPv6 does 
>>>> not and can not address link-layer attachment times, as per my 
>>>> current understanding.
>>>> 
>>>> 
>>> 
> Actually network-layer can help reduce the link-layer attachment 
> delay during handover, when establishing a link-layer security 
> association as well as resource allocation is also part of link-layer
>  attachment.

That's about the transfer of security contexts between AP's right?

> But if 802.11 handover is across ESSes, then 802.11r does not help
> and some network-layer optimization for link-layer attachment would
> be needed (e.g., use of media-independent pre-authentication with

I'll look at that some time.  I'd better try some measurements of
existing stuff first.

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Fri, 26 Aug 2005 18:43:40 +0300 (EEST)

> with use of 802.1X authentication, etc.

=> Actually, I don't think it contains any factor(s) and I don't think it
shows even the total latency because it does not include the latency introduced
by the "detection phase".

Regards,

Wassim H.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Aug 2005 11:12:25 -0400

> by the "detection phase".

Depending on how a station detects the new access point, the
"detection phase" may or may not be counted in L2 handover delay.  If
the detection phase happens after the station disassociates from the
previous access point, then it should be counted in the L2 handover
delay, otherwise it does not have to.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Aug 2005 11:31:10 -0400

> measuring the 4ms 802.11b L2 handoff time mentioned in the draft?

Sure.

> Were the measurements of a PCMCIA 802.11b card?

We don't use iwconfig because it has an overhead of being executed by
a new process created by the current shell.  Instead, we directly call
ioctl() inside a deamon program.  The measured time based on iwconfig
can also depend on how many parameters are specified in the iwconfig
command.  Depending on the number of iwconfig parameters, multiple
calls of ioctl() are generated inside a single iwconfig execution.
Each of these details could be considered as a "factor".

> same link-layer attachment times.

OK.

> That's about the transfer of security contexts between AP's right?

No.

Yoshihiro Ohba

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Aug 2005 23:38:56 +0200

Yoshihiro Ohba wrote:

>>>>  802.11abg-mimo attachment is 10ms but RTT is 300us (because
>>>> 108Mbps is 10 times more than 11MBps).  So with 802.11abg-mimo
>>>> the ratio between attachment and RTT would be the same as with
>>>> 802.11b, so then again FMIPv6 would only give 10% faster.
>>>> 
>>>>  their testbed 802.11b L2 handoff is averaging 4ms.  That is a
>>>> very strong statement, IMHO, compared to my 90ms.  If most
>>>> people have 802.11b handovers in the order of 4ms then my
>>>> measurements may be very wrong.
>>> 
>>> 
>>> The L2 handoff time could be larger than 4msec with a large RTT
>>> in WLAN, and the RTT can vary depending on SNR.
>> 
>> Yoshihiro, I agree L2 handoff time could be larger than 4msec with
>> a large RTT in WLAN, and the RTT can vary depending on the SN
>> ratio.
>> 
>> What I'm pointing out is that I can't have link-layer attachment
>> time (as exposed by iwconfig) below than 90ms.  I can provide more
>> details about the measurements conditions later, if still
>> necessary.
>> 
>  a new process created by the current shell.  Instead, we directly
> call ioctl() inside a deamon program.

So do you mean that a successful ioctl() that attaches and that is
non-blocking takes 5ms?

> The measured time based on iwconfig can also depend on how many
> parameters are specified in the iwconfig command.  Depending on the
> number of iwconfig parameters, multiple calls of ioctl() are
> generated inside a single iwconfig execution. Each of these details
> could be considered as a "factor".

In my iwconfig only two parameters are called: the essid and the key.
It takes the same time (90ms) if there's no key on MN and no key on AP.

This would mean that there would be two calls to ioctl.  90ms divided by
two would be 45ms.

Also, I wanted to say that iwconfig with 802.11g takes also 90ms, even
though the RTT is minimum 1.3ms and average 2ms (as opposed to min4ms
average 5ms on 802.11b).  I've just measured.

iwconfig takes 50ms if the supplied key is incorrect or supplied essid
is absent (xor).  Which means that execution of a new process is not
larger than 50ms.  Which means any lower attachment time than 40ms is
not possible.

Alex

---

From: Emil Ivov <[email-masked]>
Date: Sat, 27 Aug 2005 00:41:31 +0300

> Were the 4ms measured with the iwconfig tool? ("time iwconfig")

Actually measuring L2 Handover through "time iwconfig" is quite wrong
(saw s.o. using it as a reference).

Iwconfig only makes one or more ioctl calls that start the L2 handover
and then return. The following handover procedure may last for quite a
while (in the order of seconds) after iwconfig has terminated.

Cheers
Emil

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 Aug 2005 12:00:13 -0400

> (saw s.o. using it as a reference).

I totally agree.  We measured by inserting kernel logging calls in the
driver code at the lines where Authentication starts and where
Association completes.

> while (in the order of seconds) after iwconfig has terminated.

These are true.  It could last in the order of seconds if unoptimized
scan is performed after the termination of iwconfig call.

Yoshihiro Ohba

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 27 Aug 2005 00:53:30 +0200

> while (in the order of seconds) after iwconfig has terminated.

I'm not sure handover lasts in order of seconds after iwconfig
terminated.  iwconfig called w/o parameters right after the connecting
iwconfig shows correctly the AP's MAC address.  I'm sure when the
iwconfig essid terminates the MN is attached.

Alex

---

From: Emil Ivov <[email-masked]>
Date: Sat, 27 Aug 2005 02:18:38 +0300

Oops... hit send too early. Sorry.

> terminated.  

It could last for seconds (which is quite common) or it could last less 
(see Yoshihiro's mail). It is even possible that it ends before iwconfig 
returns. It all depends on the driver (which one are u using?) In other 
words - execution time of iwconfig doesn't give you any information as 
to the duration of the handover. You'd have to measure that either by 
capturing the 802.11 frame exchange or add logging in your driver (as 
Yoshihiro does).

Cheers
Emil

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 27 Aug 2005 14:42:15 +0200

Emil Ivov wrote:

> It could last for seconds (which is quite common) or it could last 
> less (see Yoshihiro's mail). It is even possible that it ends before
>  iwconfig returns.  It all depends on the driver (which one are u 
> using?)

A variety of PCMCIA cards (aironet a340, a350, orinoco originals,
onboard chips for dell d400 and dell d600, netgear 802.11g).  Drivers
from pcmcia-cs that match kernels 2.4.18, 2.4.20 and 2.4.28.

> In other words - execution time of iwconfig doesn't give you any 
> information as to the duration of the handover.

Except that if I give a wrong essid (or wrong key) the iwconfig
consistently takes 40ms, and if parameters are right it consistently
takes 90ms.

> You'd have to measure that either by capturing the 802.11 frame 
> exchange or add logging in your driver (as Yoshihiro does).

Capturing 802.11 frames: yes and no.  YEs in that it gives exact time
stamps but no because it risks being much lower times than times on the
computer.  For example, the message exchange for DHCP handover is shown
as around 1s by Ethereal timestamps but is shown as 7s by "time dhclient".

Logging on the driver (instrumenting): maybe yes, but then
instrumentation introduces its own delays.  Maybe it's a good way to go
though.  I'd ask Yoshihiro about source code availability of the
instrumented source drivers.

Maybe the best way to measure it though is to know who is the actual
user of this link-layer attachment time.  Who is the first to care about
when the MN is attached?  If it is a userspace daemon using "link-layer
triggers" to send FBU then appearance of that trigger could be measured
somehow.  What is the link-layer trigger more exactly?  What variable in
/proc/net/wireless?

If it is a kernel stack, then how does the stack know it is attached?
Who tells the stack to send FBU?  If we have an idea about that then we
could measure.

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Sat, 27 Aug 2005 16:59:09 +0300 (EEST)

> delay, otherwise it does not have to.

=> the disassociation message can be send by the AP in case of a network
initiated handover. However, when the MN initiates the handover, you have two
possibilities: the MN goes through the detection phase to understand what is
going on and such process is relatively long (e.g., beacon period may be 100
ms) or can use info from the physical layer and skip the detection phase, i.e.,
it starts the probe phase immediately after the signal strenght goes below a
certain minimum.
IMHO, the main point remains that the duration of the probe phase "alone" rules
out the delivery of real time applications.

Regards,

Wassim H.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 27 Aug 2005 02:05:14 -0400

> it starts the probe phase immediately after the signal strenght goes below a

What do you mean by "detection phase" and "probe phase"?  To me those
two are the same functionality (scan) to find an access point but just
performed in different ways (passive scan or active scan) and each of
which has pros and cons.

> out the delivery of real time applications.

A better scan algorithm can reduce scan duration.  Also, a buffering
mechanism at the currently attached access point while scanning other
channels can avoid packet loss (some commercial product has this
functionality using 802.11 power management) during the scan.  The
combination of these two can make wireless LAN more friendly to real
time applications.  But there are other remaining issues as well, like
spanning tree topology update in bridged network.

Yoshihiro Ohba

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 28 Aug 2005 16:28:29 +0200

Yoshihiro Ohba wrote:
>> Actually measuring L2 Handover through "time iwconfig" is quite
>> wrong (saw s.o. using it as a reference).

what's s.o.?

> 
> 
> I totally agree.  We measured by inserting kernel logging calls in
> the driver code at the lines where Authentication starts and where 
> Association completes.

Yoshihiro, Emil,

I may agree that measuring "time iwconfig" is quite wrong in that the
delay offered may be longer than what the 802.11b frame exchanges lasted
for association.

However, measuring by inserting kernel logging calls may be wrong too.
It may be the case that kernel logging calls expose a very short l2
attachment time but the application that needs to send the FBU right
after attachment (reactive) may not take advantage of that because it
runs on user space and there is time-consuming communication between
kernel and user.

A case that may happen is like this: the driver is notified that
handover is finished and it then signals the daemon that it should send
the FBU.  The daemon is asleep because the mediaplayer application takes
all ressources.  Signalling the daemon involves waking it up from disk.
 This delay may last entire seconds.  So there is no benefit in knowing
that l2 handover took 10ms if the FBU leaves the computer after 1s.

Measuring the l2 attachment time by timestamps on 802.11b frames
(ethereal) may be useless too.  IT may be the case that the 802.11b
frames show l2 attachment completed after (say) 10ms.  The challenge
would be to have the FBU go out right after these 10ms.  From
experience, I know that the DHCP timestamps on handover show around 1s,
but the user-level application showing its effect (ifconfig eth0 showing
IP address) is giving the right information only dhen dhclient finished,
and that is around 7s.

So, in this perspective I'd argue that measuring l2 attachment times
should be performed at a point where one is sure that the FBU goes out.

Finally, the claimed 5ms link-layer attachment time may not be realistic
on a link where the RTT is itself 5ms (as measured by ping).  Assuming
that link-layer attachment takes more than just 2 frames.  I still have
to measure it with Ethereal though.

Alex

---

From: Ashutosh Dutta <[email-masked]>
Date: Sun, 28 Aug 2005 11:07:49 -0400

Alex,  I agree  RTT is  important, and  will depend  upon  the network
charateristics and number of active  clients in the testbed during the
handoff period.   I will try to  share the 802.11 frame  dump that was
taken in our case during L2 handoff  for MPA. If you have read the MPA
draft  you  must  have  noticed  that that  Binding  Update  was  sent
proactively before the L2 handoff.

Thanks
Ashutosh

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 28 Aug 2005 17:41:03 -0400

Alex,

> runs on user space and there is time-consuming communication between

This is all about how you define handover delays.  To me any delay
caused after the l2 attachment should be counted in higher layer
delay.  Our data in mpa-implementation I-D is based on such definition
and the higher layer delay contributes to the avarage inter-packet
arrival time during handover.

> that l2 handover took 10ms if the FBU leaves the computer after 1s.

Please see above.

> should be performed at a point where one is sure that the FBU goes out.

Please see above.

> to measure it with Ethereal though.

Yes, link-layer attachment time can be larger with a large RTT, and
RTT can vary with SNR, as I commented earlier.  On the other hand, I
don't know what is a typical RTT value in WLAN, so I cannot tell
whether our data is realistic or not, but that's what we measured.

Yoshihiro Ohba

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 29 Aug 2005 00:58:32 +0300 (EEST)

> performed in different ways (passive scan or active scan) and each of

=> Let me clarify few points here:

- The "detection phase" is the phase during which the MN tries to understand the
cause of frame transmission failure. It may or may not exist depending on the
wireless card used. But when it exists, it occurs *before* the probe phase
and not in parallel, thus it significantly increase the handoff latency.

During the discovery phase, the MN tries to re-transmit many times in order to
understand if the cause of the failure is a cell congestion or signal fading, or
a frame collision... After that, it can start (when needed) the probe phase.

But as I've mentioned, the detection phase may not exist at all and the MN can
start the probe phase upon receiving a hint from the physical layer (e.g., signal
strenght).

Concerning the probe phase and the active vs. passive scanning: IMHO, there is
nothing to say about passive scanning, because it seems from what I've read (please
correct me if I am wrong) that the beacon period is set to 100ms, which rules out
any hope for delivering real time applications.

The active probe phase requires the MN to send a "probe request" message on each
channel and wait for a probe response before sending another probe request on
another channel... till it scan all channels (note that you may have more than 11
channels to probe). On each channel, the MN has two timers to activate: "minimum
channel time (A)" and "maximum channel time (B)". After sending the probe request
message, the MN wait for (A) and if it gets a reponse before (A) expires then it
MUST wait for an additional (B)... If I remember correctly, (again please correct
me if I am wrong), (B) can go from 10 to 30 ms (i.e., depends on traffic load,
number of nodes...). Based on that, we also have a problem!

> spanning tree topology update in bridged network.

=> I agree that a better scan algorithm *can* improve the performance. But do you
think such solution can/will be used with all cards? IMHO, since the scan alogorithm
is enough complicated, it would be better not to touch it and to find a way where it
can be performed in parallel with data exchange or maybe create an environment where
it will be partially (or not) needed.

Regards,

Wassim H.

---

From: Victor Fajardo <[email-masked]>
Date: Sun, 28 Aug 2005 02:49:03 -0400

Hi Alex,

>somehow.  What is the link-layer trigger more exactly?  What variable in
I generally agree. One interesting side note,  sending the FBU after 
handover in the MPA scenario is not necessary so merely measuring the 
appearance of the "link-layer" trigger seems even more appropriate as 
you mentioned. For the case of draft-ohba-mobopts-implementation (mipv6 
with mpa results), the "link-layer" trigger may be defined as the 
NETDEV_UP event (notifier_chain ...) in the ipv6 stack for 2.6.x kernel. 
The "actual user" in this case would simply be the ipv6 stack. The 
kernel->user events (i.e. netlink) are also not relevant and I'm also 
guessing that events from driver to ipv6 stack is only a few(???) 
soft-irqs away, so it should be less than the RTT time being discussed.

>Who tells the stack to send FBU?  If we have an idea about that then we
-- victor

---

From: Theodoros Pagtzis <[email-masked]>
Date: Mon, 29 Aug 2005 00:28:15 +0100

> and not in parallel, thus it significantly increase the handoff latency.

EXACTLY!!!

> a frame collision... After that, it can start (when needed) the probe phase.

DITTO..

> start the probe phase upon receiving a hint from the physical layer (e.g., signal

true

> any hope for delivering real time applications.

gotcha...well, there has been a number of studies (including one of 
mine) that show the performance of the link layer with CFP repetition 
interval of less than 100ms. In strict principle you do not want to make 
the CFP repetition interval too small (say less than 40ms) because you 
strangle the contention ratio of associated MNs. But it is doable and 
has been implemented as a parameter. So to this end, things are possible 
but NOT for the purposes of an IPv6 handoff (only for wireless 
stationary frame Txs). In 802.11 you cannot detect it while at the same 
channel even by exploting channel spreading. Must change channels. There 
MaxChannelTime per channel will delay significantly the probe process.

> channel time (A)" and "maximum channel time (B)".

yes but 99.99% of the time it is (B)...unless you are alone on the cell 
(i.e. unlikely)

  After sending the probe request
> number of nodes...). Based on that, we also have a problem!

Correcto mundo! In Ciscos 350 they are about 38ms, but for a VERY good 
reason that some papers were too fast to suggest it is easy to 
reduce...well good luck to the during channel loading..

>>>out the delivery of real time applications.

well it does not rule it out completely...

>>spanning tree topology update in bridged network.

the word is CORRECT...friendly it is..!
> think such solution can/will be used with all cards? 

nope unless the WiFI imposes as a condition..but I can see vendors 
complaining since they have a budget to honour...and loading performance 
to comply with..

IMHO, since the scan alogorithm
> it will be partially (or not) needed.

I second this..

t.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Aug 2005 12:46:14 +0200

Victor Fajardo wrote:
>> Capturing 802.11 frames: yes and no.  YEs in that it gives exact 
>> time stamps but no because it risks being much lower times than 
>> times on the computer.  For example, the message exchange for DHCP 
>> handover is shown as around 1s by Ethereal timestamps but is shown 
>> as 7s by "time dhclient".
>> 
>> instrumentation introduces its own delays.  Maybe it's a good way 
>> to go though.  I'd ask Yoshihiro about source code availability of 
>> the instrumented source drivers.
>> 
>> Maybe the best way to measure it though is to know who is the 
>> actual user of this link-layer attachment time.  Who is the first 
>> to care about when the MN is attached?  If it is a userspace daemon
>>  using "link-layer triggers" to send FBU then appearance of that 
>> trigger could be measured somehow.  What is the link-layer trigger 
>> more exactly?  What variable in /proc/net/wireless?
>> 
>> 
>  handover in the MPA scenario is not necessary so merely measuring
> the appearance of the "link-layer" trigger seems even more
> appropriate as you mentioned.

I've mentioned FBU because that is the case in the reactive handover.
But if it's not reactive then probably FNA is the first message one
sends after attachment.  So FNA should come out right after attachment,
and FNA is the "user" of the l2 attachment time.  But MPA does not seem
to use neither FNA nor FBU.  The draft pictures "L2 Association and oCoA
assignment" as a single message, so I can't say what exactly happens
after association.  For MPA, what is the message that comes out of MN
right after association?

> For the case of draft-ohba-mobopts-implementation (mipv6 with mpa 
> results), the "link-layer" trigger may be defined as the NETDEV_UP 
> event (notifier_chain ...) in the ipv6 stack for 2.6.x kernel. The 
> "actual user" in this case would simply be the ipv6 stack. The 

Agree, from driver to stack it is probably only one softirq away.  How
long does raising a softirq is probably less than 802.11b RTT which is
5ms.  So if it's the stack who reacts to that event then maybe the
measurement is relevant for the stack.

Just wanted to say that since 802.11b has RTT 5ms (as measured by ping,
and RTT means round-trip, i.e. two messages), and since l2 attachment
involves more than two link-layer messages, then it is less probable
that l2 attachment time the 5ms claimed in the draft.

If the draft-ohba l2 attachment time was measured with something faster
than 802.11b that should be mentioned (the draft mentions 802.11b).
802.11g 54mbps has RTT min 1.2ms (measured by ping).  I suppose 802.11a
mimo 108mbps has RTT 500us and min 300us (haven't measured).  My gut
feeling is that faster l2 layers have faster RTT but not faster
attachment times.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Aug 2005 14:38:51 +0200

Ashutosh Dutta wrote:

> Alex,  I agree  RTT is  important, and  will depend  upon  the 
> network charateristics and number of active  clients in the testbed 
> during the handoff period.

Right, what I was trying to say is that it's little possible to have
802.11b l2 attachment time 5ms when the RTT itself is 5ms.

> I will try to  share the 802.11 frame  dump that was taken in our 
> case during L2 handoff  for MPA.

Thanks, that would be great to ease understanding.

> If you have read the MPA draft  you must  have  noticed  that that 
> Binding  Update  was  sent proactively before the L2 handoff.

Yes, I've noticed that MPA proactively sets up state prior to handover,
which may give substantial advantages in terms of L3 handover delay.

>From the text, it seems that the first message sent right after l2
attachment is PANA-Update-Request.  I am not sure if this is the
intention.  But otherwise I can not understand what is the first message
that MN sends fo R2 (because it seems it does all IP signalling prior
to handover: address autoconf, BU, IPsec, PANA).

Otherwise, when the testbed has been set up, prior to doing MPA, was
there any user experience about the RTP stream to RAT being interrupted
by Mobile IPv6?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Aug 2005 14:44:43 +0200

Yoshihiro Ohba wrote:

>> I may agree that measuring "time iwconfig" is quite wrong in that 
>> the delay offered may be longer than what the 802.11b frame 
>> exchanges lasted for association.
>> 
>> However, measuring by inserting kernel logging calls may be wrong 
>> too. It may be the case that kernel logging calls expose a very 
>> short l2 attachment time but the application that needs to send the
>>  FBU right after attachment (reactive) may not take advantage of 
>> that because it runs on user space and there is time-consuming 
>> communication between kernel and user.
> 
> 
> This is all about how you define handover delays.

Yes, I am trying to have a meaningful definition too.  Until now I was
using "l2 attachment time" to signify the time a successful iwconfig
takes.  In my testbed, the user of this "l2 attachment time" is in the
userspace: call iwconfig, send RS, execute dhclient - are all userspace
commands.

A more precise definition of l2 handover delay may be done in terms of
802.11 terminology but I'd avoid that, because the user of this l2
handover delay is either the IP stack or a userspace program (not
another l2 driver).

> To me any delay caused after the l2 attachment should be counted in 
> higher layer delay.

Absolutely.

> Our data in mpa-implementation I-D is based on such definition and 
> the higher layer delay contributes to the avarage inter-packet 

Right, in this case I can't understand that the higher-layer delay
called "l2 handoff" is given as 4ms (in draft-ohba-implementation), this
looks way too short to me.

Alex

---

From: Victor Fajardo <[email-masked]>
Date: Sun, 28 Aug 2005 03:55:23 -0400

Hi Alex,

>after association.  For MPA, what is the message that comes out of MN
For MPA in general, there are really no messages that comes out of the 
MN related to handoff itself (i.e. FBU, FNA ... all of the message 
exchanges related to handoff occurs after pre-auth and before handoff). 
However, since there is an "interface up" event rigth after handoff, the 
v6 stack itself will most likely send router solicitaions. On a side 
note, an interesting item is that in the process of performing MPA, 
router information maybe revealed prior to handoff (i.e. 802.21 AIS). So 
these methods may further reduce v6 signalling after handoff (RS, 
neighbor discovery ...etc).

>measurement is relevant for the stack.
I agree.

>that l2 attachment time the 5ms claimed in the draft.
I agree. But I guess the 5ms RTT reported by ping has different meaning 
compared to the measurements taken if "link-layer" trigger is our point 
of measurement. It all depends on how were l2 measurement boundary is 
defined.

>feeling is that faster l2 layers have faster RTT but not faster
I guess we can define "attachment time" as one or more of {assoc message 
RTT + processing time of message at driver/firmware } if we use the 
"link-layer" trigger we define above. Pls correct me if I'm wrong but I 
think "processing time of message" is more likely less than the RTT 
(depends on firmware/driver). In such scenario, the RTT carries more weigth.

-- victor

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Aug 2005 13:10:33 -0400

I agree.

> looks way too short to me.

In our measurement, the higher-layer delay (i.e., the delay caused by
the user of l2 handover delay) was *not* counted in l2 handoff.  As
far as I understand in our measurement, the delays are partitioned as
follows (my colleague took the actual measurement data, so he may
correct me if I am wrong):

Part of l2 handoff delay:

[a] Time to completion of L2 association within driver.

Part of higher layer handoff delay:

[b] After the completion of l2 association, time to wake up the user
daemon program that is waiting for the ioctl() system call for l2
handover to complete. 

[c] After the deamon program wakes up, time to complete the secure
proactive handover post-switching phase of MPA by doing higher layer
signaling, i.e., exchanging PANA-Update messages with the new AR in
our testbed.

[b] and [c] take more time (>=10msec), but they were not counted in
the l2 handoff delay.

Hope this helps,

Yoshihiro Ohba

---

From: Victor Fajardo <[email-masked]>
Date: Sun, 28 Aug 2005 07:14:30 -0400

Hi Alex, Yoshihiro,

Just to add to what Yoshihiro has mentioned ...

>[a] Time to completion of L2 association within driver.
This is correct. In the measurement, the "completion of L2 association"
is from the instant the driver initializes and sends the first auth
request and the instant the driver receives the assoc resp and sends a
NETDEV_UP event to the v6 stack (to relate to the discussion in a
separate thread). A total of 2 RTT's in open mode.

>[b] and [c] take more time (>=10msec), but they were not counted in
We can also include [d] higher layer handoff

[d] v6 stack gets notified of "interface up" event and exchanges RS/RA.

Best regards,
-- victor fajardo

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 30 Aug 2005 10:28:35 +0200

> separate thread). A total of 2 RTT's in open mode.

Victor, Yoshihiro, thanks for this.  I agree.  Emil sent an Ethereal
dump of a 802.11g link-layer attachment showing 5ms, resumed below:
0.0 MN-AP Probe Request
0.8 AP-MN Probe Response
2.1 MN-AP Authentication
3.0 AP-MN Authentication
4.1 MN-AP Association Request
5.1 AP-MN Association Response

This means that my comparing of ping RTT (2 datagrams take 5ms) to
link-layer attachment (6 frames take 5ms) was wrong.

> [d] v6 stack gets notified of "interface up" event and exchanges RS/RA.

Ok.

My intention in this discussion was to find the boundaries that can be
reached in terms of handover delay, for an IP application.

Alex