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

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

Hongyi's note about jitter and bicasting spurred a bit of pondering
about how to get a better idea of the problem, similiar to the
bounds on buffering in draft-kempf-beth-ipv6-01.txt. The following is
an analysis, not as mathematically based as the buffering bounds, but
still perhaps useful. It seems to me that jitter is one technical
problem that the proponents of bicasting need to address in order
to have a convincing solution.

Consider the following sequence of packets from the CN:

	CN packet stream: x,x+1,x+2,x+3,x+4,x+5...
	
where x is the sequence number when bicasting begins. 

There are two possible cases where jitter could cause duplication
or dropped packets:

1) A packet is delayed on the bicast link to the new AR due to network
congestion between the source of the bicast and the new AR:

	old L2 packet stream: x,x+1,x+2,x+3,x+4,x+5...
	new AR packet stream: x,x+1,...,x+2,x+3,x+4,x+5...
	
In this case, the MN gets a duplicate packet when it appears on the
new L2. For example, if the MN hands off at x+3, it gets a duplicate
x+4 packet.

2) A packet is delayed on the old L2 link due to deterioration in the
radio conditions approaching handoff:

	old L2 packet stream: x,x+1,...,x+2,x+3,x+4,x+5,...
	new AR packet stream: x,x+1,x+2,x+3,x+4,x+5,...
	
In this case, a packet is dropped. For example, if the MN hands off
at x+3, it will miss x+4.

In the case of 1, the probability of a duplicate packet has nothing
whatsoever to do with the radio link. It is purely a matter of traffic
engineering in the wired network. So the probablility of a duplicate
packet can be reduced by properly engineering the wired network. In
addition, the probability is likely to increase with the topological
distance between the new AR and the source of the bicast (simply
because, the more network a packet has to traverse, the more likely
it is that a congestion event may cause delay). Since engineering
of the wired network is largely under the network operator's control,
this problem is fairly straightforward to solve, though it may
require measures such as overprovisioning.

The same is not true of 2. Radio conditions at handover are not entirely
controllable through network engineering. They change based on dynamic
factors such as what types of objects (like big trucks) sit between the MN and 
the radio AP, in addition to more static factors. So a more likely source
of problems due to jitter is a dropped packet due to delay of a packet
on the radio link.

Before drilling down on this problem, I'd like to consider two different
kinds of bicasting that have been proposed, since I think they have
very different properties with regard to a solution. The differences
may not be clear in people's minds, though there have been illusions
to them in the email. They are:

	1) Simultaneous bindings, in which an agent (HA/RegReg/MAP, etc.)
	back in the network is bicasting simultaneously to the old AR
	and new AR (reference: draft-elmalki-mobileip-bicasting-v6-00.txt).
	
	2) Edge tunnels, in which the old AR is bicasting to the new AR
	(references: draft-kempf-beth-ipv6-01.txt, 
	 draft-ietf-mobileip-lowlatency-handoffs-ipv4-01.txt,  and implied
	 in draft-ietf-mobileip-fast-mipv6-01.txt if the old CoA is
	 used on the new AR).
	 
In 1), signalling from the MN establishes simultaneous bindings for
old and new CoA. In 2), the routers (or FAs for MIPv4) bicast without
the MN becoming involved.

The delay of a packet on the radio link usually happens because radio
conditions deteriorate. Bit error rates around handover can escalate
to 10**-3 or 10**-2, something unheard of on wired networks. At 10**-3,
one could expect a bit error on every Ethernet-sized (1500 byte)
packet. To counter this, most radio protocols have relatively small
L2 frame sizes, and perform retransmit on a frame basis. So a bit
error in a single radio frame doesn't require the entire packet to
drop.

The net effect of increased bit error rate and retransmit is that
the MN begins to see a decrease in the IP data rate as radio conditions
become worse during handover. If the rate near the center of the cell
is 9.6 kbps, maybe it drops to 5 kbps as handover approaches. Of
course, if the MN doesn't handover, it drops to 0 kbps and the connection
is severed.

