Subject: Re: [Diffserv] problem with " Simpler EF redefinition" in draft salsano-simpl

From: Bill Courtney <[email-masked]>
Date: Thu, 3 Aug 2000 13:55:53 -0400 (EDT)

John,

You wrote

> What appears to be missing here is that the R term in the 
> min statement needs to include an offered load value. R 
> has no meaning if there is nothing to send. By 
> including such a term, the min statement > would result 
> in R * (t2 - (t2-E-epsilon)) and thereby hold for the 
> example given above. 
> 
> The general term could perhaps be written: 
> 
> O (t1, t2) >= min (R*(t2-t1-E)*L, I(t1,t2-E)) 
 
> where L is the percentage of the interval during which 
> there is something to send. 

I was going write earlier, but held back after Anna commented on
Stefano's message. The discussion on Stefano's suggestion is 
rapidly evolving toward something like the rate-latency 
service curve discussed in draft-Charny as definition 2 on 
pages 10-11. I'm not saying that we've arrived at that 
service discipline, but we're headed there, I think.

In "Latency-Rate Servers: A General Model for Analysis of 
Traffic Scheduling Algorithms," (available for downloading 
from the page 
www.cse.ucsc.edu/research/hsnlab/projects/scheduling.html), 
Stiliadis and Varma give a well-formulated 
definition of L-R servers that can be seen as the logical 
outcome of the current direction of thought, I think.

Even if I'm wrong in predicting the direction that the 
thread is going, Stefano's original definition and John's 
revision share a common difficulty with the L-R server in 
providing an EF-like PHB. Incidentally, this difficulty was 
discussed in the original thread on EF Defintion problems 
back in April/May of this year.

A difficulty with the described behavior is that it can 
provide service at a much higher than configured rate and 
follow that with service much slower than the configured 
rate (including no service at all for a time). In other 
words, the behavior can burst out a long sequence of 
packets back-to-back, and then not provide any service for 
a while (living off the credit accumulated during the 
burst, so to speak). Call such a non-service interval a 
drought.

Such a secenario is not terribly far-fetched. If small 
bursts all destined for the same output port arrive nearly 
simultaneously on several input ports, then a sizeable 
short-term backlog of packets can be in the router. In the 
absence of competing traffic, the router can serve all but 
one of those backlogged packets. Then, because competing 
traffic has arrived, the scheduler can neglect the one 
remaining packet not just for E seconds but for much 
longer. It can do this because its output during all 
intervals [t3, current_time] where t3 >= t1 is far in 
excess of R*(current_time - t3 - E). (This is assuming that 
R < C. The smaller R is relative to C, the more pronounced 
the effect can be.)

There has been some recent discussion on the mailing list 
about just how troublesome the scenario in the previous 
paragraph might be.Some DiffServers have made good cases 
that, as a practical matter, the scenario is not too 
troubling. They have indicated that short droughts should 
not adversely impact applications that might use EF in the 
future. Nonetheless, draft-Charny is based on the belief 
that at the heart of the intuition of EF is a behavior that 
can, if the router's scheduler is capable and properly 
configured, forward packets very smoothly at time scales 
down to the smallest conceivable time scale for this 
behavior (on the order of the time it takes to send a 
single packet at the EF-configured rate). This conservative 
belief arises from consideration of the PDBs that might be 
built on top of routers providing EF - for instance VW. 
This is why the draft moved on from a behavior like the 
ones described in this thread to the packet scale rate 
behavior defined in the draft.

Regards,
Bill Courtney
TRW, Network System Engineering

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