Subject: [Diffserv] The compromise is actually 2 PHBs as per Anna 's message.

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Sat, 16 Dec 2000 18:42:20 -0000

Anna,

> 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.
> 
this exactly is a statement confirming you don't specify
the behaviour outside an operating region, which proves
Bruce's claim FALSE.

> 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).
> 
OK, but your statement equals to saying that
if a packet is not dropped it gets delivered.
We are interested in the behaviour within the operating region,
outside of it is not EF, and you don't provide
any better clue than we do.
Let's face it, your position is a bit
stretched...

> > >  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. 
> 
I would say a mistake.

>  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.
> 
this is unrelated to bruce's statement. And the fixed delay
bound is service and operator choice. 
You cannot specify it (and in fact you don't in
the draft). Again A WRONG STATEMENT HAS BEEN SUPPORTED
BY A FALSE STATEMENT (the E_* terms allow for unspecified
fixed delay)

> > > 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.
> 
WRONG STATEMENT.
You would use another S. Note that your E_a nad E_p could change
too:). 

>   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.  
> 
Why do you use a OR?  We do both, in fact.
We do an AND :). 

> 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.
> 
We state that S*MTU/R  is a delay variation bound associated to a router
config and burstiness. So we are doing pretty much the same ;).

> > > 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.
> 
Well, this then makes really clear that you actually have two PHBs,
since you are stating that the color blind definition
allows compliance of existing implementations, so an acceptable PHB
would comply with the first part, and the other would be irrelevant.
THIS PROVES YOU HAVE DEFINED 2 PHBs and SOLD THEM AS ONE.

> > > 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. 
> 
1-a nad 1-b are always different independent of the minimal internal jitter
in a router :). SO, let's move on...

> 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.
> 
Exactly. So, for EF purposes we care only about 1_b.
I WOULD SUPPORT 1-a is UNNECESSARY FOR EF DEFINITION.

To me 1-a is there just to justify your draft as COMPROMISE:).

> >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.
> 
So, THIS STATES: "EFRESOLVE IS JUST FINE: WE ADDED THIS
TO FIX OUR (BUGGY) DEFINITION, WHICH WAS NOT REALLY EF".
SO, decency would call for the group of twelve to concede,
at this point in time that the only meaningful part for EF
is what has been added in the compromise (1-b) and I trust you to 
verify that using EFRESOLVE would have not been any worse.

> 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.    
> 
There is no relationship between S and E_p.

FALSE STATEMENT.

> 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.
> 
With the difference EFRESOLVE does this with less
ROCKET SCIENCE haze around it.

> 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.
> 
But, this is part of a benchmarking exercise outside
the SCOPE OF EF.  An informational RFC would be
more appropriate for this.

> >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. 
> 
I'm satisfied with your answers, that confirm
my fears.

> 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. 
> 
The benchmarking aspect should be part of an info RFC,
the rate based only compliance is unacceptable, and
should be rejected by the WG, I hope.

>  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.  
> 
But this is of no interest for EF. EF cares of
per packet delay variation, not aggregate service
rate per se.

> 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.
> 
So, the useful part of the compromise matches EFRESOLVE.

THE WG NOW HAS A CLEAR PICTURE.

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: demir <[email-masked]>
Date: Sat, 16 Dec 2000 13:27:24 -0800 (PST)

Alessio,

> Let's face it, your position is a bit

Exactly. I agree with you 100%. I have made above point along time ago. I
told RFC-2598 is fine. Kathleen told me that it is required  to
"RESOLVE" it. I don't have any problem with accepting this. Let's
"evaluate" the situation. Two solutions has been proposed. As you are
stating above they have "clue" problem. I agree. I have said this before
and saying this again: What two solution is trying to do is that trying to
"embed" specific "algorithms" into the EF. The problem is:	
D(i) < delay_bound_function(input_parameters) (low delay)
D(i) - E(i) < delay_variance_function(input_parameters)	(low-jitter)

"low delay" and "low jitter" statements are already in the RFC-2598. The
problem is that is it ever "possible" to "embed" a specific
"algorithm" into EF (I mentioned that AF is not doing this. I agree
they are intended for different puposes). I got the respose that it is
"okay". No problem. So what is the way to achieve this? i) "Embed
something" "immature" into the EF? ii) Express this in words? iii) Leave
it to a PDB/and/or an EF "implementation"? 

RFC-2598 doesn't specify any specific "algorithm" regarding to "input 
output rate v.s. small time-scale". Charny draft has solved this with
"packet level MAX-MIN" approach. I give alot of credit for that. However,
this is "only" a "specific" algorithm. If you are familiar with "fair
queuing", similar approaches are valid for FQ, too. These are  
"implementation" issues as if in the case of "low-delay", "low-jitter". It
would be nice to clarify them in RFC-2598. However, the way of
clarification is "important".

Alper K. Demir

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 17 Dec 2000 16:17:55 +0000

whatever van wanted, whatever we thugh the RFC said
whatever the history, i accept that 
we now have a useful PHB specification -
whatever its name and i guess people are mostly going to be on the
same side on the list as were in the face2face meeting

however, it has two modes of application - color aware and color
blind 
-  so we could have 1 PHB but with 2 different services - i..e the
debate should move on (soon) to what we really want out of VW...
and whether there could be two  PDBs made from one PHB - it seems to
me that one useful PDB is certainly the one documented and on hold and
intended to be supported in a parsimoniuous way by the old PHB - this
can stil be suported by the new PHB in color aware mode....there's
also a service (oops, sory PDB) that seems to be wanted which has more
parameters - (will be visible in the SLA) which is a rate with optinal
delay distribution or bound....this is also a candidate for a "wet
wire"....

next...
 cheers

   jon

---

From: "Bill Courtney" <[email-masked]>
Date: Sun, 17 Dec 2000 10:28:00 -0800

Hi Jon,

What is a "wet wire?"

Cheers,
Bill