Subject: [mobile-ip] Analysis of Latency Propagation with Buffering

From: James Kempf <[email-masked]>
Date: Fri, 27 Jul 2001 14:18:23 -0700 (PDT)

Most of the criticisms over the past few days have focussed
on bicasting. In the interests of equal time, this note is focussed
on problems with buffering. I've exchanged email with people a couple
on this, and it is discussed in detail in draft-kempf-beth-ipv6-00.txt.
Apologies for reposting it here, but nobody seems to be initiating
a note about problems with buffering. The point of this note is that *both* 
smoothing techniques will require more work until they are ready for prime time.

The model for the analysis is a buffer at the AR sized to buffer incoming 
traffic in the time period during handover when the MN is unable
to receive real time traffic due to handover-related signalling
on L2 and L3. An incoming real-time stream is assumed that
delivers packets at a constant rate. The analysis is completely
irrelevant for nonrealtime data, since there are no constraints
on how much of a gap is tolerable before the user notices (well,
there are constraints, they are just not very tight). The radio
uplink is also assumed to have a constant, and relatively slow
data rate. The analysis is also not relevant for WLAN-style networks
with aggregate bandwidth at 10 Mbps with a few MNs in microcells.

With this model, the AR buffers traffic during the 
handover, T(0) in the analysis, then downloads that buffer
during a time interval of T(1). During the download, the AR 
needs to buffer again, and download during the time interval
of T(2)...etc. Obviously, if the incoming data rate is equal
to or larger than the uplink radio data rate, the process
never converges and the AR fails to catch up. If the
incoming data rate is less than the uplink rate, the
AR eventually catches up, but if it takes too long
the user will notice because the stream will lose its
real time characteristic.

It is possible to bound handover latency for a given incoming
and uplink data rate with a more formal analysis. 
Let:
    
      A = incoming data rate of the real time stream 
       
      B= outgoing data rate of the radio link 

      T(i) = time interval of the ith buffering 
    
In these notation, T(0) is the initial latency delay incurred during 
handover, T(1) is the delay incurred downloading the buffered 
traffic from handover, etc. 
    
The initial amount of data accumulated in the buffer during handover 
is A*T(0). The amount of time it will take to download this data to 
the MN over the radio link is (A*T(0))/B. This is equivalent to T1. 
Continuing the process results in a series: 
    
      T1 = (A*T(0))/B 
       
      T2 = (A*T(1))/B = (A*((A*T(0))/B))/B = ((A/B)**2)*T(0) 
       
                        ... 
       
Which can be represented as: 
    
        R = limit (n->infinity) sum (i = 0,n) ((A/B)**i)*T(0) 
    
The above is a simple geometric series, which converges to: 
    
        R = T(0)/(1 - (A/B)) 

In Appendix B of the paper, I used a figure of 300 ms for an
upper limit before people start noticing. Subsequently, Gary Kenward
and Michael Mahalo have recommended  125 ms or even
40 ms, suggesting 300 ms to be too generous. 

Suppose we take 125 ms provisionally, and see what handover time
would work for a 6 kbps real time stream (== A) and a 9.6
kbps radio uplink (== B). VoIP streams generally run about 6 kbps
and 2.5 G systems use 9.6 kbps radio uplinks for voice, so the
networking rate is about what we have now and what we would have
to match to have a competitive 4G system. Calculating T(0) results
in a handover bound of:

		T(0) < 46 ms
		
So if the initial handover latency is less that 46 ms, the buffering
latency will propagate until the user notices. 

There are a couple of conclusions I think one can draw from this:

	- Buffering won't work very well for real time data unless
	the initial handover latency is really tiny. You might
	do better by simply dropping the real time packets.
	
	- Since the analysis is irrelevent for nonrealtime data,
	buffering should be fine if there is no hard upper limit
	on the amount of propagated latency the user will tolerate.
	For TCP streams, for example, it will probably work
	better than bicasting because there is no chance of
	dropped or duplicated packets.
	
	- With  the exception of BETH, most of the FMIPv4 and FMIPv6 
	handover scenerios have L2 + L3 handover latencies far in excess 
	of this figure, suggesting that buffering won't work for them if real
	time data streams are the primary consideration.
	
Comments?

		jak

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 30 Jul 2001 15:53:38 +0200 (CEST)

>        R = T(0)/(1 - (A/B)) 

Jim,

You seem to have computed the total time until the buffering and downloading
of the buffer process is running.
This is longer than the maximum delay that buffering adds to any packet.
In fact, isn't the max delay added just T(0) for the first packet
that was buffered. Then subsequent packets see a linearly decreasing 
addional delay until R time units have passed.

  Erik