Internet DRAFT - draft-bergsten-e2eqos-questions
draft-bergsten-e2eqos-questions
Network Working Group Anders Bergsten, TRAB
INTERNET-DRAFT Krisztian Nemeth, BUTE
Expiration Date: January 2002 Istvan Cselenyi, TRAB
Gabor Feher, BUTE
July 2001
Fundamental Questions Regarding End-to-End QoS
<draft-bergsten-e2eqos-questions-00.txt>
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.
Abstract
This short memo aims to discuss the different functions and
topological areas of an internetwork, where some kind of
enhancements are required in order to provide predictable end-to-end
quality of service (QoS) to customers. These enhancements require
(1) the exchange of QoS-related information and (2) enforcement of
QoS-related decisions. This can be, but not necessarily is, done by
some existing or new signaling protocols.
The following five points are identified:
1) The access network: the probability of congestion is the highest
in the access network, thus it is very likely that some kind of
mechanism supporting the QoS instantiation is necessary here
2) End-to-end signaling between applications: we believe that a high
level information exchange must be the first step of a QoS
session initiation in several cases
3) Inter-domain communication, particularly on a peering link: an
automatic service announcement is needed, something like BGP, but
with QoS enhancements. In addition, it is considerable to have a
Bergsten et al. Expires January 2002 [Page 1]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
mechanism, which actually provides inter-domain provisioning of
these resources.
4) Identifying, which customer to penalize in case of a network
congestion: when a severe congestion occurs and a contract has to
be breached, it should be under the control of the network
provider (through policies) which contract to breach. It should
be considered both as a technical and a business problem, which
customer to turn down.
5) Providing requirement information from customers: Customers could
inform the service providers about the current and intended
network utilization, specifying for example the expected
destinations and traffic volumes. The operator could then use
this knowledge to dimension its network better, and also to
calculate the amount of services to buy from the neighboring
operators.
1. Introduction
Looking from the perspective of the end-user, a predictable end-to-
end quality of service seems to be the most beneficial facility in
the whole QoS (quality of service) concept. Consequently the network
providers should aim for making this type of service available to
the user.
DiffServ (Differentiated Services [1]) gives us the fundamental
building blocks to achieve service differentiation. This alone can
take us very far. Differentiated Services provides means to separate
(i.e., the Per Hop Behavior, PHB), to police and to describe service
components (i.e., the Per Domain Behavior, PDB). These are all the
basic, but mandatory ingredients for QoS provisioning. Furthermore,
DiffServ also gives us a couple of more architectural ingredients:
the contractual agreement (i.e., the Service Level Agreement, SLA)
and the assumption that an ISP (Internet Service Provider) must be
knowledgeable enough to provision its network correctly.
Given the ability to separate, provision the network correctly and
to write contracts between parties is enough for QoS -- as seen from
an operator's perspective. However, to achieve end-to-end service
quality, several pieces of the "QoS pie" seem to be missing from
this point of view.
At this point we would also like to acknowledge that the implicit
method used in todayÆs Internet [2] should play a fundamental role
also in the future, even for IP QoS. After a contract has been
signed the probability of blocking in a domain is designed to be
extremely low (0.01 to 0.00001) during normal operations. Thus,
blocked flows are the exception rather than the rule, why we are
looking into an architecture that takes the implicit method as a
starting point for customers.
Bergsten et al. Expires January 2002 [Page 2]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
In this short memo we try to identify those places in the network
architecture, where some enhancements are required, or at least
could be beneficial in order to achieve end-to-end QoS. In the third
section, we detail our list of these places.
2. Scenario
Our targeted scenario is the "public" Internet of the near future,
we do not aim for special IP networks, like for example mobile
telephony carriers over IP.
There are four fundamental players in the QoS game. The two customer
sides that are communicating, the operators that sign contracts with
the customers and the network that supply the resources. Of course,
there may be more than four physical (or logical) players performing
these roles.
Using this network, users run the same applications as today, plus
some QoS-demanding ones, just like IP-telephony, web-TV, etc. The
structure of the network is coming from the Internet architecture we
have today: there are several Internet Service Providers and each
has its own network, which are connected to other providers enabling
connectivity for the whole Internet. From the user's perspective the
network consists of an access network, which is his or her local
Internet Service Provider. The network node with which the user is
communicating resides in the far end access network. Between these
there might be several transit domains owned by different operators,
over which the communication goes through.
We also assume that premium services that the network operators
offer to customers in the near future have similar characteristics
and also based on the services that we have today. In this memo we
describe two different types of such premium services, and study the
end-to-end QoS provisioning issues considering these two types only.
2.1 Corporate Service
First, there is a service, which is very similar to the Virtual
Private Network (VPN) service. The main attributes of this service
are: the Service Provider guarantees some QoS bounds for the
customer's traffic that is targeted to a known set of network
domains; the customer is responsible for its traffic, which should
not exceed the agreed limits; the customer and the operator makes a
contract (Service Level Agreement, SLA), which is valid for a
reasonable long time period. This type of premium service is ideal
for companies, who frequently require the QoS guarantees, or would
like to build up VPNs among distant network nodes (e.g. branch
offices). That is the customer of this service can continuously
expect the same QoS for his macro-service.
Bergsten et al. Expires January 2002 [Page 3]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
2.2 Consumer Service
Second, we can imagine a premium service, which is similar to
current prepaid telephone-card based calling service. In this case
the customer shall subscribe to the ability of using premium service
(buy the phone card). Than whenever he wants to have a service
session, he can request it as long as there are units on the phone
card.
This type of service in our model is for the majority of users. It
is not based on quasi-permanent SLAs, but it supports the setup of
dynamic QoS sessions. Examples can be a video watching session
downloading the film from a digital library or a distributed game-
party. These sessions are always preceded by an explicit setup
request sent from the endpoint to its local ISP. It is the ISP's
responsibility to handle these requests. After the end of the
session, it is torn down. Probably the biggest difference compared
to the corporate service is that these requests can be accepted or
denied at the initiation time in case of not enough resources.
However, since customers certainly do not like blocked services, it
is the responsibility of the network operator to provision its
network to achieve low consumer service blocking probability.
Certainly the tradeoff between the service blocking probability and
the network utilization is also a business-related issue.
3. Possible places of enhancements
3.1 The access network
Problem statement:
The access network is perhaps the most critical from the QoS
perspective. The number of contracts (one for each end-user and for
each peering domain) is the highest and the traffic demand is the
least predictable here. In addition, the peak and average data rate
generated by the end-users are usually very different from each
other, meaning a relative high peak but low average utilization.
Because of these issues, overprovisioning is generally not a
solution in IP access networks. Another consequence is that the
access is still the bottleneck, where most of the congestion occurs.
Thus, some way of QoS control mechanism seems to be needed in the
access networks. Moreover, in some cases, like for example shared
cable-TV access links, the lower network layers also demand QoS
support mechanisms.
To sum up, here we need communication between the customer and the
access network (and the far-end customer and his access network),
and both information exchange and QoS enforcement is needed.
Discussion:
For the corporate service probably no signaling is necessary. After
the contract has been signed (meaning that the network can cope with
Bergsten et al. Expires January 2002 [Page 4]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
the new amount of traffic) the network has to be configured once.
After instantiation some form of traffic engineering might be used
to prevent congestion. This can be very useful if the network
operator wants to control the resources in its network, and
signaling might also be handy to support the traffic engineering.
However, even if the customer informs the local access network about
his or her resource demand and enforces the allocation of that,
there may be problems in the far-end access network. For this
reason, the mechanisms applied in access networks should also
support session setup requests coming from the direction the core
network.
For the customer service type signaling based resource reservation
seems to be more adequate since this gives tighter control of
resources. The endpoints should provide some information about their
requirements, and the ISP must accept or reject the setup request
and in the former case should inform the user about the price for
the service as well.
3.2 Application-to-application information exchange
Problem Statement:
The goal of this type of communication is to have means for the
applications/users to inform each other and to negotiate about a QoS
session, prior to its establishment. Thus, here the information
exchange is done between the two customer sites; the QoS enforcement
is optional.
Discussion:
In most of the cases this involves something more than just agreeing
upon the fact of a new session setup. For example before starting to
watch a movie (video on demand), the user may wish to choose among
different qualities and prices. (Note, the same kind of choice is
already available in some telephone networks, where for long
distance calls the users may choose between the traditional phone
connection or the IP-based one, where the latter is cheaper but is
of worse quality.) Application settings might also be negotiated
here, which are dependent for example on the hardware equipment of
the endpoints (e.g. support for video transmission for an IP phone
session makes sense only if the users have got a camera).
As partly mentioned already, charging information may also form part
of this communication, as for example it has to be agreed who pays
for the session. This may involve the participation of a third
party, who -- on behalf of the operator -- informs the users about
the price of the service in question.
Without going into details of the possible realizations, we can
state that it will most probably be application specific. It can
Bergsten et al. Expires January 2002 [Page 5]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
also be mentioned, that existing protocols, such as SIP could be
used for this purpose.
3.3 Inter-domain signaling
Problem Statement:
Quality of service is an end-to-end problem. The customer needs to
understand what he is buying, in order to decide about what service
to buy and from which operator. Thus the service provider should
supply the end-to-end QoS parameters of an offered session.
We discuss two issues here:
1) how to announce the service promises between operators end-to-end
2) how to enforce the accepted promise per domain
The information exchange happens between operators. QoS enforcing is
per domain.
Discussion:
(1) For announcing promises end-to-end
Many operators today describe the best effort service that is being
sold to their customers. This is done in the contract between the
parties, and also as an advertisement on a web page for example. The
quality (delay and packet loss) that the customer will receive in
the domain in question is described in the contract. Note that we
wrote "the domain in question". This is one of the fundamental
problems of the Internet QoS today that the promise only deals with
one domain and not the entire path.
A chain of domains (building up and end-to-end service), that all
separately describe the service they deliver, will nevertheless not
be able to state what the end-to-end QoS will be as there is no
control of the entire path. BGP [3] solve this problem for the
simplest service -- connectivity. The equivalent in QoS, which is
the metrics by which the service is described, is not transported
the same way.
Thus, there is a need for a protocol that is able to collect the
promises for QoS parameters that each ISP is making and thereby
forming an end-to-end description of the service. Note that we
deliberately use "promises", as this is a much simpler problem to
deal with than to take into account what the actual delay and packet
loss is.
(2) For enforcing promises per domain
While there is a definite need for a mechanism that describes the
expected end-to-end QoS parameters for the customers, it is also a
natural idea to think about a mechanism, which actually provides
inter-domain provisioning of these resources.
Bergsten et al. Expires January 2002 [Page 6]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
This would mean some way of automated SLA generation and processing.
This could happen on a peering link between two neighboring domains
only, or these service level agreements could form a larger scale,
multi-provider, quasi-dynamic resource provisioning system.
This certainly would run on a much larger time-scale than the
dynamic provisioning; SLA's would be modified in a weekly/monthly
basis for example.
3.4 Business oriented congestion control
Problem Statement:
As we operators are selling services, we bind ourselves to contracts
that we should fulfill or otherwise some form of penalty will come
into play. We are now talking about the case where the already
admitted sessions cannot be served fully. This might happen due to a
partial network failure or due to bad provisioning.
The basic idea here is to insert some kind of policy into the QoS
congestion control. When a severe congestion occurs then probably a
contract has to be breached. It is both a technical and a business
problem which customer to turn down in this case, but the conditions
are not given today so that business considerations could be taken
into account during this decision. These considerations would
require the knowledge of the contracts, and also the history of
events, i.e., when and which customers we have already denied
service to.
In this case information exchange and QoS enforcement is done within
a network domain.
Discussion:
In the case of DiffServ if the contracts are broken, it can happen
in either controlled or un-controlled way. The un-controlled method
is what we would call "pure" DiffServ (i.e. DiffServ as it is today,
with no extra functionality). The higher packet loss or delay will
be seen by all customers that share the over-utilized resource.
A possible approach that an operator can take in this case is to
degrade some of the flows going through the congestion. Treating
these flows artificially worse (e.g. drop/remark/delay its packets
at the domain border) might relieve the congestion and thus help the
operator to keep the contract for the rest of the flows. For the
selection of the blocked flows we can use a policy, which takes into
account both technical and business-oriented aspects. In this case
an end-to-end signaling might help to identify the customers related
to the data flows.
3.5 Supplying requirement information from the customers to the
providers
Bergsten et al. Expires January 2002 [Page 7]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
Problem Statement:
It is beneficial for the operator to have some information about the
current and future demand of the customers in order to provision his
network and prepare it for the future challenges, including buying
services from neighboring operators (peering). Customers could
inform the service providers about the current and intended network
utilization, specifying for example the expected destinations and
traffic volumes. This is needed on per customer basis (and not per
flow, neither per behavior aggregate).
Apart from this customer-operator information exchange, no immediate
QoS enforcement happens.
Discussion:
Today, an operator can guess the user demand by looking at aggregate
statistics of link utilization. That is, bandwidth usage and
possibly some more statistics. Another mean for an operator to do
it, if signaling is used, is to collect statistics of the signaling
protocols (RSVP [4], for example).
With DiffServ an operator can only use the first method which might
be a problem if end-to-end congestion control is being used. The
demand of users, however, might differ from the actual throughput
that shows up on a single link. For example, due to an upstream
congestion a downstream operator will not see the real demand. When
the upstream congestion has cleared there is risk that the
congestion will only move to another place in the network.
Thus, to understand the resource need of users, there might be a
reason to explore if it is possible to construct a "resource demand"
information signaling protocol. Then there would exist a simple mean
for the operator to figure out what requirements the users have.
Although such a mechanism seems undoubtedly useful, it has to be
noted that the significance of this method is very hard to foresee.
Currently it is also not straightforward, how the customers would
generate the traffic forecast data. It should also be mentioned that
such a protocol might be subject to misuse. For example, if used
naively, it might be tricked to fool an ISP to make more resources
available towards certain areas of the Internet where capacity is
not actually needed.
4. Legacy solutions
Certainly we did not want to reinvent the wheel, nor protocols for
that matter. There are many legacy solutions that can cover parts of
the aforementioned problems. Nevertheless, it is always good to look
at the requirements first and then to identify the solutions.
Bergsten et al. Expires January 2002 [Page 8]
INTERNET-DRAFT Fundamental Questions Regarding E2E QoS July 2001
Looking at existing specific solutions that can solve parts of the
problems is out of the scope of this memo.
5. Security Considerations
We tried to address problems and not their solutions; thus security
considerations are not addressed in this memo.
6. References
[1] Blake S. et al., "An architecture for Differentiated Services",
RFC 2475
[2] Crowcroft J., mail to SigLite mailing list 09/01/2001 16:30
http://lists.cs.columbia.edu/mailman/listinfo/siglite
[3] Rekhter Y. and Li T., "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771
[4] Braden R. (Ed), "A Resource reSerVation Protocol (RSVP)
Version 1 Functional Specification", RFC 2205
7. Acknowledgments
The authors would like to acknowledge the helpful discussions with
Niklas Borg, Peter Fuzesi and Rikard Holmberg.
8. Author's Addresses
Anders Bergsten
Telia Research AB
Aurorum 6; 977 75 Lulea; Sweden
Phone: +46 920 754 50
E-mail: Anders.P.Bergsten@telia.se
Krisztian Nemeth
Budapest University of Technology and Economics
Department of Telecommunications and Telematics
Pßzmßny P. s. 1/D.; H-1117 Budapest; Hungary
Phone: +36 1 463 3119
E-mail: nemeth_k@ttt-atm.ttt.bme.hu
Istvan Cselenyi
Telia Research AB
Vitsandsgatan 9; S-12386 Farsta; Sweden
Phone: +46 8 713 8173
E-mail: Istvan.I.Cselenyi@telia.se
Gabor Feher
Budapest University of Technology and Economics
Department of Telecommunications and Telematics
Pßzmßny P. s. 1/D.; H-1117 Budapest; Hungary
Phone: +36 1 463 2187
E-mail: feher@ttt-atm.ttt.bme.hu
Bergsten et al. Expires January 2002 [Page 9]
