Subject: QoS replacement text for Links draft

From: Dan Grossman <[email-masked]>
Date: Tue, 05 Sep 2000 10:13:30 -0400

Per my assignment from Pittsburgh, here is a first pass at QoS text.  It might 
stand a bit more polishing, but it's probably time to see what the rest of the 
group has to say about it.

Dan  

Existing text:
Quality of Service, Fairness vs Performance, Congestion signalling

   The IP header includes a 1-byte TOS (type of service) field. This
   field is broken into two parts: a 3-bit precedence field that
   indicates the relative importance of this packet compared to others,
   and a 4-bit "qualitative tradeoff" field to indicate if low delay,
   high throughput, high reliability or low cost is qualitatively more
   important for this particular packet. One TOS bit is reserved.

   Although the TOS field has not been heavily used in the past, it is
   becoming increasingly important to the provision of Quality of
   Service (QoS) features necessary for services such as Voice over IP
   (VoIP).

   Many subnetwork designers are faced with inherent tradeoffs between
   delay, throughput, reliability and cost. When this is the case, the
   subnetwork should provide an interface to IP that allows the IP TOS
   bits to control these tradeoffs on a per-packet basis. For example,
   when a subnetwork implements a hop-by-hop retransmission scheme to
   improve reliability, this invariably comes at the cost of increased
   delay variance. An IP packet presented to this subnetwork with the
   "low delay" bit set in its TOS field should disable hop-by-hop
   retransmission within the subnetwork for that particular packet.
   Another example is link forward error correction, which can increase
   reliability at the expense of throughput without significantly
   affecting delay.

----------------------
New text
Quality-of-Service (QoS) Considerations
QoS is best understood in terms of a layered communications architecture.  It 
is most broadly defined as that set of parameters and attributes concerning an 
instance of communication that a service provider offers a service user, from 
the perspective of the service user.  In this context:
.in +5
-- a "service provider" (in lower case) is not the same thing as a "network 
operator" or ISP. Rather, it is the entities (or concatenation of entities) at 
a layer, combined with the services which support them, which offer service to 
an entity (the service user) at the next higher layer.  

-- Parameters are objectives for values of attributes which are offered (e.g., 
during connection/flow establishment or as installed by policy management) to 
the service users by the service provider. 

-- Attributes are actual values of some measurable characteristic, resulting 
from a set of measurements over a number of interactions between the service 
users and the service provider.  
.in -5

Each of the QoS parameters and attributes offered by a service provider can be 
broadly characterized as relating to one of performance, availability, 
security and cost.  Of these categories,  parameters and attributes in the 
performance category are the best understood, to the extent that most people 
equate QoS with the performance parameters and attributes. 

The entities at a layer cooperate with each other through the protocol(s) that 
operate(s) between them to maintain, enhance or degrade QoS attributes of the 
service offered to them by the lower layers, and to map these to the QoS 
attributes offered to the next higher layer.  This often implies some 
tradeoffs within a layer, selecting mechanisms that enhance one attribute at 
the expense of another.  For example, a link layer may enhance packet loss 
performance at the expense of delay jitter performance by operating a 
retransmission mechanism, or it may enhance packet loss performance at the 
expense of fixed delay performance by operating a FEC mechanism.  The 
performance that results from the selected mechanism is mapped to the service 
offered by the link layer to the next higher layer (i.e., the IP layer).

QoS parameters and attributes are quantitative and measureable.  They relate 
to the abstract service offered by the service provider to the service user, 
rather than the mechanisms used within the service provider:  for example, 
"100 mS fixed delay" is a QoS parameter, while "FEC ON" is not.

Relative priority is often misunderstood to be a QoS parameter.  It is not.  
There can be no measurable attribute associated with relative priority.  The 
service user has no way to verify that it has received priority, or to assess 
the effect of priority on its own performance relative to that of other 
service users.   Relative priorities alone do not offer any kind of assurance 
that any particular performance objective will be met for higher priority 
users. Particularly when used with greedy sources and TCP, it can provide 
excessively good performance to high priority users and excessivly poor 
performance to low priority users.  Priorities are also difficult to manage.  
However, priorities can be used in  mechanisms like schedulers and contention 
resolution schemes that are components of systems which do offer QoS 
guarantees.     

