Subject: Re: Delay vs. Jitter + Broken Profiles

From: [email-masked] (Konstantinos Dovrolis)
Date: Fri, 24 Oct 1997 12:21:08 -0500

> 
> I disagree. What they negotiate is the token bucket description of the
> traffic's rate, and (in the guaranteed service) one of the outputs is a set
> of numbers that will permit the receiver to calcuate the worst case end to
> end delay. The Guaranteed Spec talks a lot about end to end delay
> measurements, but does not in fact enable anyone to specify maximum
> acceptable end to end delay or jitter.
> 

I find the above kind of confusing. 

In my understanding there are two types of GS-based applications:
the delay-bounded and the buffer-bounded ones.

Delay-bounded applications
--------------------------
They have an upper bound on the playback delay because they are
interactive (and non-adaptive...). 
In this case the RECEIVER calculates the reserved
rate R based on its playback delay and the token bucket + path
characteristics that it received in the Path message.

Buffer-bounded applications
---------------------------
They don't have a playback delay requirement (since they
are not interactive) but they have a constraint on the playback buffer
(because they deal with a lot of incoming data, say movie-on-demand
type of applications).
This buffer should not overflow/undeflow. In this case it makes
sense for the RECEIVER to map the buffer size B to an e2e delay bound D 
that satisfies this overflow/undeflow condition (there is a way to
do the mapping).

In both cases the receiver determines the delay bound, and the reserved
rate is calculated based on this bound and the Tspec/Adspec parameters.

Of course all these were relevant and interesting before we realize
that we are all crazily in love with differential services... ;-)

Constantinos

---

From: David Black <[email-masked]>
Date: Fri, 24 Oct 1997 19:18:15 -0400

