Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 10:42:32 +0200

Agreed.

Hesham

  > -----Original Message-----
  > From: Rajeev Koodli [mailto:[email-masked]]
  > Sent: Thursday, March 28, 2002 9:00 PM
  > To: [email-masked]
  > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11
  > 
  > 
  > Sorry to interrupt..
  > 
  > I think if IAPP is improved in IEEE, that's good; another 
  > crucial step
  > towards supporting real-time applications during WLAN mobility..
  > For us, we should constrain ourselves with IP mobility 
  > aspects. If it
  > turns out that certain link-specific issues are of 
  > interest, they should
  > be handled separately in an appropriate "link-specific extensions"
  > document.
  > 
  > In general, I have reservations to including L2-specific 
  > optimizations
  > in the base specification.
  > 
  > My 2 cents..
  > 
  > -Rajeev
  > 
  > 
  > George Tsirtsis wrote:
  > 
  > > James,
  > >
  > > Maybe the larger question is why WE (the IETF) is 
  > concerned with how a link
  > > layer mobility management protocol works and indeed why 
  > are we discussing
  > > how it should be changed to become better or worst. 
  > Otherwise we should also
  > > get the specs from GSMA, 3GPP, 3GPP2, and a hundred other 
  > organizations and
  > > start analyzing them and trying to make them do this and that.
  > >
  > > I think this does not make any sense at all...and I 
  > wonder...is it only me?
  > >
  > > George
  > >
  > > -----Original Message-----
  > > From: James Kempf [mailto:[email-masked]]
  > > Sent: Thursday, March 28, 2002 6:46 PM
  > > To: [email-masked]
  > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11
  > >
  > > Hesham,
  > >
  > > > => Which is exactly my point. IAPP is not relevant here.
  > > > The only way to do it in WLAN (at least so far) is to
  > > > make sure that the MN initiates the handover
  > > > based on internal triggers.
  > > >
  > >
  > > If the vendors build IAPP into their APs and 802.11 
  > handover is designed
  > > to require a secure IAPP transaction to complete before 
  > the new AP lets
  > > the MN send packets onto the new link, then this will 
  > lengthen 802.11
  > > handover out considerably beyond the rather poor 
  > performance of the
  > > current round of AP products. Regardless of what the MN 
  > does prior to
  > > handover. So I think it is very relevent indeed.
  > >
  > > > => I don't understand why PREREG is not considered
  > > > a solution here? We always assumed that IAPP is
  > > > not relevant.
  > > >
  > >
  > > It doesn't matter which fast handover algorithm is used, 
  > if the IAPP
  > > transaction takes, say, 200 ms to complete and the L2 
  > handover takes 200
  > > ms to complete before the MN is allowed to get new 
  > packets through the
  > > new AP, then any optimization at Layer 3 will  be in the 
  > noise. I wasn't
  > > making a point about PREREG v.s. POSTREG, I was making a 
  > point about how
  > > the assumptions being made by the 802.11 committee are 
  > causing both
  > > algorithms to be not useful.
  > >
  > > > => James I don't understand why or how you can do that.
  > > > Unless you have connection oriented l2s with the MN
  > > > reporting measurements to the APs, you can't
  > > > do it. Is IEEE going to design a cellular network
  > > > now?
  > > > Even if this happens, are we going to run IAPP
  > > > between subnets?? Even if we do that, wouldn't
  > > > there still be some interruption from the time
  > > > IAPP does its thing, till the MN actually moves?
  > > >
  > > > The level of complication is astounding and frankly
  > > > I don't understand why you would want to do that.
  > > >
  > > > If people within the WG keep ignoring the work that this
  > > > WG is doing, then I agree, nothing produced
  > > > by the WG will ever be used!
  > > >
  > >
  > > Please stay calm, Hesham.
  > >
  > > "We" are not going to run IAPP, that is what the 802.11 
  > committee wants
  > > to do. The problem IAPP is supposed to solve is to tell 
  > the old access
  > > point to unallocate buffers and clean up other data structures
  > > associated with providing the MN with IP connectivity. 
  > Onto that, there
  > > has been additional stuff loaded, like context transfer. 
  > Also, I believe
  > > they are thinking of using it for flushing the ARP cache.
  > >
  > > I'd suggest that if you have some interest in seeing the 
  > right thing
  > > done, you contact Bernard Abboba who has been  monitoring 
  > them closely,
  > > and have him brief you on the details. Also, take a look 
  > at the 802.11f
  > > IAPP spec, http://grouper.ieee.org/groups/802/11/ and 
  > browse from there.
  > > If you see something that he and I have missed, then  
  > please let us
  > > know. We are just trying to convince them that their 
  > protocol needs some
  > > work if it will properly support fast IP handover.
  > >
  > >                 jak
  >

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 02 Apr 2002 11:36:48 +0200

"Hesham Soliman (ERA)" wrote:

>   > Also, there were some other questions raised about
>   > bicasting around the
>   > effect on reliable transports that need resolution, we're
>   > planning on
>   > looking into experimentally them soon.
>
> => I haven't seen any substantial proof of that.
> In fact I saw a paper that proved the opposite
> (and neither me or Karim had anything to do
> with it :) ).
> Also the Eifel algorithm can solve any potential
> problems.

If in fact, there is no problem, this question is not relevant, but
are there any other proposals (besides Eifel) to solve this?
Eifel has IPR. This IPR is royalty free for implementation on
open source platforms. It is not royalty free for other platforms.

-gabriel

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 11:59:25 +0200

Gabriel, 

  > open source platforms. It is not royalty free for other platforms.

=> :)
You want royalty free for everyone do you ? :)
I believe on top of the royalty free, there are some 
words on reciprocity ...etc. 
But of course, all this comes down to whether there 
*is* a problem at all. 

Hesham