Objective values of QoS attributes are expressed as a QoS parameter set.  QoS 
parameters may be subject to multiparty negotiation between the service users 
and the service provider, or they may be subject to policy set by the service 
provider.  Negotiation, if any, is performed by a control protocol, such as 
Q.2931 (at the subnet layer when the subnet is an ATM network) or RSVP (at the 
IP layer).   Sometimes, sets of particular QoS parameter values are 
standardized as a profile or class.  This approach is inflexibile, often 
unscalable, usually creates contentiousness in standards committees, and is 
difficult to administer.  Negotiation of individual parameters based on the 
capabilities of the service provider is preferable.

Support for QoS guarantees in the Internet is not yet mature.  However, it is 
generally recognized that such guarantees are needed to support real-time 
multimedia, toll quality telephony and other performance critical 
applications. There are presently two architectural approaches to providing 
QoS support in the Internet.

.in +5
IP Integrated Services (Intserv) [RFC1633] provides fine-grained service 
guarantees to individual flows.  Flows are identified by a flow specification 
(flowspec), which creates a stateful association between individual packets by 
matching fields in the packet header.  Bandwidth is reserved for the flow, and 
appropriate traffic conditioning and scheduling is installed in routers along 
the path.  The ReSerVation Protocol (RSVP) [RFC2205, RFC2210] usually, but not 
necessarily, is used to install flows.  Intserv defines two services, in 
addition to the Default (best effort) service.  
.in +5

-- Guaranteed Service (GS) [RFC 2212] offers hard upper bounds on delay to 
flows that conform to a traffic specification (TSpec).  It uses a fluid flow 
model to relate the TSpec and reserved bandwidth (RSpec) to variable delay.  
Non-conforming packets are forwarded on a best-effort basis.

-- Controlled Load Service (CLS) [RFC2211] offers delay and packet loss 
equivalent to that of an unloaded network to flows that conform to a TSpec, 
but no hard bounds. Non-conforming packets are forwarded on a best-effort 
basis.
.in -5

Intserv requires installation of state information in each participating 
routers, and absent this state in every router along the path, performance 
guarantees cannot be ensured.  This, along with RSVP processing and the need 
for usage-based accounting is believed to lead to scalability problems, 
particularly in the core of the Internet. [RFC2208]

IP Differentiated Services (Diffserv) [RFC2475] provides at "toolkit" that can 
be used to offer coarse-grained controls on aggregated flows.  Diffserv in 
itself does NOT provide services or QoS guarantees, but can be used to 
construct services with QoS guarantees across a Differv domain.  It attempts 
to address the scaling issues associated with Intserv by requiring state 
awareness only in the edge of a Diffserv domain.  At the edge, packets are 
classified into flows, and the flows are conditioned (marked, policed or 
shaped) to a traffic conditioning specification (TCS).  A Diffserv Codepoint 
(DSCP), which identifies a per-hop behavior (PHB) is set in each packet 
header.  The DSCP is carried in the DS-field, which subsumes six bits of the 
former TOS byte of the IP header [RFC2474].   The PHB is the forwarding 
behavior which is to be applied to the packet in each node in the Diffserv 
domain. Although there is a "recommended" DSCP associated with each PHB, the  
mappings from DSCPs to PHBs are defined by the DS-domain.  In fact, there can 
be several DSCPs associated with the same PHB.  Diffserv presently defines 
three PHB groups.  

.in +5 
The class selector PHB [RFC2474] subsumes the IP precedence semantics of the 
former TOS byte. It offers relative forwarding priorities.   

The Expedited Forwarding (EF) PHB [RFC2598] gurantees that packets will have a 
well-defined minimum departure rate which, if not exceeded, ensures that the 
associated queues are short or empty.  EF is intended to support services that 
offer tightly bounded loss, delay and delay jitter.  

The Assured Forwarding (AF) PHB group [RFC2597] offers different levels of 
forwarding assurances for packets belonging to an aggregated flow.  Each AF 
group is independently allocated forwarding resources.  Packets are marked 
with one of three drop precedences, such that those with the highest drop 
precedence are dropped with lower probability than those marked with the 
lowest drop precedence.  DSCPs are recommended for four independent AF groups, 
although a DS domain can have more or fewer AF groups.  

