Subject: Re: [Diffserv] The EF definition

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Jul 2000 10:28:37 -0700

Hi,

>-----Original Message-----
>From: Brijesh Kumar [mailto:[email-masked]]
>Sent: Friday, July 28, 2000 11:22 AM
>To: 'Grenville Armitage'; 'Shahram Davari'
>Cc: 'Diff Serv'
>Subject: RE: [Diffserv] The EF definition
>
>
>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.

Thanks. I am happy that at least somebody agreed that there is nothing wrong
with the essense of this draft.

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

No it is not compliant. How could you make a VW with this EF?

 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?

I think Van Jacobson won't agree with you. Because he says it is easy to
measure. (see below)

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

I think you are wrong here. I will quote from Van Jacobson:

"you measure the total input & output EF bits vs time while subjecting the
box to a "realistic" traffic mix. The distribution of the difference of
these two measurements is the distribution of the total delay variation
through the box. The difference between the max & min of this distribution
is the EF bound. It's hard to calculate but easy to measure."

In other words, we are defining an upper bound on delay/jitter for a
"realistic" traffic mix. This upper bound is irrelevant of the statistical
variation nature of the flow and is FIXED. In other words no sample (from
the "realistic" flow) should violate this bound, otherwise the box is not EF
compliant.

I think so far the examples that we have given in our draft and on the list
are pretty realistic, and therefore must meet the delay/jitter bound
(although they are only one sample).

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

Before designing any scheduler that could serve EF traffic, one must know
what is expected from that scheduler. I think an accurate definition of the
EF would automatically set the requirements for a compliant scheduler. Now
how a vendor needs to prove to the customers that his scheduler is actually
EF compliant, is up to them (out of the scope of IETF). The customer may be
satisfied with the theoretical upper bounds, or they may be satisfied with
the simulation results, or they may need actual physical data.   

Regards,
-Shahram

>
>--brijesh
>Ennovate Networks Inc.
>
>
>>
>> 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
>>
>> _______________________________________________
>> 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/
>

_______________________________________________
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: Fri, 28 Jul 2000 20:28:13 -0700

Shahram Davari wrote:
	[..]
> with the essense of this draft.

I'm not sure anyone's really attempted to undermine the essence of
draft-charny-....   because that's not the point. I'm sure it is
a wonderfully precise statement of what it is. I think even Kathie
observed that draft-charny-... is probably an accurate representation
of a possible PHB behavior. However, the issue facing the WG isn't
whether another precisely defined PHB can be developed (sure it can).
The issue we as a WG are discussing is what minimal set of text and/or
clarification of assumptions is required to understand Expedited
Forwarding as defined in RFC2598. Some of us still feel that
draft-charny-... makes inappropriate a-priori assumptions about the
role RFC2598 is intended to play in Diffserv. Hence, more thinking
is required....

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

---

From: Martin Westhead <[email-masked]>
Date: Sun, 30 Jul 2000 16:32:22 +0100

I have a question I'd like to put to the authors of
draft-charny-ef-definition:

I'm bothered by your definitions of P_inp(j) and P_out(j). Doesn't the
fact that you don't track a packet through the router open up the
possibility that I could build a router which conformed to your
definition but maliciously held up packets introducing arbitrary amounts
of jitter to a flow. 

You explicitly disallow reordering of packets within a microflow but
supposing I have two flows entering my router A and B then providing I
had B packets to maintain my output rate I could delay an A packet for
as long as I like (so long as I don't reorder the A packets) thus
introducing arbitrary jitter into A?

Martin
-- 
--------|epcc|------------------------------------------------ 
Dr Martin D. Westhead | <[email-masked]> 
                      | http://www.epcc.ed.ac.uk/~martinwe 
Principal Consultant  | phone : +44 (0)131 650 5958       
    Research          | mobile: +44 (0)7050 193530
-------------------------------------------------|epcc|-------

---

From: Anna Charny <[email-masked]>
Date: Sun, 30 Jul 2000 13:59:34 -0400

Martin,

>introducing arbitrary jitter into A?

I would like to point out that  the current EF definition does NOT provide 
any guarantee whatsoever that a
given packet will not be delayed indefinitely.   It looks only at aggregate 
departure rate, being completely
blind to the origin of the packets, or their delay in the 
router.  Therefore, unless you insist on the ideal output-buffered
  model where all EF packets share a FIFO,  the RFC can indefinitely delay 
packets as well
(please let me know if I need to defend this statement by example).  On the 
other hand, if you insist on ideal output buffered
model where all EF packets share a FIFO, our definition will *never* cause 
indefinite delay - all packets will depart in the order of
their arrival.  Hence, our definition simply preserves this property of the 
RFC 2598 - which is what we intended, since our goal was not to change
the RFC but to fix it.

Since we set about clarifying the RFC with the minimal amount of changes, 
we felt we should not change this fundamental property of EF
(aggregate treatment, blindness to packet identity). Our definition 
preserves that spirit by looking at the arrival times and the departure 
times of the
aggregate, being blind to which individual "stream" these packets belong to.

While I personally think that it may be beneficial to change this property 
of EF,  that would clearly be a rather significant change in EF philosophy, 
at least in my opinion.
As a popular argument does, it would be a valid PHB but not EF :-)

Regards,
Anna

>Martin

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126