idnits 2.17.1 draft-you-tsvwg-latency-loss-tradeoff-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2016) is 2965 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) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 3248 == Outdated reference: A later version (-01) exists of draft-briscoe-aqm-dualq-coupled-00 -- No information found for draft-hurley-alternative-best-effort - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Tsvwg Working Group J. You 3 Internet-Draft Huawei 4 Intended status: Standards Track M. Welzl 5 Expires: September 14, 2016 University of Oslo 6 B. Trammell 7 M. Kuehlewind 8 ETH Zurich 9 K. Smith 10 Vodafone Group 11 March 13, 2016 13 Latency Loss Tradeoff PHB Group 14 draft-you-tsvwg-latency-loss-tradeoff-00 16 Abstract 18 This document defines a PHB (Per-Hop Behavior) group called Latency 19 Loss Tradeoff (LLT). The LLT group is intended to provide delivery 20 of IP packets in two classes of services: a low-loss service (Lo 21 service) and a low-latency service (La service). The LLT group 22 enables an application to request treatment for either low-loss or 23 low-latency at a congested network link. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 14, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . 3 68 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Existing DSCP PHBs . . . . . . . . . . . . . . . . . . . 5 71 3.1.1. Default PHB . . . . . . . . . . . . . . . . . . . . . 5 72 3.1.2. Class Selector PHB . . . . . . . . . . . . . . . . . 5 73 3.1.3. Assured Forwarding PHB Group . . . . . . . . . . . . 5 74 3.1.4. Expedited Forwarding PHB . . . . . . . . . . . . . . 6 75 3.1.5. Voice Admit PHB . . . . . . . . . . . . . . . . . . . 6 76 3.1.6. Delay Bound PHB . . . . . . . . . . . . . . . . . . . 6 77 3.2. Incentives . . . . . . . . . . . . . . . . . . . . . . . 6 78 4. Definition of LLT PHB . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Goal and Scope of LLT . . . . . . . . . . . . . . . . . . 7 80 4.2. Description of LLT behavior . . . . . . . . . . . . . . . 8 81 4.2.1. Implementation Considerations . . . . . . . . . . . . 8 82 4.3. Microflow misordering . . . . . . . . . . . . . . . . . . 9 83 4.4. Recommended Codepoints . . . . . . . . . . . . . . . . . 9 84 4.5. Mutability . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.6. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.7. Interaction with other PHBs . . . . . . . . . . . . . . . 9 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 7.2. Informative References . . . . . . . . . . . . . . . . . 11 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 94 1. Introduction 96 Different applications have different communication requirements 97 [QoS]. In interactive applications of real-time sound transmission, 98 as well as in virtual reality, the overall one-way delay needs to be 99 short in order to give the user an impression of a real-time 100 response. Yet, these applications may be able to tolerate high loss 101 rates. In conventional text and data networking, delay thresholds 102 are the least stringent. The response time in these types of 103 applications can increase from 2 to 5 seconds before becoming 104 unacceptable. However, given that increased loss reduces the 105 throughput of TCP, these applications desire minimal loss. 107 The network resources consist primarily of buffers and link 108 bandwidth. Operators often favor high utilization of bottleneck 109 links at the price of high queuing delay. This is beneficial for 110 non-real time applications. However, this may be considered 111 unacceptable for some real-time applications. The proposed LLT group 112 enables an application to choose between low-latency and low-loss at 113 a congested network link [ABE] [RD]. Typically, an interactive 114 application with real-time deadlines, such as audio, will mark most 115 of its packets as a low-latency service. In contrast, an application 116 that transfers bulk data will mark most of its packets as a low-loss 117 service. The LLT group can be thought of as allowing an application 118 to trade loss for delay by marking packets low-latency service (La) 119 or to trade delay for loss by marking packets low-loss service (Lo). 121 2. Terminology 123 This section contains definitions for terms used frequently 124 throughout this document. 126 2.1. Abbreviations and acronyms 128 DS: Differentiated Service 130 PHB: Per-Hop Behavior 132 LLT: Latency Loss Tradeoff 134 TCA: Traffic Conditioning Agreement 136 TCP: Transmission Control Protocol 138 2.2. Definitions 140 DS-capable: capable of implementing differentiated services as 141 described in this architecture; usually used in reference to a 142 domain consisting of DS-compliant nodes. 144 DS codepoint: a specific value of the DSCP portion of the DS 145 field, used to select a PHB. 147 DS-compliant: enabled to support differentiated services functions 148 and behaviors as defined in [RFC2474], this document, and other 149 differentiated services documents; usually used in reference to a 150 node or device. 152 DS field: the IPv4 header TOS octet or the IPv6 Traffic Class 153 octet when interpreted in conformance with the definition given in 154 [RFC2474]. The bits of the DSCP field encode the DS codepoint, 155 while the remaining bits are currently unused. 157 Low-latency service (La service): puts an emphasis on low queuing 158 delay at a congested network link. It allows an application to 159 trade loss for delay. 161 Low-loss service (Lo service): puts an emphasis on low packet loss 162 rate at a congested network link. It allows an application to 163 trade delay for loss. 165 Per-Hop-Behavior (PHB): the externally observable forwarding 166 behavior applied at a DS-compliant node to a DS behavior 167 aggregate. 169 PHB group: a set of one or more PHBs that can only be meaningfully 170 specified and implemented simultaneously, due to a common 171 constraint applying to all PHBs in the set such as a queue 172 servicing or queue management policy. A PHB group provides a 173 service building block that allows a set of related forwarding 174 behaviors to be specified together (e.g., four dropping 175 priorities). A single PHB is a special case of a PHB group. 177 Traffic Conditioning Agreement (TCA): an agreement specifying 178 classifier rules and any corresponding traffic profiles and 179 metering, marking, discarding and/or shaping rules which are to 180 apply to the traffic streams selected by the classifier. A TCA 181 encompasses all of the traffic conditioning rules explicitly 182 specified within a SLA along with all of the rules implicit from 183 the relevant service requirements and/or from a DS domain's 184 service provisioning policy. 186 3. Problem Statement 188 3.1. Existing DSCP PHBs 190 3.1.1. Default PHB 192 A default Per-Hop Behavior (PHB) [RFC2474] MUST be available in a 193 DiffServ (DS)-compliant node. This is the common, best-effort 194 forwarding behavior available in existing routers as standardized in 195 [RFC1812]. Codepoint '000000' from Pool 1 is used as the default PHB 196 value. In this document, packets received with the Default PHB is 197 treated as Lo service on the LLT-compliant router. 199 3.1.2. Class Selector PHB 201 The Class Selector (CS) PHB [RFC2474] is introduced for backwards 202 compatibility with use of the IPv4 Precedence field. Any of the 203 eight codepoints in the range 'xxx000' (where 'x' may equal '0' or 204 '1') from Pool 1 is assigned as Class Selector codepoint. The CS PHB 205 does not match the services that LLT PHB is trying to deliver. 207 3.1.3. Assured Forwarding PHB Group 209 The Assured Forwarding (AF) PHB group [RFC2597] allows the operator 210 to provide assured forwarding of IP packets as long as the aggregate 211 traffic does not exceed the subscribed rate. Traffic that exceeds 212 the subscribed rate is not delivered with as high a probability as 213 the traffic that is within the rate. 215 The AF PHB group provides delivery of IP packets in four 216 independently forwarded AF classes. Within each AF class, an IP 217 packet can be assigned one of three different levels of drop 218 precedence. The combination of classes and drop precedence yields 219 twelve separate DSCP encodings from AF11 through AF43 as follows: 221 Class 1 Class 2 Class 3 Class 4 222 +----------+-----------+-----------+----------+ 223 Low Drop Prec | 001010 | 010010 | 011010 | 100010 | 224 Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | 225 High Drop Prec | 001110 | 010110 | 011110 | 100110 | 226 +----------+-----------+-----------+----------+ 228 The AF PHB does not match the services that LLT PHB is trying to 229 deliver. 231 3.1.4. Expedited Forwarding PHB 233 Expedited Forwarding (EF) PHB [RFC3246] is intended to provide a 234 building block for low delay, low jitter and low loss services by 235 ensuring that the EF aggregate is served at a certain configured 236 rate. EF traffic requires a strict admission control mechanism. 237 Codepoint '101110' is recommended for the EF PHB. The EF PHB does 238 not match the services that LLT PHB is trying to deliver. 240 3.1.5. Voice Admit PHB 242 The Voice Admit (VA) PHB [RFC5865] has identical characteristics to 243 the Expedited Forwarding PHB. However Voice Admit traffic is also 244 admitted by the network using a Call Admission Control (CAC) 245 procedure. The recommended DSCP for Voice Admit is '101100', 246 parallel with the existing EF codepoint '101110'. The VA PHB does 247 not match the services that LLT PHB is trying to deliver. 249 3.1.6. Delay Bound PHB 251 The Delay Bound (DB) PHB [RFC3248] requires a bound on the delay of 252 packets due to other traffic in the network. Two parameters - capped 253 arrival rate (R) and a 'score' (S), are defined and related to the 254 target delay variation bound. An experimental codepoint '101111' is 255 suggested for DB behavior. In this document, there's no specific 256 bound on the delay, the LLT PHB only indicates the tradeoff. 258 3.2. Incentives 260 The primary goal of differentiated services is to allow different 261 levels of service to be provided for traffic streams on a common 262 network infrastructure. Hence, an adversary may be able to obtain 263 better service by modifying the DS field to codepoints indicating 264 behaviors used for enhanced services or by injecting packets with the 265 DS field set to such codepoints. Such theft-of-service ([RFC2474], 266 [RFC2475]) becomes a denial-of-service attack when the modified or 267 injected traffic depletes the resources available to forward it and 268 other traffic streams. 270 DS ingress nodes must condition all traffic entering a DS domain to 271 ensure that it has acceptable DS codepoints. This means that the 272 codepoints must conform to the applicable TCA(s) (Traffic 273 Conditioning Agreement) [RFC2475] and the domain's service 274 provisioning policy. Packets received with an unacceptable 275 codepoints must either be discarded or must have their DS codepoints 276 modified to acceptable values before being forwarded. For example, 277 an ingress node receiving traffic from a domain with which no 278 enhanced service agreement exists may reset the DS codepoint to the 279 Default PHB codepoint. However, the Default PHB (i.e. best-effort 280 forwarding) cannot meet the diverse needs of different Internet 281 applications. 283 The objective of the LLT PHB group is to retain the best-effort 284 service while providing low delay to real-time applications at the 285 expense of increased loss or providing low loss to non real-time 286 applications at the expense of increased delay. This requires 287 Internet applications to mark their traffic with appropriate 288 codepoint values. Since the low-loss service is neither better nor 289 worse than the low-latency service but is merely different, there is 290 no incentive for Internet applications to abuse such codepoints, and 291 no need for admission control. 293 4. Definition of LLT PHB 295 The LLT group provides forwarding of IP packets in two classes of 296 service: a low-loss service (Lo) and a low-latency service (La). The 297 LLT group enables an application to choose between low latency and 298 low loss at a congested network link. The packets marked as low- 299 latency service receive little queuing delay. The packets marked as 300 low-loss service receive at least as much throughput as they would in 301 a legacy best effort network. La-marked packets are more likely to 302 be dropped during periods of congestion than the Lo-marked packets. 303 Note that among the two services, neither of the two has priority 304 over the other. 306 4.1. Goal and Scope of LLT 308 The LLT group may be used by a network operator in two distinct ways: 309 either as a separate service, or as a replacement of the flat 310 (existing) best-effort IP service. 312 A DS (Differentiated Services) node SHOULD implement the LLT group. 313 It MAY allocate a configurable, minimum amount of forwarding 314 resources (buffer space and bandwidth) to LLT group. 316 The LLT group MAY also be configurable to receive more forwarding 317 resources than the minimum when excess resources are available from 318 other PHB groups. This is beyond the scope of this document. 320 The LLT PHB definition does NOT mandate or recommend any particular 321 method for achieving LLT behavior. 323 4.2. Description of LLT behavior 325 To support the LLT group on an output link, the router can maintain 326 two FIFO (First-In First-Out) queues referred to as a Lo (Loss- 327 sensitive) queue and La (Latency-sensitive) queue for packets 328 destined to the link. Depending on whether an incoming packet is 329 marked for the low-loss or low-latency service, the router appends 330 the packet to the Lo or La queue respectively. The packets within 331 each queue are served in the FIFO order. The scheduling is work- 332 conserving. 334 A router can support the desired delay differentiation between the Lo 335 and La services through buffer sizing for the Lo and La queues, and 336 by ensuring that the La queue does not grow larger than the Lo queue. 337 As common in current Internet routers, the size of the Lo buffer is 338 chosen large enough so that the oscillating transmission of TCP 339 (Transmission Control Protocol) and other legacy end-to-end 340 congestion control protocols utilizes the available link rate fully. 341 The La buffer is configured to a much smaller dynamic size to ensure 342 that queuing delay for each forwarded packet of the La class is low. 343 The assurance of low maximum queuing delay is attractive for delay- 344 sensitive applications and easily verifiable by outside parties. 346 4.2.1. Implementation Considerations 348 This document does not specify any particular implementation method 349 for achieving LLT behavior. Some LLT-like implementations may refer 350 to [I-D.hurley-alternative-best-effort], [RD] and 351 [I-D.briscoe-aqm-dualq-coupled]. 353 [I-D.hurley-alternative-best-effort] marks every best effort packet 354 as either green or blue. Green packets receive a low, bounded delay 355 at every hop, the value of the per-hop delay bound configured by the 356 operator. However, when transmitting more aggressively, the green 357 users can enjoy both a higher rate and lower queuing delay than those 358 of the blue users, which weakens the incentives for incremental 359 deployment. [RD] proposes Rate-Delay (RD) service enabling a user to 360 choose either a higher transmission rate or low queuing delay. The R 361 (Rate) service is like Lo service while D (Delay) service is like La 362 service. 364 Note that both classes defined in this document do not provide any 365 absolute guarantees on the loss rate or delay a packet will 366 experience. Using these classes only provides a relative treatment 367 compared to the other class. Depending on the amount of traffic 368 arriving per class, it is possible for traffic in the La class to 369 experience more delay than traffic in the Lo class. However, this 370 may be circumvented by using scheduling mechanisms, for example, by 371 adjusting the scheduling function that assigns traffic to the Lo and 372 La queues, or by adjusting the scheduling weight based on the average 373 load in each class. Moreover, the delay experienced by La traffic is 374 always bounded by the length of the La queue. The particular 375 implementation is beyond the scope of this document. 377 When a DS-compliant node claims to implement the LLT PHB, the 378 implementation MUST conform to the specification given in this 379 document. 381 4.3. Microflow misordering 383 The packets within each queue are served in the FIFO order. Packets 384 belonging to a single microflow within the LLT aggregate SHOULD NOT 385 experience re-ordering in normal operation of the device when passing 386 through. 388 4.4. Recommended Codepoints 390 Recommended codepoints for the LLT PHB group are given below. 392 Low-loss service: 000001 393 Low-latency service:000101 395 4.5. Mutability 397 Packets marked for LLT PHB MAY be remarked at a DS domain boundary 398 only to other codepoints that satisfy the LLT PHB. Packets marked 399 for LLT PHBs SHOULD NOT be demoted or promoted to another PHB by a DS 400 domain. 402 4.6. Tunneling 404 When LLT packets are tunneled, the tunneling packets must be marked 405 as LLT. 407 4.7. Interaction with other PHBs 409 Other PHBs and PHB groups may be deployed in the same DS node or 410 domain with the LLT PHB. 412 Packets received with the Default PHB SHOULD be treated as Lo service 413 as default by the LLT PHB aware device. [RD] has proved that La 414 service does not hurt Lo service. 416 Packets received with the LLT PHB SHOULD be treated as Default PHB as 417 default by the LLT PHB unaware device. 419 5. Security Considerations 421 Internet applications cannot benefit from wrongly indicating low-loss 422 or low-latency as they have to pay the expense of high delay or high 423 loss as a tradeoff. Hence there is no incentive for Internet 424 applications to set the wrong codepoints. 426 6. IANA Considerations 428 This document suggests two experimental codepoints, 000001/000101, in 429 Pool 3 of the code space defined by [RFC2474]. 431 7. References 433 7.1. Normative References 435 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 436 RFC 1812, DOI 10.17487/RFC1812, June 1995, 437 . 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 445 "Definition of the Differentiated Services Field (DS 446 Field) in the IPv4 and IPv6 Headers", RFC 2474, 447 DOI 10.17487/RFC2474, December 1998, 448 . 450 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 451 and W. Weiss, "An Architecture for Differentiated 452 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 453 . 455 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 456 "Assured Forwarding PHB Group", RFC 2597, 457 DOI 10.17487/RFC2597, June 1999, 458 . 460 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 461 J., Courtney, W., Davari, S., Firoiu, V., and D. 462 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 463 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 464 . 466 [RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J., 467 Halpern, J., Kumar, B., and J. Schnizlein, "A Delay Bound 468 alternative revision of RFC 2598", RFC 3248, 469 DOI 10.17487/RFC3248, March 2002, 470 . 472 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 473 Services Code Point (DSCP) for Capacity-Admitted Traffic", 474 RFC 5865, DOI 10.17487/RFC5865, May 2010, 475 . 477 7.2. Informative References 479 [ABE] Hurley, P., Le Boudec, J., Thiran, P., and M. Kara, "ABE: 480 Providing a Low-Delay Service within Best Effort", IEEE 481 Network Magazine 15(3): 60-69, May 2001. 483 [I-D.briscoe-aqm-dualq-coupled] 484 Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang, 485 "DualQ Coupled AQM for Low Latency, Low Loss and Scalable 486 Throughput", draft-briscoe-aqm-dualq-coupled-00 (work in 487 progress), August 2015. 489 [I-D.hurley-alternative-best-effort] 490 Hurley, P., Iannaccone , G., Kara , M., Le Boudec , J., 491 Thiran , P., and C. Diot , "The ABE Service", November 492 2000. 494 [QoS] Chen, C., Farley, T., and N. Ye, "QoS Requirements of 495 Network Applications on the Internet", Information 496 Knowledge Systems Management 2004, 4(1): 55-76, 2004. 498 [RD] Podlesny, M. and S. Gorinsky, "RD network services: 499 differentiation through performance incentives", ACM 500 SIGCOMM Computer Communication Review, 38(4): 255-266, 501 2008. 503 Authors' Addresses 505 Jianjie You 506 Huawei 507 101 Software Avenue, Yuhua District 508 Nanjing 210012 509 China 511 Email: youjianjie@huawei.com 512 Michael Welzl 513 University of Oslo 514 PO Box 1080 Blindern 515 Oslo N-0316 516 Norway 518 Email: michawe@ifi.uio.no 520 Brian Trammell 521 ETH Zurich 522 Zurich 523 Switzerland 525 Email: ietf@trammell.ch 527 Mirja Kuehlewind 528 ETH Zurich 529 Zurich 530 Switzerland 532 Email: mirja.kuehlewind@tik.ee.ethz.ch 534 Kevin Smith 535 Vodafone Group 536 One Kingdom Street, 537 London 538 UK 540 Email: kevin.smith@vodafone.com