.in -5
The scope, field of application and correct use of Diffserv has been widely 
misunderstood.  Diffserv was intended as a set of tools to allow ISPs to offer 
service level agreements to aggregates of customer traffic.  It was not 
intended to allow individual flows to request and receive QoS guarantees.  It 
does not, in itself, offer any particular QoS guarantees.    There are no 
intrisic guarantees associated with marking a packet with a DSCP.  Any QoS 
guarantees are subject of a service offered by an ISP.  They underwritten by 
the use of classification, conditioning and scheduling at the edge of the 
Diffserv domain, traffic engineering and bandwidth management as well at the 
PHB selected by the DSCP.  Ongoing work in the IETF is addressing ways to 
support Intserv with Diffserv;  however, the Diffserv domain must be correctly 
engineered to support this.  Similarly, there is ongoing work to create a set 
of Per-domain Behaviors (PDBs), which define the services offered by a 
Diffserv domain;  note that these are NOT end-to-end services.

.in -5
Support for QoS guarantees at the IP layer requires the correct operation of a 
set of cooperating mechanisms.  These may include bandwidth reservation and 
admission control, policy management, routing, traffic classification, traffic 
conditioning (marking, policing and/or shaping), selective discard, queueing 
and scheduling.  Note that some of these mechanisms require per-flow (or 
per-aggregate) state.   Support for QoS in subnets may require similar 
mechanisms, especially when these subnets are general topology subnets (e.g., 
ATM, frame relay or MPLS) or shared media subnets.  In some cases, subnet 
layer and IP layer mechanisms may be combined or coordinated within the 
devices at the edge of the subnet.  More sophisticated mechanisms may allow 
more efficient use of lower layer resources and/or more fine grained QoS 
guarantees, at the expense of complexity.

The following capabilities are desirable at the subnet layer (although some 
may be trivial or moot if the subnet is a simple point-to-point link):
.in +5
- ability to reserve bandwidth for a connection or flow and schedule packets 
accordingly
- bandwidth reservations should be based on a one- or two- token bucket model, 
depending on whether the service is intended to support constant rate or 
bursty traffic
- if a connection or flow does not use its reserved bandwidth at a given time, 
the unused bandwidth should be able to be used by other flows.
- packets in excess of a connection or flow's  agreed rate should be able to 
be forwarded as best effort or discarded, depending on the service offered by 
the subnet to the IP layer.
- if a subnet contains error control mechanisms (retransmission and/or FEC), 
it should be possible for the IP layer to trade errors and/or packet loss for 
fixed or variable delay.  It should also be able to either discard or deliver 
to the IP layer any packets received with detected but uncorrected errors.  
These capabilities at the subnet/IP layer service boundary translate inside 
the subnet layer to selection of more or less error control and/or to 
selection of particular error control mechanisms.
- the subnet layer should know, and be able to inform the IP layer, how much 
fixed delay and delay jitter it offers for a flow or connection.  If the 
Intserv model is used, the delay jitter component may best be expresed in 
terms of the TSpec/RSpec model described in [RFC2212].
- although relative priority is not a QoS parameter, support of the Diffserv 
class selectors [RFC2474] does suggest that the subnet might also consider 
mechanisms that support priorities. 
- what else?
.in -5

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Sep 2000 13:02:32 -0700

> group has to say about it.
...
...
> service users.  

This seems overstated. First, anything that differentiates service 
can be a QoS parameter; it need not be quantitative or measurable.
Just because it is not objectively  verifiable does not prohibit 
its use; it may be difficult to charge or confirm, but it 
does allow differentiated service.

While I agree that it may be difficult to assess in terms of 
others' performance, its usefulness may be intra-user, e.g., 
in differentiating the streams of a single customer.

> Sometimes, sets of particular QoS parameter values are
> difficult to administer.

The second sentence here appears to be a 'position'; I feel PILC
documents should avoid such positions where possible. It would be
better to discuss technical issues only.

Joe

---

