Subject: Re: [mobile-ip] Analysis of Jitter in Bicasting

From: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 13:30:23 -0700 (PDT)

>> >   Indeed, I suspect that the end-to-end principal is our friend
>> >   here. Real time traffic already uses jitter buffers, and good
>> >   ones are adaptive to transient conditions. For this kind of
>> >   traffic, you most definitely would *not* want L2-L3 smoothing
>> >   jitter out for you or you might end up with unnecessary additive
>> >   latency. I'm not sure that jitter concealment would be all that
>> >   useful in other places though. TCP's should be fairly resilient
>> >   to small amounts of jitter, which I would expect would be the
>> >   case with localized handoff schemes such as FMIP (ie, adding
>> >   80ms to an average RTT of 80ms because of FMIP handoff, should
>> >   get lost in the noise.)
>> >
>> 
>> The other alternative is to actually not bicast at all, but to
>> simply have old AR start tunnelling when it sees that L2 has
>> stopped sending packets through old AR. If it can get this
>> information. Much more bandwidth efficient anyway...
>
>with buffering on the new router to store the tunneled packets
>till the mobile node actually shows up.
>

...*provided* the combined L2/L3 handover latency is less than 112.5 sec, given
a 6 kbps incoming real time data stream (typical for VoIP) and
an uplink data rate of 9.6 kbps (typical of existing 2G voice systems).

If the latency is more, the buffering propagates into the user visible
region and the user will notice an artifact in the conversation, so
it makes sense to simply drop any incoming packets during handover.
See Appendix B of draft-kempf-beth-ipv6-01.txt for how to calculate
this number.

If we are not talking about a real time stream, then, of course, it
might make sense to buffer regardless of the handover latency.

		jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jul 2001 13:46:23 -0700

James Kempf wrote:
> ..*provided* the combined L2/L3 handover latency is less than 112.5 sec, given

i guess you meant 112.5 ms.

i need to buffer atleast one packet, the FBACK. otherwise it gets
dropped
and could potentially screw up fast handoffs.

> might make sense to buffer regardless of the handover latency.

set the buffer to a smaller size. drop the packets which came 
earlier.

vijay