idnits 2.17.1 draft-lochin-ietf-tsvwg-gtfrc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 a Security Considerations section. ** 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. ** The abstract seems to contain references ([2]), 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 156: '...he target rate g MUST have a default v...' RFC 2119 keyword, line 162: '...to the session. This knowledge MAY be...' RFC 2119 keyword, line 323: '... sender MUST emit to X. In the case ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2006) is 6463 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) ** Obsolete normative reference: RFC 3448 (ref. '2') (Obsoleted by RFC 5348) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2697 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lochin 3 Internet-Draft National ICT Australia 4 Expires: February 2, 2007 L. Dairaine 5 ENSICA - LAAS/CNRS 6 G. Jourjon 7 National ICT Australia 8 August 2006 10 Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network 11 draft-lochin-ietf-tsvwg-gtfrc-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 2, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo introduces gTFRC, a TCP-Friendly Rate Control providing 45 throughput guarantee over the DiffServ/AF class. gTFRC is largely 46 based on TFRC [2]. It provides a mean to take into account the 47 quality of service negotiated with the network. As a result, the 48 mechanism is able to reach a minimum throughput guarantee whatever 49 the flow's RTT and target rate. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Guaranteed TCP Friendly Rate Control . . . . . . . . . . . . . 4 55 2.1. Transmit rate equation . . . . . . . . . . . . . . . . . . 4 56 2.2. Target rate default value . . . . . . . . . . . . . . . . 4 57 2.3. Target rate setting . . . . . . . . . . . . . . . . . . . 4 58 3. Simulation of gTFRC . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Model and hypothesis . . . . . . . . . . . . . . . . . . . 5 60 3.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.4.1. Security concern . . . . . . . . . . . . . . . . . . . 7 64 3.4.2. Case of under-provisioned network . . . . . . . . . . 8 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . . . 11 70 1. Introduction 72 This memo introduces gTFRC, a TCP-Friendly rate control providing 73 throughput guarantee for unicast flows over the DiffServ/AF class. 74 gTFRC is an adaptation of the TCP-friendly Rate Control (TFRC) [2]. 75 This document only specifies the modification of TFRC and do not 76 present the core TFRC mechanism that remains unchanged. 78 TFRC is a congestion control mechanism for unicast flows operating in 79 a best-effort Internet environment [2]. Based on the TCP throughput 80 equation, it is designed to be reasonably fair when competing for 81 bandwidth with TCP flow. It generates a flow with a much lower 82 variation of throughput over time than TCP. As a result, it is 83 particularly suitable for multimedia application such as video 84 streaming or telephony over Internet. 86 The DiffServ Assured Forwarding Class [1] has been designed to 87 provide a guaranteed minimal throughput that many multimedia 88 applications can take advantage of. The service offers is called 89 Assured Service (AS) and built over the AF PHB. The minimum 90 guaranteed throughput (also called target rate) is supposed to be 91 known after a negotiation phase involving application level software. 92 Adaptive application can make use of this guarantee, allowing to rely 93 on a minimum rate when the network is congested, and possibly using 94 higher rate otherwise. In this service class, a congestion control 95 is required in such a way to discover the current available bandwidth 96 and share it fairly with other competing flows. Nevertheless, due to 97 the minimum bandwidth guarantee, the congestion control mechanism 98 should never reduce the flow throughput at a value less than the 99 negotiated guaranty. 101 When TFRC is used over a DiffServ/AF network, in spite of a good 102 behavior in term of available bandwidth sharing, it not always reach 103 the target rate. Even if the target rate is finally reached, a long 104 time can happened (several tens of seconds) before the flow rate 105 converges to this value. Then, depending on end-to-end delay and the 106 loss probability of the various connections, the application does not 107 obtained the requested target rate it should, even if the underlying 108 network provides an adequate throughput guarantee. 110 This document suggests a simple approach to solve this problem. A 111 minimal adaption of TFRC allows the application to quickly reach its 112 target rate whatever the RTT value of the application's flow, while 113 still sharing fairly the available bandwidth over the various TCP- 114 friendly connections. 116 2. Guaranteed TCP Friendly Rate Control 118 In the context of the Additive Increase Multiplicative Decrease 119 approaches like TCP, the only way to obtain a service differentiation 120 with TCP protocol is to use DiffServ traffic conditioners. Indeed, 121 the AIMD principle do not use the instantaneous TCP throughput as an 122 input value for its congestion control and then can not make direct 123 use of the target rate value. On the contrary, to compute the actual 124 sending rate, TFRC uses the current rate in conjunction with the RTT 125 and the loss event of flow. Nevertheless, the TCP equation that 126 drives TFRC does not take into account the minimum guaranteed part of 127 the network capacity. 129 gTFRC is made aware of the target rate value which is integrated into 130 the transmit rate equation. Thanks to this knowledge, the 131 application's flow is sent in conformance with the negotiated QoS 132 while staying TCP-friendly in its out-profile part. 134 2.1. Transmit rate equation 136 The transmit rate is computed at sender side as the maximum between 137 the TFRC rate estimation and the target rate. The throughput 138 equation used in gTFRC is: 140 G = max(g, X) 142 Where: 144 G is the transmit rate in bytes/second. 146 g is the target rate in bytes/second. 148 X is the transmit rate in bytes/second computed by the TCP 149 throughput algorithm specified in RFC 3448 [2]. 151 The rest of the gTFRC mechanism follows entirely the TFRC 152 specification given in RFC 3448 [2]. 154 2.2. Target rate default value 156 The target rate g MUST have a default value of zero byte/second. In 157 this case, the default behavior of gTFRC corresponds to TFRC. 159 2.3. Target rate setting 161 gTFRC requires the knowledge of the target rate the DiffServ/AF 162 network service provides to the session. This knowledge MAY be 163 achieved by the use of a new socket option. 165 3. Simulation of gTFRC 167 3.1. Model and hypothesis 169 gTFRC has been evaluated over a DiffServ network using ns-2.28 170 simulator. gTFRC has been implemented from the TFRC ns-2 code base. 171 The Nortel DiffServ model [3] has been used as QoS testbed. 173 The network architecture is shown in the following figure. 175 ---- ---- 176 |s1|-------- --------- |r1| 177 ---- 10 Mb \ / 10 Mb ---- 178 5 ms \ / x ms 179 \------ ------ ------/ 180 |edge|-------|core|-------|edge| 181 /------ ------ ------\ 182 / 10 Mb 1 Mb \ 183 ---- / 5 ms 10ms \ ---- 184 |s2|-------- --------- |r2| 185 ---- 10 Mb 10 Mb ---- 186 5 ms y ms 188 where x and y take different RTT values in function of the 189 experiment. 191 Figure 1 193 In these experiments, the objective was to compare the performance of 194 TFRC and gTFRC. 196 The simulation has been achieved with the two following scenarios: 198 1. the network is exactly-provisioned (it means there is no excess 199 bandwidth for the out-profile traffic). 201 2. network is over-provisioned (when there is excess bandwidth). 203 A network is under-provisioned when the amount of in-profile traffic 204 is higher than the resource allocated to the AF class. This case is 205 considered as a bad network provision and then is excluded from the 206 field of this study. 208 In the simulations: 210 o packet size is fixed to 1500 bytes; 211 o we use a two colors token bucket marker with a bucket size of 10^4 212 bytes defined in RFC 2697 [5]; 214 o the queues size are 50 packets and RIO parameters are: 215 (MIN_out,MAX_out,P_out, MIN_in,MAX_in,P_in) = 216 (10,20,0.1,20,40,0.02); 218 o the bottleneck between the core and the egress router is 219 1000Kbits/s; 221 o measurements are carried during 100 seconds. 223 For each experiments, we evaluate the throughput at the server side 224 and compute the instantaneous throughput and the average throughput 225 for the experiment. We resport the instantaneous throughput values 226 at 20s, 50s and 100s. Because some flow can cross one or several 227 DiffServ domains and then, obtain a very large RTT difference, we 228 compare flows with a high RTT difference (i.e., 600ms). 230 3.2. Results 232 The following table presents the comparative results between TFRC and 233 gTFRC for an exactly provisioned network. 235 +========+=======+========+=======+=======+=======+=======+ 236 |Protocol| RTT | Target | After | After | After | | 237 | #flow | (ms) | (Kb/s) | 20s | 50s | 100s |Average| 238 +========+=======+========+=======+=======+=======+=======+ 239 | TFRC#1 | 640ms | 800 | 376 | 584 | 784 | 571 | 240 | TFRC#2 | 40ms | 200 | 584 | 416 | 232 | 419 | 241 +--------+-------+--------+-------+-------+-------+-------+ 242 |gTFRC#1 | 640ms | 800 | 376 | 784 | 800 | 722 | 243 |gTFRC#2 | 40ms | 200 | 584 | 224 | 200 | 271 | 244 +========+=======+========+=======+=======+=======+=======+ 246 Figure 2 247 The following table presents the comparative results between TFRC and 248 gTFRC for an over-provisioned network with either same or different 249 RTT values for the competing flows. 251 +========+=======+========+=======+=======+=======+=======+ 252 |Protocol| RTT | Target | After | After | After | | 253 |Protocol| (ms) | (Kb/s) | 20s | 50s | 100s |Average| 254 +========+=======+========+=======+=======+=======+=======+ 255 | TFRC#1 | 250ms | 700 | 296 | 744 | 744 | 654 | 256 | TFRC#2 | 250ms | 100 | 704 | 256 | 248 | 319 | 257 +--------+-------+--------+-------+-------+-------+-------+ 258 |gTFRC#1 | 250ms | 700 | 744 | 800 | 696 | 727 | 259 |gTFRC#2 | 250ms | 100 | 256 | 200 | 304 | 254 | 260 +========+=======+========+=======+=======+=======+=======+ 261 | TFRC#1 | 640ms | 600 | 376 | 520 | 608 | 504 | 262 | TFRC#2 | 40ms | 200 | 584 | 480 | 400 | 489 | 263 +--------+-------+--------|-------+-------+-------+-------+ 264 |gTFRC#1 | 640ms | 600 | 376 | 600 | 600 | 554 | 265 |gTFRC#2 | 40ms | 200 | 584 | 408 | 400 | 439 | 266 +========+=======+========+=======+=======+=======+=======+ 268 Figure 3 270 Extended results of this simulation campaign are available in [6] 272 3.3. Analysis 274 From these simulations, we see that gTFRC allows to reach a target 275 rate more quickly than TFRC. This is true whatever the RTT or the 276 target rate of the flow. The reason is obvious since at the first 277 rate decrease evaluation of the algorithm, gTFRC returns a rate equal 278 to the target rate. If the evaluated rate is higher than the target 279 rate, the classical TFRC algorithm is applied. Concerning the 280 DiffServ network behavior, the use of gTFRC raises the number of in- 281 profile packets in the network and avoid the problem of the bandwidth 282 sharing of the out-profile traffic. For information purpose, 283 concerning the Figure 2, between TFRC and gTFRC, the number of in- 284 profile traffic raises from 73.7% to 90.16%. 286 3.4. Discussion 288 3.4.1. Security concern 290 As we give the possibility to the application to instantiate through 291 a setsockopt() function the target rate negotiated between the QoS 292 network and the application, we can imagine that a misbehaving person 293 could abuse of this functionality by giving an higher value to the 294 guarantee g. In this case, the misbehaving person sends an UDP-like 295 traffic and increases its out-profile traffic. In the context of a 296 DiffServ/AF class, the edge router will still mark in-profile the 297 packets in respect with the negotiated profile and out-profile the 298 excess part. As as result, in case of network congestion, the 299 dropping precedence set in the core router will drop this excess 300 traffic. The misbehaving person will not take advantage of the 301 situation as the number of losses of its own flow increases as well. 302 Then, the in-profile traffic remains protected in the network and the 303 out-profile traffic perceives a kind of flooding attack. As the out- 304 profile traffic is a best-effort traffic, the use of gTFRC does not 305 disturb the DiffServ network. 307 3.4.2. Case of under-provisioned network 309 In the context of a DiffServ/AF class, a network is under-provisioned 310 when the amount of in-profile traffic is higher than the resource 311 allocated to the AF class. This case could occur if the Bandwidth 312 Broker [4] of a DiffServ network sends or receives false information. 313 In a DiffServ context, if the gTFRC source emits below its target 314 rate and if the gTFRC flow gets losses, it means that the in-profile 315 traffic is no guaranteed anymore in the network. In order to tackle 316 this problem, two approaches are possible. The first one is to 317 pursue to emit at the guarantee g. This behaviour is legitimate 318 since the service provider must provide to the client the service 319 that it paid for. The second one is to react to this congestion. 320 This can be done by adding a second threshold (y) to gTFRC . This 321 threshold can be applied as following: if the emission rate X 322 returned by the receiver is y times below the target rate g, the 323 sender MUST emit to X. In the case where X < g/y, it means that a 324 bunch of losses has occurred in the in-profile part and that the 325 congestion could be due to a wrong setting. We believe that this 326 problem should not be solved inside gTFRC itself and should remain 327 under the responsibility of the service provider. 329 4. Acknowledgements 331 This research work has been conducted in the framework of the EuQoS 332 European project (http://www.euqos.org). The authors has been 333 supported by funding from National ICT Australia (NICTA). The 334 authors are also grateful Sally Floyd and Mark Allman and James M. 335 Polk for useful discussions. 337 5. References 339 [1] Heinanen, J., Weiss, W., Wroclawski, J., and J. Heinanen, 340 "Assured Forwarding PHB Group", RFC 2597, STD 1, June 1999. 342 [2] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly 343 Rate Control (TFRC): Protocol Specification", RFC 3448, STD 1, 344 January 2003. 346 [3] Pieda, P., Ethridge, J., Baines, M., and F. Shallwani, "A 347 Network Simulator Differentiated Services Implementation", Open 348 IP , Nortel Networks, available at http://www.isi.edu/nsman/ns, 349 July 2000. 351 [4] Nichols, K., Jacobson, V., and L. Zhang, "A two-bit 352 differentiated services architecture for the internet", 353 RFC 2638, STD 1, July 1999. 355 [5] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", 356 RFC 2697, STD 1, September 1999. 358 [6] Lochin, E., Dairaine, L., and G. Jourjon, "gTFRC: a QoS-aware 359 congestion Control Algorithm", 5th International Conference on 360 Networking (ICN'2006) , October 2005. 362 Authors' Addresses 364 Emmanuel Lochin 365 National ICT Australia 366 Australia Technology Park 367 Eveleigh, NSW 1430 368 Australia 370 Phone: +61 8374 5541 371 Email: Emmanuel.Lochin@nicta.com.au 372 URI: http://www.nicta.com.au/ 374 Laurent Dairaine 375 ENSICA - LAAS/CNRS 376 1, place Emile Blouin 377 Toulouse, Cedex 5 31056 378 France 380 Phone: +33 5 61 61 85 00 381 Email: Laurent.Dairaine@ensica.fr 382 URI: http://www.ensica.fr/ 384 Guillaume Jourjon 385 National ICT Australia 386 Australia Technology Park 387 Eveleigh, NSW 1430 388 Australia 390 Phone: +61 8374 5206 391 Email: Guillaume.Jourjon@nicta.com.au 392 URI: http://www.nicta.com.au/ 394 Intellectual Property Statement 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org. 418 Disclaimer of Validity 420 This document and the information contained herein are provided on an 421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 423 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 424 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 425 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 428 Copyright Statement 430 Copyright (C) The Internet Society (2006). This document is subject 431 to the rights, licenses and restrictions contained in BCP 78, and 432 except as set forth therein, the authors retain all their rights. 434 Acknowledgment 436 Funding for the RFC Editor function is currently provided by the 437 Internet Society.