If we assume that the wired network provides a data rate considerably higher
(like 2-3 orders of magnitude) than the radio network, one way to
solve this problem is to clock the bicast data rate to the radio link
rate. So if the radio link slows down to 5 kbps, the bicast link going
out from the source does too. If this is done, the bicast source can
delay sending a packet out over the bicast stream until it is finished
sending on the radio link. This assures that the packet does not
get to the new AR (where it will be dropped if the MN hasn't
arrived yet) before it gets to the MN. Or, it can even *not* send the packet 
since the bicast source knows the MN has go it, and only send packets when
the MN actually disappears due to L2 handover. 

In any event, with the simultaneous binding approach, the HA/RegReg/MAP
agent is too far away from the radio link to be able to fine tune
bicasting in this way without additional help. One could imagine further
protocol support for getting this information to the agent, but since
there would be a delay due to  the transport time, it probably wouldn't
help, as there could be hysteresis as the agent tried to catch up
to the varying quality of the radio link.

With the edge tunnel approach, since the tunnel runs from the old
AR, the AR is in a position to obtain timely and accurate information
on the dynamically changing data rate over the radio link. Examples
here are the PDSN and GGSN for cdma2000 and wCDMA (resp.). For
WLAN protocols, the AR might not be directly connected to the radio
link, the radio link may rather be available via a radio AP
that acts as a transparent bridge. These cases are harder to solve, since they 
have the same problem as the simultaneous bindings approach, namely the 
information on radio link data rate is not available at the AR. Again, protocol
support for transferring the L2 information from the AP to the AR might
help, and the delay is likely to be less because the AP is on link
with the AR, but there is nevertheless the potential. 

So, in sum, the solution to jitter in bicasting is to tightly couple
bicasting with the performance of the radio link, so that the bicast
stream accurately reflects what the MN has received. This is not
as strong a coupling as the synchronization used in CDMA, but it
should work to reduce or eliminate packet drop for the most common case.
In addition, the wired network must be properly provisioned to
avoid congestion and thus duplicate packets on the bicast link.

Comments? Did I miss anything?

---

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

Hi Phil,

I like it! You've managed to say in 4 lines what took me a page
and a half.

		jak
		
>From: Phillip Neumiller <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting
>Date: Wed, 25 Jul 2001 13:38:04 -0400
>
>James,
>
>You just put in a jitter buffer.  It adds a fixed amount of latency.
>The jitter is defined as the variance of delay.  All you have to do
>is size the jitter buffer for this variance and you have solved this
>problem.
>
>Thanks,
>
>Phil
>
>> -----Original Message-----
>> From: James Kempf [mailto:[email-masked]]
>> Sent: Wednesday, July 25, 2001 1:32 PM
>> To: [email-masked]
>> Subject: [mobile-ip] Analysis of Jitter in Bicasting
>> 
>> 
>> 	and new AR (reference: 
>> draft-elmalki-mobileip-bicasting-v6-00.txt).
>>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 25 Jul 2001 15:44:40 -0400

As I mentioned in my previous email, tunnelling does not resolve
the lost packet problem identified by James in his first email.

I am not sure if it resolves the duplication problem either: one
way to look at the tunnelling solution is that it is a (temporary)
creating of a bifurcation point at the AR. This removes the delay
bounds issue I attempted to describe previously (there are 0 hops
between the AR and the bicast source), but does it remove the
duplication issue?

BTW: as we all know, jitter buffers turn variance into fixed delay
(this is how they are used in streaming audio and video for example).
The amount of jitter compensated for through buffering comes directly
out of your end-to-end delay budget. This needs to be considered for
two-way conversational traffic.

Gary

