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

From: James Kempf <[email-masked]>
Date: Thu, 2 Aug 2001 13:48:11 -0700 (PDT)

Erik Nordmark posted a note earlier this week pointing out that
the formula I sent out was the total time over which incoming
packets are delayed, not the delay experienced by an individual
packet. My response was that the figure of merit of interest
was the delay experienced by the user. 

Upon further reflection, I realized Erik's point. The user experience
will, in fact, depend on the delay experienced by an individual
packet. If a voice packet from the CN is delayed by 100 ms, then
the user will perceive a gap in the converstation. The importance
of the formula I sent out (R = T(0) / (1 - A/B)) is that it gives
the total amount of time during which buffering is occuring. The
fraction of that total amount during which the per packet delay is
greater than the user perceivable delay indicates how long the
user must wait until the conversation no longer sounds stilted.
If that amount of time is short, then there is a short blip. If
it is long, then the user ends up in a half duplex conversation.
So R reflects how long the buffering latency from handover will propagate.

IMHO, this alters the conclusions for buffering only a little. 
The handover latency will still propagate, but as long as the handover delay is 
less than the user perceivable amount, the latency will not be noticable.
If it is greater, then either there will be a short blip (if the
latency is small) or the user will have a half duplex converstation
for a period with a duration depending on how long it takes the
buffering series to move below the perception threshold. In any event,
since the bound is pretty tight, it will be difficult to meet it if
there is any L3 latency in handover.

		jak

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 08:24:24 -0700 (PDT)

Jim -- 

I hope that this is obvious, but whether the user
experiences a blip or not is dependent on the
length of the jitter buffer. If you have long
jitter buffer, you can smooth out blips like
handover delays quite nicely, so it's not
necessarily the user experience per se. This comes
at the expense of added e2e delay, but it's
probably not linearly additive with point sources
of delay. That is, the sum of the worst case
jitter per hop >> average jitter experienced.

That said, I think it's worth considering the
effect of the rather large and potentially
frequent effect of handoffs and/or buffering, but
I don't think it's worthwhile to think of this in
terms of absoulte numbers at individual hops since
jitter buffer hueristics along with intra-speech
spurt repositioning of the playback delay can go
a very long way to smoothing a lot of network
kruftiness. (this would be even more true if
you have application layer triggers in your
jitter adjustments on impending handoffs.)

		Mike