... On Mon, Jul 17, 2017 at 2:54 PM, Mirja Kühlewind < mirja.kuehlew...@tik.ee.ethz.ch> wrote:
> I believe the problem that is addressed with this proposals is actually > assessing streaming quality from the outside/network if you don’t have > access to do the measurement on the endpoint in the app. Not saying that we > need or should do this work but that’s why this might be relevant to > transport as well as apps. > ... and thanks to you all, for the feedback :-) Spencer > > > > Am 17.07.2017 um 14:50 schrieb Ali C. Begen <ali.begen@networked.media>: > > > > > > > > On Mon, Jul 17, 2017 at 8:43 PM, Mirja Kühlewind < > mirja.kuehlew...@tik.ee.ethz.ch> wrote: > > 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. > > > > I know this is an area list, my comment was not specific to any wg. > Streaming with TCP has a lot more to do at the app layer (actually in the > application itself) rather than the transport layer. So, this topic does > not belong in here at all IMO. > > > > -acbegen > > > > > > > > > Am 17.07.2017 um 14:16 schrieb Ali C. Begen <ali.begen@networked.media > >: > > > > > > 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) < > rachel.hu...@huawei.com> 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:tsv-area-boun...@ietf.org] 代表 Ali C. Begen > > > 发送时间: 2017年7月17日 19:31 > > > 收件人: Qin Wu <bill...@huawei.com> > > > 抄送: tsv-area@ietf.org > > > 主题: 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 <bill...@huawei.com> 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; > > > > > > 抄送： tsv-area@ietf.org; 郑辉; > > > > > > 主题： 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 <bill...@huawei.com> 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 > > > > > > > > > > > > > > > > > > > > > > > >
