[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Diffserv] Model - queues - replacement text



> 
> 	[..]
> > Queues perform three distinct, but related, functions:  they store packets,
> > they modulate the departure of packets belonging to various traffic streams
> > and they selectively discard packets.  This model decomposes queues into the
> > component elements that perform each of these functions.
> 
> I disagree fundamentally with this description.
> 
I don't know quite what to suggest.

The proposed text doesn't change the scope of the section entitled 'Queues', 
which also talks about scheduling and discarding.  The difference is that I've 
decomposed the queues into buffering, discarding and scheduling functions.  
But these were already there.   


> Queues are places where things are stored. Queues are acted upon
> to effect addition to, or subtraction from, the queue's contents.
> Addition is enqueuing. Subtraction is either a discard action,
> or a scheduler action. A queue per se does no action to either
> schedule or discard packets. That's the role of the scheduler
> or discard stages. Queues peform data storage, nothing else.
> 
I have a very nice two-volume set in my office called "Queueing Systems".  
It's full of math and graphs that describe the dynamics of queues.  There's 
material on priority queueing and queueing disciplines and work conservation 
and loss formulas and.... a lot more than the 20-odd pages on stacks and 
queues in my (nondescript) Data Structures reference text.

I think that if I'm stretching the definition of a queue, others have gotten 
there first. :-)

> (When I wrote code to hold data elements in a queue, the 'queue'
> itself never modulated departure of data elements. Why should the
> defn be changed for routers?)
> 
I think that this is another case of a word that's gotten overloaded.   And 
the broader context is appropriate here.

Unless you have another word that would 'drop in'?

Otherwise, maybe the thing to do is put in some words to the effect that the 
word "queue" is overloaded, and that this document uses it in its broader 
context.

> 	[..]
> > Note that the term FIFO is overloaded (i.e., has more than one meaning).  In
> > common usage it is taken to mean, among other things, a data structure that
> > permits items to be removed only in the order in which they were inserted,
> > and a service discipline which is non-reordering.  In this model, the former
> > context is used except when explicitly noted.
> 
> So, totally ignoring the observation I (and I think Roch) made last
> week - that in this case, 'FIFO' characterizes the scheduling behavior
> applied to the queue.  Focussing on FIFO as descriptive of the queue's data
> structure just serves to complicate the whole discussion, and isn't really
> useful to an abstract router model. 
No, quite the contrary, acknowledging your observation and recognizing that 
there is more than one meaning which is commonly assigned to "FIFO".
> 
> The descriptions of all the individual elements are good material.
> But the above, expansive definition of 'a queue' is too much.
> 


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/