<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-liu-detnet-dynamic-latency-guarantee-01"
     ipr="trust200902">
  <front>
    <title abbrev="Deterministic Networking">Dynamic Latency Guarantee</title>

    <author fullname="Peng Liu" initials="P." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>liupengyjy@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>gengliang@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <!---->

    <date day="08" month="July" year="2019"/>

    <area>Networking</area>

    <workgroup>Deterministic Networking Working Group</workgroup>

    <keyword>Latency; Dynamic; Deterministic</keyword>

    <abstract>
      <t>Aiming at the deterministic demand for network latency in future
      vertical industry applications, this document analyzes the existing
      latency control methods for data transmission, points out the possible
      shortcomings, and proposes some directions for optimizing the latency
      control method. .</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>New types of services such as AR/VR, V2X, industrial motion control,
      etc. have stringent requirements for latency and stability. In order to
      meet those requirements, some network technologies such as
      time-sensitive network, deterministic network, etc., have proposed
      corresponding technical means to provide network bearers with
      deterministic latency and packet loss rate to guarantee the service
      experience. TSN includes a set of standards developed by the IEEE 802.1
      Working Group's. Deterministic network (DETNET) is based on the
      mechanism of TSN and committed to applying the method to the IP layer to
      provide more reliable and stable network transmission. This document
      will present some problems when applying TSN in DETNET, and try to
      propose reference methods to solve the corresponding problems.</t>
    </section>

    <section title="Technologies of Latency Control">
      <t>Based on time synchronization, TSN has a range of bounded latency
      technologies.</t>

      <section title="IEEE 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams">
        <t>IEEE 802.1Qav inherited from the AVB, including priority mapping
        algorithms and Credit-based Traffic Shaping algorithms. The priority
        mapping algorithms is to mapping the priority to 'traffic class',
        which represents whether the stream is time sensitive or not.
        Credit-based Traffic Shaping algorithms provide the method to allocate
        bandwidth of different streams.</t>
      </section>

      <section title="IEEE 802.1Qbv Enhancements for Scheduled Traffic">
        <t>In IEEE 802.1Qbv, the gate control list is created according to the
        actual stream and timescale. It contains the transmission sequence of
        all streams, and controls whether the data stream of each priority is
        sent at the current time or not. All streams will be transmitted
        strictly according to the current list. More Than This, IEEE 802.1Qbv
        also defines the guard band mechanism and spares part of the time to
        guarantee the transmission of high priority data frames at the
        beginning of the next time slice.</t>
      </section>

      <section title="IEEE 802.1Qbu Frame Preemption">
        <t>In the preemption mechanism, high-priority frames can interrupt the
        transmission of low-priority data frames unless low-priority data
        frames can no longer be fragmented. This standard fully guarantees the
        transmission delay of the highest priority data frame, and also
        reduces the guard band in IEEE 802.1Qbv to 127 bytes. The frame
        preemption mechanism changes the transmission rules of the ethernet
        frame and is used in conjunction with the IEEE 802.3Qbr .</t>

        <t>In addition to these, there are also other standards to guarantee
        the sequence of receiving data streams, which are fine-grained traffic
        scheduling technology and the key technologies of TSN in bounded
        latency.</t>
      </section>
    </section>

    <section title="Problems and Requirments">
      <t>DETNET refers to the bounded latency mechanism of TSN, so it needs to
      pay attention to some problems in the bounded latency mechanism. There
      are several standards refers to bounded latency. Users can decide
      whether to use a specific standard or not, which depends on the
      requirments of network and business. Some TSN testbeds have been
      established these years whose basic concept is realizing 802.1Qbv to
      ensure the deterministic transmission of time sensitive stream. Though
      it realized ignoring the interfere of background stream, the testbed was
      too simple. In fact, networking is complicated. There will be more than
      two kind of streams being transmitted. So it is not that easily to apply
      those mechanisms on real networks.</t>

      <section title="Problems in Bounded Latency">
        <t>Because of the complicated of real networks, there may be some
        situations that the preemptable data frame transmission delay is too
        large or cannot be transmitted. Thoes might occur when both
        Enhancements for Scheduled Traffic and Frame Preemption are
        enabled.</t>

        <t>Except for the highest priority, the others may be preempted by the
        time slice to wait for transmission. In the actual scenario, the
        preemptable data frame is not necessarily a completely non-time
        sensitive frame, so it also need to guarantee the transmission of some
        preemptable frame. However, Under the current mechanism, there may be
        multiple preemption to cause a very large transmission delay or no
        transmission of preemptable frame, depending on the size of the
        express frame and the period of the timescale. In an actual scenario,
        a data frame with a Secondary high priority may also be a
        time-sensitive. If it cannot be transmitted or the transmission delay
        is large, the service cannot be operated.</t>
      </section>

      <section title="Requirments of Deterministic latency">
        <t>Deterministic network includes deterministic latency and
        deterministic packet loss. We need to think how to apply the bounded
        latency mechanism effectively. Before using the bounded latency
        mechanism, network manager needs to know enough about the network and
        applications. For example, which kind of stream is time sensitive? How
        about the frame's transceiver frequency of thoes stream? How much
        bandwidth does it need? ... When you have a clear understanding of the
        real-time state of the network, you can configure a delay-limited
        algorithm for the network.</t>

        <t>However, the transmission state of the network is not invariable.
        Some transfer table might make corresponding adjustments according to
        the current network situation. So the parameters that have been
        configured before should also be changed. More than this, the bounded
        latency mechanism also need a feedback system to receive current
        network status and adjust/reconfigure the network.</t>
      </section>
    </section>

    <section title="Solutions">
      <t>The implementation of the mechanism to guarantee latency requires
      sophisticated calculation, including timescale and gate control tist .
      When the stream in the network becomes diverse, it will consume a lot of
      computing resources to schedule each stream. Therefore, a single
      transmission rule may not be able to meet the problem of multiple
      streams' transmission. Worst of all, the gate control list is not
      properly calculated, the network may not transmit or failure.</t>

      <t>Dynamic latency guarantee is a way of thinking based on the latency
      guarantee of the whole network. that is, to dynamically adjust the
      priority through the current network condition and the transmission of
      data stream, and a feedback system is needed to optimize the system. One
      of the reasons for this situation is that the prediction or mastery of
      the transmission of frames in the network is not accurate, so a feedback
      system is needed to tell the network to centrally configure the system.
      So it could help to optimize the gate control list to avoid the frequent
      occurring of this problems. The most basic case is that once there are
      multiple preemption occured, the switch need to report it to the
      Centralized Configuration System. It represent that there might be some
      unjustified configurations need to be reconfiguration. For example,
      distribute more bandwidth to the corresponding traffic class.</t>

      <t>It should be noted that all devices in the network share the same
      gate control list. However, due to the difference in time of the
      transmission path, it is necessary to keep all devices in the network
      "asynchronous" to execute the gate control list. For example, when the
      data frame is received by the device A, it is queued to be transmited
      first in the currently divided time slice. When the frame is received by
      the device B, the time t1 has elapsed. So the gate control list of
      device B needs to perform the time difference of t1 with the A device,
      which can ensure that this frame arrives at every device with a
      first-transmiting in current time slice.</t>

      <figure align="center" title="Feedback System">
        <artwork type="ascii-art">
                            --------------------------------------
                            |       Optimize Configuration       |
                            V                                    |
              +-------------+------------+                       |
              |        Centralized       |------------------------
              |       Configuration      |
              |          System          |------------------------                    
              +-------------+------------+                       |
                            |                       Feedback Data|
                            |                       of Preemption| 
      ----------------------|------------------------            | 
      |                     |                       |            |
      V                     V                       V            |
