Subject: RE: [Diffserv] Possible compromise between EFRESOLVE and draft-ch arny

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 16 Dec 2000 05:39:47 -0000

Bruce, 

I would like to discuss the merits of your proposal ("compromise"),
to form the WG consensus on the list: in fact we may have not
completely understood the proposal so far, due to tight schedule
and the little time given to the group to think and discuss about it.
In all fairness, this proposal should have been submitted around the
draft_00 deadline :).

> under our "color-aware" definition when the offered
> load to an output is bounded by rate R and burst  size B, the maximum
> per-packet delay is B/R + E_p. Clearly both definitions provide bounded
> delay under well-defined operating conditions. The second part of our
> definition addresses the intent of EFRESOLVE, but differs from EFRESOLVE
> in
> that it provides well-defined behavior for arbitrary inputs.
> 
How? could you elaborate on this? What is the intended behaviour when the
burst is exceeded? and what is the behaviour when the input rate is
exceeded?

>  In addition
> while EFRESOLVE gives a fixed delay within a specified operating region,
> 
I thought we were giving a bound on the delay variation, not a fixed
delay...
clarification from you is expected.

> our new definition allows an operator to achieve different performance
> goals
> by specifying different ranges of B and R that achieve the desired delay
> bounds.
> 
I thought that we where not preventing an operator from doing so. Where in
the
definition you detect this? 

> The first part of the definition allows existing and operational
> rate-based
> implementations and deployments of the EF PHB to continue to be deployed
> and operated (e.g EF implementation in Internet 2 managed by Bandwidth
> Brokers).  
> 
do you mean that delay variation is not a goal that the
first part of your definition is aiming at? 
what are the equations you associate to the first part?

> The second part of the definition provides the machinery for
> computing the delay bound as a function of the operating conditions.
> 
> 
> ----------
> Equations for those who care:
> 
I care:  

> The original colorblind equations from draft-charny-...-01 are eq_1a and
> eq_2a. The new ones that achieve the compromise are eq_1b and eq_2b.
> Although the latter equations are not in draft-charny...01, the intuitive
> description of the equations in that draft may still be helpful in
> understanding the equations.
> 
>     D(j) <= F(j) + E_a                                           (eq_1a)
> 
> 
the need to keep this equation (eq_1a) is unclear to me.
1b should suffice, isn't it? what makes 1a compelling in the definition?

Let's now consider

>     d(j) <= f(j) + E_p                                           (eq_1b)
> 
and

> under our "color-aware" definition when the offered
> load to an output is bounded by rate R and burst  size B, the maximum
   per-packet delay is B/R + E_p

It occurs to me that Ep is dependent on the relative distribution
over the input interfaces of the input rate (which you correctly state is
assumed to be up to
R) and the scheduler weight settings / router config. So, E_p is not a
parameter
that can be used to evaluate the goodness of a scheduler or router since it
depends on
the configuration of the scheduler and the router, and also from network
dependent aspects (the distribution of the input rate, which in turn
influences
or may influence the router configuration). 

As such what is the usefulness of this equation (1_b), and what makes this
more appropriate than saying that the delay variation must be bounded, as 
per EFRESOLVE? 

kind regards

alessio

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Dec 2000 13:44:41 -0600

Alessio,

> completely understood the proposal so far, due to tight schedule

Naturally, when the proposal has been written up in the form of a PHB
definition, we will be doing just that; that is how we reach WG
consensus.

   Brian