Subject: RE: [mobile-ip] some comments on the FMIP draft

From: James Kempf <[email-masked]>
Date: Fri, 4 May 2001 09:13:04 -0700 (PDT)

Mike,

>I didn't ask for network assisted handoff to be
>removed, and I didn't change the number or
>location in time of the pre-handoff messages from
>MN<->ARold. All I asked is for the buffering to be
>done on ARold instead of ARnew (a trivial change,
>I think) and making the HI/HACK optional if the MN
>is willing to take its chances on the new AR of
>doing DAD in a timely fashion.
>

Sure, but what I'm saying is that I think the MN signalling
pre-L2 handoff should be made optional as well if the link
layer can't support it. That's how the IPv4 design works.

With regard to the buffering, I need to take a look at
the spec more closely, but in general I think buffering
on newAR is more likely to reduce the gap for real time
traffic. I've talked to people who have done some experiements with 
buffering in IPv4 and buffering on the old Foreign Agent resulted 
in a noticable gap in real time traffic. Buffering is problematic
in any case for real time traffic, and anything that offers
the opportunity of delays will add to the delay budget and
increase the liklihood that there is a noticable gap. Buffering
on oldAR (in a bicasting/edge tunnel situation) makes sense
for smoothing during ping-ponging however.

Or am I misinterpreting your intent somehow here?

		jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 May 2001 09:29:03 -0700 (PDT)

> layer can't support it. That's how the IPv4 design works.

   Sure. But I haven't proposed anything different
   there than a couple of new flags. I think that 
   the draft supports what you're after though,
   and my proposal wouldn't change that.

 > for smoothing during ping-ponging however.

   Buffering isn't the only problem. The forward tunnel
   is going to change the delay characteristics for
   the jitter buffers too. If the two AR's are
   topologically distance and you have a short
   playback delays, the problem will, in fact,
   persist until the jitter buffer adapts. From
   that standpoint, I think it's probably a wash
   where the buffering is done.
   
 > Or am I misinterpreting your intent somehow here?

   Nope.

		Mike