idnits 2.17.00 (12 Aug 2021) /tmp/idnits26832/draft-you-taps-3red-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 2, 2015) is 2545 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. 'Performance-Evaluation' -- Possible downref: Non-RFC (?) normative reference: ref. 'QoS-Requirements' ** Downref: Normative reference to an Experimental RFC: RFC 6928 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Taps Working Group J. You 3 Internet-Draft Huawei 4 Intended status: Standards Track June 2, 2015 5 Expires: December 4, 2015 7 3RED Model for TAPS 8 draft-you-taps-3red-model-00 10 Abstract 12 This document defines a 3RED model to describe transport service 13 features. Applications can make use of the 3RED model to request 14 transport services from the TAPS by sending a request which contains 15 the explicit 3RED requirement parameters. The purpose of this 16 document is to enable applications to make use of various transport 17 services without customization or re-implementation. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 4, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. 3RED Model . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.4. Efficiency . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.5. Differentiation . . . . . . . . . . . . . . . . . . . . . 8 67 4. 3RED Implementation . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 70 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Application programmers face difficulty when they use the transport 77 services provided by the transport protocols other than TCP or UDP, 78 such as SCTP, DCCP, WebSockets, MPTCP, UDP-Lite, etc. The goal of 79 the TAPS working group is to help application and network stack 80 programmers by describing an (abstract) interface for applications to 81 make use of transport services. 83 This document is to define a 3RED model to describe transport service 84 features. Applications can make use of the 3RED model to request 85 transport services from the TAPS by sending a request which contains 86 the explicit 3RED requirement parameters. The purpose of this 87 document is to enable applications to make use of various transport 88 services without customization or re-implementation. 90 2. Terminology 92 This section contains definitions of terms used in this document. 94 3RED: Rate, Response, Reliability, Efficiency and Differentiation 96 BDP: Bandwidth-Delay Product 97 DCCP: Datagram Congestion Control Protocol 99 MPTCP: Multipath TCP 101 RTO: Retransmission Timeout 103 RTT: Round-Trip Time 105 SCTP: Stream Control Transmission Protocol 107 TCP: Transmission Control Protocol 109 UDP: User Datagram Protocol 111 UDP-Lite: Lightweight User Datagram Protocol 113 3. 3RED Model 115 +------------+ 116 | | 117 | APPs | 118 | | 119 +-----+------+ 120 | 121 | 122 3RED|Model 123 | 124 | 125 +-----v------+ 126 | | 127 | TAPS | 128 | | 129 +-----^------+ 130 | 131 | 132 | 133 | 134 | 135 +-----v------+ 136 | Transport | 137 | Protocols | 138 | | 139 +------------+ 141 Figure 1: 3RED Model 143 The APP extracts or derives the service requirement parameters (i.e. 144 3RED model) of the requested service, and then requests transport 145 services from the TAPS by sending a request which contains the 146 explicit 3RED requirement parameters. The usage of 3RED model is 147 depicted in Figure 1. 149 3.1. Rate 151 Rate, also known as bandwidth utilization rate, is the percentage of 152 the access bandwidth (in bit/s) that goes to the actually achieved 153 throughput when transmitting enough data. 155 For example, TCP Reno throughput is measured as: 157 Throughput <= min ( BW, WindowSize/RTT, MSS/(RTT*sqrt(p)) ) 159 BW: maximum bandwidth 161 WindowSize: congestion window size 163 RTT: round trip time 165 MSS: maximum segment size (fixed for each Internet path, typically 166 1460Bytes) 168 p: packet loss probability 170 For basic 4K streaming, it requires TCP throughput no less than 171 45Mbps. Assuming 100M network with RTT=50ms; p=0.01%; MSS=1460Bytes; 172 WindowSize=256KBytes. Then, 174 TCP Throughput <= min ( 100, 40.96, 23.36 ) 175 <= 23.36Mbps 177 As we can see TCP responds to loss of packets and RTT, this results 178 in poor throughput. TCP is inefficiency in high bandwidth-delay 179 product (BDP) networks. It has an inherent throughput bottleneck 180 that becomes obvious and severe with increased packet loss and 181 latency. 183 Table 1 shows the throughput and bandwidth utilization rate of 184 different congestion algorithms under different packet loss 185 conditions on a 100Mbps link with RTT=100ms when downloading a file. 186 The simulation topology is shown in Figure 2. 188 +---------+ 100M +---------+ +---------+ 189 | Sender +---------+ Switch | +---------+ Receiver| 190 +---------+ +-----+---+ | +---------+ 191 |100M | 192 | | 193 | | 194 | +---+-----+ 195 +-------+ Network | 196 | Emulator| 197 +---------+ 199 Figure 2: Simulation Topology 201 Table 1: Throughput and Rate 202 +--------+-----------------+-----------------+-----------------+ 203 | | p=0.1% | p=0.01% | p=0.005% | 204 +--------+----------+------+----------+------+----------+------+ 205 | |Throughput|Rate |Throughput|Rate |Throughput|Rate | 206 +--------+----------+------+----------+------+----------+------+ 207 |Cubic |641 KB/s |5.26% |3.14 MB/s |26.38%|4.93 MB/s |41.41%| 208 +--------+----------+------+----------+------+----------+------+ 209 |Westwood|1.19 MB/s |10.00%|3.97 MB/s |33.25%|5.41 MB/s |45.44%| 210 +--------+----------+------+----------+------+----------+------+ 211 |Veno |637 KB/s |5.23% |1.99 MB/s |16.72%|2.80 MB/s |23.52%| 212 +--------+----------+------+----------+------+----------+------+ 213 |Illinois|3.12 MB/s |26.21%|10.2 MB/s |85.68%|9.82 MB/s |82.49%| 214 +--------+----------+------+----------+------+----------+------+ 216 So Rate can be graded into 5 levels, as shown in Table 2. 218 Table 2: Rate 219 Rate Level Utilization Rate 220 ----------------------------------- 221 5 80%-100% 222 4 60%-80% 223 3 40%-60% 224 2 20%-40% 225 1 0%-20% 227 3.2. Response 229 Response (i.e. response time) is the time elapsed between the 230 emission of the first bit of a data and the accumulated data that is 231 able to make a service usable. 233 For web browsing, the response time is the time elapsed between the 234 emission of the first bit of a web page and the reception of the last 235 bit of that web page. For example, with an initial window of 3 236 segments (IW3), a transfer of 25 segments of web page will require 5 237 round trips to complete. While with the larger initial window (e.g. 238 IW=10 [RFC6928]), it will require only 2 round trips. An increase of 239 the initial window from 3 segments to 10 segments improves the 240 response latency. 242 For 4K streaming video, the response time is the time elapsed between 243 the emission of the first bit of a data and the accumulated data that 244 is ready to play 4K video. 246 For most non real time applications, such as web browsing, email, 247 FTP, a response time of 2-5 seconds is suggested. For most real time 248 applications, such as video conferencing, videophony, VoIP, a 249 response time of less than 150ms is suggested [QoS-Requirements]. 251 Table 3 shows the average response time of different congestion 252 algorithms when downloading files with different size on a 100Mbps 253 link with IW=10, meanwhile assuming a packet loss occurs during the 254 first RTT. The simulation topology is the same as shown in Figure 2. 256 Table 3: Response Time 257 +--------+-----------+-----------+-----------+-----------+-----------+ 258 | |Object Size|Object Size|Object Size|Object Size|Object Size| 259 | |10K Bytes |40K Bytes |100K Bytes |256K Bytes |3.75M Bytes| 260 +--------+-----------+-----------+-----------+-----------+-----------+ 261 |Cubic | 3RTT | 4RTT | 8RTT | 16RTT | 85RTT | 262 +--------+-----------+-----------+-----------+-----------+-----------+ 263 |Westwood| 3RTT | 5RTT | 10RTT | 18RTT | 110RTT | 264 +--------+-----------+-----------+-----------+-----------+-----------+ 265 |Veno | 3RTT | 4RTT | 8RTT | 13RTT | 98RTT | 266 +--------+-----------+-----------+-----------+-----------+-----------+ 267 |Illinois| 3RTT | 5RTT | 9RTT | 15RTT | 50RTT | 268 +--------+-----------+-----------+-----------+-----------+-----------+ 270 Response can be graded into 5 levels, as shown in Table 4. 272 Table 4: Response 273 Response Level Response Time 274 ------------------------------------ 275 5 <10ms 276 4 10-100ms 277 3 100-400ms 278 2 400-5000ms 279 1 >5000ms 281 3.3. Reliability 283 Reliability is measured by a maximum application-level packet loss 284 rate that is tolerable for the applications. 286 For web-browsing using HTTP over TCP, the expected data loss of HTTP 287 objects is zero since TCP is a reliable transfer protocol in which 288 erroneous packets are sent again using a retransmission policy. For 289 HDTV quality MPEG-2 video streams, the tolerable loss rate should be 290 less than 0.0001%. For broadcast audio streams, a tolerable loss rate 291 of no more than 0.1% is recommended. For VoIP, the tolerable loss 292 rate should be less than 1% in the G.729 codec [QoS-Requirements]. 293 When addressing the QoS needs of streaming video traffic, loss should 294 be no more than 5%. 296 So Reliability can be graded into 5 levels, as shown in Table 5. 298 Table 5: Reliability 299 Reliability Level Tolerable Loss Rate 300 --------------------------------------------- 301 5 0% 302 4 0%-0.1% 303 3 0.1%-1% 304 2 1%-5% 305 1 >5% 307 3.4. Efficiency 309 Efficiency, also known as bandwidth utilization efficiency, is the 310 percentage of network bottleneck bandwidth (in bit/s) that goes to 311 the actually achieved throughput when a number of competing 312 connections traverse the same network bottleneck. 313 [Performance-Evaluation] evaluates a set of TCP variants over a 314 single bottleneck network. 316 Table 6 shows the efficiency of different congestion algorithms under 317 different packet loss conditions when downloading files using 318 different number of flows. The simulation topology is shown in 319 Figure 3, Access Bandwidth= 1Gbps, Bottleneck Bandwidth=100Mbps, 320 RTT=100ms. 322 +---------+ 1G +---------+ +---------+ 323 | Sender +---------+ Switch | +---------+ Receiver| 324 +---------+ +-----+---+ | +---------+ 325 |100M | 326 | | 327 | | 328 | +---+-----+ 329 +-------+ Network | 330 | Emulator| 331 +---------+ 333 Figure 3: Simulation Topology 335 Table 6: Efficiency 336 +--------+-----------------------+-----------------+-----------------+ 337 | | p=0.1%: | p=0.01% | p=0.005% | 338 | +------+-------+--------+--------+--------+--------+--------+ 339 | |1 flow|5 flows|10 flows|1 flow |5 flows |1 flow |5 flows | 340 +--------+------+-------+--------+--------+--------+--------+--------+ 341 |Cubic |5% |23% |43% |25% |100% |43% |100% | 342 +--------+------+-------+--------+--------+--------+--------+--------+ 343 |Westwood|9% |67% |100% |33% |100% |40% |100% | 344 +--------+------+-------+--------+--------+--------+--------+--------+ 345 |Veno |5% |26% |53% |17% |85% |23% |100% | 346 +--------+------+-------+--------+--------+--------+--------+--------+ 347 |Illinois|26% |100% |100% |75% |100% |96% |100% | 348 +--------+------+-------+--------+--------+--------+--------+--------+ 350 Efficiency can be graded into 5 levels, as shown in Table 7. 352 Table 7: Efficiency 353 Efficiency Level Efficiency 354 ------------------------------------ 355 5 90%-100% 356 4 60%-80% 357 3 30%-60% 358 2 10%-30% 359 1 0%-10% 361 3.5. Differentiation 363 Differentiation means that a number of competing connections are 364 provided with differential opportunity to transfer data when they 365 sharing a single bottleneck link. 367 To provide a numerical measure reflecting the differential share 368 distribution across the various connections, the differentiation 369 index for one specified connection is defined as: 371 (maximum throughput from all competing connections 372 - the throughput of the specified connection) 373 --------------------------------------------------------------- 374 maximum throughput from all competing connections 376 For example, for three competing connections, their throughputs are 377 5Mbps, 4Mbps and 1Mbps respectively; then their differentiation 378 indexes are 0, 20% and 80% respectively. 380 Differentiation determines whether users or applications are 381 receiving a differential share of network resources when network is 382 congested. Application may specify differentiation to individual 383 media, in order to facilitate appropriate priority handling; for 384 example, when the congestion is experienced, it informs the 385 downstream nodes to downgrade their data transmission rate to some 386 degree and vice versa. 388 Assuming beta is a constant multiplication decrease factor applied 389 for window reduction at the time of loss in TCP Reno, the throughput 390 is measured as: 392 Throughput <= min ( BW, WindowSize/RTT, sqrt(1/beta-1/2)*MSS/(RTT*sqrt(p)) ) 394 So through adjusting beta, the throughput could be controlled. 395 Accordingly, the differentiation level could be implemented. 397 Differentiation can be graded into 5 levels, as shown in Table 8. 399 Table 8: Differentiation 400 Differentiation Level Differentiation 401 ---------------------------------------------- 402 5 0%-10% 403 4 10%-30% 404 3 30%-50% 405 2 50%-70% 406 1 >70% 408 4. 3RED Implementation 410 3RED (i.e. Rate, Response, Reliability, Efficiency and 411 Differentiation) usually cannot be satisfied at the same time. For 412 example, if Reliability would be preferred, then Rate and Response 413 have to be downgraded. When several flows share a single bottleneck 414 link, if Response would be preferred, then Efficiency may be 415 sacrificed. 417 The application could belong to end-user or service provider. For 418 end-user, it may care more about Rate, Response and Reliability; 419 however for service provider, it may care more about Efficiency and 420 Differentiation. 422 5. IANA Considerations 424 This document has no actions for IANA. 426 6. Security considerations 428 This document does not introduce any new security considerations. 430 7. Acknowledgement 432 TBD. 434 8. Normative References 436 [Performance-Evaluation] 437 Alrshah, M. and M. Othman, "Performance Evaluation of 438 Parallel TCP, and its Impact on Bandwidth Utilization and 439 Fairness in High-BDP Networks Based on Test-bed", 2013 440 IEEE 11th Malaysia International Conference on 441 Communications, November 2013. 443 [QoS-Requirements] 444 Chen, R., Farley, T., and N. Ye, "QoS Requirements of 445 Network Applications on the Internet", Information 446 Knowledge Systems Management, January 2004. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 452 "Increasing TCP's Initial Window", RFC 6928, April 2013. 454 Author's Address 456 Jianjie You 457 Huawei 458 101 Software Avenue, Yuhuatai District 459 Nanjing, 210012 460 China 462 Email: youjianjie@huawei.com