[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

    Network Working Group                                 R.R. Chodorek
    Internet Draft                  AGH Univ. of Science and Technology
    Intended status: Experimental                         July 25, 2018
    Expires: January 25, 2019
    
    
    
                  An IP option for describing the traffic flow
                     draft-chodorek-traffic-flow-option-09
    
    
    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).  Note that other groups may also distribute
       working documents as Internet-Drafts.  The list of current
       Internet-Drafts is at
       https://datatracker.ietf.org/drafts/current/.
    
       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."
    
       This Internet-Draft will expire on January 25, 2019.
    
    Copyright Notice
    
       Copyright (c) 2018 IETF Trust and the persons identified as the
       document authors. All rights reserved.
    
    
    
    
    
    Chodorek              Expires January 25, 2019            [Page 1]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
       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 ............................................... 7
          3.1. The streaming application ........................... 7
          3.2. The elastic application ............................. 7
       4. Security Considerations .................................. 8
       5. IANA Considerations ...................................... 8
       6. References ............................................... 8
          6.1. Normative References ................................ 8
          6.2. Informative References .............................. 9
    
    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
    
    
    
    Chodorek              Expires January 25, 2019            [Page 2]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
       bandwidth depending to properties of transmitted media and used
       compression and coding).
    
       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 [RFC8200] Hop-by-Hop Options has the following
       format:
    
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Option Type  |  Opt Data Len |             Flags             |
       +---------------+---------------+---------------+---------------+
       |                           Next Data                           |
       +---------------+---------------+---------------+---------------+
       |                           Next Time                           |
       +---------------+---------------+---------------+---------------+
    
                     Figure 2 Proposed IP Option for IPv6.
    
    
    
    
    
    
    Chodorek              Expires January 25, 2019            [Page 3]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
       For IPv4 the first byte (the option type) is as follows:
    
       Type:
    
         Copied flag:  1 (all fragments must carry the option)
    
         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
       Option Type value of 000xxxxx, and is as follows:
    
         Unrecognized option action: 00
                  (skip option, process the rest of the header)
    
         Option Data does not change en-route: 0
                  (option data cannot change while the datagram is en
       route)
    
         Option number: xxxxx to be allocated by IANA for this option
    
    
    
       Option Type (8 bit):
    
         Identifies the type of option.
    
    
    
       For IPv4:
    
       Len (8 bit):
    
         Variable length of IP option in bytes (including the Type and
       Len bytes). This field MUST be set to 12.
    
       For IPv6:
    
       Opt Data Len (8 bit):
    
         Length of IP option in bytes. This field MUST be set to 10.
    
    
    
       Flags (16 bit):
    
    
    
    Chodorek              Expires January 25, 2019            [Page 4]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
         Determines the format of next field and the properties
       (types) of the transmitted data, and has the following format:
    
    
    
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |        Res    |N|D|M|B|F|L|S|E|
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
       Res (8 bit):
    
         The Res (Reserved) field MUST be set to zero
    
       N (1 bit):
    
          When the flag N is set to one, this indicates that there is at
       least one router on the path that is net neutral and not apply
       traffic differentiation.
    
       D (1 bit):
    
         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 (forecasting).
    
       L (1 bit):
    
    
    
    
    
    Chodorek              Expires January 25, 2019            [Page 5]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
          When the flag L is set to one, a large amount of data will be
       transmitted.
    
       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 represents an
       unsigned integer value:
    
             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]):
    
        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):
    
    
    
    
    
    Chodorek              Expires January 25, 2019            [Page 6]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
         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.
    
       If router is net neutral (router not apply traffic
       differentiation), router must set flag N.
    
       The proposed option can be used by active queues (e.g. RED) or
       fair queuing (e.g. WFQ) [Cho2015]. The proposed option can use
       constant time horizon [Cho2015] or a variable time horizon
       (based on scene detection and analysis of the frames of the
       sending movie) [Cho2016].
    
    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.
    
    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
    
    
    
    Chodorek              Expires January 25, 2019            [Page 7]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
       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.
    
       [RFC8200] Deering, S., Hinden, R., "Internet Protocol, Version 6
                 (IPv6) Specification", RFC8200, July 2017.
    
       [IEEE754] Institute of Electrical and Electronics Engineers,
                 "Standard for Floating-Point Arithmetic", IEEE Standard
                 754, August 2008.
    
    
    
    
    
    
    
    
    Chodorek              Expires January 25, 2019            [Page 8]


    Internet-Draft      IP option forthcoming traffic          July 2018
    
    
    6.2. Informative References
    
       [Cho2016] Chodorek, R., and Chodorek, A., "TFD-capable dynamic
                 QoS assurance using a variable time horizon based on
                 scene changes", Proc. of 2016 International Conference
                 on Signals and Electronic (ICSES'16), 2016, pp. 275-
                 280.
    
       [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),
                 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), 2010,
                 pp. 326-331.
    
       [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.
    
       [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.
    
    
    
    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 January 25, 2019            [Page 9]
    

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/