This thread sure has drifted off topic.  The message of mine that Fred Baker
quoted from was a reply to Steve Deering's complaint that the network shouldn't
make promises to applications.  The text that Fred quoted (about negotiation of
end to end properties) was making the point that Integrated Services is
precisely about the network making such promises, and Differentiated Services
need not behave that way (i.e., the promises may not be made to applications or
in such a way that they're visible to applications).  The fact that the end to
end behavior properties can be assembled from node by node components is a
useful feature of IntServ, but doesn't affect Steve's original complaint
-- restated in the terms used here, his complaint is that if the application
can present a token bucket to the network and get back a delay value,
programmers are liable to code things so that if the application presents a
bucket corresponding to the minimum flow considered acceptable (for quality
of result) and gets back a delay value exceeding the maximum believed
reasonable, the application will give up with an annoying error message.  This
is doubly true if the network reduces the token bucket below the minimum
considered acceptable.

Steve believes that providing programmers with this sort of rope (with which to
hang themselves) is a mistake, and my point was that Integrated Services
*always* provides such rope, whereas Differentiated Services need not do so,
depending on where one places responsibility for things like tagging and
profile enforcement.  Hopefully, I haven't mangled Steve's views too badly in
paraphrasing them.

In the hopes of contributing something useful in this message, the point I was
trying to make about delay vs. jitter is that jitter is the more important
service characteristic because both delay-bounded and buffer-bounded
applications will cope with jitter via buffering that turns worst case jitter
into common case delay.  The moment one starts making reasonable fidelity
assumptions (i.e., no glitches in the output media stream), the ability to do
smart things on the end systems is dramatically reduced.  Audio is particularly
unforgiving in this regard (the human ear is very good at detecting glitches
and pitch changes caused by varying the speed at which samples are fed to the D/
A), video somewhat less so (with a little luck, the occasional dropped frame
won't be missed).  The other useful thing about jitter is that it is possible
to engineer network components (e.g., separate high priority queues) so that
jitter for high priority traffic scales in a far more reasonable fashion with
increasing network size than delay (e.g., a low jitter connection to the moon
is within the realm of possibility, whereas the speed of light places
fundamental limits on the delay involved).  All of this was in the context of
trying to understand what the characteristics of a high priority service (i.e.,
separate queues, as proposed in SIMA, and the Clark/Wroclawski scheme) ought to
be in a differentiated service environment.  Planning to run IntServ over the
high priority queues may not be the right answer for the same scalability
reasons that have us discussing differentiated services in the first place.

Apologies to anyone's toes on whom I've stepped in an attempt to restore
the context to this discussion.

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 25 Oct 1997 12:29:12 +0100

>into common case delay

the discussion of differnttiated service is based on experiences with
tools that trade of jitt with delay at recevers - 

while legacy appplications that need extremely low delay _and+ jitter
will need Guaranted Services (at least if you want to ru nthe net at
any apprecialble level of utilisation), it is not obvious that ISP,s or Users
are asking for these (much) - 
mbone applications show that _right now_ you can trade the jitter for
extra e2e delay (ypically twice the delay jitter variance extra delay)
- if you provide a "premium service"" that experiences short and low
variance queuesm this is insignificant in practice compared with
single packet serialization and propogation delays on international
nets (where most interactive IP audio/video is in use)

 >reasons that have us discussing differentiated services in the first place.
 
 a neat thing fo everyone on this list to do would be to TRY The Mbone
applications :-)

cheers

 jon

---

From: Roch Guerin <[email-masked]>
Date: Sat, 25 Oct 1997 15:03:19 -0400

> is doubly true if the network reduces the token bucket below the minimum

David,

This actually gets me a little confused and I actually meant to ask Steve at the
time he posted his note, but never got to it.  Your note reminded me of it, so let
me try to articulate my views of the issues at stake here.

Steve's example as I recall it, mentioned a disaster-like situation where people
where trying to make phone calls and were getting blocked because of the very high
demand.  Rather than a point blank rejection, he was arguing that if the network
would let the calls in and let them *adapt* their traffic to the current load, this
would provide for a more flexible and useful service (sorry if I misinterpreted
something).

The part that confuses me is that there are really two separate issues here.  The
first is whether applications can adapt to different levels of available network
resources, and the second is how do applications become aware of different levels of
available network resources.

In the example of phone calls being blocked after an earthquake, the two are sort of
lumped together.  The application (POTS) is not really capable of adapting and can
only get through if it gets exactly what it requested from the network (64kbps
circuit).  Conversely, the network informs the application explicitly of the
unavailability of the requested resources and in the process denies its request.

As far as Int-Serv is concerned, the model can support adaptive applications, in
that applications can negotiate with the network until they jointly identify the
level of available resources.  If that level is insufficient to ensure adequate
performance to the application, the application still has the choice to take
whatever the network is willing to grant and send the rest of its traffic as
excess.  If the network was conservative in its estimation of available resources,
that traffic will make it through.  Otherwise, the application will only get access
to what's there, and will adapt its traffic to this or if that's not enough, it will
drop out altogether.  The only "rope" this introduces for the application's
developer to hang him/herself is that the network attempts to explicitly tell the
application how much resources are available.  I happen to think this is not a bad
thing as it can prevent the application from sending traffic that has little chance
of making it through, at least not at the desired level of service.  Actually, I
thought Steve shared this view when he objected to the use of a drop precedence bit,
because this would encourage applications to send traffic that would eventually get
dropped.
So overall, I certainly believe that the network should not impose an arbitrary
(coarse) granularity in its allocation of resources (64kbps), so that applications
can use whatever is available and adapt themselves to the prevailing load
conditions.  However, I also believe that there is a benefit in having the network
explicitly notify applications of the resources they can get/reserve, i.e., the
Int-Serv model.  I don't think this precludes adaptation.  Furthermore, in an
environment where people may end-up paying for a service, they'll want to know what
they are getting!
Clearly, the network needs to also support other service models, i.e., services that
do not require negotiations with the network to reserve resources, but I firmly
believe that only supporting such services is not sufficient.

> reasons that have us discussing differentiated services in the first place.

I'm again getting confused here.  Int-Serv, and the Guaranteed Service in
particular, are certainly not attempting to control the part of delay that cannot be
controlled, i.e., latency (although we do have a new, patented scheduling policy
that may do just that...  just kidding ;-).  The only thing the service aims at
controlling is *queueing* delays, whose variations are the sole contributors to
jitter.  If you control the maximum delay, you also control the jitter.  The
engineering solution you mention to control jitter, i.e., high priority queue, is
actually one that would also control (queueing) delay.
I think that the point you want to make is that controlling the maximum (queueing)
delay may not be the most efficient way of controlling jitter.  The maximum delay
may only be experienced rarely, and the variations in delay experienced by
consecutive packets may also be relatively slow so that adaptive applications could
react to this, e.g., by adjusting their playback buffer.  This is certainly true,
but on the other hand there are also very effective ways to control jitter when you
know that the network provides an upper bound on the delay.  Furthermore, depending
on the kind of services networks end-up being able to provide and the requirements
of applications, adaptation may not always be the right answer.

Again, I think that there are instances where you'll need the kind of capabilities
that the Int-Serv model provides.  This is not to say it represents the right answer
in all cases, but conversely saying that it never is and that we only an implicit
service differentiation model does not seem very convincing to me either.

Roch

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 25 Oct 1997 21:50:20 -0400

There are several differences between IntServ adaptation and
"Mbone-style" adapation:
(1) Even if you negotiate a reservation level, you can hold onto that
reservation until the end of the "connection". This is both good and
bad: it forces the network to make commitments that it might "regret" as
the load increases, but it avoids the annoying case that a phone call
that gets started deteriorates in quality during the conversation. For
all but the "I survived the earthquake" style conversations, most would
probably prefer to wait a few minutes to make an uninterrupted phone
call rather than running the risk of being cut off in mid-conversation.

(2) Reservation is explicit, measurement-based adaptation tries to
discover network load by looking at packet losses. It is hard to get
loss-based mechanisms to be fair, it seems (the saw-tooth rate behavior
of TCP is usually not appropriate for continuous-media).

One could well imagine various hybrid forms, with time-limited
reservations, preemption or reduction of existing commitments being some
of them and measurement-based admission control another.

Henning

---

From: Shivkumar Kalyanaraman <[email-masked]>
Date: Sun, 26 Oct 1997 07:48:38 -0500 (EST)

> of TCP is usually not appropriate for continuous-media).

