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

From: Andrew Smith <[email-masked]>
Date: Thu, 16 Dec 1999 13:15:27 -0800

Then I think we need a different term than "FIFO" for this strange queueing
thingy. Alternatively we can just drop the "this does not preclude ..."
sentence.

Andrew

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, December 16, 1999 7:44 AM
> To: Andrew Smith
> Cc: [email-masked]
> Subject: Re: [Diffserv] Model - queues - replacement text
> 
> 
> Yes, I think it is a whisker too restrictive, see below:
> 
>   Brian
> 
> Andrew Smith wrote:
> > 
> > OK, so we need suitable RECOMMENDATION text instead, at all 
> places in the
> > model where re-ordering might be introduced (it's not 
> something specific to
> > the "queue" section, is it?).
> > 
> > Are we saying that my proposed text:
> > 
> > "this does not preclude implementions which support 
> operations on the FIFO
> > data structure that remove or examine packets e.g. for use 
> by discarders.
> > The only constraint on such operations is that they not add 
> packets back
> > into the FIFO in a different order."
> **into the queue in such a way as to re-order any microflow."
> > 
> > is too restrictive? Can someone provide a suitably 
> realistic example of why
> > this is too strict? If so then I think we need a less 
> misleading name for
> > this thing than "FIFO".
> > 
> > Andrew
> > 
> > > -----Original Message-----
> > > From: Brian E Carpenter [mailto:[email-masked]]
> > > Sent: Wednesday, December 15, 1999 1:18 PM
> > > To: Andrew Smith
> > > Cc: [email-masked]
> > > Subject: Re: [Diffserv] Model - queues - replacement text
> > >
> > >
> > > Well, never mind the ASICs then. RFC 2474 says
> > >
> > > >    It is RECOMMENDED that PHB implementations do
> > > >    not introduce any packet re-ordering within a microflow.
> > >
> > > The text in the model must be consistent with this.
> > >
> > >   Brian
> > >
> > > Andrew Smith wrote:
> > > >
> > > > That's fine for specific PHBs but we are talking here about
> > > the generic
> > > > model of a queueing thing for all current PHBs and as many
> > > future PHBs as
> > > > possible. Not sure I understand the relevance of
> > > MF-classifier based ASICs
> > > > to this.
> > > >
> > > > Andrew
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian E Carpenter [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 15, 1999 7:46 AM
> > > > > To: Andrew Smith
> > > > > Cc: 'Dan Grossman'; [email-masked]
> > > > > Subject: Re: [Diffserv] Model - queues - replacement text
> > > > >
> > > > >
> > > > > Andrew Smith wrote:
> > > > > ...
> > > > > > > structure that remove or examine packets (e.g., for use by
> > > > > > > discarders), as
> > > > > > > long as no operation reorder packets belonging to the
> > > > > same microflow.
> > > > > >
> > > > > > [Andrew] Suggest we not get into re-ordering issues here to
> > > > > any granularity
> > > > > > less than "per-queue": I think it suffices to say here
> > > > > "this does not
> > > > > > preclude implementions which support operations on the FIFO
> > > > > data structure
> > > > > > that remove or examine packets e.g. for use by
> > > discarders. The only
> > > > > > constraint on such operations is that they not add packets
> > > > > back into the
> > > > > > FIFO in a different order."
> > > > >
> > > > > Well, some months back we had implementors *insisting* on the
> > > > > per-microflow
> > > > > language rather than per-queue, so that the diffserv 
> model would
> > > > > be compatible with MF-classifier based ASICs. I think
> > > that was for the
> > > > > specific case of AF, but I suspect the argument is generic.
> > > > >
> > > > >    Brian
> > > > >
> > > >
> > > > _______________________________________________
> > > > diffserv mailing list
> > > > [email-masked]
> > > > http://www.ietf.org/mailman/listinfo/diffserv
> > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > >
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter (IAB Chair)
> Program Director, Internet Standards & Technology, IBM 
> On assignment for IBM at http://www.iCAIR.org 
> Attend INET 2000: http://www.isoc.org/inet2000
> Non-IBM email: [email-masked]
> Ethernet address: 00-00-AC-CF-5B-82
> 
> _______________________________________________
> 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, 16 Dec 1999 16:23:44 -0600

I agree. If we do not forbid re-ordering between microflows, it is not a FIFO.
And RFC 2474 does not forbid such re-ordering.

Maybe it's a FLIFLO (flow in flow out) :-)

  Brian

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 16 Dec 1999 15:55:45 -0800

at the risk of proving i'm confused by this tangent,
i suspect the problem is due to focusing on the queue
itself as being FIFO, rather than focussing on the
ultimate scheduling sequence from the perspective of
packets stored in the same queue/buffer.

if i've read the text below properly, the problem lies
with the notion that a discarding engine might need random
access into the queue itself?  that certainly makes the
queue difficult to describe as a pure FIFO. it is also
one of the reasons i suggested using FIFO term only to describe
the ordering relationship between packets that simply pass
through the queue/buffer without being subject to discard.
the actual internal structure of the queue/buffer doesn't
even need to be defined, just its external behavior, viz.:

	- Scheduler pulls packets out in FIFO order
	- Discarder pulls packets out using random access
	- Queue internals are irrelevant (ummm... open to
	  individual implementation choices :-)

cheers,
gja (sorry if i've completely misunderstood something here)