Subject: [Mip4] Request to consider FMIPv4 as a working group document

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 17 Mar 2005 13:53:22 -0800

Hello folks,

We made a presentation at IETF 61 about a way to do
fast handovers with Mobile IPv4.  Our method is adapted
from the protocol for Mobile IPv6,
     draft-ietf-mipshop-fast-mipv6-03.txt

The Mobile IPv6 protocol has been approved for
publication and is currently in the RFC editor's
queue.

The discussion at IETF 61 can be reviewed from the
minutes, located at:
http://www1.ietf.org/proceedings_new/04nov/toc.html#int

As part of this discussion, I showed some results which
indicate very good performance for FMIPv4, suitable for
handling interactive voice applications.  I probably have
the PowerPoint presentation around somewhere if needed.

The protocol specification for the Mobile IPv4 fast
handovers is documented in the Internet Draft:
     draft-koodli-fmipv4-00.txt
which is available in the standard IETF draft
directories.

Thanks in advance for your consideration of our
request.

Regards,
Charlie P.

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Kent Leung <[email-masked]>
Date: Fri, 18 Mar 2005 10:44:44 -0800

Hi Charlie.

Generally, I support having a WG solution for fast handover
using MIPv4.

Some of the areas that is debatable in the draft:

  - Key difference between MIPv4 and MIPv6 is FA existence.
  - FMIPv4 enabled ARs not being FAs is unlikely, IMHO.  So
    we can simplify by specifying only FA mode operation, no CCoA
    support needed since ARs would have to be MIPv4 enabled.
    This would fit the deployment model and clean up most of
    draft dealing with IP address management.
  - Support for fast handover in WiFi already exists today w/o
    MIPv4 involvement.  Therefore, realizing deployments using
    this type of scheme will be difficult.

Haven't read the draft in detail for specifics to MIPv4.  Will comment
on them later.

Kent

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 Internet Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 18 Mar 2005 12:20:26 -0800

Hello Kent,

Thanks for your comments.  I have several follow-on
discussion points below.

> Generally, I support having a WG solution for fast handover

I hope you will find that FMIPv4 is useful for that purpose.

>   - Key difference between MIPv4 and MIPv6 is FA existence.

Well -- there are route optimization details and additional security
features that are also key differences...  But these are not necessarily
relevant to FMIPv4.

>    draft dealing with IP address management.

I think it is reasonable to have an access router that is not
a foreign agent.  Specifying that operation does not seem to
complicate the rest of the specification which relates to the
case of AR == FA.  So, I don't see any reason to take out
that part of the specification, and it could be useful.

>    this type of scheme will be difficult.

Even WiFi access points or access point controllers might
well implement this feature, especially for the case of
heterogeneous media.

Thanks in advance for any more detailed comments
you can offer.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Fri, 18 Mar 2005 13:07:41 -0800

>features that are also key differences...  But these are not necessarily

The relevance is in the next point of scoping the solution space.

>that part of the specification, and it could be useful.

My point here is that "Is it realistic to upgrade the access router
with Mobile IP fast HO function w/o FA?"  Why would a network
deploy MIP and upgrade the IPv4 access router to aid Mobile
IP clients for handover and not perform FA service?  I believe
if only FA mode is supported, the draft would be simpler to
understand and implement.  Maybe I should write up a
narrow-minded version? ;)

>well implement this feature, especially for the case of

I don't see why since solution already works and end users don't care
if Mobile IP is used or not to obtain fast handover.  I think some
of the concepts in the draft are useful in practice.

Kent

---

From: "Espen Klovning" <[email-masked]>
Date: Fri, 18 Mar 2005 23:30:03 +0100

Hi Charlie

I support making this draft a WG item.

I do have some concerns that more or less reflect what Kent Leung has voiced
in previous mails on the list. 
- AR == FA 
- IP address management

An additional issue is how the MN-PAR auth extension is handled. I take it
this will reuse MN-FA auth extension. It will require key distribution of
some kind that could jeopardize the performance benefits. What am I missing?

regards
espen
Espen Klovning
Birdstep Technology

In addition, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Charles E.Perkins
> Sent: Thursday, March 17, 2005 10:53 PM
> To: Mobile IPv4 Mailing List
> Cc: Rajeev Koodli
> Subject: [Mip4] Request to consider FMIPv4 as a working group document
> 
> 
> 
> Hello folks,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 Mar 2005 17:41:03 +0100

[I have some comments on the draft, not the request itself, please
  disregard if already discussed or clarified.]

Espen Klovning wrote:
> I do have some concerns that more or less reflect what Kent Leung has
>  voiced in previous mails on the list. 
 >- AR == FA
 >- IP address management

I tend to agree with this.

