Subject: Re: Number of DP bits?

From: [email-masked] (Konstantinos Dovrolis)
Date: Wed, 5 Nov 1997 09:24:29 -0600

>  
> > I think there must be a quantitative component in these delay
> > classes. Given the fact that traffic distributions can not
> > allow us to even estimate the delays I would propose the following:
> > 
> > Class 1: I need a reasonable delay
> > Class 2: My delay must be 0.x2 of delay of class 1
> > Class 3: My delay must be 0.x3 of delay of class 2
> > Class 4: My delay must be 0.x4 of delay of class 3
> > 
> 

Dimitri and Alessio,

This is exactly why I was saying last week that any suggestion for
a new service model has to prove first that is implementable. 
And to show of course how complex this implementation would be and what else
it would require (traffic regulation? signalling protocol? statistical
assurances or hard guarantees?).

Suppose that we go with Dimitri's suggestion. How can a network
element GUARANTEE that the delay of class 3 will be at most 0.3 times
of the delay of class 2? You can provide delay bounds only if you have
bounds on the arriving traffic. In the absence of a protocol such as
RSVP you cannot have such bounds.

I am not saying that it is certainly not possible (especially if
you allow occasional violations of the service model in small time windows). 
Actually I am currently working on a scheduling mechanism that should 
do such kind of things. However, as it is not clear yet how such 
quantitative differentiated services can be provided, I feel that 
it is rather risky (or too early) to suggest them. 

Constantinos

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 05 Nov 1997 11:38:59 -0500

>RSVP you cannot have such bounds.

I would suggest that you cannot guarntee it, so let's just
dispense with it in an implementable differentiated services
framework. If you want delay bounds, use the RSVP guarnteed
service model.

I don't believe anyone ever said that both can't coexist in
the same network.

- paul

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Wed, 5 Nov 1997 12:49:14 -0500 (EST)

Konstantinos,

> assurances or hard guarantees?).

The implementation of the above scheme is simple to trivial.
Note, that there is not requirement that specific class 
gives specific delays. It merely says that the one class
is better than other. It is up to the application to
find the exact class of service that it needs (and the
money that it has to pay) for a given QoS at a given time
in the network.

As for the implementation, any rate-proportional bandwidth
distribution mechanism among the classes (like CBQ) is 
going to provide the appropriate guarantees. It is also
going to assure that if you jump from one class to other
you will see more bandwidth (by x% ) and provided that the
network is correctly engineered and traffic is "profiled"
you will probabilistacally meet the guarantees.

> RSVP you cannot have such bounds.

Again, it is traffic engineering that will allow you to
bound the arriving traffic and meet the guarantees.
(probabilistacally only ... remember it is Differentiated
and not Guaranteed service)

Dimitri

---

From: "Alessio Casati" <[email-masked]>
Date: Thu, 6 Nov 1997 11:13:25 +0100

On  5 Nov 97 at 9:24, Konstantinos Dovrolis wrote:

> of the delay of class 2 [...]

I would provide Statistical assurance, not hard guarantees.
hard guarantees require reservations ans RSVP.

Just have a proper bandwidth assigned to each class

3 classes = 3 queues

just say class 3 will have a guaranteed bandwidth which is always 3 times class 2 guaranteed 
bandwidth.

alessio