idnits 2.17.1 draft-chodorek-traffic-flow-option-06.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 (December 12, 2016) is 2691 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 December 12, 2016 4 Expires: June 12, 2017 6 An IP option for describing the traffic flow 7 draft-chodorek-traffic-flow-option-06 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 June 12, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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 S (1 bit): stream traffic indication 206 0 No stream 207 1 Stream 209 E (1 bit): elastic traffic indication 211 0 No elastic 212 1 Elastic 214 Note: 216 If S == 1, E MUST be set to 0 and if E == 1, S MUST be set to 0. 218 Next Data (32 bit): 220 size (in bytes) of data sent in the near future. 222 If Flag D is not set (D == 0): 224 Next Data = Next Data 226 If Flag D is set (D == 1), Next Data represents a floating- 227 point value as follows (representation is used in accordance with 228 IEEE 754 single precision [IEEE754]): 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |0| exponent | significand_field | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Note(1): infinity stream is defined: 237 as FFFFFFFF hex value if D == 0 238 as exponent = FF and significand_field = 0 if D == 1 240 Note(2): sign bit is always zero (positive number). 242 Next Time (32 bit): 244 Time (in milliseconds) the counting of data that were included in 245 the field Next Data. 247 3. Procedures 249 The source node sends a packet with the IP option of the Traffic Flow 250 Description. The type of traffic, which can be elastic or streaming, 251 and its basic parameters are defined by the application that is 252 capable of using the optional Traffic Flow Description. Information 253 on the amounts of data that in the near future will sent by the 254 application can be derived from measurements taken of the output 255 buffer or as a result of prediction. 257 Intermediate nodes will receive information transmitted by the 258 Traffic Flow Description for each active flow and on the basis of the 259 obtained information modify their decisions regarding traffic 260 management. 262 The proposed option can be used by active queues (e.g. RED) or fair 263 queuing (e.g. WFQ) [Cho2015]. 265 3.1. The streaming application 267 The streaming application, located at the source node, sets the IP 268 packet option of the Traffic Flow Description. Flag S (which 269 indicates streaming) is set to 1. When the stream was characterized 270 by analyzing the application output buffer, flag B is set to 1. The 271 field Next Time is set according to the buffer delay (e.g. 500 ms). 272 The value of the field Next Data is set as a sum of all data 273 currently stored in output buffer. 275 3.2. The elastic application 277 The elastic application, located at the source node, sets the IP 278 packet option of the Traffic Flow Description. The flag E (which 279 indicates an elastic application) is set to 1. When an elastic 280 application uses the TCP protocol it's a problem to estimate Next 281 Data. We can only calculate maximum throughput according to RTT, 282 congestion and the receiver window. It will be setting the maximum 283 throughput in the Traffic Flow Description by setting flag M to 1 and 284 Next Data and Next Time according to a calculation (Next Data to 285 calculate throughput and Next Time to RTT). If it is not possible to 286 calculate throughput we set Next Data to infinite value and field 287 Next Time to RTT. 289 When an elastic application uses a transport protocol (e.g. PGM), 290 which implements rate limiting mechanisms, we set maximum throughput 291 according to protocol settings. The flag E (which indicates an 292 elastic application) is set to 1, flag M is set to 1 and Next Data 293 and Next Time is set according to protocol settings. If it is 294 possible to estimate the throughput of the transport protocol in a 295 given period we use this information and set flag F (instead of M) to 296 1 and field Next Data and Next Time according to predicted values. 298 4. Security Considerations 300 Security considerations to be provided. 302 5. IANA Considerations 304 An option type must be assigned by IANA for the Traffic Flow 305 Description (TFD) option. 307 6. References 309 6.1. Normative References 311 [RFC791] Postel, J., "Internet Protocol Specification", RFC791, 312 September 1981. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 318 Specification", RFC2460, December 1998. 320 [IEEE754] Institute of Electrical and Electronics Engineers, 321 "Standard for Floating-Point Arithmetic", IEEE Standard 322 754, August 2008. 324 6.2. Informative References 326 [Cho2015] Chodorek, R., and Chodorek, A., "Providing QoS for high 327 definition video transmission using IP Traffic Flow 328 Description option", Proc. of 8th international conference 329 on Human System Interaction (HIS 2015), pp. 102-107. 331 [Cho2010] Chodorek, R., and Chodorek, A., "An Analysis of QoS 332 Provisioning for High Definition Video Distribution in 333 Heterogeneous Network", Proc. of 14th International 334 Symposium on Consumer Electronics (ISCE 2010), pp. 326-331. 336 [Cho2002] Chodorek, A., "A fast and efficient model of an MPEG-4 337 video traffic based on phase space linearised 338 decomposition", Proc. of 14th European Simulation Symposium 339 ESS'2002, 2002, pp. 44-55. 341 [Cho2003] Chodorek, A., "Prediction-based dynamic QoS assurance for 342 multicast multimedia delivery", High-Speed Networks and 343 Multimedia Communications: 6th IEEE International 344 Conference HSNMC 2003, Estoril, Portugal, July 23-25, 2003, 345 Proceedings. Vol. 6. Springer, 2003, pp. 128-135. 347 Authors' Addresses 349 Robert R. Chodorek 350 AGH Univ. of Science and Technology 351 Al. Mickiewicza 30 352 30-059 Krakow 353 Poland 355 Email: chodorek@agh.edu.pl