Internet DRAFT - draft-huang-rtcweb-monitoring
draft-huang-rtcweb-monitoring
Network Working Group R. Huang
Internet-Draft R. Even
Intended status: Standards Track Huawei
Expires: September 6, 2012 March 5, 2012
Web Real-Time Communication (RTCWEB): Monitoring Usage
draft-huang-rtcweb-monitoring-00
Abstract
This document describes the monitoring aspect usage in RTCWeb. It
also gives some guidelines for which RTCP XR metrics and extentions
need to be supported.
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 September 6, 2012.
Copyright Notice
Copyright (c) 2012 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Huang & Even Expires September 6, 2012 [Page 1]
Internet-Draft RTCWEB Monitoring March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Monitoring Issues for End Systems . . . . . . . . . . . . . . . 3
4. Monitoring Models for Service Provider . . . . . . . . . . . . 4
4.1. JS Dependent Monitoring . . . . . . . . . . . . . . . . . . 4
4.2. JS Independent Monitoring . . . . . . . . . . . . . . . . . 5
5. Guideline for Selecting Monitoring Metrics . . . . . . . . . . 5
5.1. Metrics from RFC3611 . . . . . . . . . . . . . . . . . . . 5
5.2. Other Extended Metrics . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Huang & Even Expires September 6, 2012 [Page 2]
Internet-Draft RTCWEB Monitoring March 2012
1. Introduction
RTP usage in RTCWEB framework is discussed in
[I-D.ietf-rtcweb-rtp-usage]. It specifies how RTP is used in the
RTCWEB context, and gives requirements of which RTP features and
extensions should be included. It briefly describes the performance
monitoring as one of RTP usages in RTCWEB framework, but it doesn't
go into further discussion.
To help participants to know better the quality of RTCWEB services,
it is required that RTCWEB framework should provide some means to
estimate the services quality and to inform about network problems.
This memo discusses the monitoring issues in RTCWEB framework, and
makes recommendations about the selection of monitoring metrics in
RTCWEB applications.
2. Terminology
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 [RFC2119].
3. Monitoring Issues for End Systems
Since the intention of monitoring is to reflect the service quality
and the network conditions, some information, such as statistics of
media packets and calculations of delay, should be provided to the
participants, or even service providers. This kind of information
could be presented from the signaling path (such as the total session
setup time), and from the media path. Monitoring of the signal path
is outside the scope of the RTCWEB standards suite, so only
monitoring of the media path will be discussed in the document. This
section mainly discusses the monitoring issues for participants,
while section 4 talks about the monitoring models for service
provider.
As depicted in the RTCWEB architecture, the media path goes directly
between the browsers, so browsers are the entities obtaining the
monitoring information directly. That means some APIs must be
provided for Javascript application to take advantage of this
information. An undecided issue is what kind of monitoring
information should be offered by Javascript APIs. There are two
models can be applied. One model is that the browser collects the
raw information from media path, does some calculation, and provides
some new accumulated information to Javascript Applications through
APIs. In this model, the accumulated information reflecting the
Huang & Even Expires September 6, 2012 [Page 3]
Internet-Draft RTCWEB Monitoring March 2012
quality of media transmission informed from the APIs should be very
common to any Javascript applications, so that each Javascript
application would do nothing but convey the information to web
server, or interpret it to user. Another alternative model is that
the browser conveys the raw information collected from media path to
the Javascript applications through APIs. As the browser is on the
media path, it is possible for the browser to report all monitoring
information, such as RTCP information, to the Javascript application.
This model is more flexible than the previous one. Different
Javascript applications can apply different calculations and
statistics according to their respective demands. The only shortage
is that it may be too much information which may be not required.
Another uninvestigated problem is what kind of monitoring information
should be collected from the media path. In chapter 5,
recommendations are provided to choose monitoring metrics from RTP
layer.
4. Monitoring Models for Service Provider
From the perspective of service providers who wish to comply with
service-level-agreements, they need to monitor the performance of the
infrastructure and to provide a good service experience for their
users, monitoring information should be passed to the providers'
server (maybe web server). Based on the use-cases described in
[I-D.ietf-rtcweb-use-cases-and-requirements], the monitoring
implementation may vary in different scenarios. In this chapter, the
monitoring models in RTCWEB will be discussed. Note in these models,
no other new requirements for RTCWEB API are raised other than those
discussed in chapter 3.
4.1. JS Dependent Monitoring
In this model, monitoring data goes from the browser to Javascript
application through API, and then flows to Web Server through the
signaling protocol. In this case, the Web Server is the monitoring
server to collect all the monitoring information from all the end
users for service provider. The browser-to-browser use-cases,
telephony terminal and Fedex call of browser-GW/server use-cases
specified in [I-D.ietf-rtcweb-use-cases-and-requirements] are all
applicable to this model. However, there exists minor difference
between these use-cases. For the cases of sharing one operator, two
users have logged into the same web server. The web server can get
monitoring data from both users, therefore the network condition
between the two users can be inferred easily. While for the service
with inter-operator calling, two users have logged into two different
web servers provided by different service providers. Each web server
Huang & Even Expires September 6, 2012 [Page 4]
Internet-Draft RTCWEB Monitoring March 2012
can only get its subscriber's monitoring data. If the monitoring
information of the other user is needed, some additional agreements
between two web servers will be needed, which will increase the
complexity of the whole system. Actually, the media path in RTCWEB
is a point-to-point unicast connection. Each side of the connection
can obtain or calculate all the transport information from this
unicast connection. So it is required that the browser can get
monitoring data as much as it could in the JS dependent monitoring
model.
4.2. JS Independent Monitoring
In this model, monitoring data may not go through Javascript
applications. It flows in the media path, directly collected by some
central server provided by service providers. In this case, the
central server is the monitoring server. Note that the central
server is not some new entity that will be added to the media path
just for monitoring purpose. The central server is a participant in
the RTCWEB session. Use-cases, which the browser of each participant
establishes connections with a central server, such as the video
conferencing system with central server specified in
[I-D.ietf-rtcweb-use-cases-and-requirements]belong to this model. In
this case, the central server is the other side of the media path.
Monitoring data can be obtained directly from the media path by the
central server. As long as adequate information is collected, the
central server can easily give service quality evaluation and network
condition diagnosis. There is no additional APIs required. All can
be done according to the current RTP monitoring activities. The
communication from the central server to the web server or other
servers is based on monitoring implementation of service operator
which is out of scope here.
5. Guideline for Selecting Monitoring Metrics
Since RTP is the media transport protocol in RTCWEB, we mainly
discuss the RTP based monitoring metrics. RTCP SR/RR collects
information and reports it periodically. But it only provides
partial information, which means that you can use it in a limited way
to solve issues such as congestion. It's not sufficient for problem
diagnosis or performance monitoring. In this chapter some guidelines
are provided for RTCWEB to choose the statistics metrics specified in
RTCP XR and other extensions defined in xrblock working group.
5.1. Metrics from RFC3611
RTP Control Protocol Extended Reports [RFC3611]extends the statistics
specified in the RTCP SR/RR. It defines a set of metrics that
Huang & Even Expires September 6, 2012 [Page 5]
Internet-Draft RTCWEB Monitoring March 2012
contain information for assessing media quality, especially VoIP, and
diagnosing problems. The information includes 4 kinds of metrics:
packet-by-packet metrics, reference time related metrics, statistics
summary metrics and VoIP metrics. Packet-by-packet metrics are
usually applied to some network tomography applications, such as
multicast inference of network characteristics (MINC). VoIP metrics
are used for VoIP performance monitoring and diagnosis. These two
kinds of metrics are not generic enough to be implemented in RTCWEB.
While the other two kinds of metrics, reference time related metrics
and statistics summary metrics, are relatively useful for RTCWEB
services.
Reference time related metrics include two report blocks defined in
RFC3611. They are receiver reference time report block and DLRR
report block. These two report blocks enable the receivers the
ability to calculate the round-trip time (RTT) between sender and
itself. Reference time related metrics are very useful for the
receiver to report the transmission time. In RTCWEB services, each
browser participating in the session may have the requirement to
measure or calculate the media path transmission time. It is
recommended that the reference time related metrics SHOULD be
implemented in the browser so that each side either receiver or
sender can calculate the transmission time in the media path and
other related .
Statistics summary report block is defined to contain statistics
summary metrics. The report block records statistics about lost
packets, duplicated packet, jitter information and TTL or Hop limit
values. Lost packets and duplicated packets give more precise
statistics than the loss statistics specified in [RFC3550]. Jitter
information metrics includes minimum jitter, max jitter, mean jitter
and deviation jitter values. These metrics evaluate the transmission
quality during an interval. In RTCWEB services, each browser
participating in the session acts as both sender and receiver. When
the browser acts as a receiver, it can calculate these metrics by
itself. While when browser is a sender, it could get this kind of
information by itself. One of the resolutions is that the receiver
receiving the media issued from the browser sends these metrics by
RTCP XR block. As what is discussed in chapter 4, each user in
RTCWEB service SHOULD try to collect enough monitoring data from both
sides. So if you have the requirements to present detail statistics
information of the media transmission, you SHOULD implement these
metrics in your browsers. TTL or Hop limit values convey the
information about the path characteristics change during an interval.
The change may lead to the increasing or decreasing of delay and
packet losses. But in RTCWEB services, the transport of media is
point-to-point and best-effort. The variety of hops in media path
isn't the most direct information for user or service provider. It
Huang & Even Expires September 6, 2012 [Page 6]
Internet-Draft RTCWEB Monitoring March 2012
is not required to be implemented in the browsers. While TTL or Hop
limit values are included in the one statistics summary report block.
It is recommended to set the TTL/Hop limit related fields to 0.
Note that the measurement intervals may be different from the RTCP
SR/RR transmission interval specified in [RFC3550]. It is
recommended that the RTCP XR report blocks are compounded with RTCP
SR/RR and sharing the same interval for simplification.
5.2. Other Extended Metrics
New report blocks containing new metrics are being discussed in the
XRBLOCK working group. Some of them may be useful to RTCWEB
applications.
RTCP SR/RR and RTCP XR have defined some metrics regarding loss/
jitter statistics and calculations. These metrics are all about per
call statistics and average packet loss rates which are too coarse,
not detailed enough to capture some transitory nature of the
impairments, such as transient network
congestions.[I.D-ietf-xrblock-rtcp-xr-burst-gap-discard] and
[I.D-ietf-xrblock-rtcp-xr-burst-gap-loss]define new report blocks
beyond the information in VoIP metrics of RFC3611 for usage in a
range of RTP applications. More burst-related metrics are reported
in either cumulative or interval reports, which gives a flexible
algorithm usage. If RTCWEB services have the requirement to see the
transient problems, it is recommended to implement the metrics
defined [I.D-ietf-xrblock-rtcp-xr-burst-gap-discard] and
[I.D-ietf-xrblock-rtcp-xr-burst-gap-loss]in the browsers. If both of
them are applied, it is recommended to compound them together. Note
the use of these two report blocks in RTCWeb applications must follow
the framework defined in [I.D-ietf-avtcore-monarch].
[I.D-ietf-xrblock-rtcp-xr-discard]] defines a report block to report
the number of packets discarded due to the jitter. It augments the
statistics summary metrics specified in RFC3611. Using this metric,
discard rate can be calculated. This kind of granular statistics
supply accurate metrics for troubleshooting and SLA delivery. It is
applicable to the applications with jitter buffer, which RTCWEB end
users definitely have. If you have the requirement to get accurate
monitoring information, you SHOULD implement the metrics defined in
[I.D-ietf-xrblock-rtcp-xr-discard] along with the statistics summary
report block of RFC3611, and keep the report interval of this metric
accordance with the interval of the statistics summary report block.
Note the use of the report block in RTCWEB applications must follow
the framework defined in [I.D-ietf-avtcore-monarch].
[I.D-ietf-xrblock-rtcp-xr-delay] defines a new report block including
Huang & Even Expires September 6, 2012 [Page 7]
Internet-Draft RTCWEB Monitoring March 2012
metrics beyond the delay metrics of VoIP metrics report block
specified in RFC3611. It augments the information with the mean,
minimum and maximum values of round-trip delay, which can be
calculated by RTCP SR/RR or RTCP XR. These metrics can be used by
the receivers to report the delays the receivers apperceive to the
senders. In RTCWEB services, each browser participating in the
session acts as both sender and receiver. When it acts as a sender,
it has the requirement to know the delay information of the media
stream sent by itself. As the browser of RTCWEB services all have
the requirement to obtain the delay of bidirectional connections, it
is recommended to implement the delay metrics defined in
[I.D-ietf-xrblock-rtcp-xr-delay] in browsers. Note that the interval
of this report block may be consistent with the RTCP SR/RR or RTCP
XR. If they use the same interval with RTCP SR/RR or RTCP XR, the
mean, minimum and maximum values of round-trip will have the same
value. The one way symmetric media path delay can be calculated from
the round trip and end system delay. The use of the report block in
RTCWEB applications must follow the framework defined in
[I.D-ietf-avtcore-monarch].
6. IANA Considerations
There is no IANA action in this document.
7. Security Considerations
The monitoring activities are implemented between two browsers or
browser-to-server. Also encryption procedures, such as those being
suggested for a Secure RTCP (SRTCP), can be used. It is believed
that monitoring in RTCWEB introduces no new security considerations
beyond those described in [I-D.ietf-rtcweb-rtp-usage] and
[I-D.ietf-rtcweb-security].
8. Acknowledgements
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Huang & Even Expires September 6, 2012 [Page 8]
Internet-Draft RTCWEB Monitoring March 2012
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
9.2. Informative References
[I-D.ietf-rtcweb-rtp-usage]
, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP",
October 2011.
[I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web",
October 2011.
[I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements",
November 2011.
[I.D-ietf-avtcore-monarch]
Wu, Q., Ed., Hunt, G., and P. Arden, "Monitoring
Architecture for RTP", February 2012.
[I.D-ietf-xrblock-rtcp-xr-burst-gap-discard]
Hunt, G., Clark, A., and Q. Wu, Ed., "RTCP XR Report Block
for Burst/Gap Discard Metric Reporting", January 2012.
[I.D-ietf-xrblock-rtcp-xr-burst-gap-loss]
Hunt, G., Clark, Alan., Zhang, S., Ed., Zhao, J., and Q.
Wu, "RTCP XR Report Block for Burst/Gap Loss Metric
Reporting", January 2012.
[I.D-ietf-xrblock-rtcp-xr-delay]
Hunt, G., Clark, A., Gross, K., and Q. Wu, "RTCP XR Report
Block for Delay Metric Reporting".
[I.D-ietf-xrblock-rtcp-xr-discard]
Hunt, G., Clark, A., Zorn, G., and Q. Wu, "RTCP XR Report
Block for Discard Metric Reporting".
Huang & Even Expires September 6, 2012 [Page 9]
Internet-Draft RTCWEB Monitoring March 2012
Authors' Addresses
Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: Rachel@huawei.com
Roni Even
Huawei
14 David Hamelech
Tel Aviv 64953
Israel
Email: roni.even@huawei.com
Huang & Even Expires September 6, 2012 [Page 10]
