[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]