RFC4445(中文)

Request for Comments: 4445                        IneoQuest Technologies

Category: Informational                                        J. Clark

                                                       Cisco Systems

                                                          April 2006

                 A Proposed Media Delivery Index (MDI)

摘要

本备忘录定义了一个媒体传输指标---Media Delivery Index (MDI)测量，可被用作监视想要传输诸如流媒体、MPEG video、Voice over IP或其他对到达时间和封包丢失敏感的网络的一个诊断工具或质量指示器。它提供了一个通信抖动指示，对标定流速率背离的一种测量，以及对某一特定流数据丢失的一览测量。例如，MDI可被用作刻画和比较承载UDP流媒体网络的一个参考。

本备忘录中定义的MDI测量仅供参考。

1.  介绍

最近几年，在提供封包交换网络之上的服务质量（QoS）以改善流媒体及其他时间敏感和封包丢失敏感应用（如[i1], [i5], [i6], [i7]）的方法开发方面已获得了相当可观的进展。QoS是许多包含有诸如视频传输之类应用的实际运营的网络所必需的，它通过针对一个网络上准许的流数量设置上限确保网络带宽的可用性，以及由网络导致的包抖动。这些是标出一个接收端缓冲尺寸以正确实时显示视频而不会产生缓冲溢出或下溢所必需的。

目前基于RSVP和Diffserv的这类网络的大规模实施正在经受试验[i3]，且被主要的服务运营商指定用于传输流媒体（如MPEG video），因此需要方便地诊断问题，并监视部署这些QoS方法的网络的实时效果，或者评估这些方法是否需要。此外，由于存在大量已安装的不带QoS方法的传统网络，一个传输系统的过渡方案可能由包括这些方法和不包括这些方法的网络混合组成，从而增加了刻画这些网络的动态行为的难度。

本备忘录的目的在于说明一套可被用来推导出媒体传输指标（Media Delivery Index）的测量方法，MDI指示承载诸如MPEG video的流媒体的网络的即时和长期行为。

虽然本备忘录主要是针对MPEG Transport Stream (TS) packets [i8] over UDP的监视，但是此通用方法被期望适用于其他流媒体和协议。该方法适用于恒定码率流（CBR）和可变码率流（VBR），尽管可变码率流在某种程度上更难以计算。

本文档以恒定码率情况作为例子来说明测量方法，但是只要编码流的动态码率可被确定（见下面第3节说明的"drain rate"），则MDI提供网络导致的累积抖动的测量。对于一个可变码率编码流的MDI计算的建议和指导可能是一个将来文档的主题。

刻画这些相同特性的网络封包传输时间变化和不同的统计量在[i10]中被说明为一个通用方法。该方法能够针对不同目的而被参数化，其意图是定义一个灵活、可定制的定义从而可适用于广泛的应用和将来的实验。刻画抖动行为的其它方法也被捕获到[i12]中。广泛的报告格式[i11]已被说明以传递包括使用RTCP协议的抖动的信息。

MDI意欲代之以专门针对一个可伸缩的、经济计算的度量需要，刻画可能被施加于流媒体的网络损伤，而于控制层面、测量传输协议或流封装协议。这个度量指标其目标是用在承载大量流的生产网络，用于监视网络流质量，或分析大量易受IP网络设备损伤的流的其他应用。一个示例应用是迅速成长的有线/电信服务运营商的IPTV部署。

如下所述，MDI提供一个可伸缩的、逐个流的测量，其关注于包的丢失和抖动的累积影响。

2.  Media Delivery Index简介

MDI提供一个在消费者节点处由于包抖动而导致需要的缓冲深度的相关指示器，以及一个丢包指示。通过在不同节点、不同负载条件下，探测一个流媒体服务网络，能够快速识别引起封包流明显抖动或丢包的设备或区域。通过持续监视一个网络，与标称抖动的偏差或丢包行为可被用来指出一个即将发生或正在发生的故障错误情况，如过载。MDI被确信提供了必要的信息，检测所有网络引起的对流视频或voice-over-IP应用的损伤。而为了检修和纠正损伤可能需要其他参数。

MDI在所选的时间间隔周期的结束点被更新，横跨多个包含流媒体（如MPEG-2中的TS包）的封包。在一个测量时间，捕获MDI成分的最大值和最小值。测量时间范围可以仅仅是在一个检修故障任务期间捕获到预期的异常的时间，也可以是不确定的长期监视或日志应用时间。最大值和最小值可以通过以合适的频率对测量采样而获取。

3.Media Delivery Index成分

MDI包括两个组成成分：延迟因素（Delay Factor）和媒体丢包率（Media Loss Rate）。

3.1.延迟因素（Delay Factor）

延迟因素（DF）是在每个媒体流封包结束处观察到的，（流入）到达的媒体数据和流出的媒体数据之间的最大差值。假设流出速率是恒定码率流（CBR）的标称、恒定的流量速率（traffic rate），或者是可变码率流封包数据的分段确定计算的流量速率。此处的“流出速率”（“drain rate”）指有效负载媒体码率；例如，对于一个典型的3.75Mb/s MPEG video Transport Stream（TS），流出速率是3.75Mb/s---有效负载在一个解码节点按此速率被消耗（显示）。如果，在采样时间点，接收到的字节数等于发送的字节数，则此瞬间的流动速率平衡将为0；但是，最小的DF将是一个封包数量的媒体数据，因为这是必须被缓冲的最小数据量。

