[dispatch] 转发: Proposal for revising RFC4445 or make RFC4445bis

Qin Wu <bill.wu@huawei.com> Mon, 17 July 2017 08:34 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50B131A95 for <dispatch@ietfa.amsl.com>; Mon, 17 Jul 2017 01:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW26wKpIhkVg for <dispatch@ietfa.amsl.com>; Mon, 17 Jul 2017 01:34:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6183A131AD7 for <dispatch@ietf.org>; Mon, 17 Jul 2017 01:33:44 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR14414; Mon, 17 Jul 2017 08:33:42 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 09:33:41 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 17 Jul 2017 16:33:36 +0800
From: Qin Wu <bill.wu@huawei.com>
To: dispatch <dispatch@ietf.org>
CC: "spencerdawkins.ietf" <spencerdawkins.ietf@gmail.com>, "mirja.kuehlewind" <mirja.kuehlewind@tik.ee.ethz.ch>
Thread-Topic: Proposal for revising RFC4445 or make RFC4445bis
Thread-Index: AQHS/tdhLdDueCiyDUiz6oNxczDYFw==
Date: Mon, 17 Jul 2017 08:33:35 +0000
Message-ID: <etPan.596c765e.327b23c6.421@Qin-Wude-iPhone>
References: <B8F9A780D330094D99AF023C5877DABA9A9FE9CE@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9A9FE9CE@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan596c765e327b23c6421QinWudeiPhone_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.596C7666.0116, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8a77f289d58fc32c19ed28b34e71a6b4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/TE9w9CaFiNRiFb13gQO3YbzqmT0>
Subject: [dispatch] 转发: Proposal for revising RFC4445 or make RFC4445bis
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 08:34:07 -0000

Cross posting, since the following proposal is also art related, want to solicit feedback from art area as well. Thanks Dan for good suggestion.

Sent from HUAWEI AnyOffice
发件人: Qin Wu
收件人: tsv-area@ietf.org;
抄送: 郑辉;
主题: Proposal for revising RFC4445 or make RFC4445bis
时间: 2017-07-17 07:39:46



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