<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ding-tcp-emdi-00" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="An EMDI based on TCP">An Enhanced Media Delivery Index
    (eMDI) based on TCP</title>

    <author fullname="Xiaojian Ding" initials="X." surname="Ding">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

        <email>dingxiaojian1@huawei.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

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

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Rong Gu" initials="R." surname="Gu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>

          <city>Beijing</city>

          <code>100053</code>

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

        <email>gurong_cmcc@outlook.com</email>
      </address>
    </author>

    <date year="2017"/>

    <area>ART Area</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Media Delivery Index</keyword>

    <abstract>
      <t>This document introduces an Enhanced Media Delivery Index (eMDI) that
      can be used as a diagnostic tool or a quality indicator for monitoring a
      network intended to deliver streaming media over TCP transport. It aims
      to address the problems that RFC4445 has when measuring in environments
      where TCP traffic is dominated as a transport for streaming media.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>TCP is one major transport protocol in use in most IP networks, and
      supports the transfer of over 80 percent of all traffic (e.g.,OTT
      traffic, IPTV VOD traffic) across the public Internet today. Packet loss
      ratio and latency are two major characteristics in the network to affect
      the behavior of TCP. The bad TCP performance might also indicate the
      unacceptable end-user-perceived quality level.</t>

      <t>Media Delivery Index (MDI)[RFC4445] is a method widely used in the
      network as a diagnostic tool to measure both the instantaneous and
      longer-term behavior of networks carrying streaming media in the media
      layer. However the limitation of MDI measurement is mostly applicable to
      streaming media and protocol over UDP, it falls short when monitoring a
      network intended to deliver multimedia applications over TCP Transport,
      i.e., the traditional MDI metrics especially Media Loss Rate (MLR)
      deployed in the network devices is difficult to infer the packet loss if
      the missing packets were retransmitted when the packet loss was detected
      by the TCP sender. On the other hand, TCP sender will adjust the sending
      data rate to reduce the probability of further packet loss, which means
      throughput is declining when extra delay is incurred by retransmitting
      lost packets. Therefore, throughput can be regarded as a quality
      indication for network monitoring and diagnosis.</t>

      <t>This document introduces a new measurement method and associated
      metrics,i.e.,downstream/upstream/end to end throughput, to complement
      methods defined in [RFC4445]. This new method can quickly identify the
      root cause of the QoS related problem, improve efficiency of network
      monitoring and troubleshooting.</t>
    </section>

    <section title="Terminologies">
      <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 RFC 2119 [RFC2119].</t>

      <t>This document uses the following terms:<list style="hanging">
          <t hangText="Measurement point (MP): ">A measurement point is the
          logical or physical location defined in the TCP that acts as a
          source of information gathered for monitoring purposes.</t>

          <t hangText="Upstream packet lost ratio (UPLR): ">UPLR is the ratio
          of the number of packets lost to the total number of packets sent
          from server to measurement point during predefined measurement
          interval.</t>

          <t hangText="Downstream packet lost ratio (DPLR): ">DPLR is the
          ratio of the number of packets lost to the total number of packets
          sent from measurement point to client during a predefined
          measurement interval.</t>

          <t hangText="Upstream average RTT (URTT): ">URTT is the average RTT
          at the path from server to measurement point during a predefined
          measurement interval.</t>

          <t hangText="Downstream average RTT (DRTT): ">DRTT is the average
          RTT at the path from measurement point to client during a predefined
          measurement interval.</t>

          <t hangText="End to end Throughput (E2ET):">E2ET is the rate of
          successful packet delivery over an end-end network path during a
          predefined measurement interval.</t>

          <t hangText="Downstream throughput (DT):">DT is measured by the
          number of packets received per second at the downstream of
          measurement point during a predefined measurement interval.</t>

          <t hangText="Upstream throughput (UT):">UT is measured by the number
          of packets received per second at the upstream of measurement point
          during a predefined measurement interval.</t>
        </list></t>
    </section>

    <section title="Measurement Setup">
      <t>A stream of packets sent by streaming media Server passes through MP
      (MP can be bridge, router or gateway), and finally reach the client
      (destination endpoint). If a node A is placed between the server and MP
      in the network , then A is upstream node of MP. Otherwise, A is
      downstream node of MP.</t>

      <figure>
        <artwork>  +--------+                MP |                    +--------+    
  | Server |------Upstream----&gt;|-----Downstream----&gt;| client |    
  +--------+                   |                    +--- ----+    
                                                         </artwork>
      </figure>
    </section>

    <section title="Measurement Method">
      <t>The rationale of the measurement is to compare DT/UT/E2ET with data
      packet rate. If DT is less than data packet rate and UT is greater than
      data packet rate, there is something wrong with the downstream network.
      Otherwise, the upstream network has some problems.</t>

      <t>When the packet loss occurs in the network, an additional limit(i.e.,
      packet loss probability) is imposed on the throughput besides TCP
      recieve window. In case of light or moderate packet loss when the TCP
      rate is adjusted by the congestion avoidance algorithm, DT can be
      calculated according to the following formula:<figure>
          <artwork>
