Network Working Group                                 R.R. Chodorek
    Internet Draft                  AGH Univ. of Science and Technology
    Intended status: Experimental                       August 14, 2022
    Expires: February 14, 2023
    
    
    
An IP option for describing the traffic flow draft-chodorek-traffic-flow-option-10

    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 February 14, 2023.
    
    Copyright Notice
    
       Copyright (c) 2018 IETF Trust and the persons identified as the
       document authors. All rights reserved.
    
    
    
    
    
    
    Chodorek              Expires February 14, 2023             [Page 1]

 Internet-Draft IP option forthcoming traffic August 2022

       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 self-limited traffic. Self-limited traffic is
       generated e.g. by IoT devices that periodically send a limited
    
    
    
    Chodorek              Expires February 14, 2023            [Page 2]

 Internet-Draft IP option forthcoming traffic August 2022

       amount of data and streaming applications (streaming
applications have a limited output bandwidth depending on the 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 February 14, 2023            [Page 3]

 Internet-Draft IP option forthcoming traffic August 2022



       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.
    
    
    
    
    
    Chodorek              Expires February 14, 2023            [Page 4]

 Internet-Draft IP option forthcoming traffic August 2022

       Flags (16 bit):
    
         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 February 14, 2023            [Page 5]

 Internet-Draft IP option forthcoming traffic August 2022

          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 February 14, 2023            [Page 6]

 Internet-Draft IP option forthcoming traffic August 2022

         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 February 14, 2023            [Page 7]

 Internet-Draft IP option forthcoming traffic August 2022

       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 February 14, 2023            [Page 8]

 Internet-Draft IP option forthcoming traffic August 2022

    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 February 14, 2023            [Page 9]
                    
        


Ad

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.
inserted by FC2 system