From: Dan Grossman <[email-masked]>
Date: Tue, 05 Sep 2000 17:48:10 -0400

> can be a QoS parameter; it need not be quantitative or measurable.

I think we have a fundamental point of disagreement.  

I think of QoS from the perspective of the service user, and ultimately the 
application and the end user.  QoS attempts to get to the issue of how 
satisfied the end user application are.  Shenker, Clark et al have treated it  
in terms of microeconomic utility, and thus "satisfied" means "utility is 
maximized".  If you can't measure it, then you can't evaluate how satisfied 
the end user is.  There's no accountability (which is an important issue in 
anything other than a monthly flat-rate charging regime).  

> Just because it is not objectively  verifiable does not prohibit
I didn't say to prohibit it's use... we can't do that... but we should make it 
clear that priority is not QoS.
 
> does allow differentiated service.
Which is not the same thing as QoS.  Maybe I should create some words to this 
effect.
> in differentiating the streams of a single customer.
I assume you're talking about N>1 independent flows having the same source 
host and the same destination host(s).  It sounds like you'd like to isolate 
these flows from all other flows and allow some to have priority over the 
others.  Why is this preferable to giving each flow independent performance 
objectives, such that the flows that you would give higher priority get more 
bandwidth and lower loss probability?  Also, is this a sufficiently important 
case to create special mechanisms to allow related flows to be identified, 
isolated and prioritized throughout the Internet?
> better to discuss technical issues only.
Seems that we've taken some pretty strong positions elsewhere in this draft, 
in PEP, in Error and elsewhere.  These are all technical concerns. Even, 
arguably, the problem of contentiousness in standards committees:  I've been 
in these discussions...  not a pretty sight.  What happens is that in order to 
create these profiles (QoS classes or the like), the committee has to pick 
some end-to-end objective numbers and then allocate the impairments to various 
parts of the network.  Everybody want's the lion's share of the allocation to 
play with in their network, the application folks want no impairment, the geo 
satellite folks demand that no QoS class have a guaranteed delay less than 300 
mS, which starts a competitive battle with terrestrial folks, the standard 
comes out with lots of caveats and reservations and 'provisional 
assignments'... and, in the end, the actual service attributes depend on 
network toplology anyway.   To my knowledge, IETF has wisely never permitted 
itself to get involved in this particular kind of bun fight.  ITU-T and ETSI 
had a need to do so before the advent of modern QoS routing protocols and 
extensible control protocols. They would now be wise to get out of that 
business.

Dan

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Sep 2000 14:55:42 -0700

> clear that priority is not QoS.

I don't think it is our job to define QoS. If there is a document
you can point to that clearly asserts that, esp. in the context
of the IETF, that would be great. But PILC should not make
these assertions of our own, but rather be as inclusive as possible.

> Which is not the same thing as QoS.  Maybe I should create some words to this

If you have a reference to back it up, fine. If not, generality 
would be preferable, as above.

> others.  

Yes.

> Why is this preferable to giving each flow independent performance
> bandwidth and lower loss probability? 

Because it may exactly be relative performance that I require.
Stating these in terms of absolute requirements is overconstraining.

> Also, is this a sufficiently important

As much as creating absolute guarantees across the internet is (i.e.,
yes).

...
> extensible control protocols. They would now be wise to get out of that

It may be sufficient to express the problems without assessing blame,
i.e.,: "This approach is difficult to coordinate." I would see it as
being inherently scalable (as the number of flows increases, contrasted
to RSVP) and easy to administer, at the expense of flexibility.

Joe

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 05 Sep 2000 15:47:24 -0700

Dan Grossman wrote:
	[..]
>    important for this particular packet. One TOS bit is reserved.

I believe the full octet is properly referred to as the "ToS byte"
or "ToS octet", with the subsidiary fields being the "Precedence bits"
and "ToS bits" (or "Precedence field" and "ToS field") respectively.

Fwiw, it seems rather torturous to introduce the four ToS bits as
'..a 4-bit "qualitative tradeoff" field...'

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Dan Grossman <[email-masked]>
Date: Wed, 06 Sep 2000 11:06:24 -0400

> I don't think it is our job to define QoS.

