Subject: RE: [seamoby] Is Mobile IP too slow or is Routing Table Update To o slow? (was....)

From: "Gary Kenward" <[email-masked]>
Date: Thu, 22 Feb 2001 22:13:38 -0500

I asked the question early on as to how slow was MIP (on
the CT email list). The only concrete answer I received was
2-3 seconds for a handover. A single data point, to be sure,
but it doesn't sound too fast to me.

The email exchange is available on the CT archive.

Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2001 5:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [seamoby] Is Mobile IP too slow or is Routing Table 
> Update Too
> slow? (was....)
> 
> 
> Phil,
> 
> Just one comment...
> 
> >While this seems to be a very concrete item for the working 
> group it's
> >difficult to see the problem statement in the rest of the 
> document for which
> >this work would apply.  It appears to be a solution without 
> a problem.
> >Specifically one might want to state a problem and then why 
> a combination of
> >mobile ip fast handovers and regional registrations wouldn't 
> suffice to
> >solve it.
> >
> >pdn>Early on, I had a single sentence problem statement that 
> b*tched about
> >pdn>how slow mobile IP would be if/when used in a tangle of 
> pico cells
> >pdn>and how completely unnecessary it is in these scenarios. 
>  It got yanked.
> >pdn>I still believe we need a single statement that does 
> complain about
> >pdn>how MIP is intended for macro not micro-mobility.
> >
> 
> I've heard this mentioned a number of times and I have not seen the
> numbers to prove it. I've also heard the opposite, namely that
> a routing update solution would be too slow because the convergence
> of routing tables is a slow process. 
> 
> The point is, nobody really knows. It seems to me that one of the
> charter items for Seamoby might be to find out if there is a problem.
> Some hard, cold data can do alot to convince.
> 
> 		jak
> 
>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Feb 2001 17:43:36 -0800

Hello Gary,

Mobile IP can be arbitrarily fast or slow.  If you'd like to make
it slow, crank down the advertisement rate to once per hour.
If you'd like it fast, register in response to layer-2 triggers over
a fast core network.  There isn't any one answer.  However,
it has been shown that, given appropriate and obvious parameters,
Mobile IP can handle voice handovers.

Regards,
Charlie P.

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Tue, 27 Feb 2001 00:55:15 -0800

Hello Charlie:

I'm in agreement that MIP can run fast - but you wouldn't 
want to do that in a large scale way, right?
I think you are hinting at that in your response.

BTW, do you have a reference for the Mobile IP handling
voice? 

Thanks,
---
Andrew
http://comet.columbia.edu/~campbell

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Charlie Perkins
> Sent: Monday, February 26, 2001 5:44 PM
> To: Gary Kenward
> Cc: [email-masked]
> Subject: Re: [seamoby] Is Mobile IP too slow or is Routing 
> Table Update
> To o slow? (was....)
> 
> 
> 
> Hello Gary,
>

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 27 Feb 2001 09:51:16 +0100

Hello,

> want to do that in a large scale way, right?

