Subject: Concerns about exported numbers 1/22/96 14:04:33

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

Reference:  Your note of Mon, 22 Jan 1996 14:04:33 +0100

Christian,

There are a number of key points in your note that I'd like to expand on
as I think there are are at the core of many of the discussions that
have recently been taking place on the mailing list.  I think you are
proposing one important simplification, namely making the handling of
excess traffic a property of the traffic itself.  However, this alone
does not resolve everything, and there are a number of other aspects
that need to be spelled out.  I'll try to articulate that more
specifically in the rest of this note.

>I believe that all this debate exhibits a major confusion in the conception
>of the "integrated" service.  Specifically, the group has long seemed to
>equate the traffic class - real time or data - and the resource reservation
>requirement.  The group assumption has been that real time is inelastic,
>cannot adapt to network conditions, while data is elastic, can be treated
>best effort.  I believe that we should reconsider this assumption.

Well, I'm not sure I agree with the above statement as, for example, the
controlled delay specs do state that they target adaptive applications,
that can adjust their behavior as a function of the network state.  In
any case, I think the question is not only what the service (RSpec)
provides, but also to which traffic it provides it, i.e., the TSpec.
This is where we get to the crux of the matter as when the network makes
some service guarantees, it needs some level of understanding of what it
is committing to, i.e., the volume of traffic (TSpec) for which the
guarantee needs to be provided.

So, we are faced with two problems.  First, how to specify a *common*
(to the user and the network) understanding of the traffic to which the
service guarantees will apply.  Second, what to do with the traffic that
has been deemed excess traffic.  I think that what you suggest in your
note pertains to the second problem, but it still leaves open how to
deal with the first one.

* The difficulty with the first problem is to come up with something that
is robust and consistent across a range of behaviors for applications and
network elements.  For example, the TSpec provides a simple rule for the
application to check if the traffic it is generating remains within
a pre-specified envelope for which the service guarantees will apply.
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.

The difficulty in coming up with such a rule is due to the fact that you
are trying to link two things, the TSpec and the RSpec, that are
typically not fully coupled at each network element unless you have
completely defined the end-to-end behavior of the service.  For example,
you would need to specify both the rate at which you guarantee to serve
the flow, e.g., a la WFQ, and the buffering that you can set aside for
the flow.  Both are a function of the TSpec and RSpec.  The Guaranteed
Service Specs fully specify this coupling, because it does it on the
basis of deterministic traffic and service parameters.  In the context of
other service models that don't rely on such a deterministic framework,
the problem of linking the TSpec and RSpec is more difficult because
of the greater flexibility in the service specification.  In that case,
you need to come up with *reasonable* rules for deciding on what is
excess traffic at a network element.  Assuming that you can guarantee
a certain *service rate* to the flow, that essentially amounts to
deciding, based on the TSpec, how much you should buffer before
you classify a packet as excess traffic.

* For the second problem of deciding what to do with excess traffic,
which is I think what you focus on, the choices are whether to drop it
or queue it for transmission at a lower priority.  If you decide to
queue it, then the problem is to determine how much this excess traffic
is allowed to impact the other (lower priority) flows.  Wrt this
particular issue, I'm very much in sync with what you outline below.

>There is ample evidence that we can build adaptive real time services.  IVS
>video is one such service, and so is RAT for audio.  The mechanism for
>supporting end to end adaptivity are specified in RTPv2, now a proposed
>standard.  There is also ample evidence of a market demand for granting
>level of services to non real time traffic, e.g. the pipe between two
>locations of a corporation, the file transfer of some large and important
>data, NFS access to a key server.  I propose that we build our model
>accordingly:
>
>* whether "excess" traffic should be dropped or queued should be a property
>of the traffic itself.  There is a well delineated provision for this in
>IPv6, where priority levels 0 to 7 apply to "data," whose excess should be
>queued, and levels 8 to 15 apply to "real time," whose excess should be
>dropped.  The feature could be retrofitted to IPv4 by specifying that
>excess is dropped when the TOS is set to "best delay", queued otherwise.

