INTERNET-DRAFT Werner Almesberger
Jean-Yves Le Boudec
EPFL ICA, Switzerland
Tiziana Ferrari
DEIS, Uni Bologna, INFN/CNAF, Italy
March 1998
SRP essentials
<draft-watfjyl-srp-00.txt>
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
This paper gives a succinct description of the design of SRP, a
highly scalable resource reservation protocol for Internet traffic.
1. About this paper
This paper is a short introduction to the "Scalable Reservation
Protocol" (SRP). It aims to provide background information for
discussions related to SRP and is, due to focussing only on the most
essential issues, necessarily incomplete. Readers interested in all
the gory details are kindly referred to [1].
This document is a summary of the current design of SRP. It is not
just an update of <draft-almesberger-srp-00.txt>. We also tried to
align it better with concepts and terminology currently used in the
diffserv [2] working group of IETF.
The Web page of SRP is at http://lrcwww.epfl.ch/srp/
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 1]
INTERNET-DRAFT draft-watfjyl-srp-00.txt March 1998
2. Overview
SRP provides a light-weight reservation mechanism for adaptive
multimedia applications [3]. Our main focus is on good scalability to
very large numbers of individual flows. End systems (i.e. senders and
destinations) actively participate in maintaining reservations, but
routers can still control their conformance. Routers aggregate flows
and monitor the aggregate to estimate the resources needed to support
present and new reservations. There is no explicit signaling of flow
parameters.
3. End-to-end service
Many adaptive multimedia applications require a well-defined fraction
of their traffic to reach the destination and to do so in a timely
way. We call this fraction the minimum rate these applications need
in order to operate properly. SRP aims to allow such applications to
make a dependable reservation of their minimum rate.
The sender can expect that, as long as it adheres to the agreed-upon
profile, no RESERVED packets will be lost due to congestion.
Furthermore, forwarding of RESERVED packets will have priority over
best-effort traffic.
4. Reservation mechanism
A source that wishes to make a reservation starts by sending data
packets marked as REQUEST packets to the destination. Packets marked
as REQUEST are subject to packet admission control by routers, based
on the following principle. Routers monitor the aggregate flows of
RESERVED packets and maintain a running estimate of what level of
resources is required to serve them with a good quality of service.
The resources are bandwidth and buffer on outgoing links, plus any
internal resources as required by the router architecture. Quality of
service is loss ratio and delay, and is defined statically. When
receiving a REQUEST packet, a router determines whether
hypothetically adding this packet to the flow of RESERVED packets
would yield an acceptable value of the estimator. If so, the REQUEST
packet is accepted and forwarded towards the destination, while still
keeping the status of a REQUEST packet; the router must also update
the estimator as if the packet had been received as RESERVED. In the
opposite case, the REQUEST packet is degraded and forwarded towards
the destination, and the estimator is not updated. Degrading a
REQUEST packet means assigning it a lower traffic class, such as best
effort. A packet sent as REQUEST will reach the destination as
REQUEST only if all routers along the path have accepted the packet
as REQUEST. Note that the choice of an estimation method is local to
a router and actual estimators may differ in their principle of
operation.
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 2]
INTERNET-DRAFT draft-watfjyl-srp-00.txt March 1998
The destination periodically sends feedback to the source indicating
the rate at which REQUEST and RESERVED packets have been received.
This feedback does not receive any special treatment in the network
(except possibly for policing, see section "Security"). Upon
reception of the feedback, the source can send packets marked as
RESERVED according to a profile derived from the rate indicated in
the feedback. If necessary, the source may continue to send more
REQUEST packets in an attempt to increase the rate that will be
indicated in subsequent feedbacks.
Thus, in essence, a router accepting to forward a REQUEST packet as
REQUEST allows the source to send a RESERVED packet in the future; it
is thus a form of implicit reservation.
5. Aggregation
Routers aggregate flows on output ports, and possibly on any
contention point as required by their internal architecture. They use
estimator algorithms for each aggregated flow to determine their
current reservation levels and to predict the impact of accepting
REQUEST packets. The exact definition of what constitutes an
aggregated flow is local to a router.
Likewise, senders and sources treat all flows between each pair of
them as a single aggregate and use estimator algorithms for
characterizing them. The estimator algorithms in routers and hosts do
not need to be the same. In fact, we expect hosts to implement a
fairly simple algorithm, while estimator algorithms in routers may
evolve independently over time.
We evaluated example host and router algorithms in [1].
6. Further issues
Further issues, such as support for multicast, are discussed in [1].
7. Security
Denial-of-service conditions may arise if flows can reserve
disproportional amounts of resources or if flows can exceed their
reservations. We presently consider fairness in accepting
reservations a local policy issue (much like billing) which may be
addressed at a future time.
Sources violating the agreed upon reservations are a real threat and
need to be policed. Policing can be efficiently implemented if
policing points filter feedback messages and monitor the accepted
reservations for the aggregate flows passing them. We assume that
networks will typically perform policing only at their boundaries.
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 3]
INTERNET-DRAFT draft-watfjyl-srp-00.txt March 1998
8. Open issues
- Definition of shaping behaviour of the source
- Encoding of RESERVED and REQUEST packet types
- Format of feedback (use RTCP ?)
- Construction and evaluation of efficient estimator algorithms
9. References
[1] Almesberger, Werner; Ferrari, Tiziana; Le Boudec, Jean-Yves.
SRP: a Scalable Resource Reservation Protocol for the Internet,
ftp://lrcftp.epfl.ch/pub/people/almesber/srp/srpMar98.ps.gz,
Technical Report SSC/1998/009, EPFL, March 1998.
[2] IETF, Differentiated Services (diffserv) working group.
http://www.ietf.org/html.charters/diffserv-charter.html
[3] Diot, Christophe; Huitema, Christian; Turletti, Thierry.
Multimedia Applications should be Adaptive,
ftp://www.inria.fr/rodeo/diot/nca-hpcs.ps.gz, HPCS'95 Workshop,
August 1995.
10. Author's address
Werner Almesberger
Jean-Yves Le Boudec
Institute for computer Communications and Applications
Swiss Federal Institute of Technology (EPFL)
CH-1015 Lausanne
Switzerland
email: Werner.Almesberger,Leboudec@epfl.ch
Tiziana Ferrari
DEIS, University of Bologna
viale Risorgimento, 2
I-40136 Bologna
Italy
and
Italian National Inst. for Nuclear Physics/CNAF
viale Berti Pichat, 6/2
I-40127 Bologna
Italy
email: Tiziana.Ferrari@cnaf.infn.it
Almesberger, Ferrari & Le Boudec Expires 9/98 [Page 4]