For the large scale scenario, you probably  have to use HMIP that is only a
simple extension to MIPv6. HMIPv6 use the same components, same
registration protocols, ... than
MIPv6 and I see (or at least I'd like to see it)  it as part of MIPv6...

I am convinced that with appropriate parameters (rt adverts. frequency. MAP
location,....) you can handle
voice handover with Mobile IPv6 in a small network...but you probably need
the hierarchical extension for a large scale scenario....

regards,
Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Gopal Dommety <[email-masked]>
Date: Mon, 26 Feb 2001 02:31:38 -0800

At 09:51 AM 27/02/01 +0100, Claude Castelluccia wrote:
>For the large scale scenario, you probably  have to use HMIP that is only a simple extension to MIPv6. HMIPv6 use the same components, same registration protocols, ... than 
>I am convinced that with appropriate parameters (rt adverts. frequency. MAP location,....) you can handle 
>voice handover with Mobile IPv6 in a small network...but you probably need the hierarchical extension for a large scale scenario.... 

There are several components to handoff delay (see an  old anchor handoff draft). One of the delays is the backhaul delay 
(most of the time this is not the problem unless you are doing VPN etc). If this is a problem it is better to perform anchor kind of a handoff. 
Hierarchical instantiations do help but mainly to reduce the signaling (or limit the signaling to the local domain).

-Gopal

>><http://comet.columbia.edu/~campbell>http://comet.columbia.edu/~campbell 
>>
>>> From: [email-masked] [<mailto:[email-masked]>mailto:[email-masked]]On 
>>> > > From: James Kempf [<mailto:[email-masked]>mailto:[email-masked]] 
><http://www.inrialpes.fr/planete/>http://www.inrialpes.fr/planete/

---

From: "Dana L. Blair" <[email-masked]>
Date: Tue, 27 Feb 2001 07:17:35 -0500

>Mobile IP can handle voice handovers.

I am sure voice handover using Mobile IP could be made to work over a few hops with a few
nodes.  However, if we consider that a registration message may require several hops
that span the globe over one or more bandwidth constrained networks, then the propogation delay
could significantly contribute to handover
delay in the break-before-make case to a point where voice handover would not be
useable.

Some handover technique where the convergence point of the new access link compared
to the old is closer to the MN is needed to facility seamless handover.  Maintaing the same
IP address between ALn and ALn+1 removes the need for Home Agent interaction.
This is what we tried to say in the micromobility problem statement.

thanks,
Dana

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 27 Feb 2001 12:56:34 +0100

> (most of the time this is not the problem unless you are doing VPN etc). If this is a problem it is better to perform anchor kind of a handoff.

I don't understand your point...HMIP provides "anchor-based" handoffs...
 It is based on MAP (Mobile ANCHOR Points) but these MAPs do not have to be deployed (although they
can) on every links (as most of others fast handoff solutions require) ....

> Hierarchical instantiations do help but mainly to reduce the signaling (or limit the signaling to the local domain).

not only ....it reduces handoff delay, provides location privacy and a lot more ;-)

Claude.

--

---

From: "Dana L. Blair" <[email-masked]>
Date: Tue, 27 Feb 2001 07:24:38 -0500

At 09:51 AM 2/27/01 +0100, Claude Castelluccia wrote: 
> simple extension to MIPv6. HMIPv6 use the same components, same registration
> protocols, ... than 

I don't think Hierarchy is the solution for faster handovers.  Nailing down the
transport path for
a MN as various points only introduces more opportunity for failure while
possibly improving handover
spead but not gauranteeing an improvement in handover.  Include more heirarchy
in the IP network
is simply duplicating the errors of the cellular network on the internet.  Peer
to Peer addressability is the
only scalable technique for large scale mobility.  Addressing various middle
man routers increases
the latency because optimal paths may not be used and decreases reliability
because a statefule
single point of failure is introduced into the network. 

If any heirarchy is needed then it should only be introduced temporarily for
the duration of
a handoff between ALn and ALn+1 where the MN IP address changes.  If the MN IP
address
does not change then heirarchy is not needed.  Maintaining network intelligence
outside of
handover window introduces unecessary complexity in the routing path and
unreliability.

thanks,
Dana

>> > From: [email-masked]
>> [<mailto:[email-masked]>mailto:[email-masked]]On 
>> > > > From: James Kempf
>> [<mailto:[email-masked]>mailto:[email-masked]]

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Tue, 27 Feb 2001 09:55:23 -0800

Some tangential issues:

I still think vanilla Mobile IP with fast handoff (i.e.,
Low latency Handoffs in Mobile IPv4) is a limited
solution and in the end a patch - I think that is what Dana 
is trying to say in a nice way. But I don't want to
put words into people's mouths ;-) 

On another note:

I agree with Dana that tree like structures like HMIP, CIP, etc.
are points of failure and lack robustness - this should be a key issue
for seamoby not just going fast, context switch and paging.
One could use per-host routes but not based on a single tree or
a single gateway but a routed network with multiple gateways; 
clearly I'm pointing to limitations in CIP here, and
other proposals. When seamoby looks at the solution space then
Hawaii is closer to what I would consider a good starting point.

Again, as I mentioned that the last meeting, MIP should not be
pushed into every new problem space (and IETF wireless working
group) with the implicit instruction and due pressure 
to "make MIP work in this space". Seamoby should
have a clean slate. The only issue being to interwork with MIP 
and not use MIP as the base class for the solution. 

