Re: [xrblock] Spencer Dawkins' No Objection on draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09: (with COMMENT)

"Huangyihong (Rachel)" <> Wed, 23 May 2018 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BAF21200E5; Tue, 22 May 2018 18:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MmOfyLsvpMTQ; Tue, 22 May 2018 18:11:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C4231200F1; Tue, 22 May 2018 18:11:08 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 4D01D93B53778; Wed, 23 May 2018 02:11:04 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 23 May 2018 02:11:05 +0100
Received: from ([]) by ([]) with mapi id 14.03.0382.000; Wed, 23 May 2018 09:11:01 +0800
From: "Huangyihong (Rachel)" <>
To: Spencer Dawkins at IETF <>
CC: IESG <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09: (with COMMENT)
Thread-Index: AQHT8TiN/kF/2KF0CECr36LMlfC3paQ7BbmwgABZaACAASHpAA==
Date: Wed, 23 May 2018 01:11:00 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C6FD7E3nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [xrblock] Spencer Dawkins' No Objection on draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2018 01:11:12 -0000

Hi Spencer,

I’ll add more specifications like burst loss gap/discard [RFC6958] [RFC7008]. Thanks again for raising the issue. I fully understand your concern.


From: Spencer Dawkins at IETF []
Sent: Tuesday, May 22, 2018 11:45 PM
To: Huangyihong (Rachel)
Cc: IESG;;;;
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09: (with COMMENT)

Hi, Rachel,

On Mon, May 21, 2018 at 9:59 PM Huangyihong (Rachel) <<>> wrote:
Hi Spencer,

Thanks for your comments. Please see inline.


> -----Original Message-----
> From: Spencer Dawkins [<>]
> Sent: Tuesday, May 22, 2018 3:19 AM
> To: The IESG
> Cc:<>; Shida Schubert;
> Subject: Spencer Dawkins' No Objection on
> draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09: (with COMMENT)
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for producing this document.
> I did have one comment (and I apologize in advance that this is a particular
> hot button for me).
> I understand that you can do things with these metrics that you can't do with
> previous metrics, but I wish there was a clearer description of "if you want to
> understand X, you should implement this metric" earlier in the document. The
> impression the reader is left with, is "if you're doing RTCWeb, you should
> implement this metric", but I'm guessing that at least some of these metrics
> would be useful for people who weren't doing RTCWeb, but need to measure
> something that people who are doing RTCWeb also need to measure, and if
> that's
> true, a short section that helped them figure that out would be helpful.

[Rachel]: Would it be helpful if we add a new short paragraph in the section 1, after the 3rd para and before the last one, as following

Standards such as "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611] as well as other extensions standardized in the XRBLOCK working group have been produced for the purpose of collecting and reporting performance metrics from RTP endpoint devices that can be used to have a end-to-end service visibility and measure the delivering quality in various RTP services. These metrics are able to complement those in [RFC3550].

This is exactly the kind of thing that I was hoping for.

If you can provide more specifics, that would probably be more helpful for people who are doing RTP but not as part of RTCWeb, but the text you suggested is already an improvement.

(I've spent a lot of time since 1996 in conversations about "it's this way because it's wireless". Actually, "it's this way because of a high error rate, or highly variable RTTs, or about a million other side effects of being wireless, that can also happen when you're not using a wireless connection but still encounter those characteristics". That's why just pointing to a use case drives me nuts! Thanks for working through that with me)