I am really curious about who is using MDI anymore. Can you share data if you have it? RTCP XR is still extensively used and for non-RTP, it is a mixed of several things.
-acbegen On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu <[email protected]> wrote: > Hi, All: > > We like to get a sense of this idea, more than 10 years ago, at the time > of RFC4445 writing, > > The popularity of delivery of streaming media over packet swtiched network > has just began, > > not all implementations support QoS methods to improve media delivery. > Many service > > delivery systems may compose the network with QoS support or without QoS > support. This add difficulty on characterizing dynamic behavior of the > network. > > > > 10 years have passed, we see most of widely deployed implementions have > adopted various different QoS mechanisms > > such as diffserv Intserv, Traffic Engineering, providing QoS guarantee to > improve delivery of media streaming, > > especially for time senestive or loss senstive application become a must; > Therefore we see a lot of value of MDI defined in RFC4445 since it provide > s a handy diagnostic tool for operators and service providers to measure > the peformance of the network carrying streaming media and quickly identify > fault in the network. > > > > Today we also see many service providers begain to offer on demand > streaming media service, many operator deployed CDN in the last mile to > provide better SLA, or provide hybrid TV service, in addition more and more > real time application not limited to IPTV application, VOIP application > have been developed,network monitoring and network troubleshooting began > more and more complicated and costy. We hear a lot of operators get hurted > and want to have a common tool to help them to measure performance in this > kind of networks and provider better troubleshooting. > > > > Another observation is today more and more implementations have adopted > packet loss repair methods to improve media delivery. > > However MDI defined in RFC4445 doesn't take into acount of various > different packet loss repair mechanims, in addition, RFC4445 is only > designed for monitoring MPEG Transport Stream (TS) packets over UDP and > fall short to addressing needs in hybrid senarios or on demand streaming > media scenarios. > > > > In addition, we see at the time of RFC4445 publication, IESG doesn't > recommend this standard, mostly becos RFC4445 doesn't define complete > Metric and clarify the relationship with existing IETF work such as RFC3611 > and RFC3933, I am wondering if it is a good idea to revise RFC4445 to > address IESG concern today and in addition fill new needs in today's > service deployment. > > Comments and suggestions? > > > > -Qin >
