BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)
RFC 5093
Document | Type |
RFC - Informational
(December 2007; No errata)
Was draft-hunt-avt-rtcpxnq (individual in rai area)
|
|
---|---|---|---|
Author | Geoff Hunt | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5093 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | avt-chairs@ietf.org |
Network Working Group G. Hunt Request for Comments: 5093 BT Category: Informational December 2007 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note The IESG has concerns about vendor code points allocation in this small namespace and might not approve similar documents in the future. Abstract This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre- standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2 3. Extended Network Quality (XNQ) Report Block . . . . . . . . . . 2 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Hunt Informational [Page 1] RFC 5093 RTCP XR eXtended Network Quality December 2007 1. Introduction A set of metrics of packet-transport quality has been defined by BT for pre-standards use in its network. These metrics are known as "XNQ" for "eXtended Network Quality". This document defines an RTCP-XR Report Block to transport the XNQ measures from an RTP end system to its peer, using the extension mechanism defined in [1]. The metrics are designed to supplement the packet-loss metric in RTCP [2] and the roundtrip delay measurement provided by RTCP. They provide metrics for IP Packet Delay Variation based on the IPDV metric defined in [3], metrics reporting the activity of the RTP end system's receiver's jitter buffer, and metrics reporting "errored" and "severely errored" seconds. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of [1]. This specification does not standardise the new report block for use outside BT's network. Work in progress on RTCP HR [5] is likely to obsolete these metrics and the RTCP-XR Report Block defined here. 2. Requirements Notation 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 [4]. 3. Extended Network Quality (XNQ) Report Block A set of metrics of packet-transport quality has been defined by BT for pre-standards use in its network. These metrics are known as "XNQ" for "eXtended Network Quality". This document defines an RTCP-XR Report Block using the extension mechanism defined in [1]. The new Report Block provides transport of the XNQ measures from an RTP end system to its peer. The metrics are described in the following text. However, some additional explanation is required for the metrics vmaxdiff, vrange, vsum, and c, which measure aspects of packet delay variation. The metrics are based on the measure known as IP Packet Delay Variation (IPDV) defined in [3]. The IPDV of a packet is the amount by which the packet was delayed in the network, minus the amount a reference packet was delayed in the network. The reference packet is usually the first packet of the connection. IPDV is a signed quantity. Hunt Informational [Page 2] RFC 5093 RTCP XR eXtended Network Quality December 2007 The metric vrange is the difference (longest minus shortest) between the longest and shortest network packet delays seen over the duration of the connection to date. The metric vrange is usually a positive quantity, but may be zero if the packet delay is exactly constant over the lifetime of the connection to date. The metric vmaxdiff is found as follows. For each RTCP measurement cycle, find the difference (longest minus shortest) between the longest and shortest network packet delays within that measurementShow full document text