Subject: RE: [Mipshop] FNA in the current spec

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 18 Aug 2005 11:44:12 -0400

> So, what this means is that packet forwarding happens in 
 > STALE state but 
 > also address resolution (NS - NA exchange) signaling takes 
 > place. Right?

=> No, address resolution has already happened in STALE. NUD
takes place in parallel (NS/NA). 

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 18 Aug 2005 10:29:46 -0700

> takes place in parallel (NS/NA). 

hmm.. Interesting that in our case, the MN has not sent a solicited NA 
to complete address resolution..

Anyway, to sum up:

1. We need to require the MN to send an NA anyway once the new link 
attachment occurs. (NOTE: FMIP neighborhood map allows a MN to map the 
new AP-ID to new AR-Info). I don't think host implementations do this 
today. Any other implementation input?

2. If the FMIP-triggered NA is a standard NA, implementation input is 
needed on the following:
    a) predictive case: does NAR forward packets in STALE state while 
simulataneously doing reachability confirmation (NS, NA) or does it wait 
until reachability confirmation before forwarding packets. It is little 
tricky here because the NAR would have initiated address resolution 
(i.e., NS) for NCoA and is waiting for a solicited NA. But instead it 
gets an unsolicited NA, which moves the ND state to STALE, where it is 
supposed to be doing reachability confirmation. In other words, even 
before address resolution completes successfully once, we are moving the 
state machine to reachbility confirmation.

2.b) reactive case: since NAR has not ND state at all for NCoA, a 
standard NA would be ignored. When packets arrive once FBU is processed, 
address resolution (NS, NA) takes place.

In both 2.a) and 2.b), there is NS - NA exchange.

3. If the FMIP-triggered NA is of different type (like FNA), we don't 
require NAR to do either reachability confirmation (2.a) or address 
resolution (2.b). Extends/modifies neighbor discovery. Saves a 
round-trip of messaging, but needs a new Type assignment (as it is now 
in RFC 4068).

Comments, especially from folks who are trying it out?

Thanks,

-Rajeev

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Aug 2005 21:27:56 +0200

Alright here's some input based on the fmipv6.org implementation.

> today. Any other implementation input?

I am not sure I understand the question since I don't see how it relates 
to the kill-the-fna discussion :) but we do. The fmipv6.org mn keeps a 
map of all access point ids that it had discovered through link layer 
mechanisms and maps them against CAR info received by the current AR 
through the RtSolPr/PrRtAdv exchange.

> state machine to reachbility confirmation.

Well actually we had the follwoing problem. Once the mn has sent the FBU 
and detaches from PAR's link, the PAR starts forwarding packets through 
its PCoA<->NCoA tunnel. Chances are however that packets arrive at the 
NAR before the MN has completed L2 handover so they trigger NDisc. NAR 
therefore sends an NS (which never gets received by anyone since mn is 
still out) and puts the MN's lla into UNREACHABLE. After the MN actually 
gets on the new link and sends the FNA we try to modify the entry but 
the IPv6 stack (on usagi's linux 2.6.8.1) seems to ignore it (that has 
to do with the fact that fmipv6.org runs in user space) and keeps it 
UNREACHABLE until the second NS leaves a second later and the NA is 
received. We therefore (wrongly or bugly but bravely) set MN's LLA to 
REACHABLE right after reception of the HI, and this works quite well for 
VoIP and kin. We haven't tried what happens if we do the same for STALE 
- it might very well work. I'll come back to you on that.

Cheers
Emil

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 18 Aug 2005 14:31:03 -0700

Hi Emil,

> I am not sure I understand the question since I don't see how it relates 

The question was do host implementations send an unsolicited NA after
attaching to a new link or not. I think they don't, but I wanted some
input.

> UNREACHABLE until the second NS leaves a second later and the NA is 

This is very good input. I wonder if it is because address resolution is
already in progress..

> REACHABLE right after reception of the HI, and this works quite well for 

