idnits 2.17.1 draft-fan-deep-performance-visualization-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-protocol' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC5424' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC7011' is defined on line 303, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-25 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Fan 3 Internet-Draft Z. Cao 4 Intended status: Informational China Mobile 5 Expires: August 18, 2014 February 14, 2014 7 Deep Performance Visualization: Use Cases, Requirements and Framework 8 draft-fan-deep-performance-visualization-00 10 Abstract 12 Providing deep performance information by the networks is expected in 13 many use cases. This document intends to discuss a unified 14 presentation of performance, by investigating use cases that benefit 15 from performance information, describing relevant requirements, and 16 proposing a framework of how the components work together to enable 17 deep performance visualization. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 18, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Potential Work . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 There are many applications today expecting a certain level of 68 knowledge about the network, e.g. topology. Knowing network related 69 information will be helpful to better make decisions and change 70 behaviors accordingly. Network performance is a valuable kind of the 71 information as it dynamically reflects how the network is performing 72 and how traffic will be likely to experience. Currently, network 73 performance information is generated and maintained by different 74 elements or systems for purposes like network monitoring, and there 75 is rather limited way for applications to get a deep and instant view 76 of the status of the whole or part of the network. This document 77 intends to discuss a service provided by the network to give a 78 unified presentation of network performance, by investigating use 79 cases that benefit from performance knowledge, describing 80 requirements for performance visualization ability, and proposing a 81 framework of how the components work together to enable deep 82 performance visualization. 84 2. Use Cases 86 This section gives a non-exhaustive list of uses cases that benefit 87 from obtaining a picture of deep network performance. 89 Network traffic optimization: 91 Traditional path selection for data traffic in a network is 92 based on static and per-link metrics (e.g. link bandwidth). 93 This approach may not be optimal without a picture of 94 performance of the entire network. For example, in a delay 95 sensitive financial network, end-to-end and per-hop latency 96 performance is critical to traffic optimization. A detailed 97 per-flow performance will be even helpful as network elements 98 can then handle the traffic in a smarter way. 100 Load balancing in data centers: 102 Data centers utilize load balancers to distribute workload 103 across multiple servers, network links or other resources, to 104 achieve optimal resource utilization, maximize throughput, 105 minimize response time, and avoid overload. A load balancer 106 uses a health monitoring function to detect whether the servers 107 can provide services, and distributes service traffic to 108 different resources according to a scheduling algorithm or 109 strategy. For workload that is better served by network 110 support, load balancing will be improved if real-time network 111 performance is taken into account. For example, it will be 112 less likely to distribute a file downloading request to a 113 server to which the network has a limited available bandwidth. 115 Application aware network provisioning: 117 Enabling information exchange between applications and the 118 network will provide ways for them to better accommodate each 119 other. An application may have certain expectations for the 120 network quality, and having an idea of how the network is 121 performing will help the application adjust its behavior 122 accordingly; a network may have its own policies on 123 applications in addition to the information provided by an 124 application, and network elements are then able to adjust 125 forwarding behavior to differentiate application performance. 127 3. Requirements 129 This section describes requirements on an architecture providing deep 130 network performance visualization service. 132 o An API interface with other systems (regarded as applications) 133 must be provided. Applications utilize the interface to query for 134 desired performance information and get the response. 136 o An ability of real-time network performance query must be provided 137 for the applications that request current performance data. The 138 data can be derived from 140 * Results obtained from instant performance measurements/tests. 142 * Status information gathered from network elements; the 143 information gathering is often performed on a periodic or 144 routine basis. 146 o An ability of querying historical performance data within a 147 certain period of time should be provided for the applications 148 that request past data. If this ability is provided, then the 149 length of the period must be configurable. 151 o In the absence of real-time performance data for a certain metric, 152 e.g. the current IP packet loss rate on the path A-B-C of TCP 153 flows with a TOS field being 0, an ability of responding with 154 other close performance data for informational reference should be 155 provided. With this ability current performance can be 156 anticipated to some extent. Informational data provided can be 158 * Historic performance data of that metric. 160 * Current performance data of related metrics, e.g. current IP 161 packet loss rate on the path A-B-C of IP flows with a TOS field 162 being 0. 164 o An ability of reporting performance data associated with network 165 topology information should be provided. Traditional metrics 166 focus more on end-to-end performance, while detailed network 167 structure and performance between endpoints are left out. 168 Performance gathered in this way may not be accurate enough, as 169 traffic may go through different paths. This is especially a 170 problem in certain situations, e.g. link aggregation, resource 171 pooling, etc. 173 o An ability of reporting flow based performance should be provided. 174 A traffic flow can be identified by a set of match fields, e.g. 175 the 5-tuples. 177 4. Framework 179 The following picture depicts a framework providing deep performance 180 visualization service. 182 +------+ +------+ +------+ +------+ +------+ +------+ +------+ 183 | ALTO | | PCE | | Load | |Traff.| | Web | | Net | |Other | 184 | | | | | ball.| |engi. | | app. | |admin | |apps..| 185 +------+ +------+ +------+ +------+ +------+ +------+ +------+ 186 /\ /\ 187 /||\ API /||\ 188 ,--------------------------------------. 189 | Performance Synthetic Analyzer | 190 \______________________________________/ 191 : : : : : 192 : : : : : 193 *---------:--:-------------:------:---------:---------* 194 / +------,-.+ : : : +------,-.+ / 195 / |Ter- ( R ) : : : |Web ( R ) / 196 / |minal `-'| : : : |server`-'| / 197 / +---------+ : : : +---------+ /---* 198 *-----------------:-------------:------:--------------* / 199 / : +--------:+ : / 200 / +--------:+ |Fwd. ,-. ,-.-------+ / 201 / |Test ,-.| |device( R ) ( R ) NMS | / 202 / |agent( R ) +-------`-' `-' | / 203 / +------`-'+ +---------+ /R:Performance 204 *---------------------------------------------------* Reporter 206 Components contained in the framework include: 208 o Performance reporter. A performance reporter obtains raw 209 performance information at a certain location of the network. The 210 carrier of a reporter can be a forwarding device, a test agent 211 that runs measurement, a web server, a mobile device, the NMS 212 (Network Management System), etc. Performance metrics covered by 213 different reporters may be varied, e.g. a reporter on a forwarding 214 device gets packet drop counts and another reporter on a web 215 server gets CPU utilization ratio. Performance information 216 obtained by a reporter is not modified, but directly sent to the 217 performance synthetic analyzer. 219 o Performance synthetic analyzer. A performance synthetic analyzer 220 receives performance information sent by the performance 221 reporters, and processes the information into performance records 222 to associate data, reduce duplication, and unify format. Records 223 are stored in the database of the analyzer. The analyzer receives 224 query request from applications, and comprehend requested 225 performance metrics. The analyzer comes up with requested 226 performance value by seeking among the records and probable 227 computations using relevant records, and responds the application 228 with the exact values, informational values as described in the 229 requirements, or a message indicating value providing failure. 231 o Applications. Applications utilize this framework to get 232 information about network performance. An application can be a 233 system/protocol/function that intends to rely on some knowledge of 234 the network to be better performed. To an application the 235 analyzer acts as an infrastructure representing a global view of 236 performance, while the details of the network are hidden under the 237 infrastructure. 239 As depicted in the picture, the framework incorporates two 240 interfaces: 242 o The analyzer-to-reporter interface is used to report raw 243 performance information from reporter to analyzer. 245 o The analyzer-to-application interface is used to request for 246 performance information from application to analyzer, and respond 247 with corresponding values from analyzer to application. 249 5. Potential Work 251 This section gives a list of work items that needs to sort through. 253 o The architecture of the framework is to be defined, including 254 specification of components and interfaces. 256 o Method of report between reporter and analyzer is to be specified, 257 including an information model and a reporting protocol. Existing 258 information models and protocols (e.g. IPFIX, Syslog, SNMP, etc.) 259 can be considered as candidates, and possible extensions are to be 260 developed in relevant working groups. 262 o API interface provided by the analyzer toward applications is to 263 be defined. How applications call the API to get the information 264 concerned has to be specified. 266 o Performance metrics that better evaluate network state for 267 different purposes will have to be extended in relevant working 268 groups. 270 6. Security Considerations 272 Certain authentication, authorization, or encryption mechanism is 273 expected to be developed to deal with potential problems of attack, 274 privacy or security. Security consideration is to be further 275 discussed. 277 7. IANA Considerations 279 This memo includes no request to IANA. 281 8. References 283 8.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", RFC 2119, March 1997. 288 8.2. Informative References 290 [I-D.ietf-alto-protocol] 291 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 292 ietf-alto-protocol-25 (Work in Progress), January 2014. 294 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 295 "Structure of Management Information Version 2 (SMIv2)", 296 RFC 2578, April 1999. 298 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 299 Element (PCE)-Based Architecture", RFC 4655, August 2006. 301 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 303 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 304 the IP Flow Information Export (IPFIX) Protocol for the 305 Exchange of Flow Information", RFC 7011, September 2013. 307 Authors' Addresses 309 Peng Fan 310 China Mobile 311 32 Xuanwumen West Street, Xicheng District 312 Beijing 100053 313 P.R. China 315 Email: fanpeng@chinamobile.com 317 Zhen Cao 318 China Mobile 319 32 Xuanwumen West Street, Xicheng District 320 Beijing 100053 321 P.R. China 323 Email: caozhen@chinamobile.com