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

RE: [Diffserv] Model - queues - replacement text



Title: RE: [Diffserv] Model - queues - replacement text

Hello:

Does any vendor offer a protocol decode for COPS-PR..

Regards

Larkland Morley
Nortel Networks

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Tuesday, December 14, 1999 2:49 PM
To: Grenville Armitage
Cc: Dan Grossman; diffserv@ietf.org
Subject: Re: [Diffserv] Model - queues - replacement text


Grenville,

Let's be clear that this is a discussion about terminology, and the question
is whether the term "queue" refers only to an ordered data store (your view)
or to an ordered data store plus the engine(s) that act on that store (Dan's view).

The -01 version of the model draft clearly uses "queue" in the narrow sense
of an ordered data store. The -01 version of the MIB uses it in the broader
sense of store + engines. So we do have to resolve this; Dan's text aligns
the model with the MIB, but one of the documents has to change anyway..

   Brian

Grenville Armitage wrote:
>
> Dan,
>
>         [..]
> > 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.
>
> 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.
>
> (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?)
>
>         [..]
> > 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.
>
> The descriptions of all the individual elements are good material.
> But the above, expansive definition of 'a queue' is too much.
>
> cheers,
> gja
> ________________________________________________________________________
> Grenville Armitage                            http://mh005.infi.net/~gja
> Bell Labs Research, Lucent Technologies
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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