Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 6 Nov 2002 19:39:09 +0100

BTW, I might take a long time to answer future emails 
on this because I'm really caught up in other issues right now. 

  > 
  > > - Anticipation is not bound to IEEE as I keep saying. On some
  > > link layers, the pr_RS is redundant and no standard API is
  > > needed to allow a router to send a pr_RA unsolicited.
  > > - If we have the pr_RS then we can have the API afterwards
  > > and people would already have a standard mechanism to use FMIPv6
  > >
  > 
  > Please give examples of currently developed link layers where:
  > 
  > a) It is possible to implement anticipated handover signaling.

=> WCDMA for one. I'm pretty sure you can do it on others 
but I'm mentioning one that I know pretty well. You can also
do it on some IEEE cards

  > 
  > b) There is not another mobility solution (such as GPRS in 
  > 3GPP and stretchy PPP
  > in 3GPP2) that would act as a barrier
  > to implementation and deployment.

=> That's irrelevant to this discussion. Please name _any_
link layer in the world that will allow for tunnel
based handover and satisfy your 2 requirements above.

  > > - What good does removing this message do?? At least if people
  > > have the right cards (like the one on my laptop), they can use
  > > this today. Why should we ban people from using this?
  > >
  > 
  > The issue isn't removing it. The issue is getting a 
  > *standards track*
  > specification that addresses the needs of current link layers.

=> Fine with me; I'm already stating that this will work on
many links and for the specific IEEE case it will work on 
some cards. We're implementing it and Greg already said that
they did as well and I have first hand knowledge of thier
work. So why should we remove this again?

  > 
  > The anticipated handover signaling is fine for an 
  > Experimental RFC, but it
  > cannot address current link layers, which means 802.11 and 
  > maybe Bluetooth
  > (though the Layer 2 handover times for Bluetooth are even 
  > worse than for
  > 802.11).

=> Bluetooth is not really relevant here IMO.

  > > You're essentially requesting to disallow a mechanism that
  > > will work sometimes in IEEE802.11 and in future can work 
  > all the time,
  > > without providing a better substitute. Needless to say that
  > > this mechanism will work on other (e.g. cellular) links.
  > >
  > 
  > Can you give me the name of an existing 802.11 product 
  > where anticipated
  > handover will work? 

=> My Lucent card gives me this information. Unfortunately
our implementation is not finished yet so I can't point you
to it; Anyway, it's not open source so I can't send it to 
the list. But see:

http://www.cs.umd.edu/~moustafa/Downloads.htm

as one example, and see Greg's mail for another example. 

I would actually like nothing better 
  > than to get my hands on
  > such a card, because I have been very eager to test 
  > anticipated in some
  > realistic deployment scenarios. We have been working on 
  > testing anticpated
  > handover now for almost a year, and the only kinds of 
  > scenarios we have been
  > able to test with are if we set a fixed prehandover trigger 
  > time and then switch
  > to a fixed access point. Needless to say, this is not 
  > realistic. We have even
  > tried to measure the power levels at handover in a real 
  > hotspot network and do
  > some statistical analysis to figure out if we could derive 
  > a threashold power
  > level that would allow us to force a handover without 
  > danger of the card
  > switching to another access point while the prehandover 
  > anticipated IP signaling
  > is completing, but we could find no correlation.
  > 

=> I agree that current testing is not realistic. I think
R. Caceres had a good paper on this a few years ago which
I managed to lose when my disk crashed. Could someone 
send a pointer please if they have it? 
Have a look on the web, or at the link I sent you for 
ideas on how to do this.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 6 Nov 2002 13:31:26 -0800

> but I'm mentioning one that I know pretty well. You can also

wCDMA, as currently defined in R5, the latest 3GPP specification, uses GTP
tunneling and GPRS for mobility management. Thus, from a *standardization* (as
opposed to experimental) standpoint, it is not a candidate. From an experimental
standpoint, is is in fact a very interesting possibility, but there is a lot of
work required on many issues, interesting topics for researchers.

W.r.t. IEEE cards, as mentioned, I would just love to get my hands on one that
would let us do anticipated handover. :-)

> based handover and satisfy your 2 requirements above.

We're not discussing tunnel based handover, we are discussing whether
anticipated handover should be standardized at this time. IMHO, pure tunnel
based handover is also experimental. For FMIPv4, this has been recognized by the
WG by taking the draft to Experimental rather than Proposed.

> work. So why should we remove this again?

Because our implementation experience is that it is not possible to implement it
on existing firmware in any way except as a laboratory test. Greg can comment on
Monash's experience.

> as one example, and see Greg's mail for another example.

Thanx for the tip, we'll look into it. It looks like there may be a few cards
where this could be done. But not all, and that is a problem with doing a
standard. Would the standard have to say something like "don't try this except
on Manufacturer Foo's card?"

We're working on trying to get some more realistic test data.

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 10 Nov 2002 13:12:02 -0600

Hello Hesham,

>but I'm mentioning one that I know pretty well. You can also
Can you please elaborate on how it is possible to implement anticipated 
HO signalling on WCDMA? I thought that even base MIPv6 handover can not 
be implemented in WCDMA?

--behcet