Subject: Terminoloby draft: summary

From: Dan Grossman <[email-masked]>
Date: Tue, 19 Oct 1999 12:23:06 -0400

We've had an interesting discussion on this issue of PHB groups and their 
relationship to AF.  The chairs and I think that we've reached a point where 
we should summarize the possible solutions, reach consensus and move on 
(preferably before this Thursday).

The issue:
The AF PHB Group appears not to comport with the definition of 'PHB group' 
because there is no common constraint among AF classes. By way of the example 
in the definition of PHB group don't share a common queue servicing or queue 
scheduling policy. In addition, there may be two levels of grouping:  AF has 
four AF classes, and each AF class has three drop precedences.  We can 
speculate that this may occur in future PHB groups.

  [note that there are some who do not agree that this is a problem.  However, 
 the fact that there have been several people who expressed confusion, and the 
fact that this was raised by one of the authors of AF suggest that this is in 
fact a problem that needs to be addressed.]

Possible solutions (in order which they were proposed)
1) As suggested in the draft. Preserve the existing definition of PHB group. 
Each of the four AF classes constitutes a separate PHB group, each having 
three PHBs corresponding to three drop precedences.  Create a new definition 
to describe a set of related PHB groups:

     PHB Group Family: a set of two or more PHB groups which are
     specified together and have similar relationships among their
     constituent PHBs, but which lack any common constraint.  A PHB
     group family provides a service building block that allows a set of
     related PHB groups to be specified together (e.g., three classes of
     PHB groups).

2)  As suggested by Brian, with embellishments by myself.  Concept of PHB 
group is recursive. An AF class is a PHB group.  AF is a PHB group of PHB 
groups.  Common constraint is relaxed to be either a common constraint or a 
shared major characteristic.  New definition of PHB group (to appear in the 
update when AF architecture advances on the standards track) is:
     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.

3) As suggested by Grenville.  AF is a type of PHB group.  Each AF class is an 
independent instance of the AF type.  No change needed to definition of PHB 
group, and no new definition needed.  RFC 2497 will need to be revised at the 
time that it advances on the standards track to reflect this.  Grenville 
agreed to provide text.

In all cases, RFC 2475 and RFC 2497 will be left alone until they are ready to 
advance, but this draft will serve as a living list to capture whatever 
changes, for the purpose of the revision and to assist authors and readers of 
future drafts.

Kathie/Brian, can we have a consensus call?

--------------------
Dan's personal opinion:  I'd be satisfied with any of these. All of them will 
meet my criteria for clarity and consistency.  I think (2) is particularly 
elegant, and gives us the most future flexibility.  The disadvantage is that 
not everybody understands recursion, and 'major characteristic' is pretty 
imprecise.  (1) is the easiest to understand, but it's yet another term to 
keep track of.  (3) is one less thing to do to RFC 2475, and emphasises the 
independence of the AF classes.  On the other hand, I'm not convinced that if 
we adopt this solution, we won't have to revisit this in the future.

---

From: John Schnizlein <[email-masked]>
Date: Tue, 19 Oct 1999 13:27:35 -0400

Thanks, Dan, for taking on this troublesome issue.

Alternative 3, requiring no special terminology, but possibly tweaking 
the text of the AF definition to indicate that four instances of the 
AF PHB group are recommended, seems sufficient to me. This strengthens
the necessary binding among members of a group, and suggests the degree
of importance (not terribly much) attributed to the number of instances.

Adding the semantic risks of "family" or "recursive" seems unnecessary.

At 12:23 PM 10/19/1999 -0400, Dan Grossman wrote:
>...
>1)   PHB Group Family: a set of two or more PHB groups which are
>2)  Concept of PHB group is recursive. An AF class is a PHB group.  
>AF is a PHB group of PHB groups.  Common constraint is relaxed to be 
>either a common constraint or a shared major characteristic. 
>
>3) AF is a type of PHB group.  Each AF class is an independent 
>instance of the AF type.

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 19 Oct 1999 11:48:36 -0700

> time that it advances on the standards track to reflect this.  Grenville

