Subject: Another attempt at QoS text for Links draft

From: Dan Grossman <[email-masked]>
Date: Wed, 21 Feb 2001 17:03:19 -0500

Per my assignment in San Diego, here is another attempt at QoS text.  I've 
tried to reflect what we'd agreed.

.ti 0
Quality-of-Service (QoS) considerations

.in +5
It is generally recognized that specific service guarantees are needed to 
support real-time multimedia, toll quality telephony and other performance 
critical applications. The provision of such Quality of Service guarantees in 
the Internet is an active area of research and standardization. The IETF has 
not converged on a single service model, or set of services or on mechanisms 
which will both offer useful guarantees to applications and be scalable to be 
used in the Internet.  Indeed, the IETF does not have a single definition of 
Quality of Service.   [RFC2990] represents the present understanding of the 
challenges in architecting QoS for the Internet.

There are presently two architectural approaches to providing mechanisms for
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 to aggregates of 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 (see 
RFCxxxx<draft-ietf-diffserv-pdb-def-03.txt>).  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 PHBs.  

.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 

Ongoing work in the IETF is addressing ways to support Intserv with Diffserv.  
There is some belief (e.g. as expressed in [RFC 2990]) that such an approach 
will allow individual flows to receive service guarantees, while scaling to 
the global Internet.  

The QoS guarantees that are able to be offered by the IP layer are a product 
of two factors:

-- the concatenation of the QoS guarantees which are offered by the subnets 
along the path of a flow. This implies that a subnet may wish to offer 
multiple services (with different QoS guarantees) to the IP layer, which can 
then determine which flows use which subnet service.  Or, to put it another 
way, forwarding behavior in the subnet needs to be 'clued' by the forwarding 
behavior (service or PHB) at the IP layer. 

-- the operation of a set of cooperating mechanisms, such as bandwidth 
reservation and admission control, policy management, traffic classification, 
traffic conditioning (marking, policing and/or shaping), selective discard, 
queueing and scheduling.  Note that 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.  

Therefore, the following capabilities may be desirable at the subnet layer 
(although some might 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].
- support of the Diffserv class selectors [RFC2474] suggests that the subnet 
might consider mechanisms that support priorities. 

.in -5