Subject: Jitter and delay in Guaranteed Service

From: [email-masked] (Mark W Garrett)
Date: Thu, 11 Jan 1996 12:31:57 -0500

> Fred Baker:
 >    Guaranteed service guarantees that packets will arrive within the
 >    guaranteed delivery time and will not be discarded due to queue
 >    overflows, provided the flow traffic stays within its specified
 >    traffic parameters.  This service is intended for applications which
 >    need a firm guarantee that a packet will arrive no later than a
 >    certain time after it was transmitted by its source.  For example,
 >    some audio and video "play-back" applications are intolerant of any
 >    packet arriving after their play-back time.  Applications that have
 >    hard real-time requirements will also require guaranteed service.

 > It occurs to me that the example is a poor one: an application that is
 > seeking to stabilize its playback point is not measuring the end to end
 > delay, the delay since *transmission*. It is measuring the variation
 > between the earliest possible time-to-reciept and the earliest
 > time-to-reciept in which a message has a certain probability of having been
 > delivered. The point is not "within what time after *transmission* may the
 > message be held without giving it to the codec to display?", but "how long
 > after I *receive* a message must I hold it to assure that all other
 > relevant messages have a high probability of being received?". An
 > application seeking to minimize its playback point needs to maximize
 > probability of delivery and minimize variation (stabilize jitter) in delay,
 > but does not need to minimize end to end delay.

Fred,

I think the example is OK, but (the way I read it) it does
have a hidden assumption.  It presumes that the difference
between the jitter and the maximum allowable delay (given by
the playback point) is small enough to neglect for the purpose
of sizing buffers.  If the fixed delay is neglected, then the
max delay and jitter are the same thing.

Also, you're introducing a notion of loss probability, which
the Guaranteed spec has tried to avoid so far.  Here's an
argument which attempts to rationalize this example:

Generalizing the description a bit, let's say there is a fixed
delay, Df and the max allowable delay, Dmax.  The difference
between them is the possible delay variation or jitter, J.

		Dmax = max delay
		Df = fixed (min) delay
		J = jitter = Dmax - Df

There is some probability that packets will be delayed beyond
Dmax and we don't call it a failure.  Call this alpha.  Lost
packets, which never arrive, are included in alpha.  (In
practice it's real hard to tell the difference between a lost
packet and one delayed beyond Dmax.  Some folks in the ATM
Forum last year had some entertaining evenings pretending that
they could make such a meaningful distinction, and tried to
describe the relationship between alpha and the cell loss
rate.)  So the delay distribution has its main body between
Df and Dmax with a small tail beyond Dmax.

	|            .
	|         .    .     |-> tail mass = alpha
	|        .       .
	|       .            ...... 
	.------------------------------------
		Df         Dmax

Now, consider the restricted case where the source sends at
constant rate (meaning that the traffic conforms to leaky
bucket (R, B) with B being a packet or two), and the e.g.
video codec which consumes packets from the receive buffer
works at the same constant rate.  Now we size the receive
buffer (this is kindergarten so far...) at Br = 2 R J and let
it fill half way before turning on the consuming process.  In
the worst case of packet delay combinations (without reordering)
the buffer will not overflow or underflow.

     source           network           receiver     consumer
                                       ---------
	R--->~~~~~~~~~~~~~~~~~~~~~~~~~->| Br | |-------R->
                                       ---------
    fixed Rate    (variable delay)       buffer      fixed rate

So if we neglect the fixed delay, assume it is zero, then
the buffer size becomes Br = 2 R Dmax, and we waste 2 R Df.

Now, (2 R Df) is equal to only 15 KB if we assume Df = 80 ms
(e.g. Frankfurt to Honolulu) and R = 1.5 Mb/s.  For 150 Mb/s
its still only 1.5 MBytes.  Pretty small.  OK, an STS3 over
a satellite gives 9 MB, maybe that's getting big.  And maybe
the packet processing in the fixed delay adds something large.
(Does it?)

So, do we need to expand the text to consider the difference
between jitter and max delay, or should we just identify the
assumption that we consider fixed delays to be insignificant
for this purpose?  Or am I totally out in left field...

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 1A-220B			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 11 Jan 96 14:44:52 -0500

From: [email-masked] (Mark W Garrett)

    So, do we need to expand the text to consider the difference between
    jitter and max delay, or should we just identify the assumption that we
    consider fixed delays to be insignificant for this purpose?

Speaking as a protypical naive reader, I think the document ought to at least
do the latter, since perceptive readers will have the same reaction Fred did
(you really only need to buffer to handle the jitter, not the minimum fixed
delay), and wonder what they are missing...

	Noel

---

From: [email-masked] (Fred Baker)
Date: Thu, 11 Jan 1996 12:31:30 -0800

At 12:31 PM 1/11/96, Mark W Garrett wrote:
>Dmax and we don't call it a failure.  Call this alpha.
>
>
>        |            .
        [snip]
>for this purpose?  Or am I totally out in left field...

I think the best thing to do is to, with respect to fixing the playback
point, correct the assumption - the playback point is somewhere between Df
and Dmax, and the effect of any of the available QoS services (Guaranteed
Delay, Controlled Load, Controlled Delay, or Predictive) is to minimize the
values of J and alpha. If what you're trying to do is find the best
playback point and maximize its usefulness, you have no reason to worry
about the size of the fixed delay. Or perhaps I should say that the only
reason that you have to worry about the size of the fixed delay is because
there is this hidden assumption.

I think that there *are* valid reasons to worry about end to end delay,
however, and that they would not only affect QoS, but would perhaps mandate
the use of TOS routing such as is found in OSPF or IS-IS. If people are
making financial trades based on the reciept of financial information over
the internet, they not only want to minimize alpha and J, they has a
financial interest in minimizing Df; parties who receive the information
later than others are statistically likely to initiate their trades later,
and are therefore at a systemic disadvantage.

So it seems to me that this draft should change in one of two ways. If the
real issue is that we are trying to minimize Dmax-Df and alpha, and in the
contemplated applications minimizing Df is a non-objective, then we should
not pretend we are trying to minimize Df, and we should not have
assumptions about it, hidden or open. If minimizing Df is in fact an
objective, we should use an example that reflects that need.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Some ideas are so crazy that only an intellectual could believe them...
        George Orwell