As I said earlier,
I think you make an important point here, namely that we should have the
ability to let a flow specify how it wants its excess traffic to be
handled.  Specifically, I fully agree that the handling of *excess*
traffic should be a property of the traffic itself.  This does not
resolve the problem of specifying what is excess traffic, but assuming
this has somehow been done, then knowing what is the appropriate handling
of this excess traffic makes for much cleaner/simpler solutions.

>* the amount of "reasonable" traffic should be determined from traffic
>allocation, policies, etc.  Best-effort, here, should not mean queuing but
>rather "fair share", i.e. the amount of service that a particular class
>would get in the absence of reservation.

I agree with the above, but as mentioned earlier, the problem of
determining what is *reasonable* may not be that simple in general.

>This model results in significant simplifications of the scheduling
>machine.  Suppose a model that combines fair queuing (by default) and
>weighted fair queuing (in the presence of reservation).

This is certainly one possible model to limit the impact that excess
traffic from flows with reservation is to have onto flows without
reservation.  Note that this is still dependent on a *reasonable*
specification of what is excess traffic, and also on the ability of
doing a fair queueing scheduling on a per-class basis (excess and best
effort) after you have taken care of the reserved traffic.  The
combination of the two may be a little bit trickier than what you
outline below.  For example, if a flow asks for a service rate (RSpec)
that is larger than the rate in its TSpec in order to ensure that it
sees good delays, then how do you define its fair share and/or what its
excess traffic is?  My take on this is that its fair share of bandwidth
is what is specified in its TSpec not in the RSpec.  However, it should
get access to it, i.e., from a queueing/delay point-of-view, based on
the rate value it specified in its RSpec.  This together with the burst
size it specifies in the TSpec will determine which of its traffic will
be classified as excess.  Assuming that the flow wants its excess
traffic to be queued and not dropped, these packets will then compete
on an equal basis with the best effort traffic and the excess traffic
from other flows for access to the remaining bandwidth.

>The reservation
>would only be understoud as a "guaranteed bottom".  They would only take
>effect if the amount of resource is more than what the class would get
>anyhow, thus eliminating the "denial of service" attack mentioned in the
>message.  The traffic handling would be entirely determined by packet
>itself, thus eliminating the adverse effect on delay jitter noticed by Mark
>Handley when some traffic is passed fast while other traffic is queued.  In
>fact, we would be satisfied with exactly one reservation class, the
>"guaranteed bottom", and with one very generic constraint, that "real time"
>packets should never be kept in long queues, even in the absence of
>reservations.  If an application requires a "hard guarantee", it will
>simply ask for a "high" bottom, and stay within it.

>Am I making it too simple ?

Well, I think that the point of making the handling of excess traffic
a property of the traffic itself is a very valid one, and one that
certainly simplifies things as it we don't need to come up with a
single solution that works for all types of traffic.

On the other hand, I also think that you still need to specify rules to
determine which traffic is going to be classified as excess, and that is
not that simple.  It is a function of the service requirements of the
traffic and the associated coupling it implies between the TSpec and the
RSpec.

However, once you have specified the rule to determine excess traffic,
your suggestion of making it compete on an equal basis with the best
effort traffic is very reasonable.  The scheduling structure may be
a little more complex than what you outline, e.g., may need some
priority structure in addition to WFQ, but it should be feasible from
an implementation point-of-view.

So, bottom line is that:

 - Making the handling of excess traffic a property of the traffic,
 greatly simplifies things.  We should make this feature available.
 - One still needs to specify *reasonable* rules to characterize
 excess traffic at network elements.  The rules will depend on the
 service specification itself.
 - The implementation of a scheduler that satisfies the service
 requirements of flows with reservation and fairly arbitrates access to
 residual bandwidth between excess and best-effort traffic, appears
 feasible although more complex than what you outline (I think).

Roch

---

From: "andrew (a.j.) hollbach" <[email-masked]>
Date: Tue, 23 Jan 1996 17:12:00 -0500

[email-masked] writes:

...

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