> From: Arthur Ross [mailto:[email-masked]]
> Sent: July 25, 2001 15:21
> At 10:54 -0700 07/25/2001, Michael Thomas wrote:
> >    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.)
> >
> I can also envision time-tagged traffic, which would open the 
> possibility of what I would call "Transmit erasures", these being 
> defined as failures of packets/frames to arrive in time. In such a 
> case the starved transmitter(s) would send some kind of "No data in 
> this frame" indication (or perhaps just send a deliberately 
> mal-formed packet that receivers could be guaranteed to reject, or 
> simply turn off the transmitter for that time slot).
> 
> FYI - the robust air interfaces utilize the concept of receive 
> erasures, this meaning received frames that have insufficient quality 
> to be considered correct. The definition of "quality" typically 
> includes a CRC, as well as other metrics, such as re-encoded symbol 
> error rate. In speech service the vocoders are constructed so as to 
> gracefully smooth over erasures. Erasure rates in the ballpark of 1% 
> typically are not objectionable for speech; higher rates are 
> increasingly deleterious.
> 
> In the context of "smoothed handoff" and more traditional IP traffic, 
> the transmit erasure would serve simply as a "don't use this one" 
> indication. Only if all participants were erased would the entire 
> frame be deemed unusable.
> 
>     -- ahmr
>

---

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

>...*provided* the combined L2/L3 handover latency is less than 112.5 sec, given
								      ^^^

Sorry, that's 112.5 *ms*.

		jak
		
>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: James Kempf <[email-masked]>
Date: Wed, 25 Jul 2001 14:26:06 -0700 (PDT)

Gary,

>This problem are not strictly a problem with bicasting. If the MN doesn't
>receive x+2 on the old L2 because of poor radio channel conditions, the
>same problem occurs with both re-routed and tunnelled approaches - namely,
>how does the handover solution know that x+2 has been lost, and how does
>it reinsert x+2?
>
>There are methods that can be used to address this problem with bicast, that
>I suspect
>are simpler then the other approaches (but someone may have a better
>approach).
>It involves purposely off-setting the stream at new AR from old L2. The
>offset
>should be equal to the number of possible packet losses (hopefully, no more
>then 1 packet). This introduces duplicates as a result (possibly with every
>handover), but a duplicate is easier to recover from then a loss,
>particularly
>when the duplicates are received within one or two packet durations.
>

This is sort of what I had in mind, but there are problems with
inserting a jitter buffer, as PhilN and MikeT have pointed out.

>
>Well, it takes more then over provisioning. You need to ensure
>the same number of hops between the bicasting source (the traffic
>bifurcation
>point if you will), and you also need to provide some guaranteed bounds on
>the delay at each hop after the bicasting source. *if* you want to ensure no
>duplicates
>at all at the receiver. This may seem like a definition of EF, but
>consider that the constraint is much more severe then that of EF. With
>EF the bound is on inter-packet delay and delay jitter for a single stream.
>With bicasting, the bound is on the arrival delay of two copies of the
>same packet that traverse different paths through N hops. The maximum
>delay difference, I believe, is one packet duration, T. Thus, the delay 
>difference bound at each hop must roughly be T/N (the relationship is
>not linear, but this gives a rough approximation). If the source of
>the delay is from queuing, then this would imply that there can be
>no other traffic following the same path. E.g. if a bicasted packet
>arrives at an AR and is queued behind a packet that is being served
>(note: served, not queued), from a different packet stream, then
>it receives a delay of roughly T/2.
>
>One obvious approach to this delay problem is to have only one hop
>after the bicasting source - the AR itself. This would seem to 
>impose serious constraints on the network engineering, and I believe
>would pose serious handover problems between bicasting sources.
>

Good points. Network engineering solutions along the lines you mention
are probably  unrealistic. People want to have more choices in the
way  they configure their access networks, not less.

>
>You have covered a lot. I  think the bottom line is that if you
>want to use bicasting, and avoid all duplicates at the receiver, you
>have to synchronize the traffic flows very carefully, which contradicts
>the principle of a hop-by-hop IP forwarding network. 
>
>The other idea is to consider the impact of duplicates, and look for
>reasonable comprimise between delay/loss compensation and duplicate
>removal over one to two packet durations.
>

IP really isn't designed for isochronous types of situations, with
these kinds of tight timing constraints (though it does suprisingly
well if you are willing to allow L2 to take care of the synchronization
for you). 

I think that the option of switching on an edge tunnel to new AR after the MN
disappears probably would work better than bicasting, if you can
fine tune things. If you can't, then you are left with having to
either bicast or buffer or neither to smooth, none of which are
particularly good.

		jak

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 26 Jul 2001 10:39:36 -0400

