idnits 2.17.1 draft-fang-diffserv-tc-tswtcm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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.) ** There are 68 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 33 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([RFC2475,RFC2474], [AFPHB]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 109: '...e Rate Estimator MAY operate in the Ro...' RFC 2119 keyword, line 110: '... latter case, the implementation MUST...' RFC 2119 keyword, line 195: '... The marker MUST operate in the forw...' RFC 2119 keyword, line 205: '...TERVAL parameter MUST be configurable ...' RFC 2119 keyword, line 222: '... The PTR MUST be equal to or greater...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 13 has weird spacing: '...d is in full ...' == Line 17 has weird spacing: '...), its areas...' == Line 18 has weird spacing: '...ups may also ...' == Line 22 has weird spacing: '... and may be...' == Line 23 has weird spacing: '...opriate to u...' == (63 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2475' on line 270 looks like a reference -- Missing reference section? 'RFC2474' on line 266 looks like a reference -- Missing reference section? 'AFPHB' on line 278 looks like a reference -- Missing reference section? 'TON98' on line 274 looks like a reference -- Missing reference section? 'UDPTCP' on line 281 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Wenjia Fang 2 Internet Engineering Task Force Princeton University 3 Differentiated Services Working Group Nabil Seddigh 4 Expires March, 2000 Biswajit Nandy 5 Nortel Networks 6 October, 1999 8 A Time Sliding Window Three Colour Marker (TSWTCM) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Abstract 36 This draft defines a Time Sliding Window Three Colour Marker 37 (TSWTCM), which can be used as a component in a Diff-Serv traffic 38 conditioner [RFC2475, RFC2474]. The marker is intended to mark 39 packets that will be treated by the Assured Forwarding (AF) Per Hop 40 Behaviour (PHB) [AFPHB] in downstream routers. The TSWTCM meters a 41 traffic stream and marks packets to be either green, yellow or red 42 based on the measured throughput relative to two specified rates: 43 Committed Target Rate (CTR) and Peak Target Rate (PTR). 45 1.0 Introduction 47 The Time Sliding Window Three Colour Marker (TSWTCM) is designed to 48 mark packets of an IP traffic stream with colour of red, yellow or 49 green. The marking is performed based on the measured throughput of 50 the traffic stream as compared against the Committed Target Rate 51 (CTR) and the Peak Target Rate (PTR). The TSWTCM is designed to mark 52 packets contributing to sending rate below or equal to the CTR with 53 green colour, packets contributing to the portion of the rate between 54 the CTR and PTR are marked yellow. Packets causing the rate to exceed 55 PTR are marked with red colour. 57 The TSWTCM has been primarily designed for traffic streams that will 58 be forwarded based on the AF PHB in core routers. 60 The TSWTCM operates based on simple control theory principles of 61 proportionally regulated feedback control. 63 2.0 Overview of TSWTCM 65 The TSWTCM consists of two independent components: a rate estimator, 66 and a scheme to associate a colour (drop precedence) with each packet 67 (marker). The marker uses the algorithm specified in section 4 to 68 associate packets with a particular colour. 70 The rate estimator provides an estimate of the running average 71 bandwidth. It takes into account burstiness and smooths out its 72 estimate to approximate the longer-term measured sending rate of the 73 traffic stream. 75 The marker uses the estimated rate to probabilistically associate 76 packets with one of the three colours. Using a probablistic function 77 in the marker is beneficial to TCP flows as it reduces the likelihood 78 of dropping multiple packets within a window. It is also beneficial 79 for certain low bandwidth voice UDP flows. Such flows can benefit 80 from Forward Error Correction methods to reconstruct lost packets if 81 the number of consecutively lost packets is kept low. 83 +---------+ 84 | Rate | Rate 85 |estimator| ========== 86 | | | 87 +---------+ | 88 ^ V 89 | +---------+ 90 | | | 91 Packet ====================>| Marker |====> Marked packet stream 92 Stream | | (Green, Yellow and Red) 93 +---------+ 95 Figure 1. Block diagram for the TSWTCM 97 The colour of the packet is translated into a DS field packet 98 marking. The colours red, yellow and green translate into DS 99 codepoints representing drop precedence 2, 1 and 0 of a single AF 100 class respectively. 102 3.0 Rate Estimator 104 The Rate Estimator provides an estimate of the traffic stream's 105 arrival rate. This rate is a running average bandwidth of the traffic 106 stream over a window of time. This draft does not dictate a 107 particular algorithm for the Rate Estimator. 109 The Rate Estimator MAY operate in the Router Forwarding Path or as a 110 background function. In the latter case, the implementation MUST 111 ensure that the Estimator provides a reasonably accurate estimation 112 of the sending rate over a window of time. The Rate Estimator may 113 use all packets or may sample only certain packets to determine the 114 rate. 116 Examples of Rate Estimation algorithms include: exponential weighted 117 moving average (EWMA) and the rate estimation algorithm provided in 118 [TON98]. The following [TON98] is one possible example of a rate 119 estimator that is designed for TCP rate estimation. 121 ========================================================================= 122 | Initially: | 123 | | 124 | Win-Length = a constant; | 125 | avg-rate = CTR; | 126 | t-front = 0; | 127 | | 128 | Upon each packet's arrival, the rate estimator updates its variables: | 129 | | 130 | Bytes_in_win = avg-rate * Win-Length; | 131 | New_bytes = Bytes_in_win + pkt_size; | 132 | avg-rate = New_bytes/( now - t-front + Win-Length); | 133 | t-front = now; | 134 | | 135 | Where: | 136 | now = The time of the current packet arrival | 137 | pkt_size = The packet size in bytes of the arriving packet | 138 | avg-rate = Measured Arrival Rate of traffic stream | 139 | | 140 | | 141 | Figure 2. Example Rate Estimator Algorithm | 142 | | 143 ========================================================================= 145 4.0 Marker 147 The Marker determines the colour of a packet based on the algorithm 148 presented in Figure 3. 150 The overall effect of the marker on the packets of a traffic stream 151 is to ensure that: 153 - If the estimated average rate is less than or equal to the CTR, 154 packets of the stream are green. 156 - If the estimated average rate is greater than the CTR but less 157 than or equal to the PTR, packets are designated yellow with 158 probability P0 and designated green with probability (1-P0). 159 P0 is the fraction of packets contributing to the measured 160 rate beyond the CTR. 162 =================================================================== 163 | avg-rate = Estimated Avg Sending Rate of Traffic Stream | 164 | | 165 | if (avg-rate <= CTR) | 166 | the packet is green; | 167 | else if (avg-rate <= PTR) AND (avg-rate > CTR) | 168 | (avg-rate - CTR) | 169 | calculate P0 = ---------------- | 170 | avg-rate | 171 | with probability P0 the packet is yellow; | 172 | with probability (1-P0) the packet is green; | 173 | else | 174 | (avg-rate - PTR) | 175 | calculate P1 = ---------------- | 176 | avg-rate | 177 | (PTR - CTR) | 178 | calculate P2 = ----------- | 179 | avg-rate | 180 | with probability P1 the packet is red; | 181 | with probability P2 the packet is yellow; | 182 | with probability (1-(P1+P2)) the packet is green; | 183 | | 184 | Figure 3. TSWTCM Marking Algorithm | 185 =================================================================== 187 - If the estimated average rate is greater than the PTR, 188 packets are designated red with probability P1, designated 189 yellow with probability P2 and designated green with probability 190 (1-(P1+P2)). P1 is the fraction of packets contributing 191 to the measured rate beyond the PTR. P2 is the fraction of 192 packets contributing to that part of the measured rate 193 between CTR and PTR. 195 The marker MUST operate in the forwarding path of all packets. 197 5.0 Configuration 199 5.1 Rate estimator 201 The TSWTCM Rate Estimator is configured with one parameter - 202 AVG_INTERVAL. AVG_INTERVAL is the amount of history (recent time) 203 that should be used by the algorithm in estimating the rate. 205 The AVG_INTERVAL parameter MUST be configurable and MAY be specified 206 in either milliseconds or seconds. 208 Research into appropriate AVG_INTERVAL values for TSWTCM with TCP 209 flows can be found in [TON98]. 211 The Rate Estimator measures the average sending rate of the traffic 212 stream based on the bytes in the IP header and IP payload. It does 213 not include link-specific headers in its estimation of the sending 214 rate. 216 5.2 Marker 218 The TSWTCM marker is configured by assigning values to its two 219 traffic parameters: Committed Target Rate (CTR) and Peak Target Rate 220 (PTR). 222 The PTR MUST be equal to or greater than the CTR. 224 The CTR and PTR MAY be specifiable in bits per second or bytes per 225 second. 227 The TSWTCM can be configured so that it essentially operates with a 228 single rate. If the PTR is set to the same value as the CTR then all 229 packets will be coloured either green or red. There will be no yellow 230 packets. 232 If the PTR is set to link speed and the CTR is set below the PTR then 233 all packets will be coloured either green or yellow. There will be no 234 red packets. 236 6.0 Scaling properties 238 The TSWTCM can work with both sender-based service level agreements 239 and receiver-based service level agreements. 241 7.0 Services 243 There are no restrictions on the type of traffic stream for which the 244 TSWTCM can be utilized. It can be used to meter and mark individual 245 TCP flows, aggregated TCP flows, aggregates with both TCP and UDP 246 flows [UDPTCP] etc. 248 The TSWTCM can be used in conjunction with the AF PHB to create a 249 service where a service provider can provide decreasing levels of 250 bandwidth assurance for packets originating from customer sites. 252 With sufficient over-provisioning, customers are assured of mostly 253 achieving their CTR. Sending rates beyond the CTR will have lesser 254 assurance of being achieved. Sending rates beyond the PTR have the 255 least chance of being achieved due to high drop probability of red 256 packets. 258 Based on the above, the Service Provider can charge a tiered level of 259 service based on the final achieved rate. 261 8.0 Security Considerations 262 TSWTCM has no known security concerns. 264 9.0 References: 266 [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of 267 the Differentiated Services Field (DS Field) in the IPv4 and IPv6 268 Headers", Internet RFC 2474, December 1998. 270 [RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and 271 W. Weiss, "An Architecture for Differentiated Services", Internet 272 RFC 2475, December 1998. 274 [TON98] D.D. Clark, W. Fang, "Explicit Allocation of Best Effort 275 Packet Delivery Service", IEEE/ACM Transactions on Networking, August, 276 1998, Vol 6. No. 4, pp. 362-373. 278 [AFPHB] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, 279 "Assured Forwarding PHB Group", RFC 2597, June 1999 281 [UDPTCP] N. Seddigh, B. Nandy, P. Pieda, "Study of TCP and UDP 282 Interaction for the AF PHB," Internet Draft, 283 , September 1999. 285 10.0 Author Addresses 287 Wenjia Fang 288 Computer Science Dept. 289 35 Olden Street, 290 Princeton, NJ08540 291 Email: wfang@cs.princeton.edu 293 Nabil Seddigh 294 Nortel Networks, 295 3500 Carling Ave 296 Ottawa, ON, K2H 8E9 297 Canada 298 Email: nseddigh@nortelnetworks.com 300 Biswajit Nandy 301 Nortel Networks, 302 3500 Carling Ave 303 Ottawa, ON, K2H 8E9 304 Canada 305 Email: bnandy@nortelnetworks.com