Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt

From: Constantinos <[email-masked]>
Date: Fri, 5 Nov 1999 20:55:50 -0600 (CST)

A couple of comments on the model draft.

1) Regarding the Class Selectors, I also think that they should be
mentioned. Since these PHBs carry the precedence semantics of the
original TOS byte, they have to provide relative differentiation between
the existing 8 classes, in terms of delays and losses.

A relative differentiation scheme does not have to be "parameter-less",
as in strict-priorities. There are scheduling and buffer management
schemes that provide the "tweaking knobs", as Andrew calls them,
for adjusting the relative delay or loss priority between classes.
For the case of delays, for example, we can use Kleinrock's scheduler
(see "A Delay Dependent Queue Discipline", Journal of the ACM, 14(2), 1967,
which is also described in the 2nd volume of his Queueing Systems
textbook). In this mechanism, a relative-priority parameter is associated 
with each class, controlling the delay spacing between classes. 

Similar dynamic-priority schemes can be devised for buffer management,
differentiating the loss-rate between classes. Which brings me to
the next comment. 

2) As far as I understand, the draft describes the dropping action as 
something that can be performed only on the just arrived packet. 
Am I right? This restricts the loss-rate differentiation that can be 
achieved between classes. A different approach is to do something like:

	- a packet arrives
	- do we need to drop one or more packets? 
	(either because we run out of buffers, as in the drop-tail case, 
	or because the regulator (like RED) says that a packet needs to be
	dropped)
	- if we need to drop a packet, select a backlogged class
	to drop from, and remove a packet from the queue of that class.
	In this way, we have better control of the loss-rate differentiation 
	between classes, since the class-to-drop variable is decoupled from 
	the class-arrived variable.

My general feeling reading the draft was that it is very well-written
and concise. What is still not clear to me, though, is whether this model
is really implementation and services-independent. Which is also mentioned
at the "open issues" section, I think.

Constantinos

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

---

From: Steve Blake <[email-masked]>
Date: Fri, 05 Nov 1999 23:30:17 -0500

> the existing 8 classes, in terms of delays and losses.

To be precise, 2474 does not define any PHBs, but only requirements
on acceptable PHBs which could be mapped to by the Class Selector codepoints.
And I agree with Andrew in that I don't see any obvious parameters implied
by these requirements that differ significantly from what is specified in the
model.

> with each class, controlling the delay spacing between classes. 

The only parameter I see falling out of this scheme is relative average
delay ratios between queues.  That is worth considering.

> achieved between classes. A different approach is to do something like:

The text implies that the enqueueing element forwards or drops on arrival.
This cannot be changed without combining the enqueueing element and the
queue into a single element given the structure of how the model
interconnects elements.

And we are not specific about which parameters an enqueueing element
might support, so I could see relative loss ratios as feasible.

> 	the class-arrived variable.

Sec. 6.6 is explicit in that an enqueueing element may make a discard
decision based on the state of all the queues in a queue set.  So assuming
that the different classes are in different queues, this is possible in
the model.

> at the "open issues" section, I think.

Well, you point to a philosophical problem with the model and the MIB
drafts which I am very sympathetic with, namely why did we go to all the
trouble to standardize abstract PHBs when we are going to define fairly
detailed queueing parameters in the model and the MIB?  The argument in 
favor of the MIB/model parameters is that they are needed to manage actual
implementations, and that the exotic stuff is not getting implemented to
any significant extent.  The alternative to this approach is to define
PHB-specific MIBs, but that obviously comes at some non-trivial cost.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <[email-masked]>
Ericsson IP Infrastructure             (919)468-8466 x232

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Nov 1999 06:20:38 -0600

Hi,

I'd be perfectly happy if the draft said that the class selectors
don't [necessarily] need any parameters; my point is that people
tend to spend all their ink on AF and EF, and that is not right.

  Brian