idnits 2.17.1 draft-chodorek-traffic-flow-option-09.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 61 lines 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 (July 25, 2018) is 2099 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R.R. Chodorek 3 Internet Draft AGH Univ. of Science and Technology 4 Intended status: Experimental July 25, 2018 5 Expires: January 25, 2019 7 An IP option for describing the traffic flow 8 draft-chodorek-traffic-flow-option-09 10 Abstract 12 Information about the behavior of the stream that will be 13 transmitted in the near future will allow for better management 14 of queues in the router and thus improve QoS and reduce the 15 potential for a serious overload. Such information is often 16 available in the transmitter. The proposed IP option allows for 17 the sending of information about forthcoming traffic from the 18 transmitter to the intermediate nodes. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current 28 Internet-Drafts is at 29 https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them other than as "work 35 in progress." 37 This Internet-Draft will expire on January 25, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described 51 in Section 4.e of the Trust Legal Provisions and are provided 52 without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ............................................. 2 57 2. Traffic Flow Description option .......................... 3 58 3. Procedures ............................................... 7 59 3.1. The streaming application ........................... 7 60 3.2. The elastic application ............................. 7 61 4. Security Considerations .................................. 8 62 5. IANA Considerations ...................................... 8 63 6. References ............................................... 8 64 6.1. Normative References ................................ 8 65 6.2. Informative References .............................. 9 67 1. Introduction 69 Information about the behavior of the stream that will be 70 transmitted in the near future will allow for better management 71 of queues in the router and thus improve QoS and reduce the 72 potential for a serious overload. Such information is often 73 available in the transmitter. Information on the amount of data 74 that in the near future will be sent by the application can be 75 derived from measurements taken in the output buffer or as a 76 result of prediction (e.g. the prediction of video traffic 77 [Cho2002]). This information can be used for dynamic bandwidth 78 allocation (e.g. the extension to RSVP protocol, based on dynamic 79 resource reservations [Cho2010] or prediction-based bandwidth 80 renegotiation module [Cho2003]). 82 The proposed IP Traffic Flow Description (TFD) Hop-by-Hop 83 option allows for the sending of information about forthcoming 84 traffic from the transmitter to the intermediate nodes. The 85 proposed IP option can be used by applications which transmit 86 streaming and elastic traffic. The proposed option will be used 87 mainly for streaming applications because streaming 88 applications are typically self-limited (have a limited output 89 bandwidth depending to properties of transmitted media and used 90 compression and coding). 92 The proposed option can be used to active queues (e.g. RED) or 93 fair queuing (e.g. WFQ). 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 96 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 RFC-2119 [RFC2119]. 100 2. Traffic Flow Description option 102 The Traffic Flow Description (TFD) header is used by an IP 103 source to carry information describing traffic flow. This option 104 must be examined by every node along a packet's delivery path. 106 The proposed IPv4 [RFC791] option has the following format: 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | 100xxxxx | Len | Flags | 110 +---------------+---------------+---------------+---------------+ 111 | Next Data | 112 +---------------+---------------+---------------+---------------+ 113 | Next Time | 114 +---------------+---------------+---------------+---------------+ 116 Figure 1 Proposed IP Option for IPv4. 118 The proposed IPv6 [RFC8200] Hop-by-Hop Options has the following 119 format: 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Option Type | Opt Data Len | Flags | 123 +---------------+---------------+---------------+---------------+ 124 | Next Data | 125 +---------------+---------------+---------------+---------------+ 126 | Next Time | 127 +---------------+---------------+---------------+---------------+ 129 Figure 2 Proposed IP Option for IPv6. 131 For IPv4 the first byte (the option type) is as follows: 133 Type: 135 Copied flag: 1 (all fragments must carry the option) 137 Option class: 0 (control) 139 Option number: xxxxx to be allocated by IANA for this option 141 For IPv6 the Traffic Flow Description header is identified by a 142 Option Type value of 000xxxxx, and is as follows: 144 Unrecognized option action: 00 145 (skip option, process the rest of the header) 147 Option Data does not change en-route: 0 148 (option data cannot change while the datagram is en 149 route) 151 Option number: xxxxx to be allocated by IANA for this option 153 Option Type (8 bit): 155 Identifies the type of option. 157 For IPv4: 159 Len (8 bit): 161 Variable length of IP option in bytes (including the Type and 162 Len bytes). This field MUST be set to 12. 164 For IPv6: 166 Opt Data Len (8 bit): 168 Length of IP option in bytes. This field MUST be set to 10. 170 Flags (16 bit): 172 Determines the format of next field and the properties 173 (types) of the transmitted data, and has the following format: 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Res |N|D|M|B|F|L|S|E| 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Res (8 bit): 181 The Res (Reserved) field MUST be set to zero 183 N (1 bit): 185 When the flag N is set to one, this indicates that there is at 186 least one router on the path that is net neutral and not apply 187 traffic differentiation. 189 D (1 bit): 191 Size in field Next Data represents: 192 0 Positive integer value 193 1 Floating-point value 195 M (1 bit): 197 When the flag M is set to one, this indicates that the value 198 of the Next Data field is set in the transmitter to a maximum 199 value for the transmission. 201 B (1 bit): 203 When the flag B is set to one, this indicates that the value 204 of the Next Data field is set in the transmitter on the basis of 205 buffer analysis. 207 F (1 bit): 209 When the flag F is set to one, this indicates that the value 210 of the Next Data field is set in the transmitter on the basis of 211 prediction (forecasting). 213 L (1 bit): 215 When the flag L is set to one, a large amount of data will be 216 transmitted. 218 S (1 bit): stream traffic indication 220 0 No stream 221 1 Stream 223 E (1 bit): elastic traffic indication 225 0 No elastic 226 1 Elastic 228 Note: 230 If S == 1, E MUST be set to 0 and if E == 1, S MUST be set to 231 0. 233 Next Data (32 bit): 235 size (in bytes) of data sent in the near future. 237 If Flag D is not set (D == 0), Next Data represents an 238 unsigned integer value: 240 Next Data = Next Data 242 If Flag D is set (D == 1), Next Data represents a floating- 243 point value as follows (representation is used in accordance with 244 IEEE 754 single precision [IEEE754]): 246 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |0| exponent | significand_field | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Note(1): infinity stream is defined: 253 as FFFFFFFF hex value if D == 0 254 as exponent = FF and significand_field = 0 if D == 1 256 Note(2): sign bit is always zero (positive number). 258 Next Time (32 bit): 260 Time (in milliseconds) the counting of data that were included 261 in the field Next Data. 263 3. Procedures 265 The source node sends a packet with the IP option of the Traffic 266 Flow Description. The type of traffic, which can be elastic or 267 streaming, and its basic parameters are defined by the 268 application that is capable of using the optional Traffic Flow 269 Description. Information on the amounts of data that in the near 270 future will sent by the application can be derived from 271 measurements taken of the output buffer or as a result of 272 prediction. 274 Intermediate nodes will receive information transmitted by the 275 Traffic Flow Description for each active flow and on the basis 276 of the obtained information modify their decisions regarding 277 traffic management. 279 If router is net neutral (router not apply traffic 280 differentiation), router must set flag N. 282 The proposed option can be used by active queues (e.g. RED) or 283 fair queuing (e.g. WFQ) [Cho2015]. The proposed option can use 284 constant time horizon [Cho2015] or a variable time horizon 285 (based on scene detection and analysis of the frames of the 286 sending movie) [Cho2016]. 288 3.1. The streaming application 290 The streaming application, located at the source node, sets the 291 IP packet option of the Traffic Flow Description. Flag S (which 292 indicates streaming) is set to 1. When the stream was 293 characterized by analyzing the application output buffer, flag B 294 is set to 1. The field Next Time is set according to the buffer 295 delay (e.g. 500 ms). The value of the field Next Data is set as 296 a sum of all data currently stored in output buffer. 298 3.2. The elastic application 300 The elastic application, located at the source node, sets the IP 301 packet option of the Traffic Flow Description. The flag E (which 302 indicates an elastic application) is set to 1. When an elastic 303 application uses the TCP protocol it's a problem to estimate 304 Next Data. We can only calculate maximum throughput according to 305 RTT, congestion and the receiver window. It will be setting the 306 maximum throughput in the Traffic Flow Description by setting 307 flag M to 1 and Next Data and Next Time according to a 308 calculation (Next Data to calculate throughput and Next Time to 309 RTT). If it is not possible to calculate throughput we set Next 310 Data to infinite value and field Next Time to RTT. 312 When an elastic application uses a transport protocol (e.g. PGM), 313 which implements rate limiting mechanisms, we set maximum 314 throughput according to protocol settings. The flag E (which 315 indicates an elastic application) is set to 1, flag M is set to 1 316 and Next Data and Next Time is set according to protocol 317 settings. If it is possible to estimate the throughput of the 318 transport protocol in a given period we use this information and 319 set flag F (instead of M) to 1 and field Next Data and Next Time 320 according to predicted values. 322 4. Security Considerations 324 Security considerations to be provided. 326 5. IANA Considerations 328 An option type must be assigned by IANA for the Traffic Flow 329 Description (TFD) option. 331 6. References 333 6.1. Normative References 335 [RFC791] Postel, J., "Internet Protocol Specification", RFC791, 336 September 1981. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC8200] Deering, S., Hinden, R., "Internet Protocol, Version 6 342 (IPv6) Specification", RFC8200, July 2017. 344 [IEEE754] Institute of Electrical and Electronics Engineers, 345 "Standard for Floating-Point Arithmetic", IEEE Standard 346 754, August 2008. 348 6.2. Informative References 350 [Cho2016] Chodorek, R., and Chodorek, A., "TFD-capable dynamic 351 QoS assurance using a variable time horizon based on 352 scene changes", Proc. of 2016 International Conference 353 on Signals and Electronic (ICSES'16), 2016, pp. 275- 354 280. 356 [Cho2015] Chodorek, R., and Chodorek, A., "Providing QoS for high 357 definition video transmission using IP Traffic Flow 358 Description option", Proc. of 8th international 359 conference on Human System Interaction (HIS 2015), 360 2015, pp. 102-107. 362 [Cho2010] Chodorek, R., and Chodorek, A., "An Analysis of QoS 363 Provisioning for High Definition Video Distribution in 364 Heterogeneous Network", Proc. of 14th International 365 Symposium on Consumer Electronics (ISCE 2010), 2010, 366 pp. 326-331. 368 [Cho2003] Chodorek, A., "Prediction-based dynamic QoS assurance 369 for multicast multimedia delivery", High-Speed 370 Networks and Multimedia Communications: 6th IEEE 371 International Conference HSNMC 2003, Estoril, 372 Portugal, July 23-25, 2003, Proceedings. Vol. 6. 373 Springer, 2003, pp. 128-135. 375 [Cho2002] Chodorek, A., "A fast and efficient model of an MPEG-4 376 video traffic based on phase space linearised 377 decomposition", Proc. of 14th European Simulation 378 Symposium ESS'2002, 2002, pp. 44-55. 380 Authors' Addresses 382 Robert R. Chodorek 383 AGH Univ. of Science and Technology 384 Al. Mickiewicza 30 385 30-059 Krakow 386 Poland 388 Email: chodorek@agh.edu.pl