Subject: RE: [Diffserv] Yesterday's EF discussion

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

Alessio,

At 02:07 AM 12/16/00 +0000, Casati, Alessio (Alessio) wrote:
>Couple of quick comments.
>
>
> > I wish to add my vote to keeping the 'EF' name for the following
> > reasons:
> >
> > 1. A new name will imply a new PHB, which is contrary to what I
> > thought the recent WG goals were (e.g. fix and not re-create).
> >
>It appears that we do have a new PHB (or a couple
>of them sold in the guise of one). At least this
>is the conclusion the author of the PHB itself
>came to, as faced with the proposal in the
>charny and its "compromise ".

We have argued in SD that the definition we propose describes two different 
*aspects* of the same behavior, rather than two different behaviors. Both 
aspects of the behavior are useful in evaluating the quality of EF 
implementations. In particular if you are interested in knowing just what 
time scale your scheduler is providing the configured rate to the EF 
aggregate (as RFC 2598 implied), E_a is of interest, while if you ask the 
question about the delay of delay-variation bound for a given packet given 
the constraints on the input traffic (as desired in EFRESOLVE), the 
parameter of interest is E_p. These are simply two *measurements* of a 
device, not two different devices. The fact that you may want two 
parameters to describe the same behavior does not mean that you have two 
different behaviors.

> > 2. Since the 'EF' PHB (RFC 2598) was a proposed standard for a length
> > of time, like other vendors, we have already implemented our version
> > of the 'EF' PHB and its corresponding DSCP based on our understanding
> > of the RFC.  This is realized in our current Nokia IPRG products,
> > network management infrastructure, documentation, training classes,
> > etc.
> >
>Implementing the EF DSCP must have been quite a
>deed :). Now, ideally you should comply with what
>PHBs diffserv WG define. If names change
>this should not matter if you comply with the
>definition. The definition has changed. Your
>implementation may or may not comply with it
>(or display or not good values of E_a nd E_p).
>Effectively, you may have designed your box
>without caring about E_a or E_p as currently
>defined. Good luck :).

I must tell you that whether or not one designed the box with E_a and E_p 
in mind, the box, once built, will have
some values of these parameters.  If you want to use this device to build a 
service which is quantifiable in terms of its worst case behavior, (as the 
working group decided it wants the service to be described),  then you'd 
better know how to reason about your device quantitatively. The knowledge 
of the two  parameters E_a and E_p will enable you to do exactly that: 
reason quantitatively about  exactly what service you can actually 
provide.  To the best of my understanding, the parameter S in EFRESOLVE 
definition had a rather similar purpose.

As far as evaluating the values of these parameters for a given device,  we 
have already given a catalogue of schedulers and their E_a terms for a 
large number of commonly used output schedulers in draft-charny. For strict 
FIFO schedulers E_p is strictly equal to E_a and so the compromise 
definition does not add any extra complexity in that case.  We intend to 
provide additional implementation guidance for non-FIFO devices as we write 
the text of the replacement RFC.

> > 3. Changing the name will be the most confusing to the those who are
> > not well versed in the underlying semantics in the first place.
> >
>The relation between the PHB name and its semantics happens to
>be quite vague (what would you guess if somebody teels you
>"assured forwarding"?)
>
> >   In
> > addition, it will cause added overhead to those of us who are involved
> > in explaining and socializing diffserv in our respective corporate
> > environments.
> >
>well, this will really be the challenge that the
>thing from the group of twelve will come with :).
>It will first require putting folks thru some
>discrete math classes. This opens up a whole new market
>on its own :).

I think the difficulty of mathematics involved in our definition does not 
exceed the level of mathematics involved in a leaky bucket policer, or any 
of  the rate-based schedulers which are well understood in the 
industry.  So I truly think you are giving far less credit to the people in 
the WG than they deserve.  On the other hand,  a certain minimal level of 
mathematical precision seems unavoidable if any quantifiable worst case 
guarantees are desired at all - and the working group clearly stated its 
interest in such worst case guarantees. It seems somewhat contradictory to 
me to desire to provide the tremendously tight jitter bound guarantees as 
claimed by the VW draft, and at the same time bemoan the fact that you 
might actually need some math to at least reason whether it is possible.

Best regards,
Anna
>alessio
>
>
>
>
> > Regards,
> >
> > /martha
> >
> > _______________________________________________
> > 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
> >
>
>_______________________________________________
>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:20:51 -0800 (PST)

Anna,
> aspects of the behavior are useful in evaluating the quality of EF 

Two different aspects of the same behavior is not the same behavior. It is
a new bahavior. A = {x,y}, B={x}, C={y} B != A, C != A, A == A. I hope
this helps.

> time scale your scheduler is providing the configured rate to the EF 

And your time-scale is "packet scale", your rate aproach is MAX-MIN. Is
there any other "scales" and rate "approaches"?

> definition had a rather similar purpose.

How I see E_a and E_p is that they are device-dependent. No
problem. You have already evaluated them. Isn't B/R is more important for
"loss rate"?

Alper K. Demir