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

From: Anna Charny <[email-masked]>
Date: Sat, 16 Dec 2000 08:03:42 -0500

Alessio,

Here are some responses.

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

First, there is no limit on the burst or input rate that our definition 
works with - the input rate and the burst is whatever it happens to 
be.  Clearly, for some input patterns there will be some loss, but the 
definition of exactly which packets should or should not be dropped is 
outside the scope of  the definition of EF PHB.

For the lossless case, the behavior is fully defined for all packets for 
arbitrary inputs which cause no loss.
For the case when there is loss, the behavior is fully defined *for all 
those packets that were not dropped* (for the purposes of the conformance 
test, the lost packets are simply  taken out of the input stream, and the 
definition is then applied only to packets that were not lost).

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

Quite true, this was a typo.  It does not really matter though, since as 
long as you know the minimal propagation time through the device (which is 
quite easy to specify), you can immediately compute the delay bound from 
the bound on delay variation.  We feel that knowing the fixed propagation 
time in addition to delay variation is quite useful since otherwise a 
definition based entirely on delay variation bound allows devices with 
infinite internal delay to be conformant.

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

If you know S for a given B and R in EFRESOLVE, this does not tell you the 
relationship between these parameters for some other B and R.  So you would 
either need to give the worst case S for all B and R within the operating 
region, or give different S for different regions.  In the case of our 
definition, once you know a bound on E_p, you can compute the delay bound 
for any B and R you choose, and conversely for a delay bound you can 
explicitly choose B and R that may give you that bound D from D=B/R + E_p.

> > 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 first part is the color-blind definition (the one with E_a). The 
color-blind version of the definition defines the timescale at which the 
aggregate is given its configured rate. The color-aware definition is the 
one that is used to compute the delay (or delay variation) bound.

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

If your service is strict FIFO, then indeed 1a and 1b are 
redundant.  However, in practice there is no such thing as a FIFO device - 
even minimal internal jitter makes a box   non-FIFO.  So in practice 1a and 
1b are always different. You can have very smooth rate service given to an 
aggregate (small E_a), but within the aggregate some packets may be served 
quite a bit later than they would have been in a FIFO server (large 
E_p).  This means that your aggregate service may be very accurate, while 
per-packet delay may still be large.

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

This is entirely true - E_p is not a parameter that can be used to evaluate 
the goodness of the the device.  That is why we actually decided against 
having E_p in our original version of the draft and chose the color-blind 
definition.  E_p has many of the same problems as S in EFRESOLVE and is 
provided in the compromise definition to enable those who want a bound on 
per packet delay (or its deviation) to enable the same functionality as was 
intended by EFRESOLVE within its operating region.  One other benefit of 
having some E_p, even if very large, is to address the concern that a 
scheduler with small E_a may silently hide a very large per-packet delay. 
In the compromise definition such a device  will have a small E_a and large 
E_p, and thus will no longer hide the fact that per-packet delay is large.

Just as is the case with S of EFRESOLVE,  for some schedulers E_p will be 
large, for others it may be small.  In some cases large (or even infinite) 
E_p will mean a good scheduler, and for some schedulers large E_p will mean 
a bad scheduler.    Note that  we do NOT intend to use E_p as a 
figure-of-merit. Evaluating the meaning of the magnitude of E_p will 
require knowledge of the details of a particular scheduler, exactly as in 
the case with S of EFRESOLVE.

In contrast,  we continue using E_a as a figure of merit, since small E_a 
always means that the configured rate is provided to the aggregate at a 
small timescale, and large E_a always means a bursty scheduler.

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

I trust I have answered this question. To reiterate: we believe that  1_a, 
defines the timescale of a rate guarantee, which we believe is quite 
important for quantifying the services built on top of EF, and can also be 
used by those who rely on the rate-based nature of RFC 2598.  In contrast, 
for any device but strict FIFO,  1_b does not necessarily give a good idea 
how well the aggregate is served at its configured rate.  However, 1_b 
provides the means for computing a bound on delay (or delay variation) as a 
function of the input rate and burstiness, which in particular allows to 
satisfy the goal of EFRESOLVE of providing a delay bound within a given 
operating region.

Anna

>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

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126

_______________________________________________
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: demir <[email-masked]>
Date: Sat, 16 Dec 2000 07:49:22 -0800 (PST)

Anna,
> explicitly choose B and R that may give you that bound D from D=B/R + E_p.

100% agreed.

> one that is used to compute the delay (or delay variation) bound.

Depends how "accurate" you are defining "delay variation" meaning what is
"low jitter", "low delay-variation".

> small timescale, and large E_a always means a bursty scheduler.

I would recommend using different name for E_p in the next version of the
draft in order to eliminate "letter-wise" confusion :)

> used by those who rely on the rate-based nature of RFC 2598.  In contrast, 

RFC-2598 doesn't have only "rate-based" nature. It has "small
time-scale" rate based nature. To me, you have "specified" this time
scale at "packet" level using MAX-MIN rate constraint approach. 

> satisfy the goal of EFRESOLVE of providing a delay bound within a given 

The goal of EFRESOLVE is different and fits RFC-2598 (having problem of
S:) What is "low delay-variation"?
	D(i) < a_constant

is also "delay-variation". 

Alper K. Demir