Subject: Initial text on QoS

From: Phil Karn <[email-masked]>
Date: Fri, 10 Mar 2000 12:11:43 -0800

I've written this text to kick off the section on QoS, fairness vs performance,
and congestion signalling. --Phil

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.

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 10 Mar 2000 21:49:16 +0000 (GMT)

> important for this particular packet. One TOS bit is reserved.

Whoa. That all plays complete havoc with diffserv: 6-bit DSCP, and two
bits reserved. The TOS definitions as above aren't widely used, and
the diffserv architecture is effectively rewriting the field.

> (QoS) features necessary for services such as Voice over IP (VoIP).

Very true - but not in its form as a TOS field per se.

> packet.

IMO we *really* don't want to encourage link designers to look at some
DSCP bit and assume low delay based on the assigned value when it is
an artefact of numbering and has nothing to do with low delay;
designing a link to interact well with some overblown QoS framework
sinking in its own complexity is a whole new ball game, and imo is
probably outside the scope of this draft.

> Another example 

of improving link reliability - but this is somewhat orthogonal to the
QoS discussion above, yes? You're not suggesting varying FEC depending
on QoS settings, surely...

> is link forward error correction, which can

L.

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

---

From: Phil Karn <[email-masked]>
Date: Fri, 10 Mar 2000 14:20:22 -0800

>the diffserv architecture is effectively rewriting the field.

Okay, I wasn't aware of that, and I guess it's time to read up more on
diffserv. Care to contribute some text? (I've already submitted the draft,
but we can continue to edit the document for the next round).

>DSCP bit and assume low delay based on the assigned value when it is

What I wanted to say is that when a subnetwork designer is faced with a
design tradeoff between delay/reliability/throughput/cost, instead of
just picking an operating point he should provide "knobs" that IP can
diddle to make the tradeoffs on a per-packet basis.

>on QoS settings, surely...

Actually, yes. It makes quite a bit of sense in some environments,
particularly those using spread spectrum/CDMA. Varying the FEC code
rate and varying the power are closely related approaches. The
Qualcomm HDR system uses a constant channel symbol rate and
transmitter power and varies the modulation type and FEC code rate
(and the user throughput) as a function of signal-to-interference
ratio. Nothing says we couldn't bias those settings according to QoS
bits if that were useful.

Phil

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 10 Mar 2000 23:04:19 +0000 (GMT)

> but we can continue to edit the document for the next round).

okay. taking the general form of what you wrote...

The IP header includes a type-of-service field [RFC791]. This was not
widely used, and has been redefined as the 'codepoint', identifying a
set of specified delivery requirements, in the differentiated services
architecture [RFC2474]. This field is becoming increasingly important
to the provision of Quality of Service (QoS) features necessary for a
variety of services.

Before considering using any labelling in this field to improve link
performance, the subnetwork MUST be aware of the definition and use of
the field within the local network. It is the responsibility of the
local network to control the access to, and use of, this field.

Many subnetwork designers are faced with inherent tradeoffs between
reliability, delay, throughput, and cost. When this is the case, the
subnetwork should use the codepoint to map the locally-understood QoS
specifications to a set of tradeoff choices on a per-packet basis.

For example, a subnetwork might implement a hop-by-hop retransmission
scheme to improve reliability. An IP packet presented to this
subnetwork with a codepoint indicating a low reliability requirement,
via a high drop precedence setting, might not be subject to
retransmission. Packets marked for a low drop precedence requirement,
indicating preferential treatment, would be more likely to be held and
retransmitted if required.

L.

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 16 Mar 2000 21:17:33 +0100

catching up on old mails ....

Yes, I think the text you have written, Phil, is *really* a step in the 
right direction.

Basically, there are two different link layer design philosophies (this has 
been mentioned before on this list):
1. "one size fits all", i.e., one IP packet is just as good as the next.
2. something what we call "flow adaptive", i.e. distinguishing flow types 
at the link layer for the purpose of adapting link layer error control 
(ARQ, FEC, power control, spreading factor control, ...) to try to best 
meet a flow's application layer QoS requirements.

There are many benefits from the latter: (A) higher e2e performance, (B) 
less load on the Internet because link layer error recovery saves e2e 
retransmissions (C) more efficient utilization of radio resources like 
transmission power (battery), etc., etc.