We have to look at the performance, especially for VoIP. In the process,
we may have to make modifications, which is just fine.

> - it might very well work. I'll come back to you on that.

Look forward to that.

Thanks,

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Aug 2005 17:15:47 +0200

Rajeev Koodli wrote:

> 
> 
> Soliman, Hesham wrote:
> 
>> => No, address resolution has already happened in STALE. NUD takes
>> place in parallel (NS/NA).
> 
> 
> hmm.. Interesting that in our case, the MN has not sent a solicited
> NA to complete address resolution..
> 
> Anyway, to sum up:
> 
> attachment occurs. (NOTE: FMIP neighborhood map allows a MN to map
> the new AP-ID to new AR-Info). I don't think host implementations do
> this today. Any other implementation input?

Another implementation does this: once MN attaches to a link, it sends
an RS, then the router sends RA, then router sends NS so the NA comes
out of MN.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Aug 2005 09:03:13 -0700

Unless the MN has a definitive mapping from AP to NAR link address prior to 
moving to the new link, RS/RA exchange is necessary. Otherwise, the MN 
doesn't have the NAR link address and so can't get packets off the link.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Aug 2005 14:15:41 +0200

Emil Ivov wrote:
[...]
> We therefore (wrongly or bugly but bravely) set MN's LLA to REACHABLE
> right after reception of the HI, and this works quite well for VoIP
> and kin.

Emil, all, please allow me to take advantage of your mentioning VoIP and
deviate the topic.

Is there any user experience about a handheld device (~200-300MHz)
running audio VoIP (no video) connected with IPv6 over 802.11b (PCMCIA),
no handovers, no Mobile IPv6?  Is the user feeling an interruption in
the audio?  Is the user experiencing delays?  Is the user experiencing
echoes?

I know it is difficult to describe user experience of an audio
application, but thanks for sharing any of it,

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 23 Aug 2005 21:10:06 +0300 (EEST)

Hi Alex,

The main contributor for the overall handoff latency at the link layer in
IEEE 802.11 is the probe phase. The significant latency added by such phase
can preclude the delivery of real time applications.

Regards,

Wassim H.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 23 Aug 2005 20:46:14 +0200

Thanks Wassim for this info.

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.

I think this IP message exchange will probably be enough to avoid the
link-layer probe phase.  I assume that when the link-layer info of the
New Access Point is available to MN, the MN no longer needs to "probe".

I see no reason why the other FMIPv6 messages are needed (HI/HAck, FBU,
FNA) to address the latency of the "probe phase".  I agree that
conceptually it is good to save packets that arrive at the PAR, but in
practice that is good only if some user-experience (or any other strong
motivator) shows how _without_ HI/HAck/FBU/FNA the VoIP/WiFi is bad.

Alex

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 23 Aug 2005 16:10:32 -0400

Wassim, Alex I agree.

>From our personal experience we have found that if one can avoid
active scanning that triggers the probe request/response, the L2 delay
can be reduced drastically. Thus knowing the AP ID, MAC address,
channel number ahead of time helps avoid the scanning part thus
reducing the L2 delay.  In the drafts
(draft-ohba-mobopts-mpa-framework-01.txt,
draft-ohba-mobopts-mpa-implementation-01.txt) presented in MOBOPTS
working group during 63rd IETF we have shown some sample handoff
results. We were able to reduce the L2 handover delay to almost 4 ms
as we obtained the L2 info of the target AP ahead of time (in this
case using 802.21 discovery procedure). As you have pointed out it
will vary depending upon the driver and card.

If you are talking about non-roaming mode, scanning may not be invoked
at all, and thus the client may stay associated with a specific
channel until it gets to roaming mode or pre-emptive roaming mode.

Thanks
Ashutosh

> >>application, but thanks for sharing any of it,

Ashutosh

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 24 Aug 2005 16:29:41 +0300 (EEST)

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

