Subject: Re: [Diffserv] Terminology draft

From: Constantinos <[email-masked]>
Date: Sat, 9 Oct 1999 19:41:41 -0500 (CDT)

> It might just be an existence proof that this definition of the
> "class" relationship in AF is ill-defined. In fact, this was
> somewhat hotly contested. I know Steve Blake made a pretty strong
> (and to my mind convincing) argument at the Orlando IETF that the 
> wording should be the same as that of the CSC PHBs. 

I totally agree with this view. It seems that the working group is at
the slippery way of defining more terms, creating generalizations,
isomorphic abstractions, recursions, and finally needing lawyers for
understanding the meaning of RFCs. And all this happens IMHO 
because of a mistake, which was to remove the class ordering 
from the AF PHBs. 

What is sad, if you think about it, is that this group started with
the intention to take the simplest possible approach in order to make 
things happen (without also limiting how things can evolve later).

People may want to read a message that Mike O'Dell sent to this list
long time ago with the subject "does anyone remember the point here..."

http://www-nrg.ee.lbl.gov/diff-serv-arch/msg01460.html

Constantinos

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Oct 1999 03:44:18 -0500

> because of a mistake, which was to remove the class ordering

Hold on. We are *not* having a discussion here about that particular
strong consensus in the WG. We are having a discussion about clarifying
the terminology.

Here is a concrete proposal.

old definition (RFC 2474):

>    Per-hop Behavior Group: a set of one or more PHBs that can only be
>    meaningfully specified and implemented simultaneously, due to a
>    common constraint applying to all PHBs in the set such as a queue
>    servicing or queue management policy.  Also PHB Group.

new definition:

   Per-hop Behavior Group (also PHB Group):  
   EITHER a set of one or more PHBs that can only be
   meaningfully specified and implemented simultaneously,
   OR a set of such PHB Groups that share major characteristics.
   Typically the PHBs in a group will share a common constraint 
   such as a queue servicing or queue management policy.  

      Brian

---

From: Dan Grossman <[email-masked]>
Date: Mon, 11 Oct 1999 12:05:16 -0400

>    such as a queue servicing or queue management policy.  

I'd had a slightly different suggestion:
"... a set of one or more PHBs or PHB groups that are specified
and possibly implemented simultaneously, due to one or more isomorphism or 
common constraint applying to all members of the set.  An example of an isomorphism is use by each member of the PHB group of an independent instance of the same type of queue servicing or queue management policy.  An example of a common constraint is the application of a single instance of a queue servicing policy to all members of the PHB group (e.g., to preserve packet ordering) . A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., three classes or four dropping priorities).  A single PHB is a special case of a PHB group.  Note that the concept of a PHB  group is recursive."

The latter is significantly less restrictive as to what we can do in the future (e.g., we may need a set of PHB groups that have a common constraint).  It also loses some useful clarifications.  However, the former does get rid of this annoying word "Isomorphism".  Try the following:

Per-hop Behavior Group (also PHB Group):
A set of one or more PHBs or PHB groups that either 1) can only be meaningfully specified and  implemented simultaneously, due to a common constraint applying to all members of the set, or 2) share major characteristics such that it is convenient to specify and implement them simultantiously.  An example of a common constraint is the use by all members of the PHB group of a shared instance of a queue servicing or queue management policy. An example of a shared major characteristic is the independent use by each member of the PHB group of the same type of queue servicing or queue management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., three classes or four dropping priorities).  A single PHB is a special case of a PHB group.  Note that the concept of a PHB  group is recursive.

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 11 Oct 1999 09:36:50 -0700

Brian E Carpenter wrote:
....
> strong consensus in the WG. We are having a discussion about clarifying

And my comment was NOT to open that up again, but to speak to the
underlying assumption that we were likely to have more of
such definitions. I happen to like what Brian proposed below. Seems
to solve the problem nicely, clarifies "common constraint" and
avoids more terminology.

	Kathie

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

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 18 Oct 1999 08:57:45 +0300 (EEST)

