Subject: [Diffserv] Fwd: response to comments on draft-charny-ef-definition-00

From: [email-masked]
Date: Wed, 26 Jul 2000 14:47:40 +0200

>below  appear to explain how this first sentence actually affects anything 
>we said in the draft.
> >We assumed this definition would be interpreted in the context of the
> >RFC's preceding section which has a lengthy discussion of how jitter and 
> loss
> >come from queues and queues come from input/output rate imbalance. The
> >variety of interesting interpretations of this definition given on the
> >diffserv mailing list, culminating in draft-charny, suggests this
> >assumption was flawed. At the risk of obscuring a simple idea with
> >opaque mathematics, here is a more formal description:
>
> >A router is a device for moving bits from input wires to output wires.
> >Routers tend to be most useful when all the bits that go in eventually
> >come out. This state is called "flow balance" and it has a formal
> >definition. If you measure at any particular time, some bits are
> >arriving at the router, some are propagating through it and some are
> >leaving. Say i(t) is the total number of EF marked bits destined for a
> >particular output interface that arrive between t and t+dt, r(t) is the
> >number in the router (including those that the router drops) and o(t) is
> >the number departing on that interface. Define:
>
> >  I(T) = \int_0^T i(t)dt
>
> >(the \int_0^T is TeX notation for "definite integral from 0 to T" so
> >this is the total number of bits that go in measured from time 0 to time
> >T) and R(T) and O(T) similarly. Then it's always true that:
>
> >  O(T) = I(T) + R(T)    [eq.1]
>
> >which is to say that the total amount that comes out over time interval
> >T is the amount that went in minus what's still in the router. The EF
> >traffic is in flow balance if R(t) is bounded, i.e., if there exists
> >some constant C such that R(t)<=C for all t (since R includes drops,
> >this is just a complicated way of saying that everything that goes in
> >comes out since otherwise R would increase over time).
>Actually, just as a point of clarification, the fact that R(t) is bounded 
>does not at all in general
>mean that everything that went in went out.  It would indeed be true for a 
>FIFO service, but
>if you allow non-fifo service, you can envision a silly scheduler that 
>puts a packet in some queue
>and then just forgets to send it forever, while forwarding every other 
>packet at input rate or faster.
>In this case R remains bounded, but the forgotten packet never leave the 
>router.
> >If you divide
> >both side of eq.1 by T, the integration interval, you get the average
> >output & input rates over interval T and you see that those rates must
> >be equal over long times since R(T)/T <= C/T and the right hand side
> >goes to 0 as T goes to infinity.
>
> >Since the above only says that R() has to be bounded, you can make a low
> >loss behavior by policing the average input rate to something less than
> >the achievable output rate then sticking enough buffer in the router to
> >handle the worst case (measured) transit time. While this is a well
> >defined behavior, it is *not* the EF behavior since it provides no
> >contraint on jitter.
>To put all of the above into the context of our draft, what you describe 
>above is an informal description of   a weaker version of the definition 
>in draft-charny....
>This weaker version is the well known rate-latency curve, and is discussed 
>in the draft.  The actual definition we offer is stronger that that.  The 
>definition we propose, informally, has the following property (for the 
>case when all EF traffic shares a single queue):  if a EF packet comes to 
>an empty queue, it will leave no later than
>by the latency bound E (for PQ E = MTU/C).  If  an EF packet comes to a 
>queue of Q bits of other EF packets in front of it, it will leave no later 
>than by time Q/R_conf +E.
>That means, informally, that any backlogged queue is given its configured 
>rate or more (within a given strictly specified error)  over any interval 
>in which the EF traffic is backlogged.
>
>In fact,  our definition DOES allow to bound jitter - the bound on jitter 
>depends explicitly on the latency term E.   For small E (such as that of 
>"EF priority queuing model" ) this bound is the smallest.  I would like to 
>point out that RFC 2598  does NOT actually demonstrate any jitter bound 
>(although it alludes that such bound exists and must be 
>small).   However,  we intentionally did not put any discussion on jitter 
>bounds in the draft, since we felt that the scope of our draft should 
>correspond that of RFC 2598. Jitter bounds are discussed in draft-...vw, 
>and I suggest that we discuss them separately.   In fact, I will shortly 
>forward some comments on the draft to the list.
>
>However, without getting into detail, let me try a quick argument 
>here.  VW draft gives an argument that a particular jitter bound  holds 
>for the PQ, which is referred in the VW draft as "EF priority queuing 
>model". Whatever that  bound might be, given that our modified definition 
>IS strictly implementable with PQ (BTW  unlike the definition of RFC 2598, 
>which as we show in the draft is not strictly speaking implementable by 
>PQ), wouldn't you agree that the jitter bound for the priority queuing 
>model does not depend on whether you call it EF or something else?
>
In Principle I agree with the statement of Kathleen Nichols

"It is certainly reasonable for the 
document's co-authors to define a different PHB and  the PDB(s) i
n which they believe it will be useful, .."

As I understand, draft-charny-ef-definition-00 states that there is
no WORK-Conserving Scheduler which is compliant to RFC 2598. But it is not
saying that there is NO NON-Work-Conserving Scheduler satisfying RFC 2598.

I see another cause for the discussion is the statement about the time of measurement
in RFC 2598 "it SHOULD average at least the configured rate when measured over any
time interval equal to or longer than ..." where especially "over any time interval"
is problematic in my view. It would be no problem if it is mentioned that "there is
at least one start time in every MTU interval" which gives the required average rate.  

Xiaoning Nie

Infineon Technolgies
Advanced Algorithms
Balanstr. 55
81541 Munich, Germany

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