This is the area list, not a wg; we are not working on any document. The purpose of announcing this work here is to figure if there is any interested in this work and if so where it should be done.
> Am 17.07.2017 um 14:16 schrieb Ali C. Begen <[email protected]>: > > Well, I believe you wanna come up with some metrics for streaming video over > http and want to extend MDI for that. Well, MDI was not designed for that at > all, so extending it in that direction is not a good idea. Further, there is > already tons of work other organizations have done to collect metrics for > streaming over HTTP. Just look at what others did already, mpeg, dash-if, SVA > and now almost all the existing work is being collected and becoming a single > common spec out of CTA. I honestly don't think this WG should work on this > given the amount of existing and ongoing work. > > -acbegen > > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) > <[email protected]> wrote: > Hi Ali, > > > > That’s one part that MDI could not do, and we hope some new metrics could be > used, which is the intention of this work. > > > > As for the RTCP XR metrics, it’s not quite realistic in middle devices like > routers, to implement them, e.g., post-repair metrics, which will need the > devices to have the ability to decode and apply FEC repair mechanisms. So > that’s why we need some ways like MDI, easy to calculate and be implemented > in the network without having to be a RTP entity or TCP proxy. > > > > BR, > > Rachel > > > > 发件人: tsv-area [mailto:[email protected]] 代表 Ali C. Begen > 发送时间: 2017年7月17日 19:31 > 收件人: Qin Wu <[email protected]> > 抄送: [email protected] > 主题: Re: 答复: Proposal for revising RFC4445 or make RFC4445bis > > > > You wanna use MDI to measure media delivery over TCP? > > > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu <[email protected]> wrote: > > We have customers using MDI to address new needs, such as wifi performance > measurement MDI falls short when measuring delivery of streaming media over > tcp, that is why we think it should be extended. Yes, rtcp XR has its value. > But I think they could be complimentary. > > Sent from HUAWEI AnyOffice > > 发件人： Ali C. Begen > > 收件人： Qin Wu; > > 抄送： [email protected]; 郑辉; > > 主题： Re: Proposal for revising RFC4445 or make RFC4445bis > > 时间： 2017-07-17 13:02:07 > > > > 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 > > > > > >
