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

From: James Kempf <[email-masked]>
Date: Wed, 21 Feb 2001 15:20:11 -0800 (PST)

>If I don't have to communicate with upstream routers, I simply don't.
>I don't have to wait for them.  They don't have to wait for me.  Unless we
>are able to ignore latency (which I don't like to do), micro-mobility will
>blow the doors off mobile IP in a bee's nest of edge devices on the
>edge where IP addrs don't change.  I know this is a hand waving
>argument but its intuitively obvious isn't it James?
>

No, it's not. If the apps are web browsing, the upstream routers are
going to have to know about the route, otherwise, the packets from
the Internet won't get back. It's got to propagate at least to
the border of the BGP routing domain. It's not clear to me that this
would be any faster or slower than hierarchical MIP. Unless the proposal is to 
simply use host routes, in which case maybe there is nothing to discuss.

And that is the point I was trying to make. We can argue this point
endlessly, numbers are a bit more difficult to argue with. 

If I might add as an aside, numbers were what convinced 3GPP to look at
IP in the UTRAN. We had simulations of IP on important UTRAN interfaces
and discovered that IP was actually better than ATM, contrary to the
"intuition" of the people who originally designed the UTRAN. 

		jak

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Feb 2001 15:35:27 -0800 (PST)

James Kempf writes:
 > the border of the BGP routing domain. 

   Not so. The change only needs to propogate to the
   join point. I'm trying to dig up some particulars
   since I'm in no way a routing expert, but a link
   reversal protocol certainly doesn't have the problem
   you claim, and I'm not convinced that IS-IS or
   OSPF are hopeless either.

 > endlessly, numbers are a bit more difficult to argue with. 
 
   Fine. Look at my RSVP stuff as one data
   point. There's lots of numbers in there and
   it's pretty clear that MIP/FMIP/HMIP suck
   rocks in comparison.

 > It's not clear to me that this

   Um, you also get to factor in that HMIP creates
   lots of single points of failure.

		  Mike

---

From: Phil Neumiller <[email-masked]>
Date: Wed, 21 Feb 2001 18:57:04 -0600

James,

You lost me with your argument here.  How is the bearer path relevant
to signaling latency?  If I don't have to signal up stream I simply
DONT, case closed right?  I have no problem with analysis, simulation,
and prototyping.  I am an advocate of this approach.  In fact in my
own demented world I have started doing this.  I plan to release
a public domain instrumented MIP reference implementation with all
kinds of cool hooks for fast handoff, SeaMoby, and MANET.  This is
something I have been hacking on for a looong time.  I even had plans
of doing some inter-operability testing at connect-a-thon with it but 
I may not make it.  The code is not intended to be a real 
implementation, i.e. it is written in Java for portability and
readability (my Java code is self documenting :=)) (it uses JNI
to build MIP ICMPs on Linux and Win32 boxes).

73s,

Phil