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

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 May 2001 13:53:40 -0400

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Friday, May 04, 2001 5:29 PM
To: [email-masked]
Subject: RE: [mobile-ip] some comments on the FMIP draft

...

 > 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.

   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.

GT> I think I mostly agree with your points here...the only case were
buffering in the newAR is useful is the case were the MN manages to send an
FBU at the oldAR before the handoff...in this case the oldAR may go ahead
and start forwarding packets to the newCOA of the MN...This packets can now
be buffered at the newAR and be delivered to the MN as soon as it connects
to the newAR...You have to admit that it does not get faster than that...and
we wanted to allow this to happen...

GT> Also buffering is a difficult subject ...and while we (design team)
recognized it to be important we did not think we could solve this at the
same time...The problem is that the MN may or may not request buffering, the
network may or may not want to provide the requested buffering ....while not
all applications would gain from buffering during handoff....there is a lot
to this....and it needs to be resolved but not as part of this draft I
think...

Thanks
George

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 May 2001 12:10:39 -0700 (PDT)

> we wanted to allow this to happen...

   Yes, faster, but the question is it faster that actually
   makes a difference in reality. Playback delay with 
   jitter buffers need to be able to smooth the entire
   set of glitches that might happen to get acceptible
   voice quality (sorry to be so VoIP-centric here), and
   the difference of, oh say, an extra 10ms with, say,
   an 80ms playback delay may not be terribly
   significant.

 > to this....and it needs to be resolved but not as part of this draft I
 
   Yup. I'm just trying to be constructive within
   the design criteria you-all are claiming is
   important.

		Mike