Subject: Re: [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 16:06:08 -0800 (PST)

>James Kempf writes:
> > 
> > > > 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. 
> > > 
> > >   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.
> > >
> > 
> > I'll take a look, but this is just one aspect. 
>
>   Sure, but it's a pretty important one for real time
>   flows.

Right, but its not the only one and it is not apparent (to me at least)
that it is the longest path. Maybe your work quantifies that?

>
> > >   Um, you also get to factor in that HMIP creates
> > >   lots of single points of failure.
> > 
> > So maybe there needs to be some kind of HMIP redundency work. 
>
>   That grinding sound you hear is the sound of wheel
>   reinvention.
>

Hmm, well, I thought we were talking here about whether to do a micromobility
protocol or not. Seems to me like the micromobility protocol is the
new wheel...

		jak

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Feb 2001 16:40:53 -0800 (PST)

> that it is the longest path. Maybe your work quantifies that?

   It tries. Quickly, a lot of the current crop of 
   proposals break pretty badly in the face of
   RSVP. Indeed RSVP as currently instantiated
   has a pretty major flaw in its current design
   because it doesn't have a sender flavor of
   shared explicit which causes RSVP to behave
   very badly in the face of any mobility. 
   Beyond that host route method fares pretty
   well though it would still benefit from a
   CT protocol which could eliminate the air
   round trips from the mobile which otherwise
   be required. 

   MIP, FMIP and HMIP are basically hopeless
   without CT though: they require a round trip
   to the CN to trace the new PATH. FMIP -- and
   maybe HMIP, I didn't consider it -- also bring
   another sticky problem: the forward tunnel
   requires a *separate* reservation (ala RFC
   2746) which presumably needs to be authorized.
   Clearly this brings up some interesting
   questions about how one would do that, and 
   try to be pretty blatent about that in the
   draft. Host routes neatly circumvents that 
   particular tar pit though.

   So just from RSVP, I can give you three concrete
   reasons why MM is useful:

   1) It doesn't require CT to produce results
      that converge locally
   2) It doesn't run afoul of the RFC2746
      implications
   3) It produces a lot less cross-net signaling

   The first two are clearly near-term wins, the
   latter is a longer term win as well.

 > protocol or not. Seems to me like the micromobility protocol is the

   I've never been convinced that there is, in fact,
   a new protocol that needs to be invented here: 
   it may very well be that IGP flood fills to
   propogate a host route which are summarized in
   a reasonable way is all that is necessary. I do
   think that it's important that this particular strategy 
   becomes part of the CT requirements though as
   route repair clearly only solves a narrow --
   though important -- set of the problem space.

   I'm not a routing geek though. Anybody know
   whether anything's going on with TORA? From
   my mostly uninformed position, it looks like
   it would produce pretty nice results for this
   problem too.

		    Mike

---

From: Claude Castelluccia <[email-masked]>
Date: Thu, 22 Feb 2001 10:50:51 +0100

Michael Thomas wrote:

>    to the CN to trace the new PATH.

really? HMIP requires only a round trip to the local MAP not to the CN...
that the basics of HMIP...
Either I did not understand your point well or you need to read the HMIP draft at
this  point ....

Claude.

--

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Feb 2001 09:55:42 -0800 (PST)

> Either I did not understand your point well or you need to read the HMIP draft at

   I should have looked at my flows again before being
   too flip.. it's more complicated than my "hopeless"
   remark.

   As it turns out, I believe that HMIP has the same
   properties as both the CN and HA cases, meaning
   that once the MAP sees the movement, it should issue
   a PATH on the new (tunnel) interface. Since
   the MAP is assumedly topologically closer, it
   ought to converge faster. The MN->CN direction
   would require MN to issue a PATH which would 
   join at MAP, assumedly.

   Also, there is the issue of dimensioning the 
   tunnel itself which seemingly requires a
   separate reservation. This is the same issue
   as with FMIP though.

   I do believe that all of these are helped by
   CT though. However, with CT, I'm not entirely
   sure what the benefit of HMIP is if any.

	   Mike