Subject: Concerns a...

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Tue, 23 Jan 96 18:01:59 EST

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.
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.

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.  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.

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

Roch