DT = MSS/(DRTT+URTT)(DPLR)(1/2);
</artwork>
        </figure></t>

      <t>Where MSS is the maximum segment size. Assuming the number of lost
      packets at the downstream during a predefined measurement interval is a,
      and the number of total packets sent by MP is x, then DPLR is then
      calculated as following:<figure>
          <artwork>
DPLR = a/x.
</artwork>
        </figure></t>

      <t>Average RTT of some packets (d1..dm) at the downstream direction are
      used to compute DRTT:<figure>
          <artwork>
DRTT= sum (RTTdi)/m, i= 1..m
Where RTTdi indicates the RTT of packet di at downstream.
</artwork>
        </figure></t>

      <t>Similarly, average RTT of some packets (u1..un) at the upstream
      direction are used to compute URTT:<figure>
          <artwork>
URTT= sum (RTTui)/n, i= 1..n
Where RTTui indicates the RTT of packet ui at the upstream.
</artwork>
        </figure></t>

      <t>And, UT can be calculated according to the formula:<figure>
          <artwork>UT = MSS/(DRTT+URTT)(UPLR)(1/2);</artwork>
        </figure></t>

      <t>Assuming the number of lost packets at the upstream during a
      predefined measurement interval is b, and the number of total packets
      sent by Server is y, then UPLR is then calculated as following:<figure>
          <artwork>
UPLR = b/y.
</artwork>
        </figure></t>

      <t>And E2ET can be calculated according to the formula:<figure>
          <artwork>E2ET = MSS/(DRTT+URTT)(UPLR+DPLR)(1/2).</artwork>
        </figure></t>
    </section>

    <section title="Use Examples">
      <section title="Network Troubleshooting in VoD scenario">
        <figure align="center" anchor="fig1" title="Figure 1">
          <artwork>
                      +--------+
        IPTV Platform +--------+----------^--------------
         /OTT/CDN     +--------+          |
                      +----+---+          |
                           |              |
                     //----+---\\         |
                 |///            \\\|     |
                |                    |    |URTT
                 |\\\            ///|     |
                     \\----+---//         |
                           |              |
                           |              |
                      +--------+          |
                CR    +--------+          |
                           |              |
                           ---------------V------------------
                           |                      ^
               BRAS  +-----+---+                  |
                     +---/---\-+                  | Downstream
                       //     \\                  |   Fixed
                     //         \                 |   Network
       OLT  +---------+        +-\------+         |    Latency
            +---------+        +--------+    DRTT |
                                                  |
          ----     ----         ----     ----  --------------
         /----\   /----\       /----\   /----\    |
         |    |   |    |       |    |   |    |    |Home Network
    Home |    |   |    |       |    |   |    |    |  Latency
   Network    |   |    |       |    |   |    |    |
         +----+   +----+       +----+   +----+----V------</artwork>
        </figure>

        <t>The proposed measurement method can be applied when VoD streaming
        media running over TCP is delivered as unicast stream from VoD server
        in the operator network to end users in home network. In some cases,
        the fault occurs in the home network which cause user experience
        downgrading, in some other cases, fault occurs in the operator
        network.</t>

        <t>To pinpoint the location of the fault , MP can be deployed on ONT
        device of the home network. The home network is refer to the
        downstream of the MP and the operator network is refer to the upstream
        of the MP. Suppose the rate of the media rate is v, we can compare
        DT/UT/E2ET with v. If DT&lt;v and UT&gt;v, the home network is the
        root cause for streaming media quality downgrading. If DT&gt;v and
        UT&lt;v, the operator network is the root cause. If DT&gt;v, UT&gt;v,
        and E2E&lt;v, both home network and operator network should be
        responsible for streaming media quality downgrading.</t>
      </section>

      <section title="WiFi Anomaly Analysis in the Home Network">
        <t>WiFi latency is a key factor impacting the user experience of home
        network application. [WIFI] shows WiFi latency follows a long tail
        distribution: its 50th, 90th and 99th percentile are around 3ms, 20ms
        and 250ms. If the WiFi network get congested, the quality degrades
        proportionally with WiFi lantency. To analyse WIFi Anomaly degree in
        the home network, See figure 1, we can calculate cumulative
        distribution of WiFi latency based on measured values:<figure>
            <artwork>WiFi Latency = DRTT - Downstream Fixed Network Latency</artwork>
          </figure></t>

        <t>and determine threshold value for WiFi Latency based on
        periodically collected dataset,e.g.,<figure>
            <artwork>Threshold = UBV + coef *(UBV-LBV)</artwork>
          </figure></t>

        <t>Where UBV is the 75th percentile value, LBV is the 25th Percentile
        value, coef is coefficiency value which can be set to 1.5.</t>

        <t>By Comparing WiFi latency measured value with the threshold value,
        we can decide if WiFi Anomaly is the root cause of network quality
        degrading.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>This document does not introduce security issues beyond those
      discussed in [[RFC4445].</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>+1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997"/>

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="WIFI">
        <front>
          <title>Characterizing and Improving WiFi Latency in Large-Scale
          Operational Networks</title>

          <author fullname="" initials="" surname="">
            <organization>MobiSys'16, 2016, Singapore, ACM ISBN
            978-1-4503-4269-8/16/06</organization>
          </author>

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

      <?rfc include="reference.RFC.4445.xml"?>
    </references>
  </back>
</rfc>
