Subject: Jitter and delay in Guaranteed Service

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 12 Jan 96 17:08:36 EST

Reference:  Your note of Thu, 11 Jan 1996 12:31:57 -0500

Mark and Fred have brought out some good points about jitter and delay,
and I wanted to add a few minor things to it.

As Mark mentions, for a number of applications that are sensitive to
delay, what you try to do when setting the playback point is to
determine how much you need to buffer before starting to play out data,
so that you can it be read out at a constant rate without having the risk
of running out of data.  Having an upper bound on the delay is clearly
helpful/needed in order to do that.

However, what you really want is to make sure that if you read a packet out,
there is another one in the buffer by the time you need to read the next
one.  In other words, you are interested in the difference in delays that
successive packets experience, aka jitter.  The smaller the bound you can
get on that difference, the less data you need to buffer and probably
more important, the lower your playback latency.  For example, if you knew
that the first packet you got has experienced the max delay Dmax, then you
could start playing it out immediately as you know the next packet has to
arrive in time (can only experience a smaller delay) for you to play it out.
In that particular case, you don't need any playback buffer.  However, in
addition to be an uncommon case, this would also require some form of
timestamps and global clock sync.

In general, you don't have access to this kind of info, so the best you
can do is to make sure you buffer enough data to accommodate the worst
case jitter.  That's the approach Mark describes in his note, but I
wanted to point that you don't need to assume Df (Mark's fixed mean delay)
is equal to 0.  Latency information is available as a general
characterization parameter, and can provide a reasonably accurate estimate
for Df.  At least one that's much better than 0.

Roch

---

From: [email-masked] (Fred Baker)
Date: Fri, 12 Jan 1996 14:48:37 -0800

While I generally agree with your comment, let me observe on this paragraph:

>helpful/needed in order to do that.

Having an upper bound on *jitter* is important (nay, critical) to that - an
upper bound that minimizes playback-point overshoot and loss (alpha) and
minimizes memory cnotraints and general variability (J=Dmax-Df). However,
from your last sentence, it sounds like you think controlling Df is
relevant. Could you detail in what way the value of Df, whether 0 or
several seconds, is relevent to positioning the playback point in the
receiving system?

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

---

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 12 Jan 96 17:53:46 EST

Fred, I'm about to leave to try to make it home despite the icy roads
(don't laugh from sunny CA, otherwise I'll do the same when you get
your next earthquake ;-)

In any case, I do not advocate controlling Df.  That's typically
hard to do in terms of scheduling, and typically imposes an
efficiency cost.   There are ways of doing it, e.g., reshaping
helps in that respect, but all add some complexity.

The only thing I was trying to say is that if you have a better idea
of what Df, i.e., don't need to assume it's 0, then you get a better
bound on the jitter which is the quantity that interests you, and I was
pointing out that the latency (or prop delay) was available as a general
characterization parameter.  Hence, you could/should use that instead
of 0.  Doing better than that is hard as you could get a packet that
zips through the net (no queues anywhere), and the next one sees the
max delay, Dmax, because congestion appeared.  So, doing better than
J = Dmax - latency is hard.

Hope this clarifies what I meant.

Roch

---

From: [email-masked] (Fred Baker)
Date: Fri, 12 Jan 1996 15:32:16 -0800

>(don't laugh from sunny CA, otherwise I'll do the same when you get

I grew up in Ohio, and while living in Minnesota, once changed a tire at
-70F. Does that count? :^)

>J = Dmax - latency is hard.

Agreed. If you want to know what Df is, on RTP traffic you should be able
to compare the NTP timestamps and select the smallest difference. It's not
likely to be zero.

---

From: [email-masked] (Fred Baker)
Date: Fri, 12 Jan 1996 14:48:37 -0800

---

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 12 Jan 96 17:53:46 EST

Roch

---

From: [email-masked] (Fred Baker)
Date: Fri, 12 Jan 1996 15:32:16 -0800

---

From: [email-masked] (Mark W Garrett)
Date: Mon, 15 Jan 1996 09:53:17 -0500

> Roch Guerin:

 > Roch:
 > That's the approach Mark describes in his note, but I
 > for Df.

 > Roch:
 > Doing better than that is hard as you could get a packet that

 > Fred Baker:

Wait a sec.  There's something that either I don't get or you are missing.
Df *is* the latency.  The fixed delay is the propagation delay plus
any processing delays which cannot be avoided.  The only way to improve
Df is through routing.  I don't understand why Roch says reshaping and
scheduling can affect Df.  Also, Df is not a *mean* in *any* sense.
It is a minimum delay.

Given some Dmax, I think that ``doing better than J = Dmax - latency''
is not just hard, but impossible by the definitions of the terms. (No?)

Next, Df is not the difference between timestamps on packets, or do you
mean (Fred) the smallest difference between the timestamp on a packet
and the absolute time at the receiver?

In any case, I wasn't originally proposing that Df was zero, but that
it might be reasonable to *treat* it as negligible to avoid the
complexity of measuring the jitter rather than Dmax.

-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: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Mon, 15 Jan 96 10:42:34 EST

Date: Mon, 15 Jan 96 10:11:59 EST
From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: Jitter and delay in Guaranteed Service

>is not just hard, but impossible by the definitions of the terms. (No?)

Mark,
I was clearly not proposing some mechanisms to improve the
propagation delay, that's sort of hard ;-)

On the other hand, Df is NOT necessarily the latency, but a lower bound
on the delay.  Granted, in general it will be equal to the propagation
delay, but you can do better.  There has been a number of proposals in
the literature on how you can do that.  For example, with a deadline
driven policy where you also include in each packet information stating
how early the transmission of this packet was wrt to its local deadline,
then you can control the minimum delay much better as you can compensate
for a small delay at one one node by making it larger at the following
one. So, you can definitely do better than J = Dmax - latency.
Now, I am not advocating that one defines a service that lets you specify
both Dmax and Dmin as it does complicate the scheduling and costs in
terms of efficiency and overall complexity.

Concerning the benefit of reshaping for jitter control, it's more a soft
benefit than a hard one.
Let me illustrate it with a simple example for a constant rate
connection, i.e., token bucket is only one packet.  In that case, the
reshaper at each node makes sure that the packets sent to the scheduler
are spaced with at least the initial inter-packet gap that corresponds to
the constant rate.  You can still have a *worst case* jitter of
Dmax - latency (first packet sees no delay and next sees Dmax).  However,
the reshaping will tend to regularly decrease the jitter, e.g., as soon
as one packet experiences Dmax, then the jitter after that will at most
be the jitter introduced by the last node on the path.  This is because
the reshaping ensures that the following packets cannot be released too
early.

Hope this clarifies things.

Roch

---

From: [email-masked] (Fred Baker)
Date: Fri, 19 Jan 1996 06:26:51 -0800

>and the absolute time at the receiver?

Yes, delta of received time (in the receiver) and send time (in the packet)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Suppose you were an idiot.  And suppose you were a [politician].
But I repeat myself. -- Mark Twain