Dan Grossman writes:

 >  Per-hop Behavior Group (also PHB Group): A set of one or more PHBs
 > or PHB groups that either 1) can only be meaningfully specified and
 > implemented simultaneously, due to a common constraint applying to
 > all members of the set, or 2) share major characteristics such that
 > it is convenient to specify and implement them simultantiously.

this sounds ok to me.

-- juha

---

From: Grenville Armitage <[email-masked]>
Date: Sat, 16 Oct 1999 12:02:31 -0700

Juha Heinanen wrote:
>  > or PHB groups

I think we can simplify it by dropping the "..or PHB groups".
"..one or more PHBs" pretty much states that a PHB Group contains
multiple PHBs, and the following cases #1 and #2 define what that
means. (Indeed, "one or more" probably ought to be "two or more"
since if there's only one, its just a PHB.)

>  > that either 1) can only be meaningfully specified and

I'm still having trouble with this whole thread. Sure, de-coupling
the constraints between the AF classes has led to an interesting
internal inconsistency in RFC 2497. But I dont see that adding option
#2 above to the definition of a PHB Group is really going to
improve clarity in the long run for DiffServ. On the contrary, it
just makes 'group' a more vague term for all subsequent uses.

I usually use the following explanation for AF:

 There is no recursive relationship between the four AF classes.
 AF1x, AF2x, AF3x, and AF4x are all just _instances_ of the AF PHB
 Group. An "AF PHB Group" is a forwarding behavior with some certain
 level of queuing resources and 3 drop precedences. RFC 2497 simply
 assigned sufficient DSCPs to identify four independent instances of
 the AF PHB Group.

Nothing more complex that that, implementation-wise or
terminology-wise.

If the problem lies with RFC 2497's references to all four 'classes'
as inclusive members of the AF PHB Group, fix that when the time comes.
Beyond that, I dont see the need for either 'Group Family' or the
broader definition of 'group'.

Note - I'm not saying 'group' cannot be recursively
defined. But AF and its four classes in RFC2497 is not an example
of recursive constraints (since the constraints that define and
relate AFx1, AFx2, and AFx3 are not the same constraints that define
and relate AF1y, AF2y, AF3y, and AF4y).

cheers,
gja

---

From: Dan Grossman <[email-masked]>
Date: Mon, 18 Oct 1999 10:25:46 -0400

> means.
If we agree that PHB groups are recursive, then we should keep "or PHB 
groups".  There is clearly a difference of opinion on that subject.

> (Indeed, "one or more" probably ought to be "two or more"
The existing definition states that a PHB is a special case of a PHB group.
> Nothing more complex that that, implementation-wise or
This is one of three possible (i.e., clear and self-consistent) solutions that 
have been discussed on the list. 

> and relate AF1y, AF2y, AF3y, and AF4y).
But nobody said that the constraints that define and relate have to be the 
same at each level of recursion.  In fact, the proposed new definition states 
that there need not be a common constraint at each level of recursion.  A 
"common characteristic" is good enough.

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 18 Oct 1999 08:34:58 -0700

Dan,

	[..]
> In fact, the proposed new definition states

The bottom line is that the new proposals add words and spread
(dilute) the currently focussed meaning of 'group'. I do not
believe it has been demonstrated that simple english explanations
(such as the one I gave in my previous email) are insufficient
to understand RFC 2497 (the apparent cause of all this effort).

Therefore on the basis of KISS, I suggest we retreat from new
definitions of "Group Family" (and similar) or re-definitions
of "Group". Instead, the terminology document ought to note
the existence of present imprecision in RFC 2497, and provide
a plain english explanation of what RFC 2497 really means
without redefining what a PHB Group is. Future RFC authors are
then reminded to be precise in how they use the "group"
terminology, especially if their RFC is proposing DSCPs to
cover multiple instances of their new PHB Group.

cheers,
gja

---

From: Marty Borden <[email-masked]>
Date: Mon, 18 Oct 1999 12:38:42 -0400

I want to add my support to Grenville's viewpoint.
It seems to me that we are unnecessarily burdening
the terminology.  I've yet to understand why the
different AFxs cannot be multiple instantiations of
AF with multiple DSCPs assigned.
marty