Subject: RE: [Diffserv] The EF definition

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Jul 2000 14:54:24 -0700

Hi,

(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.)
>

Again for the record I chose my measure period =20MTU/C which should give
you more jitter tolerance, but in fact Brejish's definition does not hold
even for the smallest possible jitter of MTU/C.

-Shahram

>cheers,
>gja
>_______________________________________________________________
>_________
>Grenville Armitage                    
>http://members.home.net/garmitage/
>Bell Labs Research Silicon 
>Valley
>
>_______________________________________________
>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 15:41:13 -0700

Shahram Davari wrote:
	[..]
> even for the smallest possible jitter of MTU/C.

I wrote what I didn't mean, and meant something I didn't write.
Sounds familiar.

Brijesh's formulation probably needs revision. Sampling
theory suggests you need sufficient samples (and a
sampling event is observing and counting an EF packet
in this case) before a running average becomes meaningful.

The case you postulated clearly would fail because the sampling
interval (20T) covers only-one-but-almost-two packets under
nominal conditions, thus making it vulnerable to even the
slightest ingress jitter. I was trying to articulate that the
sampling needed to cover more packets, and my articulation failed :)

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

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 28 Jul 2000 11:22:23 -0400

Hi,

The essence of new EF definition by Charny et el. is in these lines
(rest are all details)-

"If an EF packet arrives to the device at time t and finds Q EF bits
in the device (including the arrived packet itself), it must depart
from this device no later than at time t+Q/R +E, where R is the
configured rate, and E is the latency/ error term.  So the configured
rate is achieved when there is something to send. However, for a
non-preemptive scheduler one cannot take E smaller than  MTU/C. We do
not know any scheduler other than PQ that can in principle achieve
E=MTU/C. So the choice of E determines the set of possible scheduling
implementations and router architectures that are
capable of delivering it. "

The above text defines the required property of an EF compliant
scheduler according to the new draft. I don't think any one has a
complain about its mathematical accuracy.

I am still not sure that it really makes compliance testing any
better. Let us say that some box achieves above bounds for 99% of EF
packets, but fails to achieve this for 1% of the packet (for whatever
reasons). Is it an EF compliant node or not? There has be some
statistical variations in packet processing in practice. And what
accuracy of time stamping we are talking about. Try writing code to
time stamp packets on a 2 gigabits per second link - depending upon
your precision of your time source, you will see many packets will be
deemed to have come at the same time on the link even though they
didn't? Or did they?

The point I was trying to make is that the statistical observations to
be valid - there have to be sufficient samples, you can't take a
special odd case, and say that it does n't fit to the equations. In
this way, you can't smooth a curve, nor you can fit data to any curve
as there will always be some samples that will defy the equation. Real
applications are based on statistical behavior of a traffic stream,
not on the behavior of a single packet that missed the latency
deadline, or jitter requirements.

BTW, I am not saying that you shouldn't have accurate definitions to
begin with. But the claim that it will lead to better compliance
testing, I think, needs further examination/ explanation.

--brijesh
Ennovate Networks Inc.