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

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

Vijay,

>> 
>> Um, so what happens to the real time packets while the FBACK is getting
>> buffered? And how do you know that the FBACK will arrive and should
>> be buffered exactly during L2 handover? It could arrive before, it
>> could arrive after. What about the rest (minimum 4 at my count)
>> packets involved in FMIP handover before the MN gets to start
>> doing DAD (over the air), etc., on the new AR before it can
>> start getting its real time traffic?
>
>i lost you. it doesnt matter when the FBack arrives at the newAR, 
>the newAR has to buffer it till the MN shows up. the newAR doesnt 
>know if the MN got the FBack while it was still attached to the 
>oldAR.
>

What I'm saying is that if there is more than a 300 ms gap in
a real time voice stream, the user notices a click. If the gap
propagates forward, so that there is more than a 300 ms delay
in the real time traffic, then the conversation begins to
sound like half duplex.

The number I gave of 112.5 ms is the maximum amount time on a 9.6 kbps
uplink that buffering can be done before the 300 ms bound is exceeded.
For the scenarios calculated in Appendix A of draft-kempf-beth-ipv6-01.txt,
which I think are about the minimum traffic for an FMIPv6 handover
(somebody please correct me if I am wrong), the minimum L3 handover time is 133 
ms. This already exceeds the buffering bound.

The FBACK isn't strictly necessary for the MN to start getting
real time traffic right away after handover (and, frankly, that
is really all that counts if you want the user not to notice). The
FBACK is only necessary to complete new CoA aquisition. The MN
can get its real time traffic through a tunnel from the old AR
using its old CoA then finish new CoA aquisition whenever. That is what
draft-kempf-beth-ipv6-01.txt advocates, and it is envisioned in
draft-ietf-mobileip-fast-mipv6-01.txt as a corner case.

So if you want to buffer and you've got real time traffic, your choices are:

 1) Use FMIPv6 handover and crank the uplink data rate up until you can download
  the buffer fast enough over the air from the new AR to not have the latency
  propogate. 
  
 2) Use BETH handover if the L2 handover time is less than 112.5 ms (for
 a 9.6 kbps downlink data rate).
 
Otherwise, if L2 handover is too large for 2) or you can't crank the
data rate, you are better off dropping the packets.

		jak

---

From: Theo Pagtzis <[email-masked]>
Date: Wed, 25 Jul 2001 15:22:33 -0700

A slight correction/question,

   Mobility support for IPv6: The minRTadvInterval is set to be 0.05 sec. So far I
knew it was 0.5 sec. Is that a mistake or has it been decided to allow RT adverts
every 50 msec?

Cheers

Theo

UCL/Mobile Systems

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 26 Jul 2001 09:43:57 -0400

Comments in line .. Michael Ramalho

>in the real time traffic, then the conversation begins to

Jim,

I noticed this 300 ms assumption in your draft. However, you will
probably notice a pop/click long before 300 ms (assuming there is
coded voice/music coming toward you during this time). This depends
on the error concealment algorithms in the codec for lost/delayed
packets.

For example, depending on if you were in the middle of a long
voiced vowel - which is more forgiving - or short duration/energy
fricative or plosive - like a "b" or "p" - which becomes completely lost
in the lost packet. Thus sixty ms of loss in the middle of a vowel
can be easily concealed (six G.729 frames - usually three packets
worth), whereas the same time loss during a low energy fricative is
completely lost. Then you say ... what did you say? ... unless
you have good word interpolation skills.

The bottom line is that if the jitter buffer gets a packet after its
playback time ... it is lost for the purposes of meaningful playback
(I think Phil tried to bring this point out a few days ago). Having
good heuristics for the buffer management in this environment is
very important (Mike Thomas brought out this point a few days
ago as well).

The "worse case" 300 ms ITU number was an end-to-end number
for delay budgeting - not an "additive jitter before delays become
noticeable" number. In that sense, you misrepresented its meaning.

After 300 ms of one way delay ... interactive communications becomes
almost impossible (becomes increasingly toward a half-duplex
conversation). A satellite connection has a minimum of 512 ms
round trip delay - which is half-duplex for me.

Fortunately ... most of the coding is non-speech (e.g., silence/background
noise) and most of the "remaining real speech" is voiced ... so we have
some statistics working for us during handoff additive delays.

Lets just get the handoff/tunnels up as fast as we can ....

Michael Ramalho

>data rate, you are better off dropping the packets.

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Summer Office: +1.941.923.1203 (July/Aug 2001)
Office: +1.732.449.5762
Cell: +1.732.809.0188