Internet DRAFT - draft-fan-deep-performance-visualization
draft-fan-deep-performance-visualization
Network Working Group P. Fan
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: August 18, 2014 February 14, 2014
Deep Performance Visualization: Use Cases, Requirements and Framework
draft-fan-deep-performance-visualization-00
Abstract
Providing deep performance information by the networks is expected in
many use cases. This document intends to discuss a unified
presentation of performance, by investigating use cases that benefit
from performance information, describing relevant requirements, and
proposing a framework of how the components work together to enable
deep performance visualization.
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 http://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 August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Fan & Cao Expires August 18, 2014 [Page 1]
Internet-Draft Deep Performance Visualization February 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Potential Work . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
There are many applications today expecting a certain level of
knowledge about the network, e.g. topology. Knowing network related
information will be helpful to better make decisions and change
behaviors accordingly. Network performance is a valuable kind of the
information as it dynamically reflects how the network is performing
and how traffic will be likely to experience. Currently, network
performance information is generated and maintained by different
elements or systems for purposes like network monitoring, and there
is rather limited way for applications to get a deep and instant view
of the status of the whole or part of the network. This document
intends to discuss a service provided by the network to give a
unified presentation of network performance, by investigating use
cases that benefit from performance knowledge, describing
requirements for performance visualization ability, and proposing a
framework of how the components work together to enable deep
performance visualization.
2. Use Cases
This section gives a non-exhaustive list of uses cases that benefit
from obtaining a picture of deep network performance.
Network traffic optimization:
Traditional path selection for data traffic in a network is
based on static and per-link metrics (e.g. link bandwidth).
This approach may not be optimal without a picture of
performance of the entire network. For example, in a delay
sensitive financial network, end-to-end and per-hop latency
Fan & Cao Expires August 18, 2014 [Page 2]
Internet-Draft Deep Performance Visualization February 2014
performance is critical to traffic optimization. A detailed
per-flow performance will be even helpful as network elements
can then handle the traffic in a smarter way.
Load balancing in data centers:
Data centers utilize load balancers to distribute workload
across multiple servers, network links or other resources, to
achieve optimal resource utilization, maximize throughput,
minimize response time, and avoid overload. A load balancer
uses a health monitoring function to detect whether the servers
can provide services, and distributes service traffic to
different resources according to a scheduling algorithm or
strategy. For workload that is better served by network
support, load balancing will be improved if real-time network
performance is taken into account. For example, it will be
less likely to distribute a file downloading request to a
server to which the network has a limited available bandwidth.
Application aware network provisioning:
Enabling information exchange between applications and the
network will provide ways for them to better accommodate each
other. An application may have certain expectations for the
network quality, and having an idea of how the network is
performing will help the application adjust its behavior
accordingly; a network may have its own policies on
applications in addition to the information provided by an
application, and network elements are then able to adjust
forwarding behavior to differentiate application performance.
3. Requirements
This section describes requirements on an architecture providing deep
network performance visualization service.
o An API interface with other systems (regarded as applications)
must be provided. Applications utilize the interface to query for
desired performance information and get the response.
o An ability of real-time network performance query must be provided
for the applications that request current performance data. The
data can be derived from
* Results obtained from instant performance measurements/tests.
Fan & Cao Expires August 18, 2014 [Page 3]
Internet-Draft Deep Performance Visualization February 2014
* Status information gathered from network elements; the
information gathering is often performed on a periodic or
routine basis.
o An ability of querying historical performance data within a
certain period of time should be provided for the applications
that request past data. If this ability is provided, then the
length of the period must be configurable.
o In the absence of real-time performance data for a certain metric,
e.g. the current IP packet loss rate on the path A-B-C of TCP
flows with a TOS field being 0, an ability of responding with
other close performance data for informational reference should be
provided. With this ability current performance can be
anticipated to some extent. Informational data provided can be
* Historic performance data of that metric.
* Current performance data of related metrics, e.g. current IP
packet loss rate on the path A-B-C of IP flows with a TOS field
being 0.
o An ability of reporting performance data associated with network
topology information should be provided. Traditional metrics
focus more on end-to-end performance, while detailed network
structure and performance between endpoints are left out.
Performance gathered in this way may not be accurate enough, as
traffic may go through different paths. This is especially a
problem in certain situations, e.g. link aggregation, resource
pooling, etc.
o An ability of reporting flow based performance should be provided.
A traffic flow can be identified by a set of match fields, e.g.
the 5-tuples.
4. Framework
The following picture depicts a framework providing deep performance
visualization service.
Fan & Cao Expires August 18, 2014 [Page 4]
Internet-Draft Deep Performance Visualization February 2014
+------+ +------+ +------+ +------+ +------+ +------+ +------+
| ALTO | | PCE | | Load | |Traff.| | Web | | Net | |Other |
| | | | | ball.| |engi. | | app. | |admin | |apps..|
+------+ +------+ +------+ +------+ +------+ +------+ +------+
/\ /\
/||\ API /||\
,--------------------------------------.
| Performance Synthetic Analyzer |
\______________________________________/
: : : : :
: : : : :
*---------:--:-------------:------:---------:---------*
/ +------,-.+ : : : +------,-.+ /
/ |Ter- ( R ) : : : |Web ( R ) /
/ |minal `-'| : : : |server`-'| /
/ +---------+ : : : +---------+ /---*
*-----------------:-------------:------:--------------* /
/ : +--------:+ : /
/ +--------:+ |Fwd. ,-. ,-.-------+ /
/ |Test ,-.| |device( R ) ( R ) NMS | /
/ |agent( R ) +-------`-' `-' | /
/ +------`-'+ +---------+ /R:Performance
*---------------------------------------------------* Reporter
Components contained in the framework include:
o Performance reporter. A performance reporter obtains raw
performance information at a certain location of the network. The
carrier of a reporter can be a forwarding device, a test agent
that runs measurement, a web server, a mobile device, the NMS
(Network Management System), etc. Performance metrics covered by
different reporters may be varied, e.g. a reporter on a forwarding
device gets packet drop counts and another reporter on a web
server gets CPU utilization ratio. Performance information
obtained by a reporter is not modified, but directly sent to the
performance synthetic analyzer.
o Performance synthetic analyzer. A performance synthetic analyzer
receives performance information sent by the performance
reporters, and processes the information into performance records
to associate data, reduce duplication, and unify format. Records
are stored in the database of the analyzer. The analyzer receives
query request from applications, and comprehend requested
performance metrics. The analyzer comes up with requested
performance value by seeking among the records and probable
computations using relevant records, and responds the application
with the exact values, informational values as described in the
requirements, or a message indicating value providing failure.
Fan & Cao Expires August 18, 2014 [Page 5]
Internet-Draft Deep Performance Visualization February 2014
o Applications. Applications utilize this framework to get
information about network performance. An application can be a
system/protocol/function that intends to rely on some knowledge of
the network to be better performed. To an application the
analyzer acts as an infrastructure representing a global view of
performance, while the details of the network are hidden under the
infrastructure.
As depicted in the picture, the framework incorporates two
interfaces:
o The analyzer-to-reporter interface is used to report raw
performance information from reporter to analyzer.
o The analyzer-to-application interface is used to request for
performance information from application to analyzer, and respond
with corresponding values from analyzer to application.
5. Potential Work
This section gives a list of work items that needs to sort through.
o The architecture of the framework is to be defined, including
specification of components and interfaces.
o Method of report between reporter and analyzer is to be specified,
including an information model and a reporting protocol. Existing
information models and protocols (e.g. IPFIX, Syslog, SNMP, etc.)
can be considered as candidates, and possible extensions are to be
developed in relevant working groups.
o API interface provided by the analyzer toward applications is to
be defined. How applications call the API to get the information
concerned has to be specified.
o Performance metrics that better evaluate network state for
different purposes will have to be extended in relevant working
groups.
6. Security Considerations
Certain authentication, authorization, or encryption mechanism is
expected to be developed to deal with potential problems of attack,
privacy or security. Security consideration is to be further
discussed.
Fan & Cao Expires August 18, 2014 [Page 6]
Internet-Draft Deep Performance Visualization February 2014
7. IANA Considerations
This memo includes no request to IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-25 (Work in Progress), January 2014.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
RFC 2578, April 1999.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", RFC 7011, September 2013.
Authors' Addresses
Peng Fan
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing 100053
P.R. China
Email: fanpeng@chinamobile.com
Zhen Cao
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing 100053
P.R. China
Email: caozhen@chinamobile.com
Fan & Cao Expires August 18, 2014 [Page 7]