DF是在一个计算时间间隔（interval）期间，流动速率不平衡的最大观测值。这个以字节为单位的被缓冲的媒体数据被表示为：按照标称的流量码率（traffic rate）需要花费多长时间流出（或充填）该数据以获得DF。DF的显示建议精确到毫秒的十分位，提供流变化的合适指示，用于监视和诊断从1Mb/s到40Mb/s的典型流码率应用。

DF值必须在一个所选时间间隔（interval）的结束点更新和显示。所选时间间隔必须足以采样多个TS封包，因此，随标称的流量码率（traffic rate）而变化。对于典型的1Mb/s以上的流，1秒的间隔提供了一个足够长的采样时间，将被包含在所有的实施中。

DF指出必须缓冲（即，延迟）多长时间的一个数据流（按照其标称码率）以防止封包丢失。这个时间也可被看作由缓冲必然引起的网络延迟的一个测量，而缓冲机制是适应流抖动和防止丢失所必须的。

在测量周期（多个intervals）的期间，DF的最大值和最小值也可被显示，以呈现此测量周期中，相对于标称流量码率（流出速率），最坏情况的到达（流入）时间偏差，或抖动。它提供了一个动态的流动速率平衡指示，其最大值和最小值显示脱离平衡的最坏偏差。

DF给出在下个下游节点所需缓冲最小尺寸的一个线索。随着一个流向前行进，延迟因素的变化指示出封包堆积（packet bunching）或封包间隙（packet gaps）（抖动）。更大的DF值也指出：由于在开始流出之前，为了确保不会产生下溢出，需要预先充填一个接收缓冲，所以更多的网络延迟是必然的。

DF包括一个基于封包尺寸的固定部分，和一个基于构成交换网络架构的不同网络部件交换元素的缓冲利用情况的可变部分。

为了更详细地说明DF的计算，考虑一个虚拟缓冲（Virtual Buffer ）VB被用来缓冲一个流的接收封包。在一个计算间隔期间，当一个封包P(i)到达时，计算两个VB值，VB(i,pre)和VB(i,post)，定义如下：

VB(i,pre) = sum (Sj) - MR * Ti; where j=1..i-1

VB(i,post) = VB(i,pre) + Si

其中Sj是第j个封包的媒体负载大小，Ti是在此计算间隔中封包i到达的相对时间，而MR是标称的媒体码率。

VB(i,pre)是仅在P(i)到达之前虚拟缓冲的大小。（即：此计算间隔从开始到P(i)到达之时点，时长为Ti，共计流出MR*Ti个字节；共计收到i-1个封包，sum（Sj）个字节，j=1..i-1）

VB(i,post)是仅在P(i)到达之后的虚拟缓冲的大小。

在每个测量间隔的开始时点，使用初始条件VB（0）=0。一个测量间隔被定义为从一个标称周期（通常为1秒）期间最后一个封包到达之时之后，到下一个标称周期最后一个封包到达之时之后。

在一个测量间隔期间，如果收到k个封包，则有2*k+1个VB值用于推导VB(max)和VB(min)。在从2k+1个VB采样中确定VB(max)和VB(min)之后，此测量间隔的DF计算和显示如下： 

DF = [VB(max) - VB(min)]/ MR

如上所述，通常使用一个1秒的测量间隔。如果在一个间隔期间没有封包被接收到，则在一个有封包到达的间隔期间所计算的最后的DF将被显示。前面最后一个封包到达的时间总被保留，用于在下个封包到达时计算VB（即使最后一个接收到的封包的时间跨多个测量间隔）。

对于一个测量周期的首个接收测量间隔，没有DF被计算；但是，封包到达时间被记录，用于在下个间隔期间计算VB。

3.2.  媒体丢失率（Media Loss Rate）

媒体丢失率是在一个选定的间隔区间丢失或时序失真的信息流封包计数，此处的信息流封包是指承载流应用信息的封包。在一个IP封包中可能有0个或多个流封包。例如，在一个IP包中承载7个188字节的MPEG TS封包。在这种情况下，单独一个IP包的丢失导致计数7个丢失的封包（如果7个丢失封包中不包括null封包的话）。包括乱序（时序失真）封包是很重要的，因为许多流媒体的消费类设备不尝试重新排序所接收到的乱序包。

3.3.  Media Delivery Index

组合Delay Factor和Media Loss Rate数值产生下列MDI：

DF:MLR

其中

                          DF是延迟因素（Delay Factor）

                      MLR是媒体丢失率（Media Loss Rate）

在一个接收节点，已知其标称流出码率，DF的最大值指出适应封包抖动所需的缓冲大小。或者，按照Leaky Bucket [i9]参数术语，DF指示了bucket的大小b，表示为按给定标称流量速率r，传输bucket流量b的时间。

3.4.  MDI Application Examples