Could the router avoid saw-tooth behavior by reducing the
TCP receiver window field in acks ? We are currently
working on an adaptation of an ATM ABR (oops)
rate-based scheme to do this.

> Henning

-Shiv
===
Shivkumar Kalyanaraman   
Assistant Professor, Dept of Electrical, Computer and Systems Engg,
Rensselaer Polytechnic Institute
110, 8th Street, Rm JEC 6042, Troy NY 12180-3590
Ph: 518 276 8979  Secy (6313)	 Fax: 518 276 2433
Email: [email-masked]

---

From: Roch Guerin <[email-masked]>
Date: Sun, 26 Oct 1997 16:09:17 -0500

>There are several differences between IntServ adaptation and

Absolutely.  Did not mean to imply there were not, and I agree that
there are pros and cons with each, so that one probably wants both.

>call rather than running the risk of being cut off in mid-conversation.

The network always has the ability to kick you out, i.e., send a
RESV_ERR at any time.  This will happen in failure scenarios but need
not be restricted to that.  Once policy support is available, it may
then be possible to provide a more "orderly" degradation.

Roch

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 28 Oct 97 15:59:46 JST

David;

> smart things on the end systems is dramatically reduced.

Routing in the Internet is dynamic.

So, don't you think long-term delay variation caused by route changes,
which can be as large as delay (minus light speed delay), jitter?

						Masataka Ohta