[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 RFC 4445

                           A Proposed Media Delivery Index     June 2005





   Network Working Group                                        J. Welch
   Internet Draft                                 IneoQuest Technologies
   Intended Category:  Informational                            J. Clark
                                                           Cisco Systems
                                                              June, 2005


                      A Proposed Media Delivery Index
                          draft-welch-mdi-02.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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 a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/lid-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

   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.


Welch, Clark            Expires December 2005                [Page 1]

                           A Proposed Media Delivery Index     June 2005



Abstract

   This memo defines a Media Delivery Index (MDI) measurement which can
   be used as a diagnostic tool or a quality indicator for monitoring a
   network intended to deliver applications such as streaming media MPEG
   video and Voice over IP or other arrival time and packet loss
   sensitive information.  It provides an indication of traffic jitter,
   a measure of deviation from nominal flow rates, and a data loss at-a-
   glance measure for a particular flow.  For instance, the MDI may be
   used as a reference in characterizing and comparing networks carrying
   UDP streaming media. Included is a set of managed objects for SNMP-
   based management of IP media streams for which an MDI measurement is
   obtained.

   The Media Delivery Index measurement and MIB defined in this memo is
   intended for Information only.



1.
  Introduction

   There has been considerable progress over the last several years in
   the development of methods to provide for Quality of Service (QoS)
   over packet switched networks to improve the delivery of streaming
   media and other time and packet loss sensitive applications such as
   [i1], [i5], [i6], [i7].  QoS is required for many practical networks
   involving applications such as video transport to assure the
   availability of network bandwidth by providing upper limits on the
   number of flows admitted to a network as well as to bound the packet
   jitter introduced by the network.  These bounds are required to
   dimension a receiver`s buffer to properly display the video in real
   time without buffer overflow or underflow.

   Now that large scale implementations of such networks based on RSVP
   and Diffserv are undergoing trials [i3] and being specified by major
   service providers for the transport of streaming media such as MPEG
   video [i4], there is a need to easily diagnose issues and monitor the
   real time effectiveness of networks employing these QoS methods or to
   assess whether they are required. Furthermore, due to the significant
   installed base of legacy networks without QoS methods, a delivery
   system`s transitional solution may be comprised of both networks with
   and without these methods thus increasing the difficulty in
   characterizing the dynamic behavior of these networks.

   The purpose of this memo is to describe a set of measurements that
   can be used to derive a Media Delivery Index (MDI) which indicates
   the instantaneous and longer term behavior of networks carrying
   streaming media such as MPEG video.


Welch, Clark            Expires December 2005                [Page 2]

                           A Proposed Media Delivery Index     June 2005



   While this memo addresses monitoring MPEG Transport Stream (TS)
   packets [i8] over UDP, the general approach is expected to be
   applicable to other streaming media and protocols. The approach is
   applicable to both constant and variable bit rate streams though the
   variable bit rate case may be somewhat more difficult to calculate.
   This draft focuses on the constant bit rate case as the example to
   describe the measurement but as long as the dynamic bit rate of the
   encoded stream can be determined (the "drain rate" as described
   below in Section 3), then the MDI provides the measurement of
   network induced cumulative jitter.  Suggestions and direction for
   calculation of MDI for a variable bit rate encoded stream may be the
   subject of a future document.

2.
  Media Delivery Index Overview

   The MDI provides a relative indicator of needed buffer depths at the
   consumer node due to packet jitter as well as an indication of lost
   packets.  By probing a streaming media service network at various
   nodes and under varying load conditions, it is possible to quickly
   identify devices or locales which introduce significant jitter or
   packet loss to the packet stream. By monitoring a network
   continuously, deviations from nominal jitter or loss behavior can be
   used to indicate an impending or ongoing fault condition such as
   excessive load.  It is believed that the MDI provides the necessary
   information to detect all network induced impairments for streaming
   video or voice over IP applications.  Other parameters may be
   required to troubleshoot and correct the impairments.

   The MDI is updated at the termination of selected time intervals
   spanning multiple packets which contain the streaming media (such as
   transport stream packets in the MPEG-2 case.)  The Maximums and
   Minimums of the MDI component values are captured over a measurement
   time.  The measurement time may range from just long enough to
   capture an anticipated network anomaly during a troubleshooting
   exercise to indefinitely long for a long term monitoring or
   logging application.  The Maximums and Minimums may be obtained by
   sampling the MIB with adequate frequency.

3.
  Media Delivery Index Components

   The MDI consists of two components:  the Delay Factor (DF) and the
   Media Loss Rate (MLR).

3.1
   Delay Factor

   The Delay Factor is the maximum difference, observed at the end of
   each media stream packet, between the arrival of media data and the
   drain of media data, assuming the drain rate is the nominal constant


Welch, Clark            Expires December 2005                [Page 3]

                           A Proposed Media Delivery Index     June 2005


   traffic rate for constant bit rate streams or the piece-wise computed
   traffic rate of variable rate media stream packet data.  The "drain
   rate" here refers to the payload media rate; e.g., for a typical 3.75
   Mb/s MPEG video Transport Stream (TS), the drain rate is 3.75 Mb/s --
   the rate at which the payload is consumed (displayed) at a decoding
   node.  If, at the sample time, the number of bytes received equals
   the number transmitted, the instantaneous flow rate balance will be
   zero, however the minimum DF will be a line packet's worth of media
   data as that is the minimum amount of data that must be buffered.

   The DF is the maximum observed value of the flow rate imbalance.
   This buffered media data in bytes is expressed in terms of how long,
   in milliseconds, it would take to drain (or fill) this data at the
   nominal traffic rate to obtain the DF.  The DF value must be updated
   and displayed at the end of a selected time interval.  The selected
   time interval is chosen to be long enough to sample a number of TS
   packets and will, therefore, vary based on the nominal traffic rate.
   The Delay Factor indicates how long a data stream must be buffered
   (i.e. delayed) at its nominal bit rate to prevent packet loss.
   Another perspective of this time is as a measure of the network
   latency that must be induced from buffering that is required to
   accommodate stream jitter and prevent loss.  The DF`s max and min
   over the measurement period may also be displayed to show the worst
   case arrival time deviation, or jitter, relative to the nominal
   traffic rate in a measurement period.  It provides a dynamic flow
   rate balance indication with its max and min showing the worst
   excursions from balance.  To arrive at a bounded DF, the long term
   flow rate deviation (LFRD) must be 0, where LFRD is a running
   deviation of flow rate from expected nominal traffic rate over a
   measurement period.  A large positive or negative LFRD usually
   indicates a source flow failure or misconfiguration and would cause
   the DF value to steadily increase from interval to interval.

   The Delay Factor gives a hint of the minimum size of the buffer
   required at the next downstream node.  As a stream progresses, the
   variation of the Delay Factor indicates packet bunching (jitter).
   Greater DF values also indicate more network latency necessary to
   deliver a stream due to the need to prefill a receive buffer before
   beginning the drain to guarantee no underflow.   The DF comprises a
   fixed part based on packet size and a variable part based on the
   various network component switch elements` buffer utilization that
   comprise the switched network infrastructure [i2].

3.2
   Media Loss Rate

   The Media Loss Rate is the count of lost or out of order flow packets
   over a selected time interval, where the flow packets are packets
   carrying streaming application information.  There may be zero or
   more streaming packets in a single IP packet.  For example, it is


Welch, Clark            Expires December 2005                [Page 4]

                           A Proposed Media Delivery Index     June 2005


   common to carry seven 188 Byte MPEG Transport Stream packets in an IP
   packet.  In such a case, a single IP packet loss would result in 7
   lost packets counted for the case where the 7 lost packets did not
   include null packets.  Including out of order packets is important as
   many stream consumer type devices do not attempt to reorder packets
   that are received out of order.

3.3
   Media Delivery Index

   Combining the Delay Factor and Media Loss Rate quantities for
   presentation results in the MDI:

                                  DF:MLR

   Where:

                          DF is the Delay Factor
                        MLR is the Media Loss Rate

   At a receiving node, knowing its nominal drain bit rate, the DF`s max
   indicates the size of required buffer to accommodate packet jitter.
   Or, in terms of Leaky Bucket [i9] parameters, DF indicates bucket
   size b expressed in time to transmit bucket traffic b, at the given
   nominal traffic rate, r.

3.4
   MDI Application Examples

   In the case where a known, well characterized receive node is
   separated from the data source by unknown or less well characterized
   nodes such as intermediate switch nodes, the MDI measured at
   intermediate data links provides a relative indication of the
   behavior of upstream traffic flows.  DF difference indications
   between one node and another in a data stream for a given constant
   interval of calculation can indicate local areas of traffic
   congestion or possibly misconfigured QoS flow specification(s)
   leading to greater filling of measurement point local device buffers,
   resultant flow rate deviations, and possible data loss.

   For a given MDI, if DF is high and/or the DF Max-Min captured over a
   significant measurement period is high, jitter has been detected but
   the longer term, average flow rate may be nominal.  This could be the
   result of a transient flow upset due to a coincident traffic stream
   unrelated to the flow of interest causing packet bunching.  A high DF
   may cause downstream buffer overflow or underflow or unacceptable
   latency even in the absence of lost data.

   Due to transient network failures or DF excursions, packets may be
   lost within the network.  The MLR component of the MDI shows this
   condition.


Welch, Clark            Expires December 2005                [Page 5]

                           A Proposed Media Delivery Index     June 2005



   Through automated or manual flow detection and identification and
   subsequent MDI calculations for real time statistics on a flow, the
   DF can indicate the dynamic deterioration or increasing burstiness of
   a flow which can be used to anticipate a developing network operation
   problem such as transient oversubscription.  Such statistics can be
   obtained for flows within network switches using available switch cpu
   resources due to the minimal computational requirements needed for
   small numbers of flows.  Statistics for all flows present on, say, a
   gigabit Ethernet network, will likely require dedicated hardware
   facilities though these can be modest as buffer requirements and the
   required calculations per flow are minimal.  By equipping network
   switches with MDI measurements, flow impairment issues can quickly be
   identified, localized, and corrected.  Until switches are so equipped
   with appropriate hardware resources, dedicated hardware tools can
   provide supplemental switch statistics by gaining access to switch
   flows via mirror ports, link taps, or the like as a transition
   strategy.

   The MDI figure can also be used to characterize a flow decoder's
   acceptable performance.  For example, an MPEG decoder could be
   characterized as tolerating a flow with a given maximum DF and MLR
   for acceptable display performance (acceptable on-screen artifacts).
   Network conditions such as Interior Gateway Protocol (IGP)
   reconvergence might also be included in the flow tolerance resulting
   in a higher quality user experience.

4.
  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [i10].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [n11], STD 58, RFC 2579 [n12] and STD 58, RFC 2580 [n13].

4.1
   MIB Overview

   This MIB provides a set of objects required for the export of MDI
   metrics of IP streaming media streams.

4.2
   MIB Definitions

   --


Welch, Clark            Expires December 2005                [Page 6]

                           A Proposed Media Delivery Index     June 2005


   -- Media Stream Monitor MIB
   --

   MEDIA-MONITOR-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY,
       OBJECT-TYPE,
       Integer32,
       Unsigned32,
       mib-2,
       NOTIFICATION-TYPE,
       OBJECT-IDENTITY,
       IpAddress
           FROM SNMPv2-SMI                  -- RFC2578
       DisplayString
           FROM SNMPv2-TC
       MODULE-COMPLIANCE, OBJECT-GROUP,
       NOTIFICATION-GROUP
           FROM SNMPv2-CONF;                -- RFC2580

   mediaMonitorMIB MODULE-IDENTITY
       LAST-UPDATED "200404040000Z"         -- 04 April 2004

       ORGANIZATION " xx "
       CONTACT-INFO
         "IneoQuest Technologies, Inc.
              Postal: 170 Forbes Boulevard
                      Mansfield, MA, 02048
              Tel:    +1 508 618 0312
              E-mail: jim.welch@ineoquest.com"

       DESCRIPTION
           "The media Monitor MIB (MEDIA-MONITOR-MIB) provides
           Metrics for Monitoring IP streaming media Flows."

        --  Revision history

        REVISION     "200404040000Z"         -- 04 April 2004
        DESCRIPTION
            "Initial version, published as RFC xxxx. (this RFC)"

       ::= { xxxx }

    -- Top level structure of the MIB

     mediaMonitorObjects    OBJECT IDENTIFIER ::= { mediaMonitorMIB 1 }

   ipMediaStreamMonitorTable OBJECT-TYPE


Welch, Clark            Expires December 2005                [Page 7]

                           A Proposed Media Delivery Index     June 2005


       SYNTAX      SEQUENCE OF IpMediaStreamMonitorEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "IP Stream Monitor Table. This table is indexed by the
           Stream Handle. This Table only shows the currently ACTIVE
           Streams."
       ::= { mediaMonitorObjects 1 }

   ipMediaStreamMonitorEntry OBJECT-TYPE
       SYNTAX IpMediaStreamMonitorEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
            "IP Stream Monitor Table Entry."
       INDEX  { ipMediaStreamMonitorHandle }
       ::= { ipMediaStreamMonitorTable 1 }

   IpMediaStreamMonitorEntry ::= SEQUENCE {
       ipMediaStreamHandle
           Unsigned32,
       ipMediaStreamSourceIpAddress
           IpAddress,
       ipMediaStreamSourcePort
           Unsigned32,
       ipMediaStreamDestinationIpAddress
           IpAddress,
       ipMediaStreamDestinationPort
           Unsigned32,
       ipMediaStreamBitRate
           Unsigned32,
       ipMediaStreamInterval
           Unsigned32,
       ipMediaStreamStartTime
           DisplayString,
        ipMediaStreamMDIDelayFactor
           Unsigned32,
       ipMediaStreamMDILossRate
           Unsigned32,
       ipMediaStreamMDIDFThreshold
           Unsigned32,
       ipMediaStreamMDILRThreshold
           Unsigned32,
       ipMediaStreamMDIDFErrorIntervals
           Unsigned32
       ipMediaStreamMonitorMDIMLRErrorIntervals
           Unsigned32
           }



Welch, Clark            Expires December 2005                [Page 8]

                           A Proposed Media Delivery Index     June 2005


   ipMediaStreamHandle OBJECT-TYPE
       SYNTAX  Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
            "Table is indexed by stream Handle. The table has one row
            for each Media Stream detected from the Ip Interface.  The
            Stream Handle shall be a unique value for the life of the
            stream."
       ::= { ipMediaStreamMonitorEntry 1 }

   ipMediaStreamSourceIpAddress OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "Source IpAddress for the Stream indexed by the Stream
              Handle."
       ::= { ipMediaStreamMonitorEntry 2 }

   ipMediaStreamSourcePort OBJECT-TYPE
       SYNTAX   Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The Source port for the Stream indexed by the Stream
              Handle."
       ::= { ipMediaStreamMonitorEntry 3 }

   ipMediaStreamDestinationIpAddress OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "Destination IpAddress for the Stream indexed by the
              Stream Handle."
       ::= { ipMediaStreamMonitorEntry 4 }

   ipMediaStreamDestinationPort OBJECT-TYPE
       SYNTAX    Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The Destination port for the Stream indexed by the
              Stream Handle."
       ::= { ipMediaStreamMonitorEntry 5 }

   ipMediaStreamBitRate OBJECT-TYPE
       SYNTAX   Unsigned32


Welch, Clark            Expires December 2005                [Page 9]

                           A Proposed Media Delivery Index     June 2005


       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The nominal Bit Rate of the Media Stream in bits/second."
       ::= { ipMediaStreamMonitorEntry 6 }

   ipMediaStreamInterval OBJECT-TYPE
       SYNTAX   Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The number indicates the minimum Interval in seconds for
              a good MDI Measurement. The Interval is based on the
              current Bit Rate of the Stream.  The minimum interval
              should be chosen such that at least 10 IP packets occur
              per interval.  This value defaults to 1 second and the
              Interval is typically configured to 1 second unless the
              above criteria is not met."
       ::= { ipMediaStreamMonitorEntry 7 }

   ipMediaStreamStartTime OBJECT-TYPE
       SYNTAX     DisplayString
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The Timestamp shows the Real time at which the stream was
              detected.  The Timestamp format is YYYY/MM/DD/HH/MM/SS."
       ::= { ipMediaStreamMonitorEntry 8 }

   ipMediaStreamMDIDelayFactor OBJECT-TYPE
       SYNTAX  Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "This object displays the Media Delivery Index Delay
              Factor parameter in units of milliseconds.  This parameter
              indicates the burstiness of the stream."
       ::= { ipMediaStreamMonitorEntry 9 }

   ipMediaStreamMDILossRate OBJECT-TYPE
       SYNTAX Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "This object displays the Media Delivery Index Media Loss
              Rate in packets/sec. This parameter indicates rate of
              lost media packets of the of the  stream."
       ::= { ipMediaStreamMonitorEntry 10 }



Welch, Clark            Expires December 2005               [Page 10]

                           A Proposed Media Delivery Index     June 2005


   ipMediaStreamMDIDFThreshold OBJECT-TYPE
       SYNTAX  Unsigned32
       MAX-ACCESS  read-write
       STATUS current
       DESCRIPTION
              "The Threshold for Media Delivery Index Delay Factor in
              milliSeconds.  The default value is set to 0 indicating
              that it is invalid until configured."
       ::= { ipMediaStreamMonitorEntry 11 }

   ipMediaStreamMDILRThreshold OBJECT-TYPE
       SYNTAX  Unsigned32
       MAX-ACCESS  read-write
       STATUS current
       DESCRIPTION
              "The Threshold for Media Delivery Loss Rate
              in Packets/second. The default value is set to 0xffffffff
              indicating that it is invalid until configured."
       ::= { ipMediaStreamMonitorEntry 12 }

   ipMediaStreamMDIDFErrorIntervals OBJECT-TYPE
       SYNTAX   Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The number indicates the number of MDI DF Threshold
              (ipMediaStreamMonitorMDIDFThreshold) Crossed Intervals
              during the life of a stream. This shall be 0 and invalid
              until the MDI DF Thresholds are configured."
       ::= { ipMediaStreamMonitorEntry 13 }

   ipMediaStreamMDIMLRErrorIntervals OBJECT-TYPE
       SYNTAX   Unsigned32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The number indicates the number of MDI MLR Threshold
              (ipMediaStreamMDILRThreshold)Crossed Intervals
              during the life of a stream. This shall be 0 and invalid
              until the MDI MLR Thresholds are configured."
       ::= { ipMediaStreamMonitorEntry 14 }

   END



5.
  Summary




Welch, Clark            Expires December 2005               [Page 11]

                           A Proposed Media Delivery Index     June 2005


   The MDI combines the Delay Factor which indicates potential for
   impending data loss and Media Loss Rate as the indicator of lost
   data.  By monitoring the DF and MLR and their min and max excursions
   over a measurement period and at multiple strategic locations in a
   network, traffic congestion or device impairments may be detected and
   isolated for a network carrying streaming media content.  The
   included MIB provides a set of objects required for the export of MDI
   metrics of IP streaming media streams.


6.
  Security Considerations


   The measurements identified in this document do not directly affect
   the security of a network or user.  Actions taken in response to
   these measurements which may affect the available bandwidth of the
   network or availability of a service is out of scope for this
   document.
   Performing the measurements described in this document only requires
   examination of payload header information such as MPEG transport
   stream headers or RTP headers to determine nominal stream bit rate
   and sequence number information.  Content may be encrypted without
   affecting these measurements.  Therefore, content privacy is not
   expected to be a concern.



7.
  Normative References

   n1. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M.
      and S. Waldbusser, 'Structure of Management Information Version 2
      (SMIv2)', STD 58, RFC 2578, April 1999.
   n2. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M.
      and S. Waldbusser, 'Textual Conventions for SMIv2', STD 58, RFC
      2579, April 1999.
   n3. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M.
      and S. Waldbusser, 'Conformance Statements for SMIv2', STD 58, RFC
      2580, April 1999.

8.
  Informative References

   i1. R. Braden et al., `Resource Reservation Protocol ` Version 1
      Functional Specification`, RFC 2205, 1997.
   i2. C. Partridge, `A Proposed Flow Specification`, RFC 1363, 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.



Welch, Clark            Expires December 2005               [Page 12]

                           A Proposed Media Delivery Index     June 2005


   i5. S. Shenker, C. Partridge, R. Guerin, `Specification of Guaranteed
      Quality of Service`, RFC 2212, 1997.
   i6. J. Wroclawski, `Specification of the Controlled-Load Network
      Element Service`, RFC 2211, 1997.
   i7. R. Braden, D. Clark, S. Shenker, `Integrated Services in the
      Internet Architecture: an Overview` RFC 1633, 1994.
   i8. ISO/IEC 13818-1 (MPEG-2 Systems)
   i9. V. Raisanen, `Implementing Service Quality in IP Networks`, John
      Wiley & Sons Ltd., 2003.
   i10. J. Case, R. Mundy, D. Partain, B. Stewart, 'Introduction and
      Applicability Statements for Internet Standard Management
      Framework', RFC 3410, 2002.

9.
  Acknowledgments

   The authors gratefully acknowledge the contributions of Marc Todd and
   Jesse Beeson of IneoQuest Technologies, Inc., Bill Trubey and John
   Carlucci of Time Warner Cable, Nishith Sinha of Cox Communications,
   Ken Chiquoine of SeaChange International, Phil Proulx of Bell Canada,
   Dr Paul Stallard of TANDBERG Television, Gary Hughes of Broadbus
   Technologies, Brad Medford of SBC Laboratories, John Roy of Adelphia
   Communications, Cliff Mercer, PhD of Kasenna, Mathew Ho of Rogers
   Cable, and Irl Duling of Optinel Systems for reviewing and evaluating
   early drafts of this document and implementations for MDI.

10.
   Authors' Address

   James Welch
   IneoQuest Technologies, Inc
   170 Forbes Blvd
   Mansfield, Massachusetts 02048
   508 618 0312
   Jim.Welch@ineoquest.com

   James Clark
   Cisco Systems, Inc
   500 Northridge Road
   Suite 800
   Atlanta, Georgia 30350
   678 352 2726
   jiclark@cisco.com

11.
   Copyright Notice

   Copyright (C) The Internet Society (2005).  This document is subject to
   the rights, licenses and restrictions contained in BCP 78, and except
   as set forth therein, the authors retain all their rights.




Welch, Clark            Expires December 2005               [Page 13]

                           A Proposed Media Delivery Index     June 2005


12.
   Disclaimer

   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.'

13.
   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 ISOC's procedures with respect to rights in ISOC 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.


TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
     Changes from draft-welch-mdi-01.txt:

     *removed references to application to more generic ôUDP-based
   applicationsö to keep focus on ôstreaming mediaö
     *removed capitalization for term ôstreaming mediaö throughout
       document
     *removed redundant phrase ôstream flowö
     *removed capitalized MUST and MAY and references to RFC 2119
     *added explanation of applicability to variable bit rate streams in
       the Introduction





Welch, Clark            Expires December 2005               [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/