Re: Proposal for revising RFC4445 or make RFC4445bis

[Ali C. Begen]

Well, with most streams becoming encrypted, in-network monitoring have to
be mostly heuristics based. Whether that is something to be specified, this
list can discuss it I think.

On Mon, Jul 17, 2017 at 8: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.
>
>
> > 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 de

Re: Proposal for revising RFC4445 or make RFC4445bis

[Ali C. Begen]

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 mil

Re: 答复: Proposal for revising RFC4445 or make RFC4445bis

[Ali C. Begen]

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

Re: Proposal for revising RFC4445 or make RFC4445bis

[Ali C. Begen]

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