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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 24 Aug 2005 15:01:05 -0500

Hi, 

Sorry for jumping in the middle of discussion. 
I am also confused why FMIPv6 needs to exchange link layer 
information using PRtAdv message. I guess protocol such 
as CARD is designed to address this issue anyway.  If not CARD, 
we can always use link layer mechanism for this purpose. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Narayanan Vidya-CVN065
Sent: Wednesday, August 24, 2005 2:49 PM
To: 'Wassim Haddad'; Petrescu Alexandru-AAP021
Cc: [email-masked]; [email-masked]; Rajeev Koodli
Subject: RE: [Mipshop] Re: Problem Statements for FMIPv6 (was: User experi ence VoIP over WiFi)

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

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