I've hacked up a possible revision to draft-ietf-diffserv-new-terms-00.txt
relating to PHB Groups (the second 'section 2'). It is a complete
cut-and-replace of the existing text, hopefully articulating
option #3 :-)

  [** gja edits begin here **]

 2. Definition of a PHB Group

     RFC 2475 defines a PHB group to be:

     "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. A PHB group provides a service building block
     that allows a set of related forwarding behaviors to be specified
     together (e.g., four dropping priorities).  A single PHB is a
     special case of a PHB group."

 The first official PHB Group is described in RFC 2497 [3] (entitled
 "Assured Forwarding PHB Group").  RFC 2497 defines the Assured
 Forwarding (AF) service as a forwarding behavior with some
 assigned level of queuing resources and three drop precedences.
 An AF PHB Group consists of three PHBs, and uses three DSCPs.

 RFC 2497 actually defines twelve DSCPs to support four independent
 AF PHB Groups - referred to as AF1x, AF2x, AF3x, and AF4x (where
 'x' is 1, 2, or 3 to represent drop precedence).  Each of these
 represent one instance of an AF PHB Group (referred to as a 'class'
 in RFC 2497). 

 A possible source of confusion is that RFC 2497 refers to all
 twelve DSCPs as a PHB Group. However, since each AF class
 operates entirely independent of the others, this usage is inconsistent
 with RFC 2475. The inconsistency exists for historical reasons,
 and will be removed in future revisions of the AF specification.

 Authors of new PHB specifications must retain RFC 2475's definition
 of PHB Group. RFC 2475 does not prohibit new PHB specifications from
 assigning enough DSCPs to represent multiple independent instances of
 their PHB Group. However, such a set of DSCPs must not be
 referred to as a single PHB Group.

  [** end of gja edits **]

It can be temporarily seen in context at:

http://mh005.infi.net/~gja/internet-drafts/diffserv-new-terms-gja-xx.txt

cheers,
gja

---

From: Dan Grossman <[email-masked]>
Date: Tue, 19 Oct 1999 17:07:24 -0400

A few edits to Grenville's edits: 

 
 
  The first standards track PHB Group is defined in RFC 2497 [3],
  "Assured Forwarding PHB Group".   Assured
  Forwarding (AF) is a type of forwarding behavior with some
  assigned level of queuing resources and three drop precedences.
  An AF PHB Group consists of three PHBs, and uses three DSCPs.
 
  RFC 2497 defines twelve DSCPs, corresponding to four independent
  AF classes - referred to as AF1x, AF2x, AF3x, and AF4x (where
  'x' is 1, 2, or 3 to represent drop precedence).  Each AF class is
  one instance of an AF PHB Group. 
 
  There has been confusion expressed that RFC 2497 refers to all
  four AF classes with their three drop precednences as being part of a single 
  PHB Group. However, since each AF 
  class operates entirely independently of the others, (and thus there is no 
  common constraint among AF classes as there is among drop precedences
  within an AF class) this usage is inconsistent
  with RFC 2475.   The inconsistency exists  for historical reasons,
  and will be removed in future revisions of the AF specification.  It should 
  now be understood that AF is a _type_ of PHB group,
  and each AF class is an _instance_ of the AF type.
 
  Authors of new PHB specifications must adhere to the RFC 2475 definition

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 19 Oct 1999 14:13:00 -0700

> A few edits to Grenville's edits:

Looks good to me.

cheers,
gja

---

From: Vrana Miroslav <[email-masked]>
Date: Wed, 20 Oct 1999 08:42:49 +0200

Hi Dan,

if this is the "call for vote" I vote for "3".
I can imagine, that for somebody who did not follow the discussion alternatives
"1" & "2" will be a challenge to read

Miro

Dan Grossman wrote:

> _______________________________________________
> 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: Thu, 21 Oct 1999 08:32:47 +0300 (EEST)

i'm ok with either (2) or (3).  just let me know what wg decides and
i'll spin a new version of the rfc.

-- juha

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 1999 08:18:00 -0500

Juha,

Please don't rush to revise the RFC. This change doesn't affect
the wire protocol, so I suggest we wait until we are ready to
proceed to Draft Standard... which requires implementations.

  Brian

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 21 Oct 1999 11:19:34 -0700

Juha,
Note Brian's earlier message: it's probably premature to spin a
new RFC, but the point of Dan's I-D was to "log" this stuff
so we can do so when we're ready for the next step.

	Kathie