Subject: RE: [Diffserv] Terminoloby draft: summary

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Oct 1999 09:22:54 -0700

Hi,

I also vote for "3".

                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
          Shahram Davari
          Systems Engineer, Product Research
          PMC-Sierra Inc. 
          105-8555 Baxter Place
          Burnaby, BC V5A 4V7, Canada
          Phone: +1 (604) 415-6000, Ext. 2428
          Fax  : +1 (604) 415-6206
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/

> -----Original Message-----
> From: Vrana Miroslav [mailto:[email-masked]]
> Sent: Tuesday, October 19, 1999 11:43 PM
> To: Dan Grossman
> Cc: [email-masked]
> Subject: Re: [Diffserv] Terminoloby draft: summary
> 
> 
> 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:
> 
> > 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.
> >
> > _______________________________________________
> > 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: Wed, 20 Oct 1999 14:21:10 -0500

This looks pretty close to a consensus for the 3rd option to me.
To simplify matters, I withdraw my own suggestion (#2).

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Dan Grossman <[email-masked]>
Date: Thu, 21 Oct 1999 09:38:54 -0400

> To simplify matters, I withdraw my own suggestion (#2).

Ok.  I'll update the draft and get it to the I-D editor before I leave tonight.