As a another aside, one has to make sure that one 
does not end up with a telco style 3G IP network, however;
with all that additional plumbing that limits scalability for IP.
Clearly the "All-IP" vision is more a marketing spin that substance.
Before you think I'm being rhetorical read those proposals. Stay pure
stay IP!

> From: Dana L. Blair [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2001 4:25 AM
> To: Claude Castelluccia; Andrew T. Campbell
> Cc: 'Charlie Perkins'; 'Gary Kenward'; [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2001 07:29:04 -0800 (PST)

> not only ....it reduces handoff delay, provides location privacy and a lot more ;-)

   Yeah, like single points of failure.

	      Mike

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 27 Feb 2001 08:34:49 -0800 (PST)

> You are misinterpreting what I wrote.
> 
> I never said 3G. I said that the last thing "All-IP" 3G
> networks are is "All-IP". You'd agree with that I'm sure?

As far as 3GPP2 is concerned, I actually disagree. We have been moving away
from anything legacy, and embracing IP technologies. I, of course, cannot say
anything in regards to 3GPP.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 27 Feb 2001 08:10:22 -0800 (PST)

> Before you think I'm being rhetorical read those proposals. Stay pure

Just to be clear, I work on one of the 3Gs, and it is not a marketing ploy. We
actually use IP, Mobile IP, and many other IETF protocols. In fact, you may
want to look at draft-bradner-3gpp2-collaboration-00.txt for any additional
information.

PatC

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Tue, 27 Feb 2001 11:20:29 -0800

Pat:

---
Andrew

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2001 8:10 AM
> To: Andrew T. Campbell
> Cc: 'Dana L. Blair'; 'Claude Castelluccia'; 'Charlie Perkins'; 'Gary
> Kenward'; [email-masked]
> Subject: RE: [seamoby] Is Mobile IP too slow or is Routing 
> Table Update
> To o slow? (was....)
> 
>

---

From: "Dana L. Blair" <[email-masked]>
Date: Tue, 27 Feb 2001 12:51:59 -0500

>anything in regards to 3GPP.

I concur with Pat's comments hear.  3GPP2 has been friendly with IETF protocols.
Unfortunately, however, the significantly larger market share of 2G and ultimatley
3G endpoints are will be 3GPP standards based. 

Dana

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 27 Feb 2001 08:55:56 -0800 (PST)

>    My poster child for "doesn't get IP" is the
>    CSCF. If it's anything more than a SIP proxy, it
>    misses the point big time.

Of course, this doesn't belong on this list, but I will reply anyways. The
CSCF is a really weird entity, and should be nothing more than a SIP proxy, as
you state. However 3GPP is adamant about inserting a CSCF in the visited
network, and forcing SIP clients to use the local proxy, instead of
communicating directly with their own home SIP server. How this will be
enforced is an exercise in futility, because no one there seems to want to
listen as to how IP really works.

As far as 3GPP2 is concerned, their equivalent is called the SCM. Initially,
it had the same broken architecture as the 3GPP one, but I (and others) were
able to bring them back on track, and use it as a pure SIP proxy.
Unfortunately, at the last 3GPP2 meeting I heard that some member was trying
to push the broken model again for "3GPP" compatibility. So more work is
apparently required on my part to re-introduce the "IETF" compatible mode :(

PatC

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2001 08:52:58 -0800 (PST)

> anything in regards to 3GPP.

   This is certainly good to hear. I
   can certainly understand where Andrew's coming 
   from because my admittedly blurred forrays into
   3GPP, 3GPP2, and MWIF land have mostly left me
   thinking that All-IP really means "change the
   TDM or ATM wires to IP wires, but otherwise
   faithfully recreate the current RAN/MSC". 

	      Mike

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 27 Feb 2001 09:48:30 -0800

Hello Andrew,

> I think you are hinting at that in your response.

Not at all.  This is not an issue of scalability, at least in
the way people usually mean that word.  For instance,
one could have frequent beaconing in a large population
of mobile nodes -- each node may or may not hear the
advertisement if it's send in broadcast mode, and so on.
One hopes (and is often disappointed) that beacons in
one cell do not affect another cell, but still I do not think
that beaconing affects scalability.

> BTW, do you have a reference for the Mobile IP handling

Kuang-Yeh Wang and I did some follow-on work to a paper
published by Ramon Caceres and Venkat Padmanabhan.
See http://people.nokia.net/charliep/txt/iscc99/iscc99.ps.

But more to the point I think it's intuitively obvious that something
along these lines has to work well, and can be made to work well.
Regional registration or HMIP is almost a red herring in the
discussion, except insofar as it will go about reducing the signalling
load and routing inefficiency in the core network.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2001 09:46:18 -0800 (PST)

> apparently required on my part to re-introduce the "IETF" compatible mode :(

   A little bit more a propos SEAMOBY, if there isn't explicit
   linkage to something that the subscriber wants that can
   only be allocated through the CSCF, then it's vestigial
   and hopefully harmless. The a propos SEAMOBY is that the
   only thing that _I_ can think that the provider holds over
   the user's head is QoS bits, which makes for a very good
   reason to make certain that COPS/Int/Diffserv are well
   integrated into our work so that the IETF methods are
   the path of least resistance. If they're thinking of
   going down the Packetcable DQoS COPS push model grafted
   onto the CSCF, they're in for some pretty nasty 
   surprises, because it doesn't scale to what they're
   hoping (ie, it's optimized around a single
   fixed provider), and doesn't allow other
   non-telephony QoS bits to be allocated
   (distributed online gaming, etc). 

		Mike

---

From: James Kempf <[email-masked]>
Date: Tue, 27 Feb 2001 12:43:46 -0800

Hi Andrew,

>networks are is "All-IP". You'd agree with that I'm sure?

I think 3GPP2 is making a strong effort to make their All-IP network all 
IP. They
even recently started an effort to rearchitect their RAN to be all IP (whether
it goes so far as to be connectable to the Internet, we shall see, but they
are trying).

3GPP is another story. They have lots of lingering telephony stuff around
for various reasons.

                 jak

---

From: "cnyap" <[email-masked]>
Date: Wed, 28 Feb 2001 00:33:23 -0000

Hi all

Then 3GPP may want considering to move to IIP instead. :)
Here is the 10 good reasons to move

1) Handle both mobile and non-mobile aware node,
2) Smooth transition from IPv4 to IPv6,
3) Reduced triangular routing problem,
4) Minimised (Advertisment, Paging ..... etc) over heads,
5) Highly secured signalling,
6) Precised subnet handoffs methods,
7) Eliminated ingress filtering problem,
8) Flexible addressing scheme,
9) Extremely scalable and robust,
10) Minimised protocols compatibility issues.