如果一个已知、较好特性的接收节点与数据源之间被未知的、特性不那么好的节点如中间的交换节点隔开，在中间数据链路上测量的MDI提供一个上行信息流流动行为的相应指示。对于一个给定恒定计算间隔的数据流，一个节点和另一个节点之间的DF差值指标可以指示本地区域的流量阻塞或者错误配置的QoS流规约，这些阻塞或错误配置可能引起更大地充填测量点本地设备缓冲，进而流动速率偏差，以及可能的数据丢失。

对于一个给定的MDI，如果DF很高，或者在一个包含多个间隔的一个有效测量周期区间捕获到的DF最大值-最小值很高，则已检测到抖动，但是长期的、平均流动速率可能是标称的。这可能是由于一个与感兴趣的流无关的并发信息流引起封包堆积而导致的瞬间流扰动的结果。

一个高的DF可能引起下行缓冲溢出或下溢出，或者甚至在无丢失数据的情况下不可接受的延迟。

由于瞬间的网络故障，或DF偏移，封包可能会在网络中被丢失。MDI的MLR部分显示出这种情况。

通过自动或手动的流量检测和识别，以及随后的MDI计算，获得实时的流量统计，DF可以指示一个信息流的动态退化或突发情况，这可被用来预先考虑一个发展中的网络运营问题，如瞬时的超量订购（transient oversubscription）。

在网络交换机内部的信息流（flows）的这些统计数据可以使用可用的交换机cpu资源获得，因为对于少量的信息流只有极少的计算要求。而对于一个gigabit Ethernet网络上存在的所有信息流的统计数据，将很可能需要专用的硬件设施，尽管这些设施要求不高，因为缓冲需求和每个流所需的计算都是极小的。

通过为网络交换机配备MDI测量方法，信息流（flow）损伤问题可以被快速识别、定位与纠正。在交换机采用合适的硬件资源这样配置之前，专门的硬件工具通过镜像端口、链接分接头之类获得对交换机信息流的访问，可以提供补充的交换机统计数据，作为一个过渡策略。

MDI也可被用来描绘一个流解码器的可接受性能特征。例如，一个MPEG解码器可被描绘为对于可接受的显示性能（可接受的屏幕影像）所能容忍的具有给定最大DF和MLR值的流。网络条件如Interior Gateway Protocol (IGP)路由协议重新收敛时间也可被包含在流容忍DF值中，从而获得一个更高质量的用户体验。

4.  总结

MDI组合了Delay Factor---指出即将发生的数据丢失的潜在可能，和Media Loss Rate---作为丢失数据的指示器。通过在一个测量周期区间和网络内的多个策略地点监视DF和MLR，以及它们的最小值和最大值偏差，可为一个承载流媒体内容的网络检测和隔离通信阻塞或设备损伤。

5.  Security Considerations

本文档中说明的测量不会直接影响网络或用户的安全。为应对这些测量结果而采取的可能影响网络可用带宽或业务可用性的行动不在本文档的范围内。

执行本文档所说明的测量只要求检查负载头信息（如MPEG TS头或RTP头），以确定标称的流码率和序列号信息。内容可以被加密而不影响这些测量。因此，内容的保密理应不会成为问题。

6.  参考信息

[i1]  Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[i2]  Partridge, C., "A Proposed Flow Specification", RFC 1363, September 1992. [i3]  R. Fellman, `Hurdles to Overcome for Broadcast Quality Video Delivery over IP` VidTranS 2002.

[i4]  CableLabs `PacketCable Dynamic Quality-of-Service Specification`, PKT-SP-DQOS-I06-030415, 2003.

[i5]  Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[i6]  Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.

[i7]  Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.

[i8]  ISO/IEC 13818-1 (MPEG-2 Systems)

[i9]  V. Raisanen, "Implementing Service Quality in IP Networks", John Wiley & Sons Ltd., 2003.

[i10] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.

[i11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.

[i12] Schulzrinne, H.,  Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD , RFC 3550, July 2003.

7.  致谢

作者衷心感谢IneoQuest Technologies公司的Marc Todd和Jesse Beeson，Time Warner Cable的Bill Trubey 和 John Carlucci，Cox Communications的Nishith Sinha，SeaChange International的Ken Chiquoine，Bell Canada的Phil Proulx，TANDBERG Television的Paul Stallard博士，Broadbus Technologies的Gary Hughes，SBC Laboratories的Brad Medford，Adelphia Communications的John Roy，Kasenna的Cliff Mercer, PhD，Rogers Cable的Mathew Ho，Optinel Systems的Irl Duling所做贡献，感谢他们对本文档早期版本的检查和评价及MDI的实践。

Authors' Addresses

   James Welch

   IneoQuest Technologies, Inc

   170 Forbes Blvd

   Mansfield, Massachusetts 02048

   Phone: 508 618 0312

   EMail: Jim.Welch@ineoquest.com

   James Clark

   Cisco Systems, Inc

   500 Northridge Road

   Suite 800

   Atlanta, Georgia 30350

   Phone: 678 352 2726

   EMail: jiclark@cisco.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights.  Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard.  Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).