idnits 2.17.1 draft-watfjyl-srp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 66 has weird spacing: '...ion the minim...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Werner Almesberger 3 Jean-Yves Le Boudec 4 EPFL ICA, Switzerland 5 Tiziana Ferrari 6 DEIS, Uni Bologna, INFN/CNAF, Italy 7 March 1998 9 SRP essentials 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 29 Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 This paper gives a succinct description of the design of SRP, a 34 highly scalable resource reservation protocol for Internet traffic. 36 1. About this paper 38 This paper is a short introduction to the "Scalable Reservation 39 Protocol" (SRP). It aims to provide background information for 40 discussions related to SRP and is, due to focussing only on the most 41 essential issues, necessarily incomplete. Readers interested in all 42 the gory details are kindly referred to [1]. 44 This document is a summary of the current design of SRP. It is not 45 just an update of . We also tried to 46 align it better with concepts and terminology currently used in the 47 diffserv [2] working group of IETF. 49 The Web page of SRP is at http://lrcwww.epfl.ch/srp/ 51 2. Overview 53 SRP provides a light-weight reservation mechanism for adaptive 54 multimedia applications [3]. Our main focus is on good scalability to 55 very large numbers of individual flows. End systems (i.e. senders and 56 destinations) actively participate in maintaining reservations, but 57 routers can still control their conformance. Routers aggregate flows 58 and monitor the aggregate to estimate the resources needed to support 59 present and new reservations. There is no explicit signaling of flow 60 parameters. 62 3. End-to-end service 64 Many adaptive multimedia applications require a well-defined fraction 65 of their traffic to reach the destination and to do so in a timely 66 way. We call this fraction the minimum rate these applications need 67 in order to operate properly. SRP aims to allow such applications to 68 make a dependable reservation of their minimum rate. 70 The sender can expect that, as long as it adheres to the agreed-upon 71 profile, no RESERVED packets will be lost due to congestion. 72 Furthermore, forwarding of RESERVED packets will have priority over 73 best-effort traffic. 75 4. Reservation mechanism 77 A source that wishes to make a reservation starts by sending data 78 packets marked as REQUEST packets to the destination. Packets marked 79 as REQUEST are subject to packet admission control by routers, based 80 on the following principle. Routers monitor the aggregate flows of 81 RESERVED packets and maintain a running estimate of what level of 82 resources is required to serve them with a good quality of service. 83 The resources are bandwidth and buffer on outgoing links, plus any 84 internal resources as required by the router architecture. Quality of 85 service is loss ratio and delay, and is defined statically. When 86 receiving a REQUEST packet, a router determines whether 87 hypothetically adding this packet to the flow of RESERVED packets 88 would yield an acceptable value of the estimator. If so, the REQUEST 89 packet is accepted and forwarded towards the destination, while still 90 keeping the status of a REQUEST packet; the router must also update 91 the estimator as if the packet had been received as RESERVED. In the 92 opposite case, the REQUEST packet is degraded and forwarded towards 93 the destination, and the estimator is not updated. Degrading a 94 REQUEST packet means assigning it a lower traffic class, such as best 95 effort. A packet sent as REQUEST will reach the destination as 96 REQUEST only if all routers along the path have accepted the packet 97 as REQUEST. Note that the choice of an estimation method is local to 98 a router and actual estimators may differ in their principle of 99 operation. 101 The destination periodically sends feedback to the source indicating 102 the rate at which REQUEST and RESERVED packets have been received. 103 This feedback does not receive any special treatment in the network 104 (except possibly for policing, see section "Security"). Upon 105 reception of the feedback, the source can send packets marked as 106 RESERVED according to a profile derived from the rate indicated in 107 the feedback. If necessary, the source may continue to send more 108 REQUEST packets in an attempt to increase the rate that will be 109 indicated in subsequent feedbacks. 111 Thus, in essence, a router accepting to forward a REQUEST packet as 112 REQUEST allows the source to send a RESERVED packet in the future; it 113 is thus a form of implicit reservation. 115 5. Aggregation 117 Routers aggregate flows on output ports, and possibly on any 118 contention point as required by their internal architecture. They use 119 estimator algorithms for each aggregated flow to determine their 120 current reservation levels and to predict the impact of accepting 121 REQUEST packets. The exact definition of what constitutes an 122 aggregated flow is local to a router. 124 Likewise, senders and sources treat all flows between each pair of 125 them as a single aggregate and use estimator algorithms for 126 characterizing them. The estimator algorithms in routers and hosts do 127 not need to be the same. In fact, we expect hosts to implement a 128 fairly simple algorithm, while estimator algorithms in routers may 129 evolve independently over time. 131 We evaluated example host and router algorithms in [1]. 133 6. Further issues 135 Further issues, such as support for multicast, are discussed in [1]. 137 7. Security 139 Denial-of-service conditions may arise if flows can reserve 140 disproportional amounts of resources or if flows can exceed their 141 reservations. We presently consider fairness in accepting 142 reservations a local policy issue (much like billing) which may be 143 addressed at a future time. 145 Sources violating the agreed upon reservations are a real threat and 146 need to be policed. Policing can be efficiently implemented if 147 policing points filter feedback messages and monitor the accepted 148 reservations for the aggregate flows passing them. We assume that 149 networks will typically perform policing only at their boundaries. 151 8. Open issues 153 - Definition of shaping behaviour of the source 154 - Encoding of RESERVED and REQUEST packet types 155 - Format of feedback (use RTCP ?) 156 - Construction and evaluation of efficient estimator algorithms 158 9. References 160 [1] Almesberger, Werner; Ferrari, Tiziana; Le Boudec, Jean-Yves. 161 SRP: a Scalable Resource Reservation Protocol for the Internet, 162 ftp://lrcftp.epfl.ch/pub/people/almesber/srp/srpMar98.ps.gz, 163 Technical Report SSC/1998/009, EPFL, March 1998. 164 [2] IETF, Differentiated Services (diffserv) working group. 165 http://www.ietf.org/html.charters/diffserv-charter.html 166 [3] Diot, Christophe; Huitema, Christian; Turletti, Thierry. 167 Multimedia Applications should be Adaptive, 168 ftp://www.inria.fr/rodeo/diot/nca-hpcs.ps.gz, HPCS'95 Workshop, 169 August 1995. 171 10. Author's address 173 Werner Almesberger 174 Jean-Yves Le Boudec 175 Institute for computer Communications and Applications 176 Swiss Federal Institute of Technology (EPFL) 177 CH-1015 Lausanne 178 Switzerland 179 email: Werner.Almesberger,Leboudec@epfl.ch 181 Tiziana Ferrari 182 DEIS, University of Bologna 183 viale Risorgimento, 2 184 I-40136 Bologna 185 Italy 186 and 187 Italian National Inst. for Nuclear Physics/CNAF 188 viale Berti Pichat, 6/2 189 I-40127 Bologna 190 Italy 191 email: Tiziana.Ferrari@cnaf.infn.it