For flow adaptive links to work, it would be soooo great to have the old 
TOS byte and its definitions - deployed. Unfortunaly this is not the case. 
Moreover, as already noted by Lloyd, diffserv has redefined the TOS byte 
and unfortunately does not allow the required e2e marking of, e.g., 
reliable (TCP, NFS, Reliable-Multicast, ...) vs. delay-senstive (RTP, ...) 
flows.

Maybe PILC can at some point request such CPs when diffserv work goes into 
a new round ...

However, I don't know whether such required e2e markings (that don't change 
once set by the source) are at all compatible with the diffserv model which 
allows that an IP packet's CP can change from domain to domain :-(

///Reiner

---

From: Dan Grossman <[email-masked]>
Date: Thu, 16 Mar 2000 16:01:03 -0500

Actually, I had some rather different things in mind for this section.  Sorry 
to be so late with this, I've been thinking about it for a while, and was 
having difficulty organizing my thoughts.  There's more to be said, but enough 
delay (so to speak! :-)

Dan

-----------------------------
The Internet has historically provided a single, undifferentiated best effort 
service. As applications have emerged that have specific quality-of-service 
(QoS) requirements, mechanisms have been, and continue to be developed to 
support them.

QoS, in the broadest sense, is defined as the set of service attributes that 
the provider of a service offers to the user of a service.  These service 
attributes can be categorized as relating to  performance, availability, 
security or cost.   However, this memo, like most treatments of QoS, considers 
only the set of performance attributes.  In the context of the IP and subnet 
layers, the performance attributes of most interest are:
  -- throughput
  -- delay
  -- delay jitter
  -- packet loss ratio
  -- errored packet rate
This memo does not attempt to define these.

In a layered architecture, a layer enhances and/or degrades the service 
provided to it by the layer below, so as to provide a service to the layer 
above.  Layers (especially the IP layer and below) contain impairments which 
degrade performance.  Examples of impairments include variable delays due to 
queueing and scheduling, congestive discard and errored discard.  Mechanisms 
in the layers can enhance one service attribute possibly at the expense of 
another.  For example, a retransmission mechanism in a subnet enhances 
(decreases) the packet loss ratio offered to the IP layer, at the expense of 
degrading (increasing) delay variation.  IP, however, does not contain such 
mechanisms, since strict application of the end-to-end principle relegates 
such functions to the TCP layer and above.

The Internet has historically provided an undifferentiated best effort service 
with no quantifiable service attributes. As applications have emerged that 
have specific performance requirements, mechanisms have been, and continue to 
be developed to support them.  
.in +5
-- IP Integrated Services (Intserv) [RFC1633]  provides finely granular QoS 
guarantees to individual flows.  It uses stateful mechanisms:  a 'soft' state 
is installed in routers along the path using a Reservation Protocol (RSVP) 
[RFC2750], which includes bandwidth reservations.  Reservations are admitted 
or not based on whether the requested resources are available.  State is 
'soft' because its lifetime is limited, and thus must be refreshed 
periodically.  Two integrated services are presently defined for Intserv.  A 
Guaranteed Service (GS) [RFC2212] offers firm bounds on maximum end-to-end 
queueing delay (but not delay jitter) for flows that meet an agreed traffic 
specification (TSpec).  A Controlled Load Service (CLS) offers no quantitative 
guarantees, but promises packet loss and delay closely
approximating the QoS that same flow would receive from an unloaded network.  

The mechanisms used by Intserv, especially RSVP, have been found to have 
scaling problems with respect to wide deployment in the Internet [RFC2208]

-- IP Differentiated Services (DiffServ) [RFC2475] is intended to provides 
coarse-grained QoS guarantees to aggregated flows.  Scalability is expected to 
be realized by confining  stateful mechanisms to the borders of a DiffServ 
domain.  These border nodes mark (or enforce marking) of packets with a 
DiffServ codepoint (DSCP -- the 6 most significant bits of the former TOS byte 
or  Traffic Class byte of the IPv4 or IPv6 datagram, respectively), which 
selects a defined per-hop behavior (PHB).  That PHB defines the forwarding 
behavior which the packet will experience in each node of the DiffServ domain. 
  A collection of packets with the same DSCP crossing a link in a particular 
direction is called a Behavior Aggregate (BA).  Resources are allocated to 
behavior aggregates. 

No per-flow or per-BA signalling protocols are currently defined.  DiffServ 
defines PHBs and not services.  However, PHBs can be used by service providers 
in combination with other mechanisms (such as markers, shapers, policers and 
schedulers) to provide services.