James:

  Just a quick follow-up on this thread: you mentioned in one of 
your emails that the latency tolerance for conversational voice to
be around 112.5 ms. It is my understanding that the latency bounds for
reasonable quality voice conversations (for an MOS somewhere between
3 and 4), is around 250 ms round trip. Assuming symmetry, the implication
is that the one way, end to end delay should be less then approximately
125ms end to end. 

  If the end to end service is VoIP, then this 125 ms budget must be 
applied to all the IP networks along the path - typically, an access
network, one or more transit networks and another access network. So,
I wonder if there really is 112.5 ms to buffer packets, or anywhere near
that amount, particularly given the fact that the current generation of
radio link protocols seem to consume 10s of ms simply for packet 
access (I'm alluding here to VoIP over the air, not VoIP converted to 
3G voice service).

   One rule of thumb I've always held to with packetized voice is that
if you have to delay the packet by more then the vocoder delay (e.g. 20 ms
for G.729), then you might as well drop the packet. If you start dropping
sequentially packets - e.g. 2 or 3 consecutive voice frames, the drops will
be audible to the user.

   It is my perception that the standard for voice service in cellular
systems 
during handoffs is not as stringent. However, this would not be the
"seamless
handoff" that has been talked about.

   Anyway, the question I want to raise is whether there is really a 112.5
ms 
delay budget available at the AR for handover, or whether the number is
actually
much smaller. Some of the work I have seen suggests that the bound is more 
around 40 ms, for the whole access network. This is roughly two VoIP
packets,
for a scenario with one 20 ms G.729 voice frame per IP packet.

Do you, or anyone else have any additional information? If we are talking
about
buffering vs. bicasting, this delay bound *is* very important.

Gary

> Sent: July 25, 2001 17:26

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 26 Jul 2001 14:52:02 -0400

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 7:21 PM
To: [email-masked]
Subject: RE: [mobile-ip] Analysis of Jitter in Bicasting

George Tsirtsis writes:
 > I think you are making the point that - end hosts already deal with
 > duplicate packets since this is a natural occurrence in the Internet
today
 > so bicasting should not be a problem -
 > 
 > The difference is that end nodes deal with duplicate packets up to a
 > point...i.e.: up to 3 re-orderings/losses etc generating 3 dupacks in a
row,
 > before TCP starts having problems. The fact that TCP deals with 3 dupacks
 > and not with 5 or 10 or 100 was an engineering choice that balances
 > adaptivity and throughput with the chances of this happening in the
Internet
 > or they just picked a number from thin air...wouldn't know...was not here
 > :-)
 > 
 > My argument is that bicasting, increases the chances of duplication on
top
 > of what the Internet naturally does and that could have bad effects if in
 > widespread use. Say for example, due to natural re-ordering somewhere in
the
 > Internet, a node is about to receive 2 TCP acks, which TCP can actually
deal
 > with no problems. At the same time the MN's packets are duplicated (due
to
 > bicasting) at the receiving end, which results in the MN receiving 4 TCP
 > acks! This forces TCP to half its window thinking that there must be
 > congestion in the network and the packets do not get across which is
clearly
 > not the case!
 > 
 > So, the objections here are not about being able to "deal" with
re-ordering
 > as it naturally occurs but that we should not introduce mechanisms that
 > artificially increase the chance duplicate acks.

George,

First off, disclaimer: I'm neutral on both
buffering and bicasting.

My point was simply that we not try to perform any
unnatural acts in the middle of the network to
hide jitter and duplication from the end
hosts. Yes, I agree that that will cause many
TCP's to barf, but the right thing to do is to fix
the TCP, not hide it in the network. In fact, the
effects of bicasting would only affect mobile
nodes, and I'd assume that ones which were the
targets of bicasting would have a fair amount of
incentive to deal with this inevitability. Were it
a possibility toward any random CN, then I'd
probably have a different opinion, but that
doesn't seem to be the case.

GT> But it will be towards a random CN...what do you thing the mobiles are
going to be? Definately not only specialized devices...any PC with any OS
may be mobile and thus the potential target of bicasting...BTW, I also thing
that TCP should be fixed...and thus EIFFEL is good work...we just need
experimentation experiance and time for it to be
implemented/tested/deployed...then yes, bicasting may become feasible.

