Internet DRAFT - draft-gaudioz-equivalent
draft-gaudioz-equivalent
DiffServ B. Gaidioz
Internet-Draft UCBL/ENS-Lyon
Expires: August 23, 2002 P. Primet
INRIA/ENS-Lyon
G. Montenegro
Sun Microsystems, Inc.
February 22, 2002
The Equivalent Differentiated Services
draft-gaudioz-equivalent-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes EDS (Equivalent Differentiated Services), a
new building-block for a simple, robust, free and scalable end-to-end
service differentiation in IP networks. The EDS scheme aims at
providing a spectrum of "different but equivalent" network services
that offer a trade-off between delay and loss rate to the end-to-end
flows. The EDS scheme can be deployed incrementally in the Internet.
Gaidioz, et al. Expires August 23, 2002 [Page 1]
Internet-Draft Equivalent Differentiated Services February 2002
1. Introduction and Requirements
With the diversification of Internet applications, flow sensitivity
to loss or delay variations becomes increasingly heterogeneous. This
highlights an important need for service differentiation at the IP
layer. As compared to best-effort service, some flows require better
delay and others, better loss rate. For example, whereas audio
streams are very sensitive to delay variations, different types of
TCP flows exhibit highly varying reponses to network conditions,
depending on whether they are "bulky" (e.g. large file transfers
over extended periods of time) or "interactive" (e.g. telnet with
short interactive packets). Furthermore, the web has introduced
flows which are both bulky and interactive (interactive web pages
with large multimedia content like pictures, audio or video clips).
Accordingly, an important challenge is how to complement the
traditional best-effort service by adding the appropriate
differentiation mechanisms. In keeping with the Internet's design
principles, these mechanisms must adhere to the following criteria
[3], [4]:
o They must be simple, robust and scalable,
o They must be incrementally deployable.
o The various services must be usable as freely as the current best-
effort service provided by today's IP networks. Neither pricing
nor admission control must be performed.
Active queue management mechanisms such as RED [9] and congestion
notification mechanisms like ECN [8] aim at improving the best-effort
service by having detecting congestion early and issuing
notifications to responsive flows. Active queue management fulfills
the above criteria. Nevertheless, providing differentiated services
is not one of their objectives.
To avoid pricing, the proposed services cannot constitute a hierarchy
from "better" to "worse". Consequently, even if flows do obtain
different treatment by the network, what a flow gains in one respect,
it must loose in another. This is the underlying principle of "non-
elevated services" [5] like ABE [1] or BEDS [2].
Admission control can be avoided only if guarantees are relative
rather than absolute. Absolute guarantees requires resource
provisioning, admission control and traffic control to ensure traffic
is policed accordingly. If guarantees are relative, they can still
be ensured, whatever the network load is.
Gaidioz, et al. Expires August 23, 2002 [Page 2]
Internet-Draft Equivalent Differentiated Services February 2002
The requirement for simplicity rules out the potential treatment of
individual packets. Besides, performance at the network layer must
high and compatible with the current and evolving link speeds.
Today's routers are able to classify packets and to treat them
differently in different queues efficiently. But, with improvements
in optical technology and the exponential increase of the network
capacity, the complexity of packet processing performed by routers at
ultra high speeds cannot increase much more.
The robustness requirement implies that the network remains stateless
at the core in order to support services in an end-to-end fashion.
Incremental deployment means that the scheme must support service
differentiation even if it is performed only partially along the end-
to-end path.
EDS is a new building block at the IP layer that satisfies the
preceding criteria. It aims at differentiating the per hop behavior
(PHB) to better meet the needs of each flow. EDS provides a spectrum
of different but equivalent services, that offer a trade-off between
delay and loss rate.
Gaidioz, et al. Expires August 23, 2002 [Page 3]
Internet-Draft Equivalent Differentiated Services February 2002
2. Specifications
The EDS defines an arbitrary number N of equivalent service classes
(N greater or equal to 2) which are identified by numbers ranging
from `1' to `N'. The services are directly used by end-to-end
protocols or applications.
Each "EDS-capable router" differentiates among classes over the
queuing delay of the packets and their loss rate. A class `i' is
given two constant coefficients `d_i' (the delay coefficient) and
`l_i' (the loss rate coefficient) defined as follows. Let `i' and
`j' be two different classes: in each router, a ratio of d_i/d_j
between the queuing delays of their packet and a ratio of l_i/l_j
between their loss rates are defined. Coefficients are set so that
for each i in [1,N-1], l_i+1 is higher than l_i and d_i+1 is lower
than d_i.
Class `1' is thus the class whose packets experience the lowest loss
rate and the highest queuing delay ; packets of class `N' gets the
highest loss rate and the lowest queuing delay. Packets of classes
`i' where 1<i<N get performances in between according to the value of
their coefficients.
A default class corresponding to the best-effort service is defined.
The EDS scheme can cohabit transparently with advanced differentiated
services like premium service. In DiffServ domains, routers can
consider EDS flows as best-effort flows.
Gaidioz, et al. Expires August 23, 2002 [Page 4]
Internet-Draft Equivalent Differentiated Services February 2002
3. Class Identifier
Once the class identifier for the packet is set at the source it must
not be altered. This is different from DiffServ codepoints which can
be modified by routers along the path and therefore have no end-to-
end guarantees.
One has to find another field in the packet to store the class
identifier. The requirements for this field are as follows: Its size
must be greater than one bit. Upper bound can be one byte. The size
of the class identifier field will fix the value of N, maximum number
of classes. The field has to be easily accessed by the classifier
component of routers. The class identifier 0 correspond
systematically to the default class that will experience at each
router mean performances in terms of delay and loss. This service
will approximate a best-effort service.
Gaidioz, et al. Expires August 23, 2002 [Page 5]
Internet-Draft Equivalent Differentiated Services February 2002
4. Router Requirements
PHB definition is restricted to local parameters, that means they are
not based on global criteria like flow behavior, number of routers,
etc. The number N of classes is limited by the size of the class
identifier field. Each "EDS-capable router" knows the value of N.
Each router must have a default class where all packets of codepoint
`0' are classified. This class should provide performance close to
the best-effort service (if no differentiation is practiced) in delay
and loss rate. This can be implemented by dynamically choosing the
most appropriate class or using a specific way to schedule the best-
effort packets.
EDS routers do not have to discriminate systematically each of these
N classes. Each router will map the N global classes in its local
classes. For example, let N be equal to 64 and a given router be
able to discriminate only four local classes. This router will
classify the packets identified by a global value from 1 to 16 in the
local class 1, from 17 to 32 in the local class 2, etc. The default
class 0, corresponding to the best-effort class will be mapped to the
median class.
Gaidioz, et al. Expires August 23, 2002 [Page 6]
Internet-Draft Equivalent Differentiated Services February 2002
5. Setting the Delay and Loss Coefficients
The settings of the delay and loss coefficients can differ from one
router to an other. The setting has to conform to the rule that
l_1<..<l_N and d_N<..<d_1.
As an example, the following table shows three different
coefficients settings for EDS where N is equal to 8.
+-----+-----------+-----------+-----------+
| | setting 1 | setting 2 | setting 3 |
| | d / l | d / l | d / l |
+-----+-----------+-----------+-----------+
| 1 | 8.0 1.0 | 4.0 0.5 | 8.0 1.0 |
| 2 | 7.0 2.0 | 3.9 1.0 | 4.0 2.0 |
| 3 | 6.0 3.0 | 3.8 2.0 | 2.0 4.0 |
| 4 | 5.0 4.0 | 3.7 4.0 | 1.0 8.0 |
| 5 | 4.0 5.0 | 2.5 8.0 | 0.9 8.1 |
| 6 | 3.0 6.0 | 2.0 8.1 | 0.8 8.2 |
| 7 | 2.0 7.0 | 1.5 8.2 | 0.7 8.3 |
| 8=N | 1.0 8.0 | 1.0 8.3 | 0.6 8.4 |
+-----+-----------+-----------+-----------+
examples of configuration
o In setting 1, delay and loss are regularly spread on the
performance spectrum.
o In setting 2, there are mainly two groups of classes: 1 to 4 and 5
to 8. In a group of classes, there is a well defined way of
practicing differentiation. In the first group (classes 1 to 4),
there is a stronger loss differentiation than delay
differentiation. The delay differentiation is linear while loss
differentiation is quadratic. In the second group (5 to 8), both
differentiation are linear but delay differentiation is stronger.
o In setting 3, there are two groups of classes: 1 to 4 and 5 to 8.
In the first one (1 to 4) the differentiation is strong compared
to the differentiation in the second group (5 to 8).
Gaidioz, et al. Expires August 23, 2002 [Page 7]
Internet-Draft Equivalent Differentiated Services February 2002
6. Source Requirements
The source has to set the class identifier of each packet. The
successive packets of a given flow can be tagged differently. The
end-to-end transport layer can integrate some adaptation mechanisms
to contribute to the end-to-end quality of service.
Existing adaptive transport protocols like TCP [6] can use the EDS
scheme directly by using the default class or a "low loss" class.
But to fully use the capacities of the EDS model, either existing
transport protocols may need to be adapted or, of course, a new
protocol could be designed from scratch. For such a new adaptive
protocol, the feedback information may be a class number rather than
a loss information.
With EDS, an application that has strong delay requirements can have
some control on the latency caused by the network. It can start by
using the default class and switch to the one that gives a delay
close to its threshold. It may experience a high loss if it chooses
a delay class that is too low. During periods of strong congestion,
the loss rate may be too high and the application would have to relax
its delay requirements. Under such adverse conditions, the EDS
network layer will be unable to provide a better service. However
the provided service may be better than a flat best-effort service.
Gaidioz, et al. Expires August 23, 2002 [Page 8]
Internet-Draft Equivalent Differentiated Services February 2002
References
[1] Hurley, P., Le Boudec, J., Thiran, P. and M. Kara, "ABE:
Providing a Low-Delay Service within Best Effort", in IEEE
Network, Volume 15, Number 5, May 2001.
[2] Firoiu, V. and X. Zhang, "Best Effort Differentiated Services:
Trade-off Service Differentiation for Elastic Applications", in
Proceedings of IEEE ICT'01, June 2001.
[3] Gaidioz, B., Primet, P. and B. Tourancheau, "Differentiated
fairness: Model and implementation", in Proceedings of IEEE
HPSR'01, May 2001.
[4] Gaidioz, B. and P. Primet, "The Equivalent Differentiated
Services", LIP Research Report RR2002-09, February 2002.
[5] Teitelbaum, B., "Future Priorities for Internet2 QoS", in
Internet2 QoS WG, see http://www.internet2.edu/qos/wg/papers/
qosFuture01.pdf, October 2001.
[6] Postel, J., "Transmission Control Protocol", RFC 793, STD 1,
September 1981.
[7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[8] Floyd, S. and K. Ramakrishnan, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[9] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for
Congestion Avoidance", in IEEE/ACM Transactions on Networking,
Volume 1, Number 4, pages 397-413, August 1993.
Authors' Addresses
Benjamin Gaidioz
UCBL
ENS-Lyon LR5
46, allee d'Italie
Lyon 69364
France
EMail: Benjamin.Gaidioz@ens-lyon.fr
Gaidioz, et al. Expires August 23, 2002 [Page 9]
Internet-Draft Equivalent Differentiated Services February 2002
Pascale Primet
INRIA
ENS-Lyon LR5
46, allee d'Italie
Lyon 69364
France
EMail: Pascale.Primet@ens-lyon.fr
Gabriel Montenegro
Sun Microsystems Laboratories Europe
29, chemin du Vieux Chene
Meylan 38240
France
EMail: gab@sun.com
Gaidioz, et al. Expires August 23, 2002 [Page 10]
Internet-Draft Equivalent Differentiated Services February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gaidioz, et al. Expires August 23, 2002 [Page 11]