+---------+           +----------+             +---------+       |
| Switch A|-----------| Switch B |-------------| Switch C|--------
+---------+    t1     +----------+      t2     +---------+
Gate Control          Gate Control             Gate Control
   List                  List                     List
</artwork>
      </figure>
    </section>

    <section title="Conclusion">
      <t>This draft described the existing mechanism of bounded latency and
      point out some problems when using them. It also proposed some reference
      methods to solve them. In the process of network evolution, there might
      also be more problems need to be noticed and disscuss. For example, it
      also needs to consider whether the bounded latency mechanism of layer 2
      can guarantee the deterministic processing of whole stack. There may be
      that deterministic forwarding mechanism is used in Layer 2, but due to
      the TCP/IP or other protocol in higher layer, data packets can not be
      processed in deterministic order in the queue, which leads to the
      uncertainty of latency.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.I-D.ietf-detnet-architecture"?>

      <?rfc include="reference.I-D.finn-detnet-bounded-latency"?>
    </references>

    <references title="Informative References">
      <reference anchor="IEEE802.1Qav">
        <front>
          <title>Forwarding and Queuing Enhancements for Time- Sensitive
          Streams (IEEE 802.1Qav)</title>

          <author fullname="IEEE">
            <organization/>
          </author>

          <date year="2009"/>
        </front>
      </reference>

      <reference anchor="IIEEE802.1Qbv">
        <front>
          <title>Enhancements for Scheduled Traffic</title>

          <author fullname="IEEE" surname="">
            <organization/>
          </author>

          <date year="2016"/>
        </front>
      </reference>

      <reference anchor="IEEE802.1Qch">
        <front>
          <title>Cyclic Queuing and Forwarding</title>

          <author fullname="IEEE" surname="">
            <organization/>
          </author>

          <date year="2015"/>
        </front>
      </reference>

      <reference anchor="IEEE802.1Qbu">
        <front>
          <title>Frame Preemption</title>

          <author fullname="IEEE" surname="">
            <organization/>
          </author>

          <date year="2015"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
