idnits 2.17.1 draft-chodorek-traffic-flow-option-07.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 (June 26, 2017) is 2496 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R.R. Chodorek 2 Internet Draft AGH Univ. of Science and Technology 3 Intended status: Experimental June 26, 2017 4 Expires: December 26, 2017 6 An IP option for describing the traffic flow 7 draft-chodorek-traffic-flow-option-07 9 Abstract 11 Information about the behavior of the stream that will be transmitted 12 in the near future will allow for better management of queues in the 13 router and thus improve QoS and reduce the potential for a serious 14 overload. Such information is often available in the transmitter. The 15 proposed IP option allows for the sending of information about 16 forthcoming traffic from the transmitter to the intermediate nodes. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on December 26, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction ................................................ 2 59 2. Traffic Flow Description option ............................. 3 60 3. Procedures .................................................. 6 61 3.1. The streaming application .............................. 7 62 3.2. The elastic application ................................ 7 63 4. Security Considerations ..................................... 7 64 5. IANA Considerations ......................................... 7 65 6. References .................................................. 8 66 6.1. Normative References ................................... 8 67 6.2. Informative References ................................. 8 69 1. Introduction 71 Information about the behavior of the stream that will be transmitted 72 in the near future will allow for better management of queues in the 73 router and thus improve QoS and reduce the potential for a serious 74 overload. Such information is often available in the transmitter. 75 Information on the amount of data that in the near future will be 76 sent by the application can be derived from measurements taken in the 77 output buffer or as a result of prediction (e.g. the prediction of 78 video traffic [Cho2002]). This information can be used for dynamic 79 bandwidth allocation (e.g. the extension to RSVP protocol, based on 80 dynamic resource reservations [Cho2010] or prediction-based bandwidth 81 renegotiation module [Cho2003]). 83 The proposed IP Traffic Flow Description (TFD) Hop-by-Hop option 84 allows for the sending of information about forthcoming traffic from 85 the transmitter to the intermediate nodes. The proposed IP option can 86 be used by applications which transmit streaming and elastic traffic. 87 The proposed option will be used mainly for streaming applications 88 because streaming applications are typically self-limited (have a 89 limited output bandwidth depending to properties of transmitted media 90 and used compression and coding). 92 The proposed option can be used to active queues (e.g. RED) or fair 93 queuing (e.g. WFQ). 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [RFC2119]. 99 2. Traffic Flow Description option 101 The Traffic Flow Description (TFD) header is used by an IP source 102 to carry information describing traffic flow. This option must be 103 examined by every node along a packet's delivery path. 105 The proposed IPv4 [RFC791] option has the following format: 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | 100xxxxx | Len | Flags | 109 +---------------+---------------+---------------+---------------+ 110 | Next Data | 111 +---------------+---------------+---------------+---------------+ 112 | Next Time | 113 +---------------+---------------+---------------+---------------+ 115 Figure 1 Proposed IP Option for IPv4. 117 The proposed IPv6 [RFC2460] Hop-by-Hop Options has the following 118 format: 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Option Type | Opt Data Len | Flags | 122 +---------------+---------------+---------------+---------------+ 123 | Next Data | 124 +---------------+---------------+---------------+---------------+ 125 | Next Time | 126 +---------------+---------------+---------------+---------------+ 128 Figure 2 Proposed IP Option for IPv6. 130 For IPv4 the first byte (the option type) is as follows: 132 Type: 134 Copied flag: 1 (all fragments must carry the option) 135 Option class: 0 (control) 137 Option number: xxxxx to be allocated by IANA for this option 139 For IPv6 the Traffic Flow Description header is identified by a 140 Option Type value of 000xxxxx, and is as follows: 142 Unrecognized option action: 00 143 (skip option, process the rest of the header) 145 Option Data does not change en-route: 0 146 (option data cannot change while the datagram is en route) 148 Option number: xxxxx to be allocated by IANA for this option 150 Option Type (8 bit): 152 Identifies the type of option. 154 For IPv4: 156 Len (8 bit): 158 Variable length of IP option in bytes (including the Type and Len 159 bytes). This field MUST be set to 12. 161 For IPv6: 163 Opt Data Len (8 bit): 165 Length of IP option in bytes. This field MUST be set to 10. 167 Flags (16 bit): 169 Determines the format of next field and the properties (types) of 170 the transmitted data, and has the following format: 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Res |D|M|B|F|L|S|E| 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Res (9 bit): 178 The Res (Reserved) field MUST be set to zero 180 D (1 bit): 182 Size in field Next Data represents: 183 0 Positive integer value 184 1 Floating-point value 186 M (1 bit): 188 When the flag M is set to one, this indicates that the value of 189 the Next Data field is set in the transmitter to a maximum value for 190 the transmission. 192 B (1 bit): 194 When the flag B is set to one, this indicates that the value of 195 the Next Data field is set in the transmitter on the basis of buffer 196 analysis. 198 F (1 bit): 200 When the flag F is set to one, this indicates that the value of 201 the Next Data field is set in the transmitter on the basis of 202 prediction. 204 L (1 bit): 206 When the flag L is set to one, a large amount of data will be 207 transmitted. 209 S (1 bit): stream traffic indication 211 0 No stream 212 1 Stream 214 E (1 bit): elastic traffic indication 216 0 No elastic 217 1 Elastic 219 Note: 221 If S == 1, E MUST be set to 0 and if E == 1, S MUST be set to 0. 223 Next Data (32 bit): 225 size (in bytes) of data sent in the near future. 227 If Flag D is not set (D == 0): 229 Next Data = Next Data 231 If Flag D is set (D == 1), Next Data represents a floating- 232 point value as follows (representation is used in accordance with 233 IEEE 754 single precision [IEEE754]): 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |0| exponent | significand_field | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Note(1): infinity stream is defined: 242 as FFFFFFFF hex value if D == 0 243 as exponent = FF and significand_field = 0 if D == 1 245 Note(2): sign bit is always zero (positive number). 247 Next Time (32 bit): 249 Time (in milliseconds) the counting of data that were included in 250 the field Next Data. 252 3. Procedures 254 The source node sends a packet with the IP option of the Traffic Flow 255 Description. The type of traffic, which can be elastic or streaming, 256 and its basic parameters are defined by the application that is 257 capable of using the optional Traffic Flow Description. Information 258 on the amounts of data that in the near future will sent by the 259 application can be derived from measurements taken of the output 260 buffer or as a result of prediction. 262 Intermediate nodes will receive information transmitted by the 263 Traffic Flow Description for each active flow and on the basis of the 264 obtained information modify their decisions regarding traffic 265 management. 267 The proposed option can be used by active queues (e.g. RED) or fair 268 queuing (e.g. WFQ) [Cho2015]. The proposed option can use constant 269 time horizon [Cho2015] or a variable time horizon (based on scene 270 detection and analysis of the frames of the sending movie) [Cho2016]. 272 3.1. The streaming application 274 The streaming application, located at the source node, sets the IP 275 packet option of the Traffic Flow Description. Flag S (which 276 indicates streaming) is set to 1. When the stream was characterized 277 by analyzing the application output buffer, flag B is set to 1. The 278 field Next Time is set according to the buffer delay (e.g. 500 ms). 279 The value of the field Next Data is set as a sum of all data 280 currently stored in output buffer. 282 3.2. The elastic application 284 The elastic application, located at the source node, sets the IP 285 packet option of the Traffic Flow Description. The flag E (which 286 indicates an elastic application) is set to 1. When an elastic 287 application uses the TCP protocol it's a problem to estimate Next 288 Data. We can only calculate maximum throughput according to RTT, 289 congestion and the receiver window. It will be setting the maximum 290 throughput in the Traffic Flow Description by setting flag M to 1 and 291 Next Data and Next Time according to a calculation (Next Data to 292 calculate throughput and Next Time to RTT). If it is not possible to 293 calculate throughput we set Next Data to infinite value and field 294 Next Time to RTT. 296 When an elastic application uses a transport protocol (e.g. PGM), 297 which implements rate limiting mechanisms, we set maximum throughput 298 according to protocol settings. The flag E (which indicates an 299 elastic application) is set to 1, flag M is set to 1 and Next Data 300 and Next Time is set according to protocol settings. If it is 301 possible to estimate the throughput of the transport protocol in a 302 given period we use this information and set flag F (instead of M) to 303 1 and field Next Data and Next Time according to predicted values. 305 4. Security Considerations 307 Security considerations to be provided. 309 5. IANA Considerations 311 An option type must be assigned by IANA for the Traffic Flow 312 Description (TFD) option. 314 6. References 316 6.1. Normative References 318 [RFC791] Postel, J., "Internet Protocol Specification", RFC791, 319 September 1981. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 325 Specification", RFC2460, December 1998. 327 [IEEE754] Institute of Electrical and Electronics Engineers, 328 "Standard for Floating-Point Arithmetic", IEEE Standard 329 754, August 2008. 331 6.2. Informative References 333 [Cho2016] Chodorek, R., and Chodorek, A., "TFD-capable dynamic QoS 334 assurance using a variable time horizon based on scene 335 changes", Proc. of 2016 International Conference on Signals 336 and Electronic (ICSES'16), 2016, pp. 275-280. 338 [Cho2015] Chodorek, R., and Chodorek, A., "Providing QoS for high 339 definition video transmission using IP Traffic Flow 340 Description option", Proc. of 8th international conference 341 on Human System Interaction (HIS 2015), 2015, pp. 102-107. 343 [Cho2010] Chodorek, R., and Chodorek, A., "An Analysis of QoS 344 Provisioning for High Definition Video Distribution in 345 Heterogeneous Network", Proc. of 14th International 346 Symposium on Consumer Electronics (ISCE 2010), 2010, pp. 347 326-331. 349 [Cho2003] Chodorek, A., "Prediction-based dynamic QoS assurance for 350 multicast multimedia delivery", High-Speed Networks and 351 Multimedia Communications: 6th IEEE International 352 Conference HSNMC 2003, Estoril, Portugal, July 23-25, 2003, 353 Proceedings. Vol. 6. Springer, 2003, pp. 128-135. 355 [Cho2002] Chodorek, A., "A fast and efficient model of an MPEG-4 356 video traffic based on phase space linearised 357 decomposition", Proc. of 14th European Simulation Symposium 358 ESS'2002, 2002, pp. 44-55. 360 Authors' Addresses 362 Robert R. Chodorek 363 AGH Univ. of Science and Technology 364 Al. Mickiewicza 30 365 30-059 Krakow 366 Poland 368 Email: chodorek@agh.edu.pl