With the latest development in IIP (Strictly confidential),
It is not difficult to get another 10 good reasons to bore you.

Regards
Chern Nam Yap
MIEEE, MSc(Res), BSc(Hons)
Research Associate
Center for Mobile Communication Research
Department of Electronic and Electrical Engineering
University of Sheffield
F132 Mappin Building
Mappin Street
Sheffield S1 3JD
United Kingdom
Tel:+44 (0) 114-222-5182
Mobile:+ 44(0) 7712804892
Web: www.mobile1.net
E-mail: [email-masked]

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Andrew T. Campbell" <[email-masked]>; "'Pat Calhoun'"
<[email-masked]>
Cc: "'Dana L. Blair'" <[email-masked]>; "'Claude Castelluccia'"
<[email-masked]>; "'Charlie Perkins'"
<[email-masked]>; "'Gary Kenward'" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, February 27, 2001 8:43 PM
Subject: RE: [seamoby] Is Mobile IP too slow or is Routing Table Update To o
slow? (was....)

---

From: "Phillip Neumiller" <[email-masked]>
Date: Tue, 27 Feb 2001 21:27:11 -0600

How many installed sights are there running IIP, Chern?
How many mobiles? 

Thanks,

Phil
----- Original Message ----- 
From: "cnyap" <[email-masked]>

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 27 Feb 2001 00:10:39 -0800

>not only ....it reduces handoff delay, provides location privacy and a lot more ;-)  

Depending on the hierarchys and the movement it could increase the latency (the packet processing time is typicall order of magnitude than the
packet forwarding time). Long time  ago I happen to have done some research on the
number of hierarchies on the impact of handoff latencies and signalling. For internet kind of traffic (the actual paraments are the packet
processing  times and the forwarding delays of routers) the number of hierarchies tended to be 2 (HA and FA) for handoff latencies.

-Gopal