Subject: RE: [Ieprep] policy & labels

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 13:52:35 -0400

While they are all "labels", I think there are two qualitatively different
things- categories of traffic within a given policy (e.g., the priority
levels within MLPP), and the number of different policies (e.g., pre-emption
at call set up, queueing at call setup, per packet queueing discipline at
transit nodes)

-----Original Message-----
From: Rex Buddenberg [mailto:[email-masked]]
Sent: Thursday, October 10, 2002 12:50 PM
To: Gunn, Janet; 'Ken Carlberg'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] policy & labels

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

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

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Thu, 10 Oct 2002 11:44:55 -0700

Folks,

This is a very enlightening discussion so far.

I did get a bit concerned when it drifted toward having an infinite number of
labels since it may be useful if the labels could be mapped at the gateway to
the legacy PSTN where infinity within the protocol is not as popular. I agree
with the concept that based on prior experience there is likely not to be an
unlimited number of labels. Recent ITU-T contributions on the PSTN side were
looking at a half dozen values being defined with an octet for the field  thus
leaving 250 unassigned values.

It is my sense that not binding policy to the labels too early will allow a
greater richness in the policy agreements (SLA's) that can be reached between
the near end and far end for service, and the ability to more easily modify them
over time and as more entrants join in.