idnits 2.17.1 draft-ding-tcp-emdi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4445 -- Possible downref: Non-RFC (?) normative reference: ref. 'WIFI' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Ding 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: January 4, 2018 R. Gu 6 China Mobile 7 July 3, 2017 9 An Enhanced Media Delivery Index (eMDI) based on TCP 10 draft-ding-tcp-emdi-00 12 Abstract 14 This document introduces an Enhanced Media Delivery Index (eMDI) that 15 can be used as a diagnostic tool or a quality indicator for 16 monitoring a network intended to deliver streaming media over TCP 17 transport. It aims to address the problems that RFC4445 has when 18 measuring in environments where TCP traffic is dominated as a 19 transport for streaming media. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 4, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Measurement Setup . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Measurement Method . . . . . . . . . . . . . . . . . . . . . 4 59 5. Use Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Network Troubleshooting in VoD scenario . . . . . . . . . 5 61 5.2. WiFi Anomaly Analysis in the Home Network . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 TCP is one major transport protocol in use in most IP networks, and 69 supports the transfer of over 80 percent of all traffic (e.g.,OTT 70 traffic, IPTV VOD traffic) across the public Internet today. Packet 71 loss ratio and latency are two major characteristics in the network 72 to affect the behavior of TCP. The bad TCP performance might also 73 indicate the unacceptable end-user-perceived quality level. 75 Media Delivery Index (MDI)[RFC4445] is a method widely used in the 76 network as a diagnostic tool to measure both the instantaneous and 77 longer-term behavior of networks carrying streaming media in the 78 media layer. However the limitation of MDI measurement is mostly 79 applicable to streaming media and protocol over UDP, it falls short 80 when monitoring a network intended to deliver multimedia applications 81 over TCP Transport, i.e., the traditional MDI metrics especially 82 Media Loss Rate (MLR) deployed in the network devices is difficult to 83 infer the packet loss if the missing packets were retransmitted when 84 the packet loss was detected by the TCP sender. On the other hand, 85 TCP sender will adjust the sending data rate to reduce the 86 probability of further packet loss, which means throughput is 87 declining when extra delay is incurred by retransmitting lost 88 packets. Therefore, throughput can be regarded as a quality 89 indication for network monitoring and diagnosis. 91 This document introduces a new measurement method and associated 92 metrics,i.e.,downstream/upstream/end to end throughput, to complement 93 methods defined in [RFC4445]. This new method can quickly identify 94 the root cause of the QoS related problem, improve efficiency of 95 network monitoring and troubleshooting. 97 2. Terminologies 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 This document uses the following terms: 105 Measurement point (MP): A measurement point is the logical or 106 physical location defined in the TCP that acts as a source of 107 information gathered for monitoring purposes. 109 Upstream packet lost ratio (UPLR): UPLR is the ratio of the number 110 of packets lost to the total number of packets sent from server to 111 measurement point during predefined measurement interval. 113 Downstream packet lost ratio (DPLR): DPLR is the ratio of the 114 number of packets lost to the total number of packets sent from 115 measurement point to client during a predefined measurement 116 interval. 118 Upstream average RTT (URTT): URTT is the average RTT at the path 119 from server to measurement point during a predefined measurement 120 interval. 122 Downstream average RTT (DRTT): DRTT is the average RTT at the path 123 from measurement point to client during a predefined measurement 124 interval. 126 End to end Throughput (E2ET): E2ET is the rate of successful packet 127 delivery over an end-end network path during a predefined 128 measurement interval. 130 Downstream throughput (DT): DT is measured by the number of packets 131 received per second at the downstream of measurement point during 132 a predefined measurement interval. 134 Upstream throughput (UT): UT is measured by the number of packets 135 received per second at the upstream of measurement point during a 136 predefined measurement interval. 138 3. Measurement Setup 140 A stream of packets sent by streaming media Server passes through MP 141 (MP can be bridge, router or gateway), and finally reach the client 142 (destination endpoint). If a node A is placed between the server and 143 MP in the network , then A is upstream node of MP. Otherwise, A is 144 downstream node of MP. 146 +--------+ MP | +--------+ 147 | Server |------Upstream---->|-----Downstream---->| client | 148 +--------+ | +--- ----+ 150 4. Measurement Method 152 The rationale of the measurement is to compare DT/UT/E2ET with data 153 packet rate. If DT is less than data packet rate and UT is greater 154 than data packet rate, there is something wrong with the downstream 155 network. Otherwise, the upstream network has some problems. 157 When the packet loss occurs in the network, an additional limit(i.e., 158 packet loss probability) is imposed on the throughput besides TCP 159 recieve window. In case of light or moderate packet loss when the 160 TCP rate is adjusted by the congestion avoidance algorithm, DT can be 161 calculated according to the following formula: 163 DT = MSS/(DRTT+URTT)(DPLR)(1/2); 165 Where MSS is the maximum segment size. Assuming the number of lost 166 packets at the downstream during a predefined measurement interval is 167 a, and the number of total packets sent by MP is x, then DPLR is then 168 calculated as following: 170 DPLR = a/x. 172 Average RTT of some packets (d1..dm) at the downstream direction are 173 used to compute DRTT: 175 DRTT= sum (RTTdi)/m, i= 1..m 176 Where RTTdi indicates the RTT of packet di at downstream. 178 Similarly, average RTT of some packets (u1..un) at the upstream 179 direction are used to compute URTT: 181 URTT= sum (RTTui)/n, i= 1..n 182 Where RTTui indicates the RTT of packet ui at the upstream. 184 And, UT can be calculated according to the formula: 186 UT = MSS/(DRTT+URTT)(UPLR)(1/2); 188 Assuming the number of lost packets at the upstream during a 189 predefined measurement interval is b, and the number of total packets 190 sent by Server is y, then UPLR is then calculated as following: 192 UPLR = b/y. 194 And E2ET can be calculated according to the formula: 196 E2ET = MSS/(DRTT+URTT)(UPLR+DPLR)(1/2). 198 5. Use Examples 200 5.1. Network Troubleshooting in VoD scenario 202 +--------+ 203 IPTV Platform +--------+----------^-------------- 204 /OTT/CDN +--------+ | 205 +----+---+ | 206 | | 207 //----+---\\ | 208 |/// \\\| | 209 | | |URTT 210 |\\\ ///| | 211 \\----+---// | 212 | | 213 | | 214 +--------+ | 215 CR +--------+ | 216 | | 217 ---------------V------------------ 218 | ^ 219 BRAS +-----+---+ | 220 +---/---\-+ | Downstream 221 // \\ | Fixed 222 // \ | Network 223 OLT +---------+ +-\------+ | Latency 224 +---------+ +--------+ DRTT | 225 | 226 ---- ---- ---- ---- -------------- 227 /----\ /----\ /----\ /----\ | 228 | | | | | | | | |Home Network 229 Home | | | | | | | | | Latency 230 Network | | | | | | | | 231 +----+ +----+ +----+ +----+----V------ 233 Figure 1: Figure 1 235 The proposed measurement method can be applied when VoD streaming 236 media running over TCP is delivered as unicast stream from VoD server 237 in the operator network to end users in home network. In some cases, 238 the fault occurs in the home network which cause user experience 239 downgrading, in some other cases, fault occurs in the operator 240 network. 242 To pinpoint the location of the fault , MP can be deployed on ONT 243 device of the home network. The home network is refer to the 244 downstream of the MP and the operator network is refer to the 245 upstream of the MP. Suppose the rate of the media rate is v, we can 246 compare DT/UT/E2ET with v. If DTv, the home network is the 247 root cause for streaming media quality downgrading. If DT>v and 248 UTv, UT>v, and 249 E2E. 290 [WIFI] MobiSys'16, 2016, Singapore, ACM ISBN 291 978-1-4503-4269-8/16/06, "Characterizing and Improving 292 WiFi Latency in Large-Scale Operational Networks", 2016. 294 Authors' Addresses 296 Xiaojian Ding 297 Huawei 298 101 Software Avenue, Yuhua District 299 Nanjing, Jiangsu 210012 300 China 302 Email: dingxiaojian1@huawei.com 304 Qin Wu 305 Huawei 306 101 Software Avenue, Yuhua District 307 Nanjing, Jiangsu 210012 308 China 310 Email: bill.wu@huawei.com 312 Rong Gu 313 China Mobile 314 32 Xuanwumen West Ave, Xicheng District 315 Beijing 100053 316 China 318 Email: gurong_cmcc@outlook.com