The draft explains, but is not clear about what happens to FMIP when
CCoA/DHCP _is_ used.  If DHCP is _not_ used with FMIP then the draft 
should say so and in a coherent manner, IMHO; otherwise the generic 
"compatibility" statements confuse me at three points.

   "[First Scenario]: the access routers are not involved in IP address
    management for the MN. The mobile nodes acquire a new care-of address
    upon attaching to a new subnet link as they normally do."

In some deployments, MN normally acquires an address with DHCP and the
first-hop router is a DHCP Relay, so the AR practically _is_ involved in
IP address management for the MN, although the AR is not a DHCP Server.
  So the question coming to mind immediately is what is meant by "access
routers are not involved in IP address management for the MN"?  Does
that simply mean that AR is not a DHCP Server and is a DHCP Relay?

Second point is about DHCP and additional delays.  If vanilla DHCP is 
used then the effective DHCP delays are in the range 1s-10s with a 
802.11b WEP first-hop, 100Mbit Ether and GHz computers.  That is very 
large, easily influencing real-time.  It is not clear in the draft how 
any of these numbers influence FMIP - is FMIP slower if vanilla DHCP is 
used?

Third point is the apparent incoherence between abstract and body, with 
respect to DHCP.  The abstract says "For reducing the IP address 
configuration, the draft provides two alternatives" and none is DHCP. 
Or, later in the body one can read "Address allocation and configuration 
may be supported using DHCP or any other method."

Just some thoughts...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 Mar 2005 18:31:44 +0100

Hi Charlie,

Charles E.Perkins wrote:
> As part of this discussion, I showed some results which indicate very
>  good performance for FMIPv4, suitable for handling interactive voice
>  applications.  I probably have the PowerPoint presentation around 
> somewhere if needed.

Yes, I need these slides, please send in if easily available for you,
thank you.

I am interested to find out about "hard" limits on the interruption
times that a human user of a interactive voice IP application is ready
to tolerate.  During some IP and non-IP discussions, very often the
numbers 100ms or 200ms come up.  But for some reason I'm unable to
identify a written report/paper, eventually with some "hands-on"
non-simulated experience to determine this "tolerable delay".  Anything
like a I-D report or ppt slides or journal/conference paper applies, thanks,

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 21 Mar 2005 09:58:12 -0800

40-60 ms, depending on the particular phonemes that are interrupted.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Charles E.Perkins" <[email-masked]>
Cc: "Mobile IPv4 Mailing List" <[email-masked]>; "Rajeev Koodli"
<[email-masked]>
Sent: Monday, March 21, 2005 9:31 AM
Subject: Re: [Mip4] Request to consider FMIPv4 as a working group document

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 Mar 2005 20:06:09 +0100

> 40-60 ms, depending on the particular phonemes that are interrupted.

Thanks, good to know.  That approximately matches what a 1Ghz i686
laptop, PCMCIA 802.11b WEP, linux can do, as a effective (userspace)
802.11b attachment time.

That does not mean that 802.11b userspace attachment time is that good
everywhere, and in some cases it can be as slow as 4seconds, an
interruption delay to which an IP FMIP protocol could presumably do
little or no help at all.

I'm wondering whether it's worth to note down some range of the
"tolerable L2 interruption delay", with actual quantitative limits,
within which a particular FMIP design is known to work and offer a
better user experience, IMHO.  The word "fast" itself in the protocol
name may invite to think about that, IMHO.

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 21 Mar 2005 15:52:01 -0800

Hi Alex, Espen and Kent,

thank you for your comments. We can clarify these points
in the draft. I will also provide some comments below.

Regards,

-Rajeev

> "compatibility" statements confuse me at three points.
We decouple new DHCP address acquistion latency by binding the current 
CoA (either CCoA obtained via DHCP or FA-CoA) to the NAR's IP address. 
So, when the MN arrives on the new link, it can do
DHCP/MIP while it can still use its previous CoA to send packets, and it 
receives packets sent to Previous CoA from the NAR.

> that simply mean that AR is not a DHCP Server and is a DHCP Relay?
The description is contextual. When we mentioned "access routers are not
involved in IP address management..", it is in reference to the Second and
Third scenarios where the AR/FA provides an IP address.
But, you are right that the First scenario includes an AR acting as a DHCP
relay. The protocol itself does not depend on such a functionality. This can
be clarified.

> any of these numbers influence FMIP - is FMIP slower if vanilla DHCP 
> is used?
>
Since packet forwarding to/from MN does not depend on DHCP completion, it
does not affect. (See above. the forwarding is set up for Previous CoA).

> Third point is the apparent incoherence between abstract and body, 
> with respect to DHCP.  The abstract says "For reducing the IP address 
> Or, later in the body one can read "Address allocation and 
> configuration may be supported using DHCP or any other method."
>
This needs to be rectified. _If_ the NAR returns a New CoA for exclusive 
use of MN (CCoA) via
DHCP, the NAR must have a pool of addresses to choose from when 
processing HI.

> Just some thoughts...
Thanks again for your comments.