1 / 7

Consideration for Selecting RTCP XR Metrics for RTCWEB Statistics API

Consideration for Selecting RTCP XR Metrics for RTCWEB Statistics API. draft-huang-xrblock-rtcweb-rtcp-xr-metrics-01. Rachel Huang (rachel.huang@huawei.com) Varun Singh( varun@comnet.tkk.fi ) Roni Even (roni.even@mail01.huawei.com). Motivation. WebRTC needs Statistics.

matthew-randall
Download Presentation

Consideration for Selecting RTCP XR Metrics for RTCWEB Statistics API

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Consideration for Selecting RTCP XR Metrics for RTCWEB Statistics API draft-huang-xrblock-rtcweb-rtcp-xr-metrics-01 Rachel Huang (rachel.huang@huawei.com) Varun Singh(varun@comnet.tkk.fi) Roni Even (roni.even@mail01.huawei.com)

  2. Motivation • WebRTC needs Statistics. • draft-ietf-rtcweb-use-cases-and-requirements specifies requirement for statistics. • WebRTC 1.0 has defined some statistics Javascript APIs. • draft-alvestrand-rtcweb-stats-registry introduces a registration procedure for choosing metrics reported by JS APIs, and basic metrics from standard RTCP SR/RR. • Basic statistics from RTCP SR/RR may not be sufficient. • Some metrics are not enough, e.g., packet discarded and duplicated are not considered in RTCP SR/RR. • Precise quality monitoring and troubleshooting need other metrics besides RTCP SR/RR, e.g., application layer statistics.

  3. Considerations for Metrics Selecting • Metrics could only be collected from thereceiver side browser. • What if the sender side or other monitoring side wants to know the information? • Implementing RTCP XR by SDP negotiation • Metrics could be sent to the remote side by JS APIs or by other methods provided by applications. • Metrics could be queried at arbitrary intervals.

  4. Candidate Metrics • Loss, discard and duplicated packet count metrics • Pro: they may be useful for congestion control. • No con for now. • Burst/gap pattern metrics for loss and discard • Pros: • Per call statistics could not capture transitory nature of the impairments, e.g., bursty packet loss. • helpful for quality evaluation and locating impairments • No con for now. • Frame impairment summary metrics • Pros: providing information other than those of transport layer, which may accurately reflect the quality observed by applications. • No con for now.

  5. Candidate Metrics (Cont.) • Jitter and jitter buffer metrics • Pros • Jitter metric of RTCP SR/RR may not be able to reflect the variation of the whole interval when the interval is big enough. • Jitter metrics defined in RFC3611 and RFC6798 could provide more information • Jitter buffer metrics may be useful in QoE evaluation. • Cons: Is it useful to provide such information to application? • Number of bytes discarded • Pro: supplementing the sent and received octets and provides an accurate method for calculating goodput. • No con for now.

  6. Candidate Metrics (Cont.) • Number of retransmission packets • Pro: help to provide a more accurate quality evaluation • Con: retransmission is optional in RTCWEB • Run length encoded metrics for loss, discard and post-repair • uses a bit vector to encode the status about the packet • Pros: • providing additional information which are useful. • Post-repair RLE metric indicates how success of the error-resilience mechanism is. • Con: Repair mechanisms are optional in RTCWEB.

  7. Next Step • Comments and suggestions ? • Submit it to W3C and RTCWEB when consensus made.

More Related