[altq 22] Re: When a class is delayed (undertime)

[Fulvio Risso <F.Risso@cs.ucl.ac.uk>]

> -----Original Message-----
> From: owner-altq@csl.sony.co.jp [mailto:owner-altq@csl.sony.co.jp]On
> Behalf Of Kenjiro Cho
> Sent: Monday, June 07, 1999 8:15 AM
> To: Fulvio Risso
> Cc: altq@csl.sony.co.jp
> Subject: [altq 21] Re: When a class is delayed
> 
> 
> 
> Fulvio,
> 
> 	[ This discussion is about the detail of the CBQ mechanism.
> 	  Fulvio pointed out that, though the class gets its share
> 	  of the bandwidth, it is burstier than expected. ]
> 
> The orginal CBQ algorithm was changed when LBL CBQ went to v2.0.
> In v1.0 (and in Sally's paper):
> 	- avgidle never becomes negative
> 	- the delay is always set to "offtime"
> In v2.0:
> 	- avgidle can be negative (minidle sets the lower bound)
> 	- the delay is set to "offtime + undertime"
> 
> The changes break the original intention of "minburst".


"Experimental Results for Class-Based Queueing" (by Sally Floyd and Michael Speer,  still in progress) says (page 2) that:

"at one time a minidle parameter was used in the ns simulator, but that parameter has been removed, and there is now no lower bound on avgidle".

This report dates November 11, 1998.
You can find it here: http://www-nrg.ee.lbl.gov/floyd/cbq/notes.html

Anyway, I'm very interested to know WHY this minidle was inserted, and WHY it was calculated like this. I mean: it will be some theoretical reason to define the minidle value. Which are these reasons?

Anyway, this draft reports the fact that to calculate the "suspension time", you have to do

	now + offime

and not 

	expected finishing time + offime

In fact, using my new computation for the suspension time (instead that in ALTQ) the results are definitely better:

- a class with different packet size perform as expected (insted with the previous computation there was not a clear relation between throughput and packet size)

- the steady state burst is complaining with the configuration settings.

In any case I don't think that the minidle parameter is the cause of the burstiness. My belief is that the undertime_ computation is maybe wrong.

I report also the CBQ NS-2 code:

=========================================================
	if (avgidle <= 0) {
		undertime_ = fin_time + tx_time *
			(1.0 / allotment_ - 1.0);
		undertime_ += (1-POWEROFTWO) * avgidle;
	}
=========================================================

where fin_time = now + pkt_time. (if I understand well the code).
Again, "now", not "expected finishing time".

Other details in the othe mail.

	fulvio