Subject: Fuzzy Service (was Concerns a...)

From: "andrew (a.j.) hollbach" <[email-masked]>
Date: Thu, 25 Jan 1996 16:46:00 -0500

This is a retransmission, since i never got a copy back fromthe intserv 
email exploder. Apologies if you receive both the original and this,
somewhat revised, version...

In message "Concerns a...", [email-masked] writes:

> Reference:  Your note of Tue, 23 Jan 1996 17:12:00 -0500
> 
> >> However, if you strictly use the same TSpec at a network element to
> >> decide what to do with a given packet, then you may end-up making a
> >> decision that is not consistent with the service guarantee.  This is
> >> because no matter what scheduling is used in the network elements, it
> >> will *perturb* the original packet stream so that it can violate the
> >> original TSpec.  Hence, you need some *rule/guideline* to transform the
> >> user TSpec onto something that the network element can use to make a
> >> decision on when to provide the service guarantee it agreed to.
> >>
> >
> >An alternative might be to redefine the TSpec to be the policing
> >function to be executed at each network element, for those services
> >using traffic enforcement. It would be left up to each end application
> >to decide on a TSpec-local to use for shaping transmission.
> >
> >TSpec-local would presumably be less than or equal to TSpec, based on
> >the ordering rules. The application would then be left to figure out
> >how far to "push it".
> >
> >May help to keep the network simple (a good thing :-)
> >
> >Make any sense?
> 
> Absolutely, this is certainly one alternative.  I would still want to
> see *guidelines* spelled out so that an application has some idea of
> how *onservative* it has to be in order to get the service it wants to
> get.  You may still need to provide different guidelines for different
> services, but the main drawback is that it makes for less transparent
> upgrades as network elements get better/more efficient.

Well, the application could make it's own assessment of delivered
service and adjust it's behaviour accordingly, as in RTP. Many (most?)
apps should be able to do this. Those apps that cannot include those
labeled "real-time intolerant" ; if these apps use IP at all (i'm
sceptical) they should use guaranteed service 

> I'd rather have something where the application does not have to worry
> about how a network element it is dealing with, when picking a TSpec.
> Instead, the network element will be responsible for setting aside the
> *right* amount of resources given its capabilities.

The application should only be worrying about the end-end service it receives

> So, while this is clearly an alternative, the cost it to pass some of the
> complexity onto the applications, and to some extend make for less
> transparent upgrades as network elements get better. 

Definitely moves complexity onto the applications. I'm unconvinced on the
other point.

> In essence, this
> says that we keep the service specification fuzzy and the behavior rules
> at service elements simple, but ask the applications to account for
> potential deviations.

exactly

> My own preference is to try to get that handled in the service elements.

It's worth a try, but..

The service "guarantees" are fuzzy anyway, for all except the guaranteed 
service (and even that one has a disclaimer regarding routing changes or 
equipment failure). Controlled Delay, Predictive and Controlled Load are 
all really only providing fuzzy service anyway; they offer no hard
quantitative end-end guarantees about delay, loss (or much else)

As an aside, i was looking for a summary of the overall philosophy and
rationale behind the current intserv drafts. Among other papers, i've
found  "draft-shenker-realtime-model-00.txt" dated October '93 by
Shenker, Clark and Zhang. This is very helpful in establishing context. 
This draft has expired; is anyone planning to revise and reissue this or a
similar overview draft?

.. Andy