Re: [ippm] Proposal for revising RFC4445 or make RFC4445bis

"Zhenghui (Marvin)" <marvin.zhenghui@huawei.com> Tue, 18 July 2017 21:20 UTC

From: "Zhenghui (Marvin)" <marvin.zhenghui@huawei.com>
To: "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: Proposal for revising RFC4445 or make RFC4445bis
Thread-Index: AdMACrQrzrwDTvh5RXiS40/LqRgxyQ==
Date: Tue, 18 Jul 2017 21:20:38 +0000
Message-ID: <F8F4995E43962F4996B280E9678CED0001F53042@dggemi509-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_F8F4995E43962F4996B280E9678CED0001F53042dggemi509mbschi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/At46v67EW_CiXbM8I_ZdQQgb_1s>
Subject: Re: [ippm] Proposal for revising RFC4445 or make RFC4445bis
Precedence: list

Repost to IPPM since it may be the right place to discuss metrics.

We have two individual drafts for this:
https://datatracker.ietf.org/doc/draft-zheng-emdi-udp/
https://datatracker.ietf.org/doc/draft-ding-tcp-emdi/
(one for UDP, another for TCP, there is slight inconsistency in the draft naming patterns though)

发件人: Qin Wu
发送时间: 2017年7月17日 13:39
收件人: tsv-area@ietf.org
抄送: Zhenghui (Marvin) <marvin.zhenghui@huawei.com>
主题: Proposal for revising RFC4445 or make RFC4445bis


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: [ippm] Proposal for revising RFC4445 or make … Zhenghui (Marvin)