Subject: RE: [Ieprep] policy & labels

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 11:54:12 -0400

OK, I am going to be as simplistic as possible.

At the root of it, there need to be enough different labels that there is at
least a one-to-one mapping (could be many-to-one) from label to policy in
any given environment. 

If we want to have N different policies in a given environment, there must
be at least N different labels. An "environment" could be the whole
Internet, a particular subnetwork, or even a single router or gateway.

 This does not prevent a single label being associated with several
different policies in several different environments, though this should
generally be discouraged (for human comprehension reasons as much as
anything), except when the policies are very closely related. 

So, we need to have figured out in advance how many different policies we
will want in effect in a given environment.  Then we can figure out what
parameters are needed to create those labels.

(I am using "labels" in a broad sense.  If you have two parameters, each of
which can have 3 values, I would call that 9 labels.)

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 12:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Ieprep] policy & labels

there has been a recurring discussion about policy and labels -- people
for it, against it, confused by its separation, etc.  so it may be helpful
to have a separate discussion about the subject so that we can put it to 
rest andmove on to other stuff.

so, to start the fun, lets see how the following statement grabs folks...

-------------------------------

  The process of distinguishing traffic by means of a label can be
  accomplished in one of two ways.  The first is with a single label, 
  which acts as a binary on/off indicator distinguishing a set of
  data/flows from all other data/flows.  The characteristics (e.g., drop 
  precedence) that one may apply to this single labeled traffic versus 
  all other traffic is what is refered to as policy.  In addition, the 
  type of traffic (VoIP, ftp, http, etc.) associated with a label is a
  separate issue and defined via a policy.  
 
  Another way of distinguishing traffic is to use a set of *related* 
  labels. This set may convey various measures of a characteristic that 
  is internal to that set.  An example of this case is the Assured 
  Forwarding (AF) Per-Hop-Behavior (PHB) group of code points defined in
  RFC2597.  Within each AF class, M different levels of drop level 
  precedence may be assigned to an IP packet.  Note that the exact level 
  of drop precendence is not defined for any level.  Further, different 
  classes, and different PHBs, are unrelated.
 
  From this example, we can make a more general statement and say that 
  one may choose to attribute a type of characteristic to a related set 
  of labels.  However, the characteristics between one set of defined 
  labels to all other sets of unrelated labels is separate and not part 
  of the defined label set.  

-------------------------------

Does the above seem reasonable statement to make?  Does it need to be
more precise, more constrained, less constrained? 

let thine arrows fly forth :-)

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Oct 2002 11:58:29 -0400

Since in our context, the label supply is infinite, I'm not sure we need 
to worry about this particular issue. There are more labels than IPv6 
addresses, the Internet's definition of infinite :-)

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 10 Oct 2002 09:50:23 -0700

Before we all get too carried away, at least some consciousness of prior art 
is worthwhile.

A decade ago, Alf Weaver (UVa) was doing simulation research with FDDI which 
has 8 priority levels.  I can't be terribly specific about why (discharged 
grey matter RAM cells), but Alf found that any more than 4 levels of priority 
and things lost definition -- you passed the point of diminishing returns.  
Something like "if you have a mixed load of frames of all 8 priority levels, 
the first three get treated properly; the rest all tumble into a common".  
	IEEE 802.5 token rings also have 4 levels of priority; to my knowledge never 
ever used.  The Mil version of X.25 had four as well, mirroring the military 
messaging system (see below).  Carefully written into the MilStd; probably 
never used. 
 	(Priority labeling in LANs is a rightfully neglected area -- we've been 
killing the problem by throwing bandwidth at it.  But this observation is not 
true across complex internets or radio-WANs).
	XTP was an also-ran transport protocol  (again about a decade old) that had 
the attribute of reliable multicast (which TCP can't do).  XTP had a whole 
byte set aside for priority indicators.  Never matured enough that anybody 
used the priority features, so what this 'DSCP' meant was never defined.  But 
everybody that worked on the protocol agreed that a single byte was far more 
than we'd actually need.  
	The list can get longer, but the trend appears to be that anything over four 
levels is overkill ... even if those priority labels are actually used.  

The DS byte in IPv4 used to be known as the Type of Service byte (before we 
actually started using it) and had the whole 8 bits theoretically available.  
2**8 was clearly more than anybody was going to need ... things slimmed down 
as differential services became a real cross-ISP implementation issue.

The military's messaging system has had four levels of precedence (five if 
you look in the really find print in the comms manual).  Flash (z), immediate 
(o), priority (p) and routine (r) - the fifth was known as Flash Override (y) 
and available only to JCS -- the switching system was at least in theory 
supposed to know that and react accordingly.  These precedence indicators 
were equally available (excepting y) to users and network managers (aka 
radiomen) for both substantive and net management traffic.  
	The military's messaging system has run at capacity for years -- there's a 
Parkinson's Law effect in operation here.  The shortcomings in the system 
never have seemed to be rooted in a dearth of precedence indicators -- there 
are enough, but rather in precedence creep where everybody is cheating to 
keep up with the other cheaters.  (The other form of cheating was to use the 
precedence indicator as an attention-getter rather than a QoS needs 
indicator).
	Reality check: this formal messaging system has been in place for 40 years 
-- at least since 1968 when Autodin debuted.  There is still a lot of 
operational infrastructure that uses it, but it's now rapidly becoming 
obsolete.  The few times I actually see formal message traffic these days, 
it's wrapped up in an e-mail envelope so the precedence indicator becomes 
part of the body of a composite message and is invisible to the e-mail 
handling system or it's underlying plumbing.  

Any help?

On Thursday 10 October 2002 08:54 am, Gunn, Janet wrote:
> At the root of it, there need to be enough different labels that there is
> at least a one-to-one mapping (could be many-to-one) from label to policy
> in any given environment.

-- 
b

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Oct 2002 07:28:46 -0400

I'm confused by your message. We're not debating the merits of the 
number of priority levels nor "messaging", but rather importing existing 
voice call levels into a VoIP environment. Thus, the military ('you') 
and ITU (Q.735) provide the number of levels, not the IETF.

I tend to agree that more than three levels of priority is generally of 
dubious merit, but that's beyond our bailiwick. (There will be LAN 
priority for wireless LANs, btw: 802.11e).