Regards,

Wassim H.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Aug 2005 16:38:20 +0200

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

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.

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.
The document does not describe this "probe phase" problem.  It describes
only problems related to IP address autoconfiguration and Mobile IP
updates.  The former is a DNA problem too.

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.

So, if I were to have an issue for the issue tracker, I'd put a
statement for the potential need of a problem statement for FMIPv6.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Aug 2005 17:03:51 +0200

Ashutosh Dutta wrote:

> active scanning that triggers the probe request/response, the L2 
> delay can be reduced drastically.

Ashutosh, is this scanning the same as the scan performed by the iwscan
tool on linux (iwscan is part of Wireless Tools)?

> Thus knowing the AP ID, MAC address, channel number ahead of time 
> helps avoid the scanning part thus reducing the L2 delay.  In the 
> drafts (draft-ohba-mobopts-mpa-framework-01.txt, 

Was the tool iwconfig being used to obtain 4ms attachment time?  BEcause
I use iwconfig and can't go below 90ms even if I know the ESSID and the
AP's MAC address in advance (laptop 1GHz, pcmcia, 802.11b).  It would be
wonderful if I could obtain that, so if you could please provide details
about how this was done, thanks.

> case using 802.21 discovery procedure).

I am sorry, I am not aware of the details of the 802.21 discovery
procedure.  Is any driver/card, below IP level implementing the 802.21
discovery procedure?

> As you have pointed out it will vary depending upon the driver and 
> card.

I guess so.  Most of my tests are done with off-the-shelf cards and
open-source drivers.  Is the 802.21 discovery procedure open-source
implementation?

> If you are talking about non-roaming mode, scanning may not be 
> invoked at all, and thus the client may stay associated with a 
> specific channel until it gets to roaming mode or pre-emptive roaming
>  mode.

Exactly, I'm wondering about non-roaming mode.  I know that some
real-time VoIP over IPv6 perform bad over 802.11b but ok over 100Mb
wired Ethernet.  So I am trying to identify experiences of where exactly
the IPv6 address autoconfiguration and Mobile IPv6 binding management
make VoIP work bad.

Thanks for writing draft-ohba-mobopts-mpa-implementation-01.txt.  It
seems to describe how short handover times are obtained with a special
handover scheme (Figure 2).  But I am looking for user experience
illustrating how bad RAT is when simple stateless address autoconf and
BU/BAck are used.

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 24 Aug 2005 22:25:56 +0300 (EEST)

> I think we're getting too deep into 802.11 stuff here.

=> I think we have a serious problem which needs to be solved.

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

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

> way some stuff that happens at link-layer, in the traditional link-layer

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

---

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

> depends on the load but seems to always be unacceptable for real time

Oh, I see.  Thanks for explaining.

So I may have wrongly thought that PrRtAdv helps the link-layer
attachment time.  So it means PrRtAdv only helps with IP address
autoconfiguration time.  But address-autoconfiguration time involves
only a few message exchanges (if no DAD) each taking 5ms or so.  And the
attachment time takes 90ms or so.

So PrRtAdv helps shortening 15ms to near 0, and the 90ms is still in the
critical path. I don't see any advantage in doing this.

> needed in this case...). Does this make sense?

I am not sure I understand.  In practice I didn't test the difference in
link-layer attachment times between ad-hoc and infrastructure which is
90ms.   Do you think there is a difference?

> link layer, which can preclude the delivery of what FMIPv6 has been

So this somehow means that whatever FMIPv6 does at network-layer, and
since link-layer attachment times take as long as not using FMIPv6, and
since MN can't send any IP packet during the attachment time, the holy
grail of having smooth audio/video streams could not be attained?

Alex

---

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

> => I think we have a serious problem which needs to be solved.

I think IP can't solve 802.11 handover latency problems.  To put it
simply, if the link-layer is not up then the mobile can't send IP
packets on that same link to make that link come up quicker.

Alex