Network Working Group R.R. Chodorek Internet Draft AGH Univ. of Science and Technology Intended status: Experimental June 11, 2016 Expires: December 11, 2016 An IP option for describing the traffic flow draft-chodorek-traffic-flow-option-05.txt Abstract Information about the behavior of the stream that will be transmitted in the near future will allow for better management of queues in the router and thus improve QoS and reduce the potential for a serious overload. Such information is often available in the transmitter. The proposed IP option allows for the sending of information about forthcoming traffic from the transmitter to the intermediate nodes. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 11, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Chodorek Expires December 11, 2016 [Page 1] Internet-Draft IP option forthcoming traffic June 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 2 2. Traffic Flow Description option ............................. 3 3. Procedures .................................................. 6 3.1. The streaming application .............................. 6 3.2. The elastic application ................................ 7 4. Security Considerations ..................................... 7 5. IANA Considerations ......................................... 7 6. References .................................................. 7 6.1. Normative References ................................... 7 6.2. Informative References ................................. 8 1. Introduction Information about the behavior of the stream that will be transmitted in the near future will allow for better management of queues in the router and thus improve QoS and reduce the potential for a serious overload. Such information is often available in the transmitter. Information on the amount of data that in the near future will be sent by the application can be derived from measurements taken in the output buffer or as a result of prediction (e.g. the prediction of video traffic [Cho2002]). This information can be used for dynamic bandwidth allocation (e.g. the extension to RSVP protocol, based on dynamic resource reservations [Cho2010] or prediction-based bandwidth renegotiation module [Cho2003]). The proposed IP Traffic Flow Description (TFD) Hop-by-Hop option allows for the sending of information about forthcoming traffic from the transmitter to the intermediate nodes. The proposed IP option can be used by applications which transmit streaming and elastic traffic. The proposed option will be used mainly for streaming applications because streaming applications are typically self-limited (have a limited output bandwidth depending to properties of transmitted media and used compression and coding). Chodorek Expires December 11, 2016 [Page 2] Internet-Draft IP option forthcoming traffic June 2016 The proposed option can be used to active queues (e.g. RED) or fair queuing (e.g. WFQ). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2. Traffic Flow Description option The Traffic Flow Description (TFD) header is used by an IP source to carry information describing traffic flow. This option must be examined by every node along a packet's delivery path. The proposed IPv4 [RFC791] option has the following format: +--------+--------+--------+--------+ |100xxxxx| Len | Flags | +--------+--------+--------+--------+ | Next Data | +--------+--------+--------+--------+ | Next Time | +--------+--------+--------+--------+ Figure 1 Proposed IP Option for IPv4. The proposed IPv6 [RFC2460] option has the following format: +--------+--------+--------+--------+ |Next Hdr| Len | Flags | +--------+--------+--------+--------+ | Next Data | +--------+--------+--------+--------+ | Next Time | +--------+--------+--------+--------+ Figure 2 Proposed IP Option for IPv6. For IPv4 the first byte (the option type) is as follows: Type: Copied flag: 1 (all fragments must carry the option) Chodorek Expires December 11, 2016 [Page 3] Internet-Draft IP option forthcoming traffic June 2016 Option class: 0 (control) Option number: xxxxx to be allocated by IANA for this option For IPv6 the Traffic Flow Description header is identified by a Next Header value of 000xxxxx in the immediately preceding header, and is as follows: Unrecognized option action : 00 (skip option, process the rest of the header) Change allowed flag : 0 (option data cannot change while the datagram is en route) Option number: xxxxx to be allocated by IANA for this option Next Header (8 bit): Identifies the type of header immediately following the Traffic Flow Description header. Len (8 bit): Variable length of IP option in bytes (including the Type and Len bytes). This field MUST be set to 12. Flags (16 bit): Determines the format of next field and the properties (types) of the transmitted data, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |D|M|B|F|L|S|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res (9 bit): The Res (Reserved) field MUST be set to zero D (1 bit): Chodorek Expires December 11, 2016 [Page 4] Internet-Draft IP option forthcoming traffic June 2016 Size in field Next Data represents: 0 Positive integer value 1 Floating-point value M (1 bit): When the flag M is set to one, this indicates that the value of the Next Data field is set in the transmitter to a maximum value for the transmission. B (1 bit): When the flag B is set to one, this indicates that the value of the Next Data field is set in the transmitter on the basis of buffer analysis. F (1 bit): When the flag F is set to one, this indicates that the value of the Next Data field is set in the transmitter on the basis of prediction. S (1 bit): stream traffic indication 0 No stream 1 Stream E (1 bit): elastic traffic indication 0 No elastic 1 Elastic Note: If S == 1, E MUST be set to 0 and if E == 1, S MUST be set to 0. Next Data (32 bit): size (in bytes) of data sent in the near future. If Flag D is not set (D == 0): Next Data = Next Data If Flag D is set (D == 1), Next Data represents a floating- point value as follows (representation is used in accordance with IEEE 754 single precision [IEEE754]): Chodorek Expires December 11, 2016 [Page 5] Internet-Draft IP option forthcoming traffic June 2016 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| exponent | significand_field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note(1): infinity stream is defined: as FFFFFFFF hex value if D == 0 as exponent = FF and significand_field = 0 if D == 1 Note(2): sign bit is always zero (positive number). Next Time (32 bit): Time (in milliseconds) the counting of data that were included in the field Next Data. 3. Procedures The source node sends a packet with the IP option of the Traffic Flow Description. The type of traffic, which can be elastic or streaming, and its basic parameters are defined by the application that is capable of using the optional Traffic Flow Description. Information on the amounts of data that in the near future will sent by the application can be derived from measurements taken of the output buffer or as a result of prediction. Intermediate nodes will receive information transmitted by the Traffic Flow Description for each active flow and on the basis of the obtained information modify their decisions regarding traffic management. The proposed option can be used by active queues (e.g. RED) or fair queuing (e.g. WFQ) [Cho2015]. 3.1. The streaming application The streaming application, located at the source node, sets the IP packet option of the Traffic Flow Description. Flag S (which indicates streaming) is set to 1. When the stream was characterized by analyzing the application output buffer, flag B is set to 1. The field Next Time is set according to the buffer delay (e.g. 500 ms). The value of the field Next Data is set as a sum of all data currently stored in output buffer. Chodorek Expires December 11, 2016 [Page 6] Internet-Draft IP option forthcoming traffic June 2016 3.2. The elastic application The elastic application, located at the source node, sets the IP packet option of the Traffic Flow Description. The flag E (which indicates an elastic application) is set to 1. When an elastic application uses the TCP protocol it's a problem to estimate Next Data. We can only calculate maximum throughput according to RTT, congestion and the receiver window. It will be setting the maximum throughput in the Traffic Flow Description by setting flag M to 1 and Next Data and Next Time according to a calculation (Next Data to calculate throughput and Next Time to RTT). If it is not possible to calculate throughput we set Next Data to infinite value and field Next Time to RTT. When an elastic application uses a transport protocol (e.g. PGM), which implements rate limiting mechanisms, we set maximum throughput according to protocol settings. The flag E (which indicates an elastic application) is set to 1, flag M is set to 1 and Next Data and Next Time is set according to protocol settings. If it is possible to estimate the throughput of the transport protocol in a given period we use this information and set flag F (instead of M) to 1 and field Next Data and Next Time according to predicted values. 4. Security Considerations Security considerations to be provided. 5. IANA Considerations An option type must be assigned by IANA for the Traffic Flow Description (TFD) option. 6. References 6.1. Normative References [RFC791] Postel, J., "Internet Protocol Specification", RFC791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 Specification", RFC2460, December 1998. Chodorek Expires December 11, 2016 [Page 7] Internet-Draft IP option forthcoming traffic June 2016 [IEEE754] Institute of Electrical and Electronics Engineers, "Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008. 6.2. Informative References [Cho2015] Chodorek, R., and Chodorek, A., "Providing QoS for high definition video transmission using IP Traffic Flow Description option", Proc. of 8th international conference on Human System Interaction (HIS 2015), pp. 102-107. [Cho2010] Chodorek, R., and Chodorek, A., "An Analysis of QoS Provisioning for High Definition Video Distribution in Heterogeneous Network", Proc. of 14th International Symposium on Consumer Electronics (ISCE 2010), pp. 326-331. [Cho2002] Chodorek, A., "A fast and efficient model of an MPEG-4 video traffic based on phase space linearised decomposition", Proc. of 14th European Simulation Symposium ESS'2002, 2002, pp. 44-55. [Cho2003] Chodorek, A., "Prediction-based dynamic QoS assurance for multicast multimedia delivery", High-Speed Networks and Multimedia Communications: 6th IEEE International Conference HSNMC 2003, Estoril, Portugal, July 23-25, 2003, Proceedings. Vol. 6. Springer, 2003, pp. 128-135. Authors' Addresses Robert R. Chodorek AGH Univ. of Science and Technology Al. Mickiewicza 30 30-059 Krakow Poland Email: chodorek@agh.edu.pl Chodorek Expires December 11, 2016 [Page 8]