Subject: RE: [Diffserv] The EF Definition

From: Jon Bennett <[email-masked]>
Date: Thu, 27 Jul 2000 16:02:18 -0400

brijesh,

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

I have not yet seen a simple change that produces a suitable definition, 
yours included.

> The EF traffic  should receive the rate at which it arrived when
> measured over any period of duration 

I'm afraid this statement is so vague as to be close to meaningless.
Among the many problems with it is that it suffers from the 
assumption being made by many people that terms and/or phases 
that might be said to make sense if we were theorists talking about 
fluid models, do not make any sense when we talk about actual 
packet equipment. In the interested of time I will not go into details
unless it becomes necessary, which I don't think it will since the
next portion of the definition is sufficiently non-vague for me to 
show that it fails to be workable.

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

Example 1: At time 0, two MTU sized packets arrive on different links.
At time T=MTU/C, the arrival rate is (2*MTU)/(MTU/C)= 2*C, or twice 
the link rate. This must exceed any possible value of the configured
EF rate and therefore is excluded by your definition.

Did you mean to suggest that the arrival of two packets at the same time
was not acceptable for the EF PHB?

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

 Despite what is in the above paragraph it is not clear 
when you say that the arrival is measured from the first bit of the EF 
aggregate if you mean any first bit, in which case Example 1 applies 
at any point in time. Or if you meant that you measured from the very
first EF packet only. If the later is what you meant then the following 
example applies

Example 2: Assume an EF configured rate of say 1/7, at 00:01 hours 
next Monday one EF packet arrives at the router. There are no more EF
packets until 00:01 hours next Sunday, at which point EF one MTU sized
 EF packet arrives every MTU/C time units until 23:59 Sunday night. 
The EF rate over this measurement period is at all times less than its
configured rate. However your statement of the service requirement so
that the EF traffic is not jittered will require that for a 25 hour period 
the output link transmits only EF packets to the exclusion of all else.

It doesn't matter which interpretation you prefer, this definition fails for
either one.

> I don't think hypothetical nodes that add any arbitrary
> latency, except in theory, are of any use in providing meaningful
> service with EF. 

No, but they are of great utility in determining if the definition of the
service 
can deal with non-zero latency. 

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

I have no problem with the argument that says 

"there are many things that can be solved with equipment which does 
not actually satisfy the EF definition" 

since I believe this to be true. What I have a serious problem with is
arguing 
that because of this it doesn't matter that the definition in RFC 2598 can
not be 
met. 

When you say "it will still work even though it does not meet the EF
definition" 

what you are really saying is 

"for some PHB that is like EF, but is not actually EF, this will work", 

in which case the proper thing to do is go define what that PHB actually is.

rather then to say it doesn't matter that the current definition is broken.

I await the next proposed definition.............

although I would really like to know what is wrong with the one we proposed?

Jon C. R. Bennett
Chief Engineer
RiverDelta Networks 
3 Highwood Drive
Tewksbury, MA  01876
978.858.2300/2361 (direct)
978.858.2399 (Fax)

   -export-a-crypto-system-sig -RSA-3-lines-PERL

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

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

---

From: Jon Bennett <[email-masked]>
Date: Fri, 28 Jul 2000 13:17:31 -0400

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

You have it backwards, what it *means* is, "tell us the properties of 
the scheduler and then this definition will tell you how compliant 
its to the ideal EF behavior".  

> I am still not sure that it really makes compliance testing any
> better. 

It makes performing the tests infinitely easier than if you have an 
English definition, and it make interpreting the results of those tests
easier as well.

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? 

According to RFC 2598 the only possible answer to this is 'NO' (certainly 
if you have asked for an EF PHB that can be used by the VW PDB). Under
our definition you would simply determine what the value of E is such that
the box always achieved the bounds. 

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

If the code that you are writing is VHDL for your ASIC then this is not 
an issue. Put another way, if your box is so sloppy that you can't tell 
exactly when a packet arrived, how will you be able to know when to send 
the packet out?

What your argument amounts to saying is "well I can't implement it 
correctly so it doesn't matter if the definition is unimplementable"

Try going into some other working group and suggesting that "it's ok
if the draft doesn't make sense here... we weren't really going to
implement it like that anyway", because that is what you effectively saying.

> 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 doesn't fit to the equations. 

The definition of the EF PHB is not statistical, it does not speak about 
the behavior of *most* of the packet, it speaks about the behavior of *all* 
of the packets. It also defines the measurement over *any* interval of 
the service time of *one* packet at the configured rate. This is certainly 
true when used for the VW PDB.

Given that all the "special odd cases" that we have been giving use only a 
handful of flows/packets, if the people sourcing those packets do so in
a strictly spaced fashion for example as *required* by the VW PDB, than 
you would not be talking about failure of 1% of the packets, but of 50% 
or even 100% of the packets. 

Does the phrase "denial of service attack" mean anything to you?

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

Given that we can not agree in the slightest as to what the English 
text in RFC 2598 really means, would you claim that at the moment it
it is actually possible to perform a conformance test based on RFC 2598?

In our draft we present a definition which can trivially be used by a 
test tool to determine for what value of 'E' a device complies with 
the EF PHB.

jon