Three PHB groups are defined.  The legacy class selector PHB group [RFC2474] 
provides a relative priority;  this was provided to grandfather legacy use of 
the IP precedence field in the TOS byte of the IPv4 datagram.  The Expedited 
Forwarding (EF) PHB [RFC2598]  requires that the departure rate of a BA's 
packets from any diffserv node must equal or exceed a configurable rate.  The 
EF PHB can be used to build low loss, low latency, low jitter, assured 
bandwidth, end-to-end services through DS domains. The Assured Forwarding (AF) 
PHB group [RFC2597] provides four independently forwarded AF classes.  Within 
each AF class, a packet can be assigned one of three different levels of drop 
precedence.  A DS node does not reorder IP packets of the same microflow if 
they belong to the same AF class.  The AF PHB can be used, for example, to 
provide a so-called Olympic service, which has different levels (gold, silver, 
bronze), offering relatively better or worse delay and loss probability.

Note that services constructed using DiffServ can offer QoS guarantees only on 
BAs, and not on individual microflows.

.in -5

In general, the tradeoff between granularity and scaling tends to favor use of 
Intserv in edge domains (i.e., those most involved in serving hosts) and 
Diffserv in core domains.

Subnet designers should consider whether and how their subnets can support 
Intserv or Diffserv.  The following points should be addressed:
-- If the subnet is designed to provide a constant rate service with no 
contention for subnet resources (e.g., pure TDM/TDMA), IntServ or DiffServ 
mechanisms can be used directly. 
-- Otherwise, means need to be provided to differentiate flows, aggregated 
flows or connections at the subnet layer.  These need to be treated 
independently for purposes of discarding, queueing  and scheduling.  This can 
be done using stateful mechanisms (such as labels or connection identifiers), 
stateless mechanisms analogous to DSCPs or n-tuples within the subnet packet 
header (e.g., source and destination address and SAP).  One or more flows at 
the IP layer can be associated with (or carried over) a flow or connection at 
the subnet layer.
-- Mappings need to be made between the service elements supported by the 
subnet and the Intserv services or Diffserv [service?  BA? PHB? -- things have 
gotten confusing in Diffserv, and maybe we can fill this in after Adelaide]. 
-- As part of those mappings, the subnet needs to be able to offer absolute 
guarantees and possibly relative assurances to the IP layer.  Absolute 
priority mechanisms have been atrractive to subnet designers as they are easy 
to implement.  However, they are not sufficient to provide absolute 
guarantees.  Similarly, in order to support Diffserv class selectors, subnets 
(i.e., ATM) which have offered only absolute guarantees have had to be 
rearchitected to also support relative assurances.
-- As noted elsewhere in this memo, mobility can strongly affect the kinds of 
guarantees that can be offered, and the confidence with which such guarantees 
can be offered.
-- Different service objectives can result in different mechanisms or local 
paramters associated with those objectives.  As an example, if the user of an 
Intserv service is highly intolerant of fixed delay, but more tolerant of 
packet loss, the subnet service might elect not to use FEC, or to use a less 
deep (and thus less robust) interleaver.
-- Considerations on queueing, discard and scheduling discussed elsewhere in 
this memo also affect the QoS offered by the subnet.

---

From: Jayanth Mysore <[email-masked]>
Date: Thu, 16 Mar 2000 17:05:52 -0600

> having difficulty organizing my thoughts.  There's more to be said, but enough

-- Core stateless approaches (Dynamic Packet
State<draft-stoica-diffserv-dps-00.txt> ) : Recently there
have been proposals  for supporting per flow commitments to flows using scalable
cores. These approaches may
potentially mature into standards in due course of time, given the richness of
the services they can support.  These
architectures  require edge routers to maintain per-flow state, while the core
routers maintain no per-flow state. In the
data path, edges mark packets of a flow with  the minimum necessary  state
information required by a distributed algorithm implemented
by an island of core routers. The core routers do not have to perform any packet
classification, and update the state
information on the packet header to achieve the committed end to end performance.
They also propose admisison control
algorithms that require no per flow state to support guaranteed services. Such
schemes offer the advantage of supporting per flow
commitments, using a scalable network architecture.

> Diffserv in core domains.

(or alternately, core stateless approaches end to end)

> this memo also affect the QoS offered by the subnet.

-Jayanth Mysore,
Motorola Labs