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

From: Phillip Neumiller <[email-masked]>
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
> 
> 
> 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: Michael Thomas <[email-masked]>
Date: Wed, 25 Jul 2001 10:54:21 -0700 (PDT)

> is size the jitter buffer for this variance and you have solved this

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

---

From: Arthur Ross <[email-masked]>
Date: Wed, 25 Jul 2001 12:21:18 -0700

>    80ms to an average RTT of 80ms because of FMIP handoff, should
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