An IP option for describing the traffic flow
draft-chodorek-traffic-flow-option-05

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]