Regards
George

	     Mike

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 09:06:23 -0700

Hi Gary,

>is that the one way, end to end delay should be less then approximately

Actually, I've been using a figure of 300 ms RTT, based on ITU recommendations.
112.5 ms is the handover latency that pops out when you plug a 6 kbps incoming
voice stream (about what VoIP gets) and a 9.6 kbps uplink data rate into
the formula dervied in Appendix B of draft-kempf-beth-ipv6-00.txt, which bounds
handover latency given uplink and incoming real time data rates when you buffer.
The problem is the handover latency propagates forward as you dump the buffer
to the uplink, during which time you have to buffer, then dump that buffer, etc.

IMHO, buffering is probably a nonoption for real time traffic, though I think
it could play a role for nonrealtime traffic.

>access (I'm alluding here to VoIP over the air, not VoIP converted to 

Hmm, good question. I have unfortunately been unable to get any figures
on L2 handover time, so I really can't say. But you are right that
this analysis only takes into account the handover latency. If you start
throwing in other sources, like for example transatlantic RTT for
a transatlantic call, you very quickly use up the delay budget.

>sequentially packets - e.g. 2 or 3 consecutive voice frames, the drops will

Sounds like a good rule of thumb.

>handoff" that has been talked about.

The goal is to make 4G (VoIP over the air) hard (break before make) handover have the
same quality or better as 2.5 and 3G. If the handover latency in 2.5 and 3G handover
exposes the user to artifacts, then 4G could I suppose, though running up the delay
budget to seconds with lots of signalling for new CoA aquisition, DAD, etc.
probably isn't a good idea.

Do you have any idea what the latency is for, say, a GSM handoff (which is normally
break before make)? This would certainly help us bound the problem more cleanly.

>for a scenario with one 20 ms G.729 voice frame per IP packet.

If you consider only one direction,  then 40 ms sounds right (it would be slightly less than
half of the 112 ms I calculated, which was based on a RTT time of 300 ms).

>buffering vs. bicasting, this delay bound *is* very important.

No, but I really wish someone out there in ListLand could give us some hard figures
on GSM break before make handover times. Last time I tried, I got some number like
"seconds", which doesn't sound right to me. wCDMA isn't comparable, nor is cdma2000
because they use soft handover most of the time (though perhaps their hard handover
figures would be useful).

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 14:55:55 -0700

Hi Gary,

>  I'm not sure that comparing handover latencies with 2, 2.5, or 3G
>is all that relevant. With soft handover, there is theoretically,
>no latency, although I suspect that there are exceptions - I'm checking
>to see if there are published numbers. I have heard some atrociously
>poor numbers for packet data, but I won't repeat them here because
>they are not verifiable.
>

My point is that users have a given level of service with 2.5G. If we
come to the 3Gs and say "we've got mobile IP handover figured out, but hard
handover times are 1.5 sec instead of 200 ms, so users are going to
notice when a hard handover occurs" they are less likely to be interested
in deploying VoIP to the handset.

>  The issue with packet data, and the reason that the latency starts to
>look bad, is that soft handover is extremely difficult to do with shared 
>channels, datagrams and a routed network (i.e. the issues are not all 
>that different from the issues being discussed with respect to bicasting).

Well, after having spent the last year looking at soft handover in IP RANs,
I am not convinced that this is the case. Soft handover is an L2 issue,
once the packet pops out of the macrodiversity combiner (or goes in),
it's exactly like getting it out of or putting it into a router that's
connected to an optical network or any other L2. Sure, there are issues
of isochrony w.r.t. getting the radio frames from the macrodiversity
combining point to the radio access points, but these need to be handled
by properly designing the L1/L2 in the RAN, regardless of whether IP or ATM is used
as the transport.

But we should probably take this to a separate thread.

>IMHO 2-3G networks are not well suited to IP services because they were not
>designed to switch packets fast across the channel (by fast I mean ms, not
>10s or 100s of ms). Ultimately, this channel access delay may be the
>real pacer for handover, not the mobility solution.
>

The PDSN/GGSN designs seem a bit on the heavy weight side. If/when we
get this handover story straigtened out, perhaps we can move the
routing point at least as far as the RAN controller.

>  Enough doom and gloom. In anticipation of a different approach in 4G,
>there is little information on how to allocate an appropriate "latency 
>budget" across the network. I know that the transit delays for North
>America for single operator networks have been dropping steadily, and are
>well below 100 ms (I've heard numbers as low as 50 ms, but I haven't had
>a chance to check the latest).
>
>  So, if its 50 ms transit delay, that leaves approximately 30 ms for each
>access network for one leg of a two way conversation. Not a heck of a lot 
>of time. Of course, it is arguable that you can asymmetrically allocate
>the budget between access networks, as it is unlikely that they will both
>need the maximum budget at the same instant (e.g. if both access networks
>are wireless, it is unlikely that both will be in the process of handing
>over
>at the same time).
>

Agreed.

>  BTW: I did not checked the ITU spec, but 300 ms is as good as 250 ms,
>certainly
>as far as these discussions are concerned. End to end latency bounds are 
>determined by the desired quality of the voice service, and usually are
>based upon empirical measurements from subjective quality tests (the ITU
>numbers are). 
>The numbers from these tests, called Mean Opinion Scores, have a very high 
>variance, and the real quality difference caused by an increase in latency
>from 
>250 to 300 ms is not easily detected (which means you probably can drop 
>the 0.5 from 112.5 ;^} ). One has to be careful in some respects, because
>there
>are thresholds where a majority of listeners can detect significant changes
>in
>quality (humans being largely non-linear systems), but if I believe the
>first
>threshold is upwards towards 500 ms, as someone else has mentioned.
>
>

