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

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 13:42:43 -0500

Using EFResolve (or Charny or in fact any other reasonable definition) will 
require network calculus.  Some of that will be in the PDB.  Some will be 
done by the vendor, and some by the customer.
But that does not mean that the EF definition requires network 
calculus.  The EF definition has to be defined in terms of a region of 
applicability, including received burst characteristics.  The user then 
ensures that his usage results in traffic that falls within that 
characteristic.

Yours,
Joel M. Halpern

PS: To defend my reference to the Charny draft having the same requirement, 
note that the E_p definition is only applicable within an operating 
region.  That is the same operating region as for EFResolve.

At 06:51 PM 12/11/00 +0100, ROBERTS James FTRD/DAC/ISS wrote:
> > ROBERTS James FTRD/DAC/ISS wrote:
> > ...
> > > If, to simplify, we assume there is only EF traffic in the
> > network and the
> > > routers provide perfect FIFO output queuing, is it then
> > possible to come up
> > > with the "network calculus" necessary to quantify how
> > burstiness evolves
> > > from node to node and how it impacts the necessary bound S?
> > Current research
> > > (the previously cited paper by Charny and Le Boudec and
> > references therein)
> > > would suggest this is extremely difficult or even impossible.
> >
> > We are not attempting to solve research problems, and we all hopefully
> > agree that this "network calculus" is a research problem. Our job is
> > very limited: specify a well-defined behaviour with some measureable
> > properties. Requiring that we understand all the implications of a
> > non-existent network calculus for compositions of this behaviour
> > is by definition impossible. So we are going to re-specify EF without
> > attempting the impossible. We're engineers.
> >
> >   Brian Carpenter
> >   diffserv co-chair
> >
> >
>
>It seemed to me that EFRESOLVE requires network calculus to specify what is
>meant by tolerable burstiness. For instance, I think it is not sufficient to
>use a token bucket if you can't predict how bucket parameters evolve as EF
>flows progress through the network aggregating and splitting in a fairly
>arbitrary manner. How can you measure this burstiness and if you can't, how
>can the behaviour be well defined?
>
>It seems the modified rate guarantee definition successfully avoids the need
>to specify or measure burstiness. It defines a behaviour which can be
>reasonably interpreted in a literal sense as "expedited forwarding", ie, it
>approximates work conserving FIFO scheduling to within the tolerance defined
>by the E bounds. It looks to me like a reasonable engineering solution.
>
>Jim
>
>_______________________________________________
>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

---

From: demir <[email-masked]>
Date: Mon, 11 Dec 2000 11:25:05 -0800 (PST)

Joel,
> ensures that his usage results in traffic that falls within that 

To me, this is a "trade off" between "engineering" and "science". If it is
okay to feel full by only "drinking water/juice" intead of 'eating a
meal", then there is "no problem". No offence or harm to anyone.

> region.  That is the same operating region as for EFResolve.

It seems this "operating region" has a great impact on "degree" that I
have mentioned in my previous email. However, I don't think that both
Charny draft and EFRESOLVE will have "same degree". 

Alper K. Demir