Subject: RE: [Diffserv] The EF definition

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Jul 2000 12:44:04 -0700

Hi,

>-----Original Message-----
>From: Brijesh Kumar [mailto:[email-masked]]
>Sent: Thursday, July 27, 2000 2:05 PM
>To: 'Diff Serv'
>Subject: [Diffserv] The EF definition
>
>
>
>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.
>

In the last sentense did you mean link rate or configured 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.
>

Fine. Here is a very simple example to reject your definition:

Assume an EF flow consisting of MTU size packets arriving at rate r=C/20, in
which C is the input/output link rate. And that the EF configured rate is
R=C/10. Assume also that T=MTU/C

Assume the EF flow is nicely shaped except for the 2nd packet which has a
jitter of T=MTU/C (which is by the way acceptable by RFC-2598). So the
arrival times are:

Arrival 	0-19T-40T-60T-80T-100T- ...

Assume that all packets arrive and exit the router without delay, except the
second packet that exits with a delay of T=MTU/C in the router (which is
acceptable by RFC-2598).

Arrival 	0-19T-40T-60T-80T-100T- ...
Departure	0-20T-40T-60T-80T-100T-...

The first packet arrives at time t=0 in to the router and departs with zero
delay at time t=0. The second packet arrives at t= 19T (its last bit arrives
at 20T) but this time the router has a very small delay of T=MTU/C and
therefore the packet departs at t= 20T. 

Now lets measure the rate from t=0 to t=20MTU/C. First of all this time is a
multiple of MTU/C (time to send an MTU size packet at link rate), and just
in case you had a typo in your last sentence it is also a multiple of
10MTU/C (the time to send an MTU size packet at configured rate). The number
of bits received by the router during this interval is 2MTU, but the number
of bits transmitted is MTU. 

As you can see your measured output rate is MTU/(20T) which is half of your
measured input rate of 2MTU/(20T) during this interval. Any more arguments?

Regards,
-Shahram
>
>--brijesh
>Ennovate Networks Inc.
>
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

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

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 27 Jul 2000 14:43:40 -0700

> >From: Brijesh Kumar [mailto:[email-masked]]
	[..]
> >measured over any period of duration T provided the rate of arrival is
                                          ^^^^^^^^
> >less than or equal to the configured rate R.
   ^^^^^^^^^^^^^^^^^^^^^

	[..]
> jitter of T=MTU/C	[..]

> measured input rate of 2MTU/(20T) during this interval. Any more arguments?

Seems like Brijesh's first sentence says it only applies during those
periods where the ingress rate is <= R. So the interval you chose
is automatically excluded.  (Note too that the choice of T is
basically a choice of jitter tolerance. Using only a multiple of 2
creates a low jitter tolerance. Higher multiples of MTU/C would
result in correspondingly higher tolerance of jitter when calculating
the running average in/out rates. This is an operator configurable
parameter.)

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley