Subject: Terminology draft

From: Dan Grossman <[email-masked]>
Date: Wed, 06 Oct 1999 13:59:39 -0400

As you saw this morning, draft-ietf-diffserv-new-terms-00.txt has been posted. 
I would appreciate discussion on the list, and will try to get a -01 out 
before the October 22 I-D deadline.

Kathy Nichols and I had an offline discussion which I wish to summarize.  She 
did not agree with how I proposed to handle the anomaly in the mapping of AF 
and AF classes to PHB groups.  The core of her argument is that the 
requirement for independence among AF classes and the requirement for 
non-aggregation of AF classes is a 'common constraint', and that therefore AF 
is a PHB group and an AF class is a PHB scheduling class. 

My implicit assumption was that 'common constraint' meant that the correct 
behavior of one PHB in the PHB group depended on the state of the other(s).  
This means that since AF classes are independent, they cannot have common 
constraints.  Thus, AF can't be a PHB group, AF classes are a PHB group, and 
AF classes are also a PHB scheduling class, which is a special case of a PHB 
group.  Kathy thinks that 'common constraint' should be more loosely 
interpreted, and if we accept a loose interpretation, then AF is a PHB group.

This concept of PHB group families was only a way out of a consistency problem 
in the definitions.  I'd be happy to get rid of it if there were a change that 
could be made to the definition of PHB group in RFC 2475:
>      "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 issues as this relates to AF are:
1) if you take the view that 'common constraints' should be read to have a 
formal meaning (as I do and Kathy doesn't), then AF classes don't have a 
common constraint amongst them.  They are similar or (dare I use a really 
formal word) isomorphic.
2) AF classes don't share a queue servicing policy or queue management policy. 
 They do have similar/isomorphic queue scheduling policies.
3) the 'four dropping priorities' seems to refer to the drop precedence within 
an AF class rather than AF.

In addition, Scott Brim disagrees that AF classes must necessarily be 
implemented together.

At this point, I'd like to see what the group thinks.  I have no strong belief 
in any particular solution, but do believe very strongly that whatever we come 
up with must be clear, self-consistent and unambiguous and whatever we define 
must be consistently applicable to AF and class selectors.

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 6 Oct 1999 14:44:39 -0400

I have a simple question.

If a flow is re-marked, by the core diffserv network, from AFn to
AF(n-1), and if diffserv mandates that the packets in this flow
remain ordered, does this not say that AF must belong to one PHB
group?

You quote RFC 2475: "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)."

Why would one not conclude that AF belongs to the same PHB group?

Bert
[email-masked]

----- Original Message -----
From: Dan Grossman <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 06, 1999 1:59 PM
Subject: [Diffserv] Terminology draft

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

---

From: Dan Grossman <[email-masked]>
Date: Wed, 06 Oct 1999 16:39:52 -0400

> [email-masked]
I was about to say that the ordering constraint applies only to packets of a 
microflow belonging to the same AF class.  This is true.  However, it's not 
that simple.

Section 3 of RFC 2597 says that that a node at the edge of a DS domain can 
reassign packets to other AF classes as long as it doesn't "cause" reordering 
of packets belonging to the same microflow. I read this to mean that it had 
better map all packets of the same microflow to the same DS class, since even 
if the DS edge node preserved ordering during the remapping, there would 
likely be reordering at downstream nodes.  Thus, a remapping that mapped 
packets of the same microflow to different DS classes would "cause" reordering.

However, this is an implied requirement on traffic conditioners.  It does not 
affect downstream DS nodes.  Thus, it is not a shared constraint between AF 
classes.

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 6 Oct 1999 17:02:45 -0400

----- Original Message -----

[ ... ]

> affect downstream DS nodes.  Thus, it is not a shared constraint
between AF

Hmmm. I guess I read that to mean that if a diffserv networks
re-marks an AF flow, the PHBs along the path must somehow ensure
that packets of individual microflows are not reordered, which in
turn implies, by RFC 2475, that these PHBs must belong to the same
group?

Is this wrong? This is getting a little thick for me. If the PHBs do
belong to the same group, then in principle this group could be made
to prevent reordering of packets.

Maybe what we're saying is that the RFC 2597 _can_ be met by
requiring the PHBs of AF to belong to the same PHB group, but that
perhaps there are also other ways to achieve the no-reordering of
packets in microflows requirement?

Bert

---

From: Ambarish Kenghe <[email-masked]>
Date: Wed, 6 Oct 1999 18:12:59 -0500 (EST)

Hi,
	I agree with Dan that AF does not look like a PHB group anymore.
I guess, initially AF was a PHB group, as according to the first AF draft
there was an ordering between different AF classes. Now, that the new RFC
says that AF classes should be forwarded independently of each other,
the term  'AF group family' does seem to capture that 'independence'.

Regards,
ack
------
Ambarish C. Kenghe
Department Of Computer Science,		215 Littleton Street, #6,
Purdue University,			West Lafayette, IN47906, 
West Lafayette, Indiana, USA.		USA.
E-mail: [email-masked]             Tel: (765)-495-7664 (Voice Mail)
Tel: (765) 494-5231 (Without Voice Mail)
"Live For Today, Plan For Tommorow, Party Tonite!"

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Oct 1999 03:38:16 -0500

AF classes are independent and there is no ordering constraint
across AF classes. The ordering constraint is clearly required across
drop precedences within an AF class.

If an AF flow happens to go through a traffic conditioner that
remarks it from one AF DSCP to another AF DSCP, that really has
nothing to do with the terminology issue; it's simply business as
usual at a network/network boundary. 

Now, back to terminology. I observe that the word "group" is
recursive; there is no problem with the concept of a PHB Group
that contains several PHB Groups. One possible approach is to
accept this view, agree that both Kathie and Dan are correct,
and tweak the definition of PHB Group accordingly. 

   Brian

---

From: Dan Grossman <[email-masked]>
Date: Thu, 07 Oct 1999 12:04:32 -0400

> usual at a network/network boundary. 
This is my understanding as well.  However, this obviously is an ambiguity in 
RFC 2497.  If a reasonable reader can come up with an interpretation like 
Bert's, then it seems that some words are needed in the next version of AF to 
correct.
> and tweak the definition of PHB Group accordingly. 
I _like_ recursion.  

We would still have to do something about 'common constraints' and the examples in the definition to relax it enough to cover AF. Like, for example:

... 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."

"Isomorphism" seems a bit presumptuous, even pompous, but I can't think of a better word right now.

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 07 Oct 1999 12:49:12 -0400

Dan Grossman wrote:

	[and Brian wrote...]
> > and tweak the definition of PHB Group accordingly.

Me too.

But one thing that occured to me - are we twisting ourselves up
unecessarily by trying to define a 'group' in abstract terms?

Decoupling each AF class from the others means that there really is,
from a behavioral perspective, only one AF class having 3 drop
precedences. It just so happens that RFC 2597 defines 4 DSCPs for
up to 4 independent instances of this generic AF class and its 3 drop
precedences.

So AF1x is a PHB Group. AF2x is also a PHB Group, but its essentially
the same group as AF1x in abstract terms - its only when specific
queue weights and drop probabilities are configured per-hop that
AF1x and AF2x may result in specific different behaviors. Should this
be formalized as a a 'group of groups'? I'm not sure.

Am I heading anywhere useful?

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: Dan Grossman <[email-masked]>
Date: Thu, 07 Oct 1999 13:51:02 -0400

> Am I heading anywhere useful?
I somewhat doubt it, but could be persuaded.

You're right that the four AF classes are four instances of the same type.  However, the fact that we said that we would specify exactly four instances together, and expect them to be implemented together (sorry Scott) implies some kind of grouping of groups.

---

From: Siamack Ayandeh <[email-masked]>
Date: Thu, 07 Oct 1999 15:36:17 -0400

Dan Grossman wrote:

> constraints.

Dan,

The constraint may arise at times in allocating resources to AF classes. For
example
with similar traffic conditioning, relative service would require relative
scheduling
weights.  Yet again AF classes may be used to partition traffic where the weights
lose their significance.

In search of improved terminology, lets not have a cure which is worst than the
disease.

Regards, Siamack

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 07 Oct 1999 19:53:43 -0400

[..]
> You're right that the four AF classes are four instances of the same
> type.  However, the fact that we said that we would specify exactly
> four instances together, and expect them to be implemented together
> (sorry Scott) implies some kind of grouping of groups.

Here's what worries me a bit. Clearly AF1x is a group defined by
constrained behavior. However, AF1*, AF2*, AF3*, and AF4* together are
a group created by a document but otherwise having no 'behavioral
constraint' relationship between them. Seems that RFC 2597 defines
only one PHB group, and four blocks of DSCPs allowing up to four
independent instantiations of this PHB group.

So I'm still a little uncertain about using AF as an example of
recursive 'PHB Group'. Perhaps I'm just missing something obvious?

cheers,
gja

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 07 Oct 1999 20:46:26 -0700

> usual at a network/network boundary.

So I'm not sure what that diversion was about, but since Brian
was making it, there has to have been a point. :)

> and tweak the definition of PHB Group accordingly.

If we can agree to use "PHB Groups" recursively and NOT invent
any new terminology, I'll be happy to let Dan be the only one
who's "correct".

I really think we should seriously consider a moratorium on new 
terminology until we go to Draft Standard. Is lack of terminology
keeping anyone from implementing diffserv? 

	Kathie

---

From: Dan Grossman <[email-masked]>
Date: Fri, 08 Oct 1999 10:21:40 -0400

> recursive 'PHB Group'. Perhaps I'm just missing something obvious?
In that case, what is AF?  Is it a family of groups, as I suggested in the 
draft?  Or are you suggesting that we redraft RFC 2597 to define one PHB 
group, of which there may be four independent instances?  I'm not sure how 
you'd do that.

---

From: Dan Grossman <[email-masked]>
Date: Fri, 08 Oct 1999 10:50:07 -0400

> was making it, there has to have been a point. :)
This was in response to Bert's question about remarking packets of the same 
microflow to different AF classes.
> any new terminology, I'll be happy to let Dan be the only one
I would prefer that we all be 'correct'. 
> keeping anyone from implementing diffserv? 
The issue here is that reasonable people -- in fact, people who participate in 
the mailing list -- are reading the RFCs and coming to very different 
conclusions as to what they mean.  This implies that there are problems with 
the RFCs.  If people can read the same words and assign different meanings to 
them, then, yes, there is a terminology problem.

And this means that if the objective is multiple, independent, interoperable 
implementations, then yes,  terminology is an impediment to implementing 
diffserv.  Not that there aren't people in various places furiously coding 
away...  just that what they come up with in the end is probably not going to 
be interoperable if in fact it is truly independent.  IMHO, it is far better 
to be discussing the meanings of things on the list with a view toward 
improving clarity than having to do so in real time at some future bake-off.

I don't quite see the point to precluding ANY avenue toward improving the 
usability of the documents.  I'd rather that we deal with this as an 
identified problem of clarity in the documents and reach a consensus as to how 
to fix it.  If we can do so by fixing existing definitions, so much the 
better.  If we discover that we have two very different concepts covered by 
the same overloaded term, and find we need a new term to cover one of them, so 
be it.

---

From: "Scott W Brim" <[email-masked]>
Date: Fri, 08 Oct 1999 11:26:06 -0400

At 20:46 10/07/1999 -0700, Kathleen Nichols wrote:
>Is lack of terminology

Exactly.

Lack of agreed-on terminology does confuse people when we explain it, though.

...Scott

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 08 Oct 1999 09:13:27 -0700

> Lack of agreed-on terminology does confuse people when we explain it, though.

Good point. But the answer is to clarify exisiting terminology
and that is not isomorphic to adding more terms.

	Kathie

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 08 Oct 1999 09:26:55 -0700

Dan Grossman wrote:
...  IMHO, it is far better
> the same overloaded term, and find we need a new term to cover one of them, so

I agree with your first statement I've included above. I'm not
convinced we've exhausted the "clarification" route. 

Further, since the discussion seems to center on the AF RFC, it seems
perhaps premature to develop a new *general* term to cover
one PHB Group, maybe there just needs to be a clarification in
the terminology draft of the use of the term PHB Group with
respect to the AF PHBs.

	Kathie

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 08 Oct 1999 12:46:24 -0400

Dan Grossman wrote:
	[..]
> In that case, what is AF?

AF is a PHB Group.   AF1x is AF.  Per RFC 2597, so are AF2x, AF3x, and
AF4x.

>  Is it a family of groups, as I suggested in the
> draft?

Where I'm a little concerned (confused) is to why we need a recursive
group terminology to call the four AF classes a Group Family (or
similar). Begs the definition of 'Family'. Since there's
no ordering/behavioral constraint _between_ the four AF classes
I dont think 'family' can neatly be categorized as having a simple
recursive relationship to the definition of 'group'.

>  Or are you suggesting that we redraft RFC 2597 to define one PHB

I looked back over the thread, and the only potential for confusion
I saw was Bert's question about what occurs if a node remarks from
one instance of AF to another. Personally, I agree with Brian's
observation that its outside terminology at that point. I dont think
we need to invent a specific 'family' concept in order to explain
the consequences of remarking traffic from one independent class of
service to another.

For example (bear with me for a moment) some might decide to
remark AF2x to EF at a boundary. Ignoring the question of
_why_ one would even do this, we dont need a 'family' to encompass
EF and AF2x in order to explain that re-ordering within microflows
ought to be avoided. I think the same applies to understanding
the meaning of PHB Group vis-a-vis remarking from one AF class
to another.

cheers,
gja

---

From: Dan Grossman <[email-masked]>
Date: Fri, 08 Oct 1999 14:36:12 -0400

> convinced we've exhausted the "clarification" route. 
I agree.  I have no preference as to how we fix the problem, as long as we 
come up with something that is clear and internally and externally consistent.

> the terminology draft of the use of the term PHB Group with
I'm assuming that DiffServ did not create this whole framework in order to 
support exactly two PHB (groups?  group families?) plus the legacy class 
selectors, but rather in the expectation that in future there will be 
additional ones.  AF seems to be an existence proof that we  have groupings of 
PHB groups that are similar but do not have common constraints.  It seems 
reasonable to expect that we might have others.  So I suggest we treat it as a 
general problem for which we have one known example.

p.s.,
In writing the above, I noticed two things.  First of all, I couldn't discuss 
the problem of the taxonomy it without having some words to use -- "PHB 
(groups?  group families?)".  Second, the recursion idea starts to look quite 
attractive in this context, since it applies to EF (a PHB, which by the 
current definition is a degenerate case of a PHB group) and AF (which is... 
whatever we determine it is).

---

From: Dan Grossman <[email-masked]>
Date: Fri, 08 Oct 1999 15:19:11 -0400

> AF is a PHB Group.   AF1x is AF.  Per RFC 2597, so are AF2x, AF3x, and
Sorry, I'm having trouble parsing "AF1x is AF".

One way to parse it is "AF1x is AF is a PHB group;  therefore, AF1x is a PHB 
group.  (I know that's not what you meant)

Another way to parse it is "AF1x is **missing operator** AF".  Do you mean 
that AF1x is "an instance of" AF?  

> recursive relationship to the definition of 'group'.
The recursion concept would make the family concept unnecessary.

> the consequences of remarking traffic from one independent class of

No, the problem is not Bert's remarking problem  -- that's a separate issue 
having to do with an abiguity in the traffic conditioner text.  The problem 
was actually raised by Juha some time back, and is documented in the draft.  
When I agreed to take on the I-D, one of the things I was asked to include was 
this issue.  Since there was no conclusion to the discussion --- and Juha 
didn't have any suggestions -- I drafted the PHB group families text as a 
strawman.

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 08 Oct 1999 15:28:48 -0400

> that AF1x is "an instance of" AF?

Yes. If someone asked me for "Assured Forwarding" service,
I could deliver it using AF1x across my network. So yes, "AF1x
is an instance of AF" would be more wordy, but the same thing.

> The recursion concept would make the family concept unnecessary.

My thought is that recursion doesn't work here. The behavior constraint
that relates AFx1, AFx2, and AFx3 is not the same one that relates
AF1x, AF2x, AF3x, and AF4x. Indeed, in the latter example there are
no constraints binding each 'instance of AF' to the others.

At this point I haven't got an answer, just wanted to clarify
my confusion over the question.

cheers,
gja

---

From: Dan Grossman <[email-masked]>
Date: Fri, 08 Oct 1999 15:57:54 -0400

> no constraints binding each 'instance of AF' to the others.
Thus, my proposal to relax 'common constraint' to 'isomorphism or common 
constraint'.  I agree that it wouldn't work with the present definition of PHB 
group.

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 08 Oct 1999 16:58:28 -0700

Dan Grossman wrote:
...
> general problem for which we have one known example.

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. 

Maybe it would be better for us to say that if there isn't any
common constraint between something, it shouldn't be a PHB Group?

	Kathie

---

From: Dan Grossman <[email-masked]>
Date: Mon, 11 Oct 1999 11:28:14 -0400

> "class" relationship in AF is ill-defined.
I think that's been clear for a while.

> In fact, this was
You don't mean that we should reconsider the decision to make the AF classes 
independent (I hope!)?

> common constraint between something, it shouldn't be a PHB Group?
That works.  The problem is, if we say that, then we will have to have another 
name for a set of similar PHB Groups that don't have a common constraint.  The 
draft attempts to create such a name. There was considerable opposition to 
that.

Perhaps this discussion has clarified the need for a new name?  Or are you 
suggesting that there may be a way to finesse AF (and future PHB 'thingys') to 
avoid having to refer to the similarity issue?

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 15 Oct 1999 14:43:43 +0300 (EEST)

> and tweak the definition of PHB Group accordingly. 

that would be fine with me.  i would not like to introduce yet another
term, i.e., phb group family.  so we can have phb groups that contain
other phb (sub)groups as members.

-- juha

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 15 Oct 1999 13:10:16 +0100 (BST)

> other phb (sub)groups as members.

Can a PHB group contain itself?
What happens if it does (directly or indirectly) through some error
or other?

A new PHB group family term at least helps prevents such loopiness,
and keeps things simple.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 16 Oct 1999 07:33:13 +0300 (EEST)

> A new PHB group family term at least helps prevents such loopiness,

how about if you have a phb group that has a three layer hierarchy, what
do you call the top level entity that consists of phb families?  so i
still like the idea of just having a hierarchy of phb groups.  the
things on the bottom of the tree could be called leaf phb groups.

-- juha

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 16 Oct 1999 05:54:39 +0100 (BST)

On Sat, 16 Oct 1999, Juha Heinanen wrote:

> do you call the top level entity that consists of phb families? 

The phb mob.

L.

are that many levels actually useful?