This is a tutorial.  Defining QoS for uninformed readers is well within its 
scope, in much the same way that we teach about the end-to-end principle and 
how TCP works.

> If there is a document
> of the IETF, that would be great.

Unfortunately, IETF has tended to assume that those who work in this area read 
the research literature on the subject.   There's nothing new here.  It's well 
documented in the literature.

> But PILC should not make

What do you mean by "generality"?

> Because it may exactly be relative performance that I require.

Why would an application want two streams with some unspecified 
differentiation between them?  

> Stating these in terms of absolute requirements is overconstraining.

Well, we need some constraints.

> As much as creating absolute guarantees across the internet is (i.e.,

Except that we have absolute guarantees in Intserv and (at least arguably) in 
Diffserv (draft-ietf-diffserv-pdb-def-00.txt).  And we have absolute 
guarantees in ATM.  And at least a hint of absolute guarantees in MPLS.  We 
don't have any architecture or mechanism that allows small groups of flows to 
be given resources and priority to be assigned within those groups on a 
fine-grained basis end-to-end.

> i.e.,: "This approach is difficult to coordinate."
Nobody is assessing blame.  It's a case where an architectural decision has 
bad consequences. One of these consequences is that it is guaranteed to create 
conflicts in standards committees. 

> I would see it as
> to RSVP)
It is inherently topologically inscalable.  The objective values of the 
parameters has to increase as the diameter of the network and/or the 
composition of the worst-case characteristics of the links.  As a result, the 
guarantees offered become more and more diluted.  And the applications don't 
have a clue as to what kind of performance to expect, absent knowledge of 
network topology, since the difference between the performance of the best 
path and the performance of the worst path is so large.

> and easy to administer,
No... it pushes to the administrative realm concerns that are best handled by 
control protocols and routing.   What happens is that network design and 
engineering becomes complicated by the constraints of the QoS Classes.  In 
multi-provider environments, customer complaints of failure to achieve a fixed 
objective for a particular QoS class becomes a finger pointing contest between 
providers.  QoS classes lack economy of scope:  every time somebody creates an 
application with different needs, a new class has to be created and supporting 
machinery disseminated in the network.  
> at the expense of flexibility.
> 
Dan

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 6 Sep 2000 16:29:34 +0100 (BST)

> scope, in much the same way that we teach about the end-to-end principle and 

Since really informed readers can't decide on what QoS is either (see
Crowcroft's post today to the main IETF discussion list) I frankly
don't see the point of doing so. Pointers to further reading,
fine. But prescriptive text?

> Diffserv (draft-ietf-diffserv-pdb-def-00.txt).

'absolute' is meaningless outside a single administrative
domain. Downstream degradation in diffserv, etc.

L.

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

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 06 Sep 2000 08:30:39 -0700

