Subject: [Diffserv] The EF issue

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2000 10:56:43 -0500

Diffservers,

I've just made a resolution that as the differv co-chair who is
not a principal in the EF debate, I will refrain from further
comments of substance on the various threads for the moment,
while we try to resolve the situation. There will be some
agenda time for this in Pittsburgh, but probably not enough
to reach a consensus. At the end of the discussion next week
I hope to come up with a firm plan for reaching a consensus
on a reasonable timescale.

I'd also like to suggest a rule-of-the-game for the discussion
of the VW PDB drafts: please avoid drifting off into discussion
of the basic EF issue; assume for the purpose of the VW debate
that the EF issue has been resolved.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Internet Society: http://www.isoc.org
Non-IBM email: [email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 27 Jul 2000 14:04:59 -0400

I have been trying to argue that even if the definition in RFC 2498 is
not perfect the change required in the definition (if any) is minimal.
OK, here is the revised definition to begin with:

The EF traffic  should receive the rate at which it arrived when
measured over any period of duration T provided the rate of arrival is
less than or equal to the configured rate R. The arrival rate is
measured starting at the epoch when the first bit of an EF aggregate
enters the router, and the departure rate is measured from the time
the first bit of the EF aggregate leaves the router. The duration T is
a multiple of the time it takes to send  at least one MTU size packets
at the link rate.

Note that with this definition, if you reset the input clock, you have
to reset the output clock too. Take any period as long as the input
packets get the rate within the configured bounds - there is minimal
jitter (except the node processing delay).

The primary use of EF is to transport delay, jitter sensitive
applications.  G.729 coded voice has been cited as an example in some
quarters. ITU-T G.114 specifies 150msec as one way latency to achieve
high quality voice. Therefore, as long as the latency buffer of the
total path is less than this, the application requirement for critical
application such as voice over IP are likely to be met (on aggregate
basis). I don't think hypothetical nodes that add any arbitrary
latency, except in theory, are of any use in providing meaningful
service with EF. The same is true for providing appropriate jitter
buffer along the route. As long as jitter buffer on each node is
within the required bounds, and the path latency meets the
requirement, I cannot figure out any problem in fulfilling the need of
applications for which the EF PHB is devised whether it satisfies a
particular theoretical definition or not. Like to know what are the
problems with these arguments.

--brijesh
Ennovate Networks Inc.

---

From: Siamack Ayandeh <[email-masked]>
Date: Thu, 27 Jul 2000 15:25:23 -0400

Brian E Carpenter wrote:

> Diffservers,
>
>  There will be some agenda time for this in Pittsburgh, but probably
> not enough
> to reach a consensus.

Draft_charny-ef  is an attempt to clarify RFC 2598.  Amongst
all the valuable contributions that it makes it introduces two things:

1. An equation, i.e. eq-2, that helps with conformance testing. The
mailing
list already has textual descriptions of the same equation that seem to
be adequate.  By now we should all know how to do conformance for
EF PHB whether we use the equation or the suggested text.

2. The delay term, E, that accounts for router and scheduler latency:
    Router latency is a parameter of per domain behavior (PDB).  Any PDB

    using EF should specify this parameter.

    Scheduler latency is treated vaguely in RFC 2598, perhaps with the
intent
    to clamp it down in the PDB, as is done in the VW PDB, that is
limited
    to priority schedulers.

So it seems to me that draft-charney has already reached its objective
of
clarifying the RFC and allowing for a more rigorous discussion. Perhaps
it would help to have it as an appendix to the RFC.

Regards, Siamack

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2000 17:00:42 -0500

Siamack,

Two observations.

1. We manifestly do not have a consensus in the WG that draft-charny-...
is the appropriate clarification.

2. We manifestly do not have consensus that the ability to rigorously 
test "conformance" in the sense you use it is a required property 
of this (or any) PHB definition.

This is why we need to discuss a little more in Pittsburgh and then
put in place a way to resolve the discussion.

   Brian