Subject: RE: [Diffserv] Model - queues (second draft)

From: Shahram Davari <[email-masked]>
Date: Thu, 6 Jan 2000 11:05:44 -0800

Hi Andrew, 

Imagine an edge router which has two Metering stages: a Microflow and an
Aggregate Metering stage. Now imagine that flow A is not marked by the
customer, and needs both Microflow and Aggregate metering. Also imagine flow
B is already marked by the customer and needs only aggregate metering. Now
if the metering stage is a parallel processing system in which flow A and B
can be metered simultaneously, then it is possible for a packet from flow B
to overtake a packet from flow A even if it had arrived later (because it
needs less processing). 

So I don't think assumption of serial delivery to the FIFO is implicit in
the concept of packet FIFO.

-Shahram

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: Thursday, January 06, 2000 1:48 PM
> To: 'Grenville Armitage'
> Cc: [email-masked]
> Subject: RE: [Diffserv] Model - queues (second draft)
> 
> 
> Grenville,
> 
> I think that's implicit in the concept of a packet FIFO: I 
> think the way
> packets from multiple sources make their way into the FIFO 
> *is* an attribute
> of the FIFO queueing stage. If the FIFO worked on units of 
> less than one
> packet (e.g. 53-byte chunks of it :-)) then, I agree, some 
> sort of merge
> block might be needed. 
> 
> Maybe the clarification should be just the "packet" part of 
> this: there is
> no smaller unit of time under consideration here than a 
> complete packet time
> so the use the word "First" in "First In First Out" implies 
> "the time at
> which the start of the packet arrives at the queue" (or 
> should it be the end
> of the packet?). It is arguable that any definition that 
> involves "first" or
> "the time at which ..." implies a scheduling stage but I 
> think, in this
> case, that is splitting hairs.
> 
> Andrew
> 
> > -----Original Message-----
> > From: Grenville Armitage [mailto:[email-masked]]
> > Sent: Thursday, January 06, 2000 9:56 AM
> > To: Dan Grossman
> > Cc: [email-masked]
> > Subject: Re: [Diffserv] Model - queues (second draft)
> > 
> > 
> > 
> > 
> > Dan Grossman wrote:
> > 	[..]
> > > > 2) You mention that a FIFO can have more than one input. 
> > I think if there
> > > > are more that one inputs, then there should be another 
> > element (i.e.,
> > > > scheduler elements such as FCFS or MUX) before the FIFO. 
> > So I suggest
> > > > changing the text to "A FIFO has one input and one 
> > output, but if more that
> > > > one input are required for a FIFO they have to pass 
> > through a scheduler
> > > > element".
> > > >
> > > I thought about this and don't agree.  It would be common, 
> > for example to have
> > > more than one classifier feeding the same queue.  If the 
> > flow of packets is
> > > assumed to be serial, there is no scheduler element required.
> > 
> > Dan,  I think I agree with Shahram's observation here. If we assume
> > the packets arrive serially from the outputs of preceding 
> classifiers
> > then the merging (aka 'multiple inputs') isn't really an attribute
> > of the queue/buffering stage - its a simple 'OR' function of
> > multiple streams of packets, which might happen anywhere prior to
> > the FIFO.  At the very least, add text clarifying
> > the assumption that the multiple inputs are in fact being fed
> > by synchronized packet streams (i.e. synchronized to have
> > non-overlapping arrival times at the FIFO input{s} )
> > 
> > cheers,
> > gja
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jan 2000 16:04:04 -0600

Shahram,

I think we agreed that elements can be cascaded; what you are describing is
cascading traffic conditioners in front of the input to a queue. I think we had
the notion that the input to a queue is a multiplexer rather than a wire a
long time ago. So I think the text should make it clear that the input to
a queue may be a multiplexer, but the queue certainly doesn't include the
traffic conditioners feeding that multiplexer.

Apart from this point, where we need one more spin, I'm going to pick up 
my co-chair's gavel and say that Dan's text should go into the pending 
revision of the model draft.

  Brian