Tired, sleepy, stupid - you name it, I'm sure that's why
I commented on the old text rather than the new text Dan's
proposing. Duh :(

cheers,
gja

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Sep 2000 09:09:47 -0700

> scope, in much the same way that we teach about the end-to-end principle and

Agreed - I was asserting that it not our job to _uniquely_ define QoS.
If there is a reference for the definition given, that's fine. New
definitions should be avoided (esp. in a tutorial).
 
> documented in the literature.
             ^^^^^^^^^^^^^^^^^

OK - so a non-IETF reference is fine.

> What do you mean by "generality"?

Your definition of QoS precludes relative services. I would prefer a
more general definition, e.g., one that allows relative service.

> differentiation between them?

I didn't say that it was unspecified, only that it was relative. E.g.,
that queuing loss on stream A should be twice that of stream B, e.g.

> fine-grained basis end-to-end.

Sure we do - that's what happens anytime muxing occurs within a flow,
e.g., BXXP.

> conflicts in standards committees.

The architectural decision requires standards committees agree. Any such
requirement generates conflicts in such committees. Does that imply that
any standards-based solution is architecturally bad? What properties
about this solution _uniquely_ make it more difficult to standardize
than, say, _any_ system that requires protocol agreement?

> It is inherently topologically inscalable. 

Ahh - then perhaps that could be indicated. As a few others have pointed
out, "scale" requires indicating what parameter doesn't scale. 

> control protocols and routing.

That sounds like religion, not architecture.

> What happens is that network design and
> providers. 

That is an organizational failure, not necessarily a protocol failure.

> QoS classes lack economy of scope:  every time somebody creates an

The same is true for parameters - say you create a QoS system that
specifies delay, jitter, rate, and loss. Then someone comes along and
cares about some other parameter, e.g., variance of the jitter. The
system similarly has to be re-engineered.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Sep 2000 11:48:56 -0700

Dan Grossman wrote:
> Ok... see RFC1633:
>           It is true that simply giving higher priority to real-time
>            traffic would lead to adequate real-time service at some
>            times and under some conditions.  But priority is an
>            implementation mechanism, not a service model.  If we define
>            the service by means of a specific mechanism, we may not get
>            the exact features we want.  In the case of simple priority,
>            the issue is that as soon as there are too many real-time
>            streams competing for the higher priority, every stream is
>            degraded.  Restricting our service to this single failure
>            mode is unacceptable.  In some cases, users will demand that
>            some streams succeed while some new requests receive a "busy
>            signal".
> We could reference RFC1633 here.

If that is the limit of what you are suggesting that link layers
support.

> Are we talking about drop precedence, as in AFxy and CLP (in ATM) or are we
> talking about scheduling priority?

Scheduling priority is more likely to be intra-stream. Making drop
precedence intrastream is hard, excepting intra-packet relationships
(e.g., EPD).

> It forces the committee to make decisions that advantage or disadvantage some
> service
> providers relative to others, or service providers relative to equipment
> manufacturers.  A different architecture would simply obviate these issues.

That is not a property of the architure - it is a property of any finite
set of decisions.

> I'll agree with that.
> Ad homenem attack.
> The point is that dynamic, real-time and short-term predictive controls built
> into protocols and distributed algorithms are more granular (read efficient)
> and require less human intervention (read: cost and opportunity for human
> error) than administration, albeit at a cost of complexity and protocol
> overhead.

Better stated. Can a variant of that be included?

> It is an architectural failure.

State the architectural requirement then, as such. I.e., you want a
distributed, objective system which allows independent assessment. It
would be much better than talking about the undesireable side effects
which are believed to be the result of alternate architectures, e.g.,
organizational confusion, etc.

Joe

---

From: Dan Grossman <[email-masked]>
Date: Thu, 07 Sep 2000 14:36:23 -0400

> > documented in the literature.
I'm having trouble finding a comprehensive reference.  By "in the literature", 
I meant a significant body  of work over the past decade or so.  I'd be 
grateful if somebody could point out a (or a few) comprehensive papers that 
reflect the proposed text.

Ok... see RFC1633:

I'll agree with that.
Ad homenem attack.

> system similarly has to be re-engineered.
Far more rarely, if ever. By way of drawing on others' experiences, I'm aware 
of at least three occasions where ITU-T has needed to define additional QoS 
classes for ATM since the initial publication of I.356 (sorry, don't remember 
details). Neither ITU-T nor ATM Forum have needed to add new QoS parameters.  
Also, the ATM Forum approach of individually negotiated QoS parameters, in 
conjunction with supporting machinery in PNNI is being adopted by network 
operators, including some who'd opposed it originally.

But this is off topic.  As was pointed out in Pittsburgh (by the retiring IAB 
chair and our A-D), IETF doesn't standardize performance objectives.

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 18 Sep 2000 19:42:24 +0100

Dan Grossman wrote:

> ....

Presume you're aware of :

Paul Fergusson and Geof Houston's Book:
QoS:Delivering QoS on the Internet and in Corporate Networks
Wiley.

Just wondered whether the discussion has drifted away from "best practice",
as accumulated over the past years, and into the (probably more interesting -
at least from my perspective) "research isues and current mode of thinking".
Please can we be clear which is being discussed in the QoS issues, I'm
beginning to have my vision blurred.

As someone once said about RSVP: developed =/= deployed.

Gorry

P.S.
I wonder if the old concept of ToS - with well known - yet vague -
classes could possibly prove be most beneficial from the **link** perspective.

------------------------------
http://www.erg.abdn.ac.uk/users/gorry