I've heard the upper threshold is around 600 ms when the conversation
really starts to sound half  duplex.

One thing concerns me though: should we be using RTT or single leg? I've
been using RTT in my calculations, because if the mobile is out of contact
or busy downloading a buffer, then it would be so for both directions.

In any event, I think we need to use the delay budget for the access network
alone, which removes the delay across the backbone and in the other access
network.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Jul 2001 15:59:54 -0700

Hi Michael,

OK, so it sounds to me like the delay budget is even *worse* for buffering than
I thought. 300 ms is being generous. The numbers Gary and Arthur were quoting
seemed to be pointing in that direction.

It is beginning to sound more and more as if neither buffering nor bicasting
will do the trick. As you say, perhaps we should simply just get the tunnel
up as fast as possible and drop anything that comes in during L2 handover.

		jak

>Comments in line .. Michael Ramalho
>
>At 03:15 PM 7/25/2001 -0700, James Kempf wrote:
>>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.
>
>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
>
>
>>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
>
>
>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
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 27 Jul 2001 12:50:02 +0200

George,

> implemented/tested/deployed...then yes, bicasting may become feasible.
	=> The MN _requests_ bicasting. If it thinks it's "bad" then 
	it doesn't have to request it. What is the problem here ???
	If the MN decides that EIFEL is required to request bicasting and 
	it doesnt have it then it won't request it. 
	If it doesn't have EIFEL and doesn't have TCP connections open 
	then it can request bicasting without any troubles. 
	Only the MN is affected by its request. 

	In fact that is the main reason for the protocol change instead
	of making ARs just bicast on their own.

	I don't understand your point. 

	Regards,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 27 Jul 2001 12:53:10 +0200

> doesn't seem to be the case.
	=> That just makes TOO much sense !

	Hesham

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 27 Jul 2001 10:40:52 -0400

James:

  Sounds like we are reading from the same page. I realize I opened
up a can of worms with my comment on diversity combining and packet 
data. As you said, I think we will have to take the conversation off
line, perhaps over coffee in London. 

  Just to summarize, the purpose behind my comments on comparison
to 2G, etc., and delay budgets was that it is my view we have much
less then 100 ms for handover. Probably more like 20 ms - 40 ms. 
If we can agree upon this rough range, then we can avoid a very difficult
requirements analysis problem.

Gary 

> Sent: July 26, 2001 17:56
> To: mobile-ip; [email-masked]'