Subject: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

From: Qin Wu <[email-masked]>
Date: Tue, 14 May 2013 02:20:23 +0000

Hi,
We have a minor update to QoE draft which incorporates the similar changes that are applied to burst gap related drafts.
Also we add a new appendix to apply RFC6390 template.
One comment was raised in the Last IETF meeting is about suggestion on soliciting review from SDP Directorate review for SDP part.
We think the current version is ready to go for such review and WGLC.

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, May 14, 2013 10:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Metric Blocks for use with RTCP's Extended Report Framework Working Group of the IETF.

	Title           : RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric Reporting
	Author(s)       : Alan Clark
                          Qin Wu
                          Roland Schott
                          Glen Zorn
	Filename        : draft-ietf-xrblock-rtcp-xr-qoe-07.txt
	Pages           : 22
	Date            : 2013-05-13

Abstract:
   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) Block including two new segment types and associated SDP
   parameters that allow the reporting of QoE metrics for use in a range
   of RTP applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-qoe-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-qoe-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 May 2013 13:58:04 +0100

Qin,

While I think this is in good shape, I do still have some comments on this version:

The ABNF in Section 4.1 defines mediatype and mosreference rules. It’s not clear that these are needed: can’t the media types and resolution be inferred from the payload type? If they are needed, I think their purpose needs to be clearer, and the draft needs to better explain how they interact with SDP O/A, especially in terms of failure modes. 

The ABNF defines video and multimedia mediatypes, but this draft only defines audio metric report blocks. 

The ABNF and the table of registrations in the IANA considerations include P1201_01, P1201_02, P1202_01, and P1202_02 algorithms, which only work for multimedia or video, but this draft only defines audio metric report blocks.

The policies for the new registry of calculation algorithms in Section 5.4 state that the information require should include “how values of the metric are reported in the one 16-bit fields or 13-bit fields”, but the registration template and initial assignments do not do so. 

Regards,
Colin

On 14 May 2013, at 03:20, Qin Wu wrote:
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 May 2013 17:16:53 +0100

Qin pointed out to me off-list that I've misread the draft, and that the single stream per SSRC segment can apply to audio and video, so my second and third points are not valid. Apologies for the noise, however I would suggest that section 3.2.1 be re-titled "Single Stream Audio/Video per SSRC Segment" to stop others making the same mistake.

My first and fourth comments are unaffected.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 May 2013 02:26:21 +0000

Hi, Colin:
Thank for your valuable review, please see my reply inline below.

Regards!
-Qin

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, May 16, 2013 8:58 PM
To: Qin Wu
Cc: 'xrblock'; 'xrblock-chairs'
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

Qin,

The ABNF in Section 4.1 defines mediatype and mosreference rules. It's not clear that these are needed: can't the media types and resolution be inferred from the payload type? If they are needed, I think their purpose needs to be clearer, and the draft needs to better explain how they interact with SDP O/A, especially in terms of failure modes. 

[Qin]: I agree mediatype can be inferred from payload type. Ad for mosrefereence, for audio application, I agree  whether it is narrowband or wideband, this can also be inferred from payload type since payload type will indicate whether it is narrowband or wideband.
For video, it seems payload type doesn't distinguish standard definition video codec and high definition video codec.
Anyway I am okay to remove mediatype and mosreference.
The question is shall we need to remove media type in the registry when we decide remove media type from SDP format?

[Qin]:That's not true. The single stream per segment will be used for video and multimedia media types. Multimedia media type means it can be either audio media type or video media type or audiovisual media type, e.g., P.1201.

[Qin]: See above.

The policies for the new registry of calculation algorithms in Section 5.4 state that the information require should include "how values of the metric are reported in the one 16-bit fields or 13-bit fields", but the registration template and initial assignments do not do so. 

[Qin]:I am not sure how this sentence " how values of the metric are reported in the one 16-bit fields or 13-bit fields " affects registration template and initial assignment since this sentence really means how we format "MOS value" in 16 bits or 13 bits. The details of definition of "MOS value" field
Has been specified in the section 3.2.1 for 16-bit "MOS value" and in the section 3.2.2 for 13-bit "MoS value". What am I missing?

Regards,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 May 2013 02:27:32 +0000

Hi, Colin:
Thank for your correction. I agree with your rewording for the title of section 3.2.1.

Regards!
-Qin
-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Friday, May 17, 2013 12:17 AM
To: Qin Wu
Cc: xrblock-chairs; xrblock
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 May 2013 11:45:45 +0100

> For video, it seems payload type doesn't distinguish standard definition video codec and high definition video codec.

If you can't tell what video QoE metric to use from the payload format and it's parameters, then you might need to keep the parameter. I was assuming that the information needed was available.

> The question is shall we need to remove media type in the registry when we decide remove media type from SDP format?

I don't understand your question. Can you clarify?

> Has been specified in the section 3.2.1 for 16-bit "MOS value" and in the section 3.2.2 for 13-bit "MoS value". What am I missing?

If you need to specify something different about how the metric values are reported for each metric then the IANA registration template needs to specify what information is needed. If not, then you should remove that sentence from Section 5.4, since it implies that additional information is needed. 

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 May 2013 11:03:22 +0000

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Monday, May 20, 2013 6:46 PM
To: Qin Wu
Cc: 'xrblock'; 'xrblock-chairs'
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

[Qin]: Yes, I see.

[Qin]: Sorry for bringing you confusion. What I am saying is 
In the registration template we defined in the section 5.4,"type" field is defined to indicate which media type the calculation algorithm is applied to.
I am wondering if you we agree to remove syntax element "mediatype" in the SDP, shall we remove "type" in the registration template as well?

[Qin]: Agree, thank for your clarification.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 May 2013 12:07:08 +0100

> I am wondering if you we agree to remove syntax element "mediatype" in the SDP, shall we remove "type" in the registration template as well?

I wouldn't think so, since that defines what media types it applies to.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 20 May 2013 11:24:07 +0000

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Monday, May 20, 2013 7:07 PM
To: Qin Wu
Cc: 'xrblock'; 'xrblock-chairs'
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

[Qin]:Agree, thank for your clarification.

Colin

-- 
Colin Perkins
http://csperkins.org/