From dromasca@avaya.com Wed Feb 5 02:31:36 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0EE1A00C5 for ; Wed, 5 Feb 2014 02:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham 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 klR3RwICTmTZ for ; Wed, 5 Feb 2014 02:31:34 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id CF4E51A00C6 for ; Wed, 5 Feb 2014 02:31:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAKYS8lLGmAcV/2dsb2JhbABZgkgjIThXqEKWAYELFnSCJwEBAxILEF4BDAkVViYBBBsah2MBDJ4YhFKrehMEjkQtgjoPZoEUBJ8bizGDLYIq X-IronPort-AV: E=Sophos;i="4.95,786,1384318800"; d="scan'208,217";a="48062035" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Feb 2014 05:31:29 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 05 Feb 2014 05:20:34 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 5 Feb 2014 05:31:28 -0500 From: "Romascanu, Dan (Dan)" To: "xrblock@ietf.org" Thread-Topic: xrblock wg meeting at ietf-89 - call for agenda items Thread-Index: Ac8iXW1aBZA+8gI6Qd2ZNYtcJyVg2Q== Date: Wed, 5 Feb 2014 10:31:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E3EC7A1@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7A1AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [xrblock] xrblock wg meeting at ietf-89 - call for agenda items X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 10:31:36 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7A1AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda at https://datatracker.ietf.org/meeting/89/agenda.tx= t shows the WG meeting scheduled for Wednesday 3/5 in the 1520 -1620 meetin= g slot. Note that this scheduling is subject to change. If you plan to present and discuss your work at the meeting please send us = your agenda request including the topic, name of the relevant I-D or I-Ds a= nd the estimated time. Items which are part of the WG charter have higher p= riority, non-chartered items will be included if time allows. Thanks and Regards, Shida and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7A1AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda at https://datatracker.ietf.org/meeting/89/agenda.txt shows the WG meeting= scheduled for Wednesday 3/5 in the 1520 -1620 meeting slot. Note that this= scheduling is subject to change.

 

If you plan to present and discuss your work at the = meeting please send us your agenda request including the topic, name of the= relevant I-D or I-Ds and the estimated time. Items which are part of the W= G charter have higher priority, non-chartered items will be included if time allows.

 

Thanks and Regards,

 

Shida and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E3EC7A1AZFFEXMB04globa_-- From internet-drafts@ietf.org Sat Feb 8 00:56:33 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2301ADF43; Sat, 8 Feb 2014 00:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Fxzp5dfTKWj3; Sat, 8 Feb 2014 00:56:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 967281ADF23; Sat, 8 Feb 2014 00:56:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140208085631.17351.26487.idtracker@ietfa.amsl.com> Date: Sat, 08 Feb 2014 00:56:31 -0800 Cc: xrblock@ietf.org Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-synchronization-08.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 08 Feb 2014 08:56:33 -0000 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 Synchronization Delay and Offset Metrics Reporting Authors : Hitoshi Asaeda Qin Wu Rachel Huang Filename : draft-ietf-xrblock-rtcp-xr-synchronization-08.txt Pages : 15 Date : 2014-02-08 Abstract: This document defines two RTP Control Protocol (RTCP) Extended Report (XR) Blocks that allow the reporting of synchronization delay and offset 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-synchronization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-synchronization-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-synchronization-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Sun Feb 9 20:59:40 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5B51A07AA for ; Sun, 9 Feb 2014 20:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 juDrAkONcwcu for ; Sun, 9 Feb 2014 20:59:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAAD1A0237 for ; Sun, 9 Feb 2014 20:59:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY42496; Mon, 10 Feb 2014 04:59:34 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 04:58:24 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 04:59:32 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 12:59:26 +0800 From: Qin Wu To: "xrblock@ietf.org" Thread-Topic: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: Ac8mHMohgTqbV6RzRzOEe/CvyioJpwAAAXlA Date: Mon, 10 Feb 2014 04:59:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7B965nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [xrblock] FW: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 04:59:40 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7B965nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI. From: Qin Wu Sent: Monday, February 10, 2014 12:59 PM To: pm-dir@ietf.org; Varun Singh; Huangyihong (Rachel) Cc: 'MORTON, ALFRED C (AL)'; 'Benoit Claise' Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-= repair-loss-count Hi, Authors: I am the assigned PM-DIR reviewer for this draft. Here is my review to this draft based on RFC6390 PM template. This draft defines two new metrics in the same metric block and has alread= y applied RFC6390 template to these two metrics, However I do have some comments below regarding metri= cs definition. 1. Appendix A, Part a, Bullet 3 says: " * Method of Measurement or Calculation: It must be measured in the source stream. It must be measured for the packets that have no further chance of being repaired. " The first sentence is a little bit confusing, are you saying the measuremen= t is applied to source stream, I think you can reference to section 3, the defin= ition "SSRC of source" for that. The second sentence seems also repeat what the definition of "unrepaired lo= ss count", you can simply reference that definition. 2. Appendix A, Part a, Bullet 5 says: " Measurement Point(s) with Potential Measurement Domain: See section 3, 1st paragraph. " Section 3, 1st paragraph doesn't explain where to measure? I suggest you can add the following sentence to the section 3, 1st paragrap= h as follows: " The measurement of these metrics is made at the receiving end of the RTP st= ream " And you then you reference section 3 for measurement points. 3. Appendix A, Part a, Bullet 6 says: " * Measurement Timing: See Section 4 for measurement timing. " Section 4 has no text to explain measurement timing. Since Since this metric doesn't rely on the measurement interval in the Measurement Information Block [RFC6776] indicating the span of the report, I believe you rely on sequence number range to indicate measurement timing, please make it clear in the text. 4. Appendix A, Part b, Bullet 3 My comment on Appendix A, part a Bullet 3 is also applied here. 5. Appendix A, Part b, Bullet 5 My comment on Appendix A, part a Bullet 5 is also applied here. 6. Appendix A, Part b, Bullet 6 My comment on Appendix A, part a Bullet 6 is also applied here. 7. Section 1, paragraph 1 s/measured on media stream/measured on RTP stream 8.Section 1, Paragraph 1 says: " Hence, the sending endpoint cannot assess the performance of the repair mechanism by observing the change in fraction loss and the cumulative loss statistics. " It is better to add a reference for fraction loss and the cumulative loss, = I think It should be RFC 3550 RTCP SR which carries fraction loss statistics. 9. Section 1, Paragraph 1 says: " When applications use multiple XR blocks, the endpoints require more concise reporting to save bandwidth. " I don't think the endpoints MUST have such concise reporting in such case. Therefore I suggest to say the endpoint may require more concise reporting = in such case. 10. Section 1, Paragraph 2 says: " Thus it is RECOMMENDED that this report block should be generated for those source packets that have no further chance of being repaired. But a potential ambiguity may result from sequence number range inconsistent. To address this issue, we use begin sequence number and end sequence number to explicitly indicate the actual sequence number range that the report block reports on. " Whose ambiguity? RFC3550 or RFC5725? Not sure you should highlight using begin seq or end seq since RFC5725 also= use this. You'd better have more text to explain where sequence number inconsistency = come from? 11. Section 1, Paragraph 2 says: " In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre- repair loss count during the this range. Note that the metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of RFC3550. " The definition of repaired loss count here is not consistent with the defin= ition of repaired loss count in section 3? It looks repaired loss count here is referred to the value carried in the S= R while repaired loss count in section is referred to the packet that is repaired after loss repair mechanism is appl= ied. Please fix this to make them consistent. 12. Section 3, Paragraph 1 says: " This block describes the residual number of packets lost after applying repair mechanisms. The report block is complementary to the RTCP XR metrics defined in [RFC5725] as= it uses a non-RLE format. " What Does residual number mean? Suggest to remove residual. It doesn't add any benefit but introduce confusing. 13. Section 3 says: " begin_seq: 16 bits The sequence number of the first packet in the session or the sequence number of the first packet fully repaired that this block reports on. end_seq: 16 bits The sequence number of the last packet fully repaired that this block reports on plus one. " Why not use the same definition as defined in the RFC3611 or RFC5725, why m= ake these definitions so specific? I don't think the begin_seq should only be chosen either as the first packe= t sequence number in the session Or the first packet sequence number that is fully repaired. Why not choose = the sequence number of any packet you received? In some case, you may not lose any packet, then in such case, both unrepair= ed loss count and repaired loss count should be set to zero. Regards! -Qin --_000_B8F9A780D330094D99AF023C5877DABA43C7B965nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI.=

 

From: Qin Wu
Sent: Monday, February 10, 2014 12:59 PM
To: pm-dir@ietf.org; Varun Singh; Huangyihong (Rachel)
Cc: 'MORTON, ALFRED C (AL)'; 'Benoit Claise'
Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-x= r-post-repair-loss-count

 

Hi, Authors:

I am the assigned P= M-DIR reviewer for this draft.

Here is my review t= o this draft based on RFC6390 PM template.

This draft defines = two new metrics  in the same metric block and has already applied RFC6= 390 template

to these two metric= s, However I do have some comments below regarding metrics definition.=

 

1. Appendix A, P= art a, Bullet 3 says:

“<= /span>

* Method of Measure= ment or Calculation: It must be measured in the

  source strea= m. It must be measured for the packets that

  have no furt= her chance of being repaired.

”<= /span>

The first sentence = is a little bit confusing, are you saying the measurement is

applied to source s= tream, I think you can reference to section 3, the definition “SSRC o= f source” for that.

The second sentence= seems also repeat what the definition of “unrepaired loss count̶= 1;,

you can simply refe= rence that definition.

 

2. Appendix A, P= art a, Bullet 5 says:

“<= /span>

Measurement Point(s= ) with Potential Measurement Domain: See

   &= nbsp;  section 3, 1st paragraph.

“<= /span>

Section 3, 1st para= graph doesn’t explain where to measure?

I suggest you can a= dd the following sentence to the section 3, 1st paragraph as follows:<= /o:p>

“<= /span>

The measurement of = these metrics is made at the receiving end of the RTP stream

”<= /span>

And you then you re= ference section 3 for measurement points.

 

3. Appendix A, P= art a, Bullet 6 says:

“<= /span>

* Measurement Timin= g: See Section 4 for measurement timing.

 

”<= /span>

Section 4 has no te= xt to explain measurement timing. Since

Since this metric d= oesn’t rely on the

measurement interva= l in the Measurement Information Block [RFC6776]

indicating the span= of the report, I believe you rely on sequence number

range to indicate m= easurement  timing, please make it clear in the text.

 

4. Appendix A, P= art b, Bullet 3

My comment on Appen= dix A, part a Bullet 3 is also applied here.

 

5. Appendix A, P= art b, Bullet 5

My comment on Appen= dix A, part a Bullet 5 is also applied here.

 

6. Appendix A, P= art b, Bullet 6

My comment on Appen= dix A, part a Bullet 6 is also applied here.

 

7. Section 1, pa= ragraph 1

s/measured on medi= a stream/measured on RTP stream

 

8.Section 1, Par= agraph 1 says:

“<= /span>

Hence, the = sending

endpoint ca= nnot assess the performance of the repair mechanism by

observing t= he change in fraction loss and the cumulative loss

statistics.

”<= /span>

 

It is better to add= a reference for fraction loss and the cumulative loss, I think<= /span>

It should be RFC 35= 50 RTCP SR which carries fraction loss statistics.

 

9. Section 1, Pa= ragraph 1 says:

“<= /span>

When
applications use multiple XR blocks, the endpoints require more
concise reporting to save bandwidth.

&n= bsp;

”<= /span>

I don’t think= the endpoints MUST have such concise reporting in such case.

Therefore I suggest= to say the endpoint may require more concise reporting in such case.<= /o:p>

 

10. Section 1, P= aragraph 2 says:

“<= /span>

Thus it is RECOMMEN= DED that this report

block should be gen= erated for those source packets that have no

further chance of b= eing repaired. But a potential ambiguity may

result from sequenc= e number range inconsistent. To address this

issue, we use begin= sequence number and end sequence number to

explicitly indicate= the actual sequence number range that the report

   block = reports on.

”<= /span>

Whose ambiguity? RF= C3550 or RFC5725?

Not sure you should= highlight using begin seq or end seq since RFC5725 also use this.

You’d better = have more text to explain where sequence number inconsistency come from?

 

11. Section 1, P= aragraph 2 says:

“<= /span>

In addition,  = another metric, repaired loss count,

is also introduced = in this report block for calculating the pre-

repair loss count d= uring the this range. Note that the metrics in

this report block M= UST NOT be directly compared with the pre-repair

loss metric of RFC3550.

“<= /span>

The definition of r= epaired loss count here is not consistent with the definition of repaired l= oss count in section 3?

It looks repaired l= oss count here is referred to the value carried in the SR while repaired lo= ss count in section is

referred to the pac= ket that is repaired after loss repair mechanism is applied. Please fix thi= s to make them consistent.

 

 

12. Section 3, P= aragraph 1 says:

“<= /span>

This block describe= s the residual number of packets lost after

applying repair mec= hanisms. The report block is complementary to the

RTCP XR metrics def= ined in [RFC5725] as it uses a non-RLE format.

”<= /span>

What Does residual = number mean? Suggest to remove residual.

It doesn’t ad= d any benefit but introduce confusing.

 

13. Section 3 sa= ys:

“<= /span>

   begin_seq: 16 bits
 
      The sequence number of the first p=
acket in the session or the
      sequence number of the first packe=
t fully repaired that this block
      reports on.

 


   end_seq: 16 bits


 


      The sequence number of the last pa=
cket fully repaired that this


      block reports on plus one.


&n=
bsp;


”<=
/span>


Why not use th=
e same definition as defined in the RFC3611 or RFC5725, why make these defi=
nitions so specific?


I don’t think=
 the begin_seq should only be chosen either as the first packet sequence nu=
mber in the session


Or the first packet=
 sequence number that is fully repaired. Why not choose the sequence number=
 of any packet you received?


In some case, you m=
ay not lose any packet, then in such case, both unrepaired loss count =
 and  repaired loss count should be set to zero.


 


 


Regards!


-Qin
--_000_B8F9A780D330094D99AF023C5877DABA43C7B965nkgeml501mbschi_-- From rachel.huang@huawei.com Mon Feb 10 01:58:05 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE81A07E4; Mon, 10 Feb 2014 01:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 4-HfvOm8xX6O; Mon, 10 Feb 2014 01:58:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BC09F1A07E2; Mon, 10 Feb 2014 01:57:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY69644; Mon, 10 Feb 2014 09:57:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 09:56:55 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 09:57:46 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 17:57:35 +0800 From: "Huangyihong (Rachel)" To: Qin Wu , "pm-dir@ietf.org" , "Varun Singh" Thread-Topic: [xrblock]RE: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: Ac8mHMohgTqbV6RzRzOEe/CvyioJpwAIUm3Q Date: Mon, 10 Feb 2014 09:57:35 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591E6FE@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "MORTON, ALFRED C \(AL\)" , "xrblock@ietf.org" Subject: Re: [xrblock] Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 09:58:05 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qin, Thanks for your comments. Please see inline. Best regards, Rachel From: Qin Wu Sent: Monday, February 10, 2014 12:59 PM To: pm-dir@ietf.org; Varun Singh; Huangyihong (Rachel) Cc: MORTON, ALFRED C (AL); Benoit Claise Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-= repair-loss-count Hi, Authors: I am the assigned PM-DIR reviewer for this draft. Here is my review to this draft based on RFC6390 PM template. This draft defines two new metrics in the same metric block and has alread= y applied RFC6390 template to these two metrics, However I do have some comments below regarding metri= cs definition. 1. Appendix A, Part a, Bullet 3 says: " * Method of Measurement or Calculation: It must be measured in the source stream. It must be measured for the packets that have no further chance of being repaired. " The first sentence is a little bit confusing, are you saying the measuremen= t is applied to source stream, I think you can reference to section 3, the defin= ition "SSRC of source" for that. [Rachel]: Sorry. It should be the "primary source stream". For some impleme= ntations using retransmission, it is possible that retransmission stream ha= s the same SSRC with the primary source stream, but in different sessions. The second sentence seems also repeat what the definition of "unrepaired lo= ss count", you can simply reference that definition. [Rachel]: How about changing to "It must be measured in the primary source = stream for the packets with no further chance to be repaired"? 2. Appendix A, Part a, Bullet 5 says: " Measurement Point(s) with Potential Measurement Domain: See section 3, 1st paragraph. " Section 3, 1st paragraph doesn't explain where to measure? I suggest you can add the following sentence to the section 3, 1st paragrap= h as follows: " The measurement of these metrics is made at the receiving end of the RTP st= ream " And you then you reference section 3 for measurement points. [Rachel]: Good suggestion. Thanks. 3. Appendix A, Part a, Bullet 6 says: " * Measurement Timing: See Section 4 for measurement timing. " Section 4 has no text to explain measurement timing. Since Since this metric doesn't rely on the measurement interval in the Measurement Information Block [RFC6776] indicating the span of the report, I believe you rely on sequence number range to indicate measurement timing, please make it clear in the text. [Rachel]: Good point. How about adding the following sentence to section 3? "This new RTCP extended report block share the same timing interval with RT= CP SR/RR " 4. Appendix A, Part b, Bullet 3 My comment on Appendix A, part a Bullet 3 is also applied here. [Rachel]: Okay. 5. Appendix A, Part b, Bullet 5 My comment on Appendix A, part a Bullet 5 is also applied here. [Rachel]: Okay. 6. Appendix A, Part b, Bullet 6 My comment on Appendix A, part a Bullet 6 is also applied here. [Rachel]: Okay. 7. Section 1, paragraph 1 s/measured on media stream/measured on RTP stream [Rachel]: Okay. 8.Section 1, Paragraph 1 says: " Hence, the sending endpoint cannot assess the performance of the repair mechanism by observing the change in fraction loss and the cumulative loss statistics. " It is better to add a reference for fraction loss and the cumulative loss, = I think It should be RFC 3550 RTCP SR which carries fraction loss statistics. [Rachel]: Will do. 9. Section 1, Paragraph 1 says: " When applications use multiple XR blocks, the endpoints require more concise reporting to save bandwidth. " I don't think the endpoints MUST have such concise reporting in such case. Therefore I suggest to say the endpoint may require more concise reporting = in such case. [Rachel]: You're right. Will do. 10. Section 1, Paragraph 2 says: " Thus it is RECOMMENDED that this report block should be generated for those source packets that have no further chance of being repaired. But a potential ambiguity may result from sequence number range inconsistent. To address this issue, we use begin sequence number and end sequence number to explicitly indicate the actual sequence number range that the report block reports on. " Whose ambiguity? RFC3550 or RFC5725? Not sure you should highlight using begin seq or end seq since RFC5725 also= use this. You'd better have more text to explain where sequence number inconsistency = come from? [Rachel]: That's why we don't use the measurement interval in the Measureme= nt information Block [RFC6776]. The report block we develop is reporting th= e number of repaired packets and packets that won't be repaired anymore i= n the current interval. Some of the packets may not be repaired in current = interval, instead, they may be repaired in next or next several intervals. = If we use the same sequence range defined in RFC6776, like other RTCP XRs, = only cumulative counts are meaningful. So we choose to use the same interva= l with RTCP SR/RR and indicating the sequence number range explicitly. I will explain more in the draft to let people understand well. 11. Section 1, Paragraph 2 says: " In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre- repair loss count during the this range. Note that the metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of RFC3550. " The definition of repaired loss count here is not consistent with the defin= ition of repaired loss count in section 3? It looks repaired loss count here is referred to the value carried in the S= R while repaired loss count in section is referred to the packet that is repaired after loss repair mechanism is appl= ied. Please fix this to make them consistent. [Rachel]: I'm not trying to define repaired loss count here. I'm trying to = say that repaired loss count is used to calculating the pre-repaired loss c= ount. repaired loss count + unrepaired loss count =3D pre-repaired loss co= unt. Since some of the packet in the SR may not be repaired in current int= erval, pre-repaired loss count is not equal to the loss metrics in RTCP SR= . 12. Section 3, Paragraph 1 says: " This block describes the residual number of packets lost after applying repair mechanisms. The report block is complementary to the RTCP XR metrics defined in [RFC5725] as= it uses a non-RLE format. " What Does residual number mean? Suggest to remove residual. It doesn't add any benefit but introduce confusing. [Rachel]: Okay. 13. Section 3 says: " begin_seq: 16 bits The sequence number of the first packet in the session or the sequence number of the first packet fully repaired that this block reports on. end_seq: 16 bits The sequence number of the last packet fully repaired that this block reports on plus one. " Why not use the same definition as defined in the RFC3611 or RFC5725, why m= ake these definitions so specific? I don't think the begin_seq should only be chosen either as the first packe= t sequence number in the session Or the first packet sequence number that is fully repaired. Why not choose = the sequence number of any packet you received? In some case, you may not lose any packet, then in such case, both unrepair= ed loss count and repaired loss count should be set to zero. [Rachel]: Yes, you're right. The definition in RFC3611 is good. Regards! -Qin --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qin,

 

Thanks for your commen= ts. Please see inline.

 

Best regards,

Rachel

 

From: Qin Wu
Sent: Monday, February 10, 2014 12:59 PM
To: pm-dir@ietf.org; Varun Singh; Huangyihong (Rachel)
Cc: MORTON, ALFRED C (AL); Benoit Claise
Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-x= r-post-repair-loss-count

 

Hi, Authors:

I am the assigned P= M-DIR reviewer for this draft.

Here is my review t= o this draft based on RFC6390 PM template.

This draft defines = two new metrics  in the same metric block and has already applied RFC6= 390 template

to these two metric= s, However I do have some comments below regarding metrics definition.=

 

1. Appendix A, P= art a, Bullet 3 says:

“<= /span>

* Method of Measure= ment or Calculation: It must be measured in the

  source strea= m. It must be measured for the packets that

  have no furt= her chance of being repaired.

”<= /span>

The first sentence = is a little bit confusing, are you saying the measurement is

applied to source s= tream, I think you can reference to section 3, the definition “SSRC o= f source” for that.

 

[Rachel]: Sorry. It sh= ould be the ”primary source stream”. For some implementations u= sing retransmission, it is possible that retransmission stream has the same= SSRC with the primary source stream, but in different sessions.

 

The second sentence= seems also repeat what the definition of “unrepaired loss count̶= 1;,

you can simply refe= rence that definition.

 

[Rachel]: How about ch= anging to “It must be measure= d in the primary source stream for the packets with no further chance to be= repaired”?

 

2. Appendix A, P= art a, Bullet 5 says:

“<= /span>

Measurement Point(s= ) with Potential Measurement Domain: See

   &= nbsp;  section 3, 1st paragraph.

“<= /span>

Section 3, 1st para= graph doesn’t explain where to measure?

I suggest you can a= dd the following sentence to the section 3, 1st paragraph as follows:<= /o:p>

“<= /span>

The measurement of = these metrics is made at the receiving end of the RTP stream

”<= /span>

And you then you re= ference section 3 for measurement points.

 

[Rachel]: Good suggest= ion. Thanks.

 

3. Appendix A, P= art a, Bullet 6 says:

“<= /span>

* Measurement Timin= g: See Section 4 for measurement timing.

 

”<= /span>

Section 4 has no te= xt to explain measurement timing. Since

Since this metric d= oesn’t rely on the

measurement interva= l in the Measurement Information Block [RFC6776]

indicating the span= of the report, I believe you rely on sequence number

range to indicate m= easurement  timing, please make it clear in the text.

 

[Rachel]: Good point. = How about adding the following sentence to section 3?

 

“This new RTCP e= xtended report block share the same timing interval with RTCP SR/RR ”=

 

4. Appendix A, P= art b, Bullet 3

My comment on Appen= dix A, part a Bullet 3 is also applied here.<= o:p>

[Rachel]: Okay.

 

5. Appendix A, P= art b, Bullet 5

My comment on Appen= dix A, part a Bullet 5 is also applied here.

[Rachel]: Okay.

 

6. Appendix A, P= art b, Bullet 6

My comment on Appen= dix A, part a Bullet 6 is also applied here.

[Rachel]: Okay.

 

7. Section 1, pa= ragraph 1

s/measured on medi= a stream/measured on RTP stream

[Rachel]: Okay.

 

8.Section 1, Par= agraph 1 says:

“<= /span>

Hence, the = sending

endpoint ca= nnot assess the performance of the repair mechanism by

observing t= he change in fraction loss and the cumulative loss

statistics.

”<= /span>

 

It is better to add= a reference for fraction loss and the cumulative loss, I think<= /span>

It should be RFC 35= 50 RTCP SR which carries fraction loss statistics.

[Rachel]: Will do.

 

9. Section 1, Pa= ragraph 1 says:

“<= /span>

When
applications use multiple XR blocks, the endpoints require more
concise reporting to save bandwidth.

&n= bsp;

”<= /span>

I don’t think= the endpoints MUST have such concise reporting in such case.

Therefore I suggest= to say the endpoint may require more concise reporting in such case.<= /o:p>

 

[Rachel]: You’re= right. Will do.

 

10. Section 1, P= aragraph 2 says:

“<= /span>

Thus it is RECOMMEN= DED that this report

block should be gen= erated for those source packets that have no

further chance of b= eing repaired. But a potential ambiguity may

result from sequenc= e number range inconsistent. To address this

issue, we use begin= sequence number and end sequence number to

explicitly indicate= the actual sequence number range that the report

   block = reports on.

”<= /span>

Whose ambiguity? RF= C3550 or RFC5725?

Not sure you should= highlight using begin seq or end seq since RFC5725 also use this.

You’d better = have more text to explain where sequence number inconsistency come from?

[Rachel]: That’s= why we don’t use the measurement interval in the Measurement informa= tion Block [RFC6776]. The report block we develop is reporting the number o= f  repaired  packets and packets that won’t be repaired anymore in the current interval. Some of the packets may not be repaired i= n current interval, instead, they may be repaired in next or next several i= ntervals. If we use the same sequence range defined in RFC6776, like other = RTCP XRs, only cumulative counts are meaningful. So we choose to use the same interval with RTCP SR/RR and = indicating the sequence number range explicitly.

I will explain more in= the draft to let people understand well.

 

11. Section 1, P= aragraph 2 says:

“<= /span>

In addition,  = another metric, repaired loss count,

is also introduced = in this report block for calculating the pre-

repair loss count d= uring the this range. Note that the metrics in

this report block M= UST NOT be directly compared with the pre-repair

loss metric of RFC3550.

“<= /span>

The definition of r= epaired loss count here is not consistent with the definition of repaired l= oss count in section 3?

It looks repaired l= oss count here is referred to the value carried in the SR while repaired lo= ss count in section is

referred to the pac= ket that is repaired after loss repair mechanism is applied. Please fix thi= s to make them consistent.

 
[Rachel]=
: I’m not trying to define repaired loss count here. I’m trying=
 to say that repaired loss count is used to calculating the pre-repa=
ired loss count.  repaired loss count +=
 unrepaired loss count =3D pre-repaired loss count. Since  some of the=
 packet in the SR may not be repaired in current interval, pre-repaired los=
s count is not equal to the loss  metrics in RTCP SR.

 

12. Section 3, P= aragraph 1 says:

“<= /span>

This block describe= s the residual number of packets lost after

applying repair mec= hanisms. The report block is complementary to the

RTCP XR metrics def= ined in [RFC5725] as it uses a non-RLE format.

”<= /span>

What Does residual = number mean? Suggest to remove residual.

It doesn’t ad= d any benefit but introduce confusing.

[R= achel]: Okay.

 

13. Section 3 sa= ys:

“<= /span>

   begin_seq: 16 bits
 
      The sequence number of the first p=
acket in the session or the
      sequence number of the first packe=
t fully repaired that this block
      reports on.

 


   end_seq: 16 bits


 


      The sequence number of the last pa=
cket fully repaired that this


      block reports on plus one.


&n=
bsp;


”<=
/span>


Why not use th=
e same definition as defined in the RFC3611 or RFC5725, why make these defi=
nitions so specific?=



I don’t think=
 the begin_seq should only be chosen either as the first packet sequence nu=
mber in the session


Or the first packet=
 sequence number that is fully repaired. Why not choose the sequence number=
 of any packet you received?


In some case, you m=
ay not lose any packet, then in such case, both unrepaired loss count =
 and  repaired loss count should be set to zero.


[Rachel]: Yes, youR=
17;re right. The definition in RFC3611 is good.



 


Regards!


-Qin
--_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_-- From ron.even.tlv@gmail.com Mon Feb 10 02:44:57 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B981A07E9 for ; Mon, 10 Feb 2014 02:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 2f2n7FG4EiDn for ; Mon, 10 Feb 2014 02:44:55 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 187CC1A07F1 for ; Mon, 10 Feb 2014 02:44:54 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id c13so2842026eek.17 for ; Mon, 10 Feb 2014 02:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=ifOli5lpJXBPJadqEq9W7jtAkg4+SOou92e9n3mtpfE=; b=Sby8Q+sjhHYqDmaBFec3E7Hr972wjtsyH4wNfUZa252ALj2SdO0vwjxrPnygUsMJsr w9kMkoqaRdRdlQipSLFlIXKXXGYUJTgPG9aL5vpxMpkL5J5xBA7X514sM/HSBkl/yhWD tO8bbrAuV6mezCOf6hCsfoZMZ8i9smP67drWGvOl74Yzeh5D98duNnhHZVUtp6FjPp/B 78HiFi0zSaLLwU42yeXhdsZKq9/PJv+2qG9KZK9BkOsz491S+7SWyTHkOvx0l29qkQqQ O9kFsFLjtoIDDBad4mvZDlgaDl+3M5zmbKaT+/fUfM+c+p6grY5/Ox4YtP5rkQXVQPPT Zfag== X-Received: by 10.14.173.200 with SMTP id v48mr83323eel.111.1392029094277; Mon, 10 Feb 2014 02:44:54 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id k6sm53076831eep.17.2014.02.10.02.44.52 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Feb 2014 02:44:53 -0800 (PST) From: "Roni Even" To: "'xrblock'" Date: Mon, 10 Feb 2014 12:44:43 +0200 Message-ID: <07c901cf264d$1e805d60$5b811820$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07CA_01CF265D.E209A290" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8mTF5h5WrKU6iPTX602kQgjBUH9w== Content-Language: en-us Subject: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 10:44:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07CA_01CF265D.E209A290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed the draft and it looks OK some small comments 1. Section 1 discuss the delay of the reporting to allow for the repair to take place. There may be a difference in the delay between conversional services and streaming application. Is the delay related to the jitter buffer size? 2. In section 3 "begin_seq", I am not sure why you have two options and why not use the RFC3611 definition Roni Even ------=_NextPart_000_07CA_01CF265D.E209A290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed the = draft and it looks OK some small comments

 

1.       = Section 1 discuss the = delay of the reporting to allow for the repair to take place. There may = be a difference in the delay between conversional services and streaming = application. Is the delay related to the jitter buffer = size?

2.       = In section 3 = “begin_seq”, I am not sure why = you have two options and why not use the RFC3611 = definition

 

Roni = Even

 

------=_NextPart_000_07CA_01CF265D.E209A290-- From csp@csperkins.org Mon Feb 10 15:40:05 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D93A1A0671 for ; Mon, 10 Feb 2014 15:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 YDkX4A92lBME for ; Mon, 10 Feb 2014 15:40:02 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E40A1A0619 for ; Mon, 10 Feb 2014 15:40:02 -0800 (PST) Received: from [81.187.2.149] (port=36291 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WD0SG-00060x-Mn; Mon, 10 Feb 2014 23:40:01 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <07c901cf264d$1e805d60$5b811820$@gmail.com> Date: Mon, 10 Feb 2014 23:39:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <09F5F14D-4280-40A3-A742-825F6DE5AA4C@csperkins.org> References: <07c901cf264d$1e805d60$5b811820$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: xrblock Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 23:40:05 -0000 Hi, On 10 Feb 2014, at 10:44, Roni Even wrote: > I reviewed the draft and it looks OK some small comments > =20 > 1. Section 1 discuss the delay of the reporting to allow for the = repair to take place. There may be a difference in the delay between = conversional services and streaming application. Is the delay related to = the jitter buffer size? > 2. In section 3 =93begin_seq=94, I am not sure why you have two = options and why not use the RFC3611 definition I agree with Roni that the definitions of begin_seq and end_seq are hard = to follow in this draft.=20 It=92s also not clear why the un-repaired loss count and repaired loss = count fields are 32 bits in size. For the end_seq field to be = unambiguous it has to be within a single RTP sequence number cycle of = the begin_seq field. This implies that at most 2^16 packets can be lost = in a single reporting interval, so the loss counts can be reduced to 16 = bits, saving four octets overall.=20 Both metrics say =93this metric must be measured in the primary source = stream=94, but the draft doesn=92t define what is meant by the primary = source stream. The phrasing would lead me to think the FEC and/or = retransmission is sent separately to the media, but we have some formats = that send FEC in the same packet stream (and in some cases in the same = packets) as the original media; the distinction between primary source = stream and repair stream is unclear in these cases. The phrase =93lost packets that haven=92t finished repairing=94 is not = clear, since a packet has either been repaired or not, and isn=92t = generally in the process of being repaired. A clearer wording may be = =93packets for which repair might still be possible=94? It might be = helpful to explicitly define the conditions under which a packet is = considered no longer possible to repair.=20 --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Feb 10 15:49:14 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3771A0708 for ; Mon, 10 Feb 2014 15:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HJ8JnF9TYfLy for ; Mon, 10 Feb 2014 15:49:12 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE111A0702 for ; Mon, 10 Feb 2014 15:49:12 -0800 (PST) Received: from [81.187.2.149] (port=44195 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WD0b9-0000dM-E5 for xrblock@ietf.org; Mon, 10 Feb 2014 23:49:11 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <20131216181001.9813.97028.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 23:49:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131216181001.9813.97028.idtracker@ietfa.amsl.com> To: xrblock mailing list X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 10 Feb 2014 23:49:15 -0000 On 16 Dec 2013, at 18:10, Internet-Drafts@ietf.org wrote: > 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. >=20 > Title : RTP Control Protocol (RTCP) Extended Report = (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information = (PSI) Decodability Statistics Metrics reporting > Author(s) : Jiangang Tong > Claire Bi > Roni Even > Qin Wu > Rachel Huang > Filename : = draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt > Pages : 10 > Date : 2013-12-05 >=20 > Abstract: > An MPEG2 Transport Stream (TS) is a standard container format used = in > the transmission and storage of multimedia data. Unicast/Multicast > MPEG2 TS over RTP is widely deployed in IPTV systems. This document > defines an RTP Control Protocol (RTCP) Extended Report (XR) Block > that allows the reporting of MPEG2 TS decodability statistics = metrics > related to transmissions of MPEG2 TS over RTP. The metrics = specified > in the RTCP XR Block are related to Program specific information > carried in MPEG TS. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodabili= ty It occurs to me that the issue with begin_seq and end_seq having to be = within the same RTP sequence number cycle to be unambiguous is present = in this draft, as well as the post-repair-loss-count draft (also in RFC = 6990 and maybe other places). The various *_count field here can = probably all be shortened to 16 bits without changing the utility of the = report block (several use 0xFFFF as an over-range value, so this seems = to be implied anyway). --=20 Colin Perkins http://csperkins.org/ From rachel.huang@huawei.com Mon Feb 10 18:57:11 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587381A0763 for ; Mon, 10 Feb 2014 18:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 qwPgR0s-8IIB for ; Mon, 10 Feb 2014 18:57:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD951A0760 for ; Mon, 10 Feb 2014 18:57:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL48537; Tue, 11 Feb 2014 02:57:08 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:56:57 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 02:57:07 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 10:57:00 +0800 From: "Huangyihong (Rachel)" To: Roni Even , "'xrblock'" Thread-Topic: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: Ac8mTF5h5WrKU6iPTX602kQgjBUH9wAfPEww Date: Tue, 11 Feb 2014 02:56:59 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591EA14@nkgeml501-mbs.china.huawei.com> References: <07c901cf264d$1e805d60$5b811820$@gmail.com> In-Reply-To: <07c901cf264d$1e805d60$5b811820$@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB4591EA14nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 11 Feb 2014 02:57:11 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591EA14nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thank you for your comments. Please see inline. Best regards, Rachel From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Roni Even Sent: Monday, February 10, 2014 6:45 PM To: 'xrblock' Subject: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-co= unt Hi, I reviewed the draft and it looks OK some small comments 1. Section 1 discuss the delay of the reporting to allow for the repa= ir to take place. There may be a difference in the delay between conversion= al services and streaming application. Is the delay related to the jitter b= uffer size? [Rachel]: The delay is raised in [RFC5725]. Yes, I think it indi= cates the jitter buffer size. 2. In section 3 "begin_seq", I am not sure why you have two options a= nd why not use the RFC3611 definition [Rachel]: Will fix it. Thanks. Roni Even --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591EA14nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thank you for your com= ments. Please see inline.

 

Best regards,

Rachel

 

From: xrblock = [mailto:xrblock-bounces@ietf.org] On Behalf Of Roni Even
Sent: Monday, February 10, 2014 6:45 PM
To: 'xrblock'
Subject: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-= loss-count

 

Hi,

I reviewed the draft and it looks OK some small comm= ents

 

1.     &= nbsp; Section 1 discuss the delay of the reporting to all= ow for the repair to take place. There may be a difference in the delay bet= ween conversional services and streaming application. Is the delay related = to the jitter buffer size?

   &nbs= p;       [Rachel]: The delay is raised in [RF= C5725]. Yes, I think it indicates the jitter buffer size.=

 

2.  =      In section 3 “begin_seq”, I am not sure why you have two options and why not us= e the RFC3611 definition

           [Rachel]: Will fix it.  Thanks.

 

Roni Even

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB4591EA14nkgeml501mbschi_-- From rachel.huang@huawei.com Mon Feb 10 19:35:32 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601561A0770 for ; Mon, 10 Feb 2014 19:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 xOIFePVZVhDR for ; Mon, 10 Feb 2014 19:35:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2901A076F for ; Mon, 10 Feb 2014 19:35:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ38082; Tue, 11 Feb 2014 03:35:28 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 03:35:16 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 03:35:27 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 11:35:21 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins , Roni Even Thread-Topic: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: Ac8mTF5h5WrKU6iPTX602kQgjBUH9wAKfyGAABeloeA= Date: Tue, 11 Feb 2014 03:35:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591EA36@nkgeml501-mbs.china.huawei.com> References: <07c901cf264d$1e805d60$5b811820$@gmail.com> <09F5F14D-4280-40A3-A742-825F6DE5AA4C@csperkins.org> In-Reply-To: <09F5F14D-4280-40A3-A742-825F6DE5AA4C@csperkins.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: xrblock Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 11 Feb 2014 03:35:32 -0000 Hi Colin, Thanks for your comments. Please see inline. Best regards, Rachel > -----Original Message----- > From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin > Perkins > Sent: Tuesday, February 11, 2014 7:40 AM > To: Roni Even > Cc: xrblock > Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post- > repair-loss-count >=20 > Hi, >=20 > On 10 Feb 2014, at 10:44, Roni Even wrote: > > I reviewed the draft and it looks OK some small comments > > > > 1. Section 1 discuss the delay of the reporting to allow for > the repair to take place. There may be a difference in the delay > between conversional services and streaming application. Is the delay > related to the jitter buffer size? > > 2. In section 3 "begin_seq", I am not sure why you have two > options and why not use the RFC3611 definition >=20 > I agree with Roni that the definitions of begin_seq and end_seq are > hard to follow in this draft. Will fix this. >=20 > It's also not clear why the un-repaired loss count and repaired loss > count fields are 32 bits in size. For the end_seq field to be > unambiguous it has to be within a single RTP sequence number cycle of > the begin_seq field. This implies that at most 2^16 packets can be lost > in a single reporting interval, so the loss counts can be reduced to 16 > bits, saving four octets overall. >=20 Good point. 16-bit is sufficient.=20 > Both metrics say "this metric must be measured in the primary source > stream", but the draft doesn't define what is meant by the primary > source stream. The phrasing would lead me to think the FEC and/or > retransmission is sent separately to the media, but we have some > formats that send FEC in the same packet stream (and in some cases in > the same packets) as the original media; the distinction between > primary source stream and repair stream is unclear in these cases. >=20 How about changing to "primary source packets"? Even if FEC/retransmission = is the same packet with primary source content, this packet is also primary= source packet and should be measured.=20 > The phrase "lost packets that haven't finished repairing" is not clear, > since a packet has either been repaired or not, and isn't generally in > the process of being repaired. A clearer wording may be "packets for > which repair might still be possible"? It might be helpful to > explicitly define the conditions under which a packet is considered no > longer possible to repair. Good suggestion. Thanks. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock From rachel.huang@huawei.com Tue Feb 11 04:10:04 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705031A0808 for ; Tue, 11 Feb 2014 04:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 y_ZHvCymkkTL for ; Tue, 11 Feb 2014 04:10:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4B1A07D0 for ; Tue, 11 Feb 2014 04:10:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ83413; Tue, 11 Feb 2014 12:10:00 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 12:08:54 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 12:09:49 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 20:09:46 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins , xrblock mailing list Thread-Topic: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt Thread-Index: AQHO+ooUKmNf2dvn1EaL1oEQNMEohJqu+jGAgAFRTgA= Date: Tue, 11 Feb 2014 12:09:45 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591EB55@nkgeml501-mbs.china.huawei.com> References: <20131216181001.9813.97028.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 11 Feb 2014 12:10:04 -0000 Hi Colin, Please see inline. Best regards, Rachel > -----Original Message----- > From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin > Perkins > Sent: Tuesday, February 11, 2014 7:49 AM > To: xrblock mailing list > Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi- > decodability-00.txt >=20 > On 16 Dec 2013, at 18:10, Internet-Drafts@ietf.org wrote: > > 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) > Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) > Decodability Statistics Metrics reporting > > Author(s) : Jiangang Tong > > Claire Bi > > Roni Even > > Qin Wu > > Rachel Huang > > Filename : draft-ietf-xrblock-rtcp-xr-psi-decodability- > 00.txt > > Pages : 10 > > Date : 2013-12-05 > > > > Abstract: > > An MPEG2 Transport Stream (TS) is a standard container format used > in > > the transmission and storage of multimedia data. Unicast/Multicast > > MPEG2 TS over RTP is widely deployed in IPTV systems. This > document > > defines an RTP Control Protocol (RTCP) Extended Report (XR) Block > > that allows the reporting of MPEG2 TS decodability statistics > metrics > > related to transmissions of MPEG2 TS over RTP. The metrics > specified > > in the RTCP XR Block are related to Program specific information > > carried in MPEG TS. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi- > decodability >=20 > It occurs to me that the issue with begin_seq and end_seq having to be > within the same RTP sequence number cycle to be unambiguous is present > in this draft, as well as the post-repair-loss-count draft (also in RFC > 6990 and maybe other places). The various *_count field here can > probably all be shortened to 16 bits without changing the utility of > the report block (several use 0xFFFF as an over-range value, so this > seems to be implied anyway). >=20 >=20 The metrics in this draft count the errors of TS packets which is encapsula= ted in RTP packets. One RTP packets may contain 8 TS packets at most. Thoug= h it seldom happens, it is still possible that the value of the metrics ove= r 16-bit. Right? > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock From csp@csperkins.org Tue Feb 11 14:23:47 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F1C1A0791 for ; Tue, 11 Feb 2014 14:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Zh93QzF6r3JJ for ; Tue, 11 Feb 2014 14:23:44 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1E81A0786 for ; Tue, 11 Feb 2014 14:23:44 -0800 (PST) Received: from [81.187.2.149] (port=39226 helo=[192.168.0.15]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WDLjx-00047i-Ee; Tue, 11 Feb 2014 22:23:42 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4591EB55@nkgeml501-mbs.china.huawei.com> Date: Tue, 11 Feb 2014 22:23:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6BFDD880-8A07-4242-A7A5-1AC4A042684A@csperkins.org> References: <20131216181001.9813.97028.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB4591EB55@nkgeml501-mbs.china.huawei.com> To: "Huangyihong (Rachel)" X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: xrblock mailing list Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 11 Feb 2014 22:23:47 -0000 Rachel, On 11 Feb 2014, at 12:09, Huangyihong (Rachel) = wrote: =85 >> -----Original Message----- >> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin >> Perkins >> Sent: Tuesday, February 11, 2014 7:49 AM >> To: xrblock mailing list >> Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi- >> decodability-00.txt >>=20 >> On 16 Dec 2013, at 18:10, Internet-Drafts@ietf.org wrote: >>> 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=92s = Extended Report Framework Working Group of the IETF. >>>=20 >>> Title : RTP Control Protocol (RTCP) Extended Report = (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information = (PSI) Decodability Statistics Metrics reporting >>> Author(s) : Jiangang Tong >>> Claire Bi >>> Roni Even >>> Qin Wu >>> Rachel Huang >>> Filename : = draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt >>> Pages : 10 >>> Date : 2013-12-05 >>>=20 >>> Abstract: >>> An MPEG2 Transport Stream (TS) is a standard container format used = in >>> the transmission and storage of multimedia data. Unicast/Multicast >>> MPEG2 TS over RTP is widely deployed in IPTV systems. This = document >>> defines an RTP Control Protocol (RTCP) Extended Report (XR) Block >>> that allows the reporting of MPEG2 TS decidability statistics = metrics >>> related to transmissions of MPEG2 TS over RTP. The metrics = specified >>> in the RTCP XR Block are related to Program specific information >>> carried in MPEG TS. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodabili= ty >>=20 >> It occurs to me that the issue with begin_seq and end_seq having to = be >> within the same RTP sequence number cycle to be unambiguous is = present >> in this draft, as well as the post-repair-loss-count draft (also in = RFC >> 6990 and maybe other places). The various *_count field here can >> probably all be shortened to 16 bits without changing the utility of >> the report block (several use 0xFFFF as an over-range value, so this >> seems to be implied anyway). >=20 > The metrics in this draft count the errors of TS packets which is = encapsulated in RTP packets. One RTP packets may contain 8 TS packets at = most. Though it seldom happens, it is still possible that the value of = the metrics over 16-bit. Right? For some of the metrics, that might be true. I misread the draft.=20 That said, many of the metrics in the draft are defined as counting the = number of times something =93does not come up at least every 0.5 = seconds=94. Given typical RTCP reporting intervals, it seems unlikely = that these will come close to overflowing a 16 bit field, let alone a 32 = bit field, in a single reporting interval. You might consider sizing the = fields appropriately.=20 Also, an undefined/over-range value of 0xffff makes sense for a 16 bit = unsigned field, but not so much for a 32 bit field. These values should = probably be adjusted to match the field sizes.=20 --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Feb 11 14:25:55 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524B81A0782 for ; Tue, 11 Feb 2014 14:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 XUerI9rBnimb for ; Tue, 11 Feb 2014 14:25:53 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87D1A0786 for ; Tue, 11 Feb 2014 14:25:51 -0800 (PST) Received: from [81.187.2.149] (port=43454 helo=[192.168.0.15]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WDLm1-0004iN-M9; Tue, 11 Feb 2014 22:25:50 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4591EA36@nkgeml501-mbs.china.huawei.com> Date: Tue, 11 Feb 2014 22:25:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1108AF8F-D5EC-4F61-98E5-C857201D12A1@csperkins.org> References: <07c901cf264d$1e805d60$5b811820$@gmail.com> <09F5F14D-4280-40A3-A742-825F6DE5AA4C@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB4591EA36@nkgeml501-mbs.china.huawei.com> To: "Huangyihong (Rachel)" X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: xrblock Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 11 Feb 2014 22:25:55 -0000 Rachel, One quick reply inline.=20 Colin On 11 Feb 2014, at 03:35, Huangyihong (Rachel) = wrote: > Hi Colin, >=20 > Thanks for your comments. Please see inline. >=20 > Best regards, > Rachel >=20 >> -----Original Message----- >> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin >> Perkins >> Sent: Tuesday, February 11, 2014 7:40 AM >> To: Roni Even >> Cc: xrblock >> Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post- >> repair-loss-count >>=20 >> Hi, >>=20 >> On 10 Feb 2014, at 10:44, Roni Even wrote: >>> I reviewed the draft and it looks OK some small comments >>>=20 >>> 1. Section 1 discuss the delay of the reporting to allow for >> the repair to take place. There may be a difference in the delay >> between conversional services and streaming application. Is the delay >> related to the jitter buffer size? >>> 2. In section 3 "begin_seq", I am not sure why you have two >> options and why not use the RFC3611 definition >>=20 >> I agree with Roni that the definitions of begin_seq and end_seq are >> hard to follow in this draft. >=20 > Will fix this. >=20 >>=20 >> It's also not clear why the un-repaired loss count and repaired loss >> count fields are 32 bits in size. For the end_seq field to be >> unambiguous it has to be within a single RTP sequence number cycle of >> the begin_seq field. This implies that at most 2^16 packets can be = lost >> in a single reporting interval, so the loss counts can be reduced to = 16 >> bits, saving four octets overall. >>=20 > Good point. 16-bit is sufficient.=20 >=20 >> Both metrics say "this metric must be measured in the primary source >> stream", but the draft doesn't define what is meant by the primary >> source stream. The phrasing would lead me to think the FEC and/or >> retransmission is sent separately to the media, but we have some >> formats that send FEC in the same packet stream (and in some cases in >> the same packets) as the original media; the distinction between >> primary source stream and repair stream is unclear in these cases. >>=20 > How about changing to "primary source packets"? Even if = FEC/retransmission is the same packet with primary source content, this = packet is also primary source packet and should be measured.=20 That could be fine, provided =93primary source packet=94 is defined = clearly in the draft. >> The phrase "lost packets that haven't finished repairing" is not = clear, >> since a packet has either been repaired or not, and isn't generally = in >> the process of being repaired. A clearer wording may be "packets for >> which repair might still be possible"? It might be helpful to >> explicitly define the conditions under which a packet is considered = no >> longer possible to repair. >=20 > Good suggestion. Thanks. >=20 >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >> _______________________________________________ >> xrblock mailing list >> xrblock@ietf.org >> https://www.ietf.org/mailman/listinfo/xrblock --=20 Colin Perkins http://csperkins.org/ From rachel.huang@huawei.com Tue Feb 11 17:54:43 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F0D1A070B for ; Tue, 11 Feb 2014 17:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 3WEV8BX0kCpG for ; Tue, 11 Feb 2014 17:54:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1AE31A03CC for ; Tue, 11 Feb 2014 17:54:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBA31912; Wed, 12 Feb 2014 01:54:38 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 01:53:39 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 01:54:35 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 09:54:30 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins Thread-Topic: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt Thread-Index: AQHPJ3fx9fqoNHOuJEmvIFImJSXPt5qw1BEQ Date: Wed, 12 Feb 2014 01:54:29 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591ED6A@nkgeml501-mbs.china.huawei.com> References: <20131216181001.9813.97028.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB4591EB55@nkgeml501-mbs.china.huawei.com> <6BFDD880-8A07-4242-A7A5-1AC4A042684A@csperkins.org> In-Reply-To: <6BFDD880-8A07-4242-A7A5-1AC4A042684A@csperkins.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: xrblock mailing list Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 01:54:44 -0000 Hi Colin, I get your point. It will be fixed according to your comments. Thanks.=20 Best regards, Rachel > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, February 12, 2014 6:24 AM > To: Huangyihong (Rachel) > Cc: xrblock mailing list > Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi- > decodability-00.txt >=20 > Rachel, >=20 > On 11 Feb 2014, at 12:09, Huangyihong (Rachel) > wrote: > ... > >> -----Original Message----- > >> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin > >> Perkins > >> Sent: Tuesday, February 11, 2014 7:49 AM > >> To: xrblock mailing list > >> Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi- > >> decodability-00.txt > >> > >> On 16 Dec 2013, at 18:10, Internet-Drafts@ietf.org wrote: > >>> 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) > Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) > Decodability Statistics Metrics reporting > >>> Author(s) : Jiangang Tong > >>> Claire Bi > >>> Roni Even > >>> Qin Wu > >>> Rachel Huang > >>> Filename : draft-ietf-xrblock-rtcp-xr-psi-decodability- > 00.txt > >>> Pages : 10 > >>> Date : 2013-12-05 > >>> > >>> Abstract: > >>> An MPEG2 Transport Stream (TS) is a standard container format used > in > >>> the transmission and storage of multimedia data. > Unicast/Multicast > >>> MPEG2 TS over RTP is widely deployed in IPTV systems. This > document > >>> defines an RTP Control Protocol (RTCP) Extended Report (XR) Block > >>> that allows the reporting of MPEG2 TS decidability statistics > metrics > >>> related to transmissions of MPEG2 TS over RTP. The metrics > specified > >>> in the RTCP XR Block are related to Program specific information > >>> carried in MPEG TS. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi- > decodability > >> > >> It occurs to me that the issue with begin_seq and end_seq having to > be > >> within the same RTP sequence number cycle to be unambiguous is > present > >> in this draft, as well as the post-repair-loss-count draft (also in > RFC > >> 6990 and maybe other places). The various *_count field here can > >> probably all be shortened to 16 bits without changing the utility of > >> the report block (several use 0xFFFF as an over-range value, so this > >> seems to be implied anyway). > > > > The metrics in this draft count the errors of TS packets which is > encapsulated in RTP packets. One RTP packets may contain 8 TS packets > at most. Though it seldom happens, it is still possible that the value > of the metrics over 16-bit. Right? >=20 > For some of the metrics, that might be true. I misread the draft. >=20 > That said, many of the metrics in the draft are defined as counting the > number of times something "does not come up at least every 0.5 seconds". > Given typical RTCP reporting intervals, it seems unlikely that these > will come close to overflowing a 16 bit field, let alone a 32 bit field, > in a single reporting interval. You might consider sizing the fields > appropriately. >=20 > Also, an undefined/over-range value of 0xffff makes sense for a 16 bit > unsigned field, but not so much for a 32 bit field. These values should > probably be adjusted to match the field sizes. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From rachel.huang@huawei.com Tue Feb 11 19:06:50 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206CC1A07DA for ; Tue, 11 Feb 2014 19:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 qx2MjWbBZ9uE for ; Tue, 11 Feb 2014 19:06:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 16A8F1A07C7 for ; Tue, 11 Feb 2014 19:06:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBA36312; Wed, 12 Feb 2014 03:06:43 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 03:06:29 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 03:06:41 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 11:06:37 +0800 From: "Huangyihong (Rachel)" To: Colin Perkins Thread-Topic: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: AQHPJ3hFGMYvrcc2mEGc6eSZ9i/wIJqw5o3A Date: Wed, 12 Feb 2014 03:06:36 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591ED94@nkgeml501-mbs.china.huawei.com> References: <07c901cf264d$1e805d60$5b811820$@gmail.com> <09F5F14D-4280-40A3-A742-825F6DE5AA4C@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB4591EA36@nkgeml501-mbs.china.huawei.com> <1108AF8F-D5EC-4F61-98E5-C857201D12A1@csperkins.org> In-Reply-To: <1108AF8F-D5EC-4F61-98E5-C857201D12A1@csperkins.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: xrblock Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 03:06:50 -0000 Hi Colin, How about the following definition? "primary source packet: the original RTP packet sent from the RTP sender fo= r the first time. A primary source packet may be lost when transporting. Th= e lost one can be repaired by mechanisms like FEC or retransmission." Best regards, Rachel > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Wednesday, February 12, 2014 6:26 AM > To: Huangyihong (Rachel) > Cc: Roni Even; xrblock > Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post- > repair-loss-count >=20 > Rachel, >=20 > One quick reply inline. > Colin >=20 >=20 >=20 > On 11 Feb 2014, at 03:35, Huangyihong (Rachel) > wrote: > > Hi Colin, > > > > Thanks for your comments. Please see inline. > > > > Best regards, > > Rachel > > > >> -----Original Message----- > >> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin > >> Perkins > >> Sent: Tuesday, February 11, 2014 7:40 AM > >> To: Roni Even > >> Cc: xrblock > >> Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post- > >> repair-loss-count > >> > >> Hi, > >> > >> On 10 Feb 2014, at 10:44, Roni Even wrote: > >>> I reviewed the draft and it looks OK some small comments > >>> > >>> 1. Section 1 discuss the delay of the reporting to allow for > >> the repair to take place. There may be a difference in the delay > >> between conversional services and streaming application. Is the > delay > >> related to the jitter buffer size? > >>> 2. In section 3 "begin_seq", I am not sure why you have two > >> options and why not use the RFC3611 definition > >> > >> I agree with Roni that the definitions of begin_seq and end_seq are > >> hard to follow in this draft. > > > > Will fix this. > > > >> > >> It's also not clear why the un-repaired loss count and repaired loss > >> count fields are 32 bits in size. For the end_seq field to be > >> unambiguous it has to be within a single RTP sequence number cycle > of > >> the begin_seq field. This implies that at most 2^16 packets can be > lost > >> in a single reporting interval, so the loss counts can be reduced to > 16 > >> bits, saving four octets overall. > >> > > Good point. 16-bit is sufficient. > > > >> Both metrics say "this metric must be measured in the primary source > >> stream", but the draft doesn't define what is meant by the primary > >> source stream. The phrasing would lead me to think the FEC and/or > >> retransmission is sent separately to the media, but we have some > >> formats that send FEC in the same packet stream (and in some cases > in > >> the same packets) as the original media; the distinction between > >> primary source stream and repair stream is unclear in these cases. > >> > > How about changing to "primary source packets"? Even if > FEC/retransmission is the same packet with primary source content, this > packet is also primary source packet and should be measured. >=20 > That could be fine, provided "primary source packet" is defined clearly > in the draft. >=20 > >> The phrase "lost packets that haven't finished repairing" is not > clear, > >> since a packet has either been repaired or not, and isn't generally > in > >> the process of being repaired. A clearer wording may be "packets for > >> which repair might still be possible"? It might be helpful to > >> explicitly define the conditions under which a packet is considered > no > >> longer possible to repair. > > > > Good suggestion. Thanks. > > > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> _______________________________________________ > >> xrblock mailing list > >> xrblock@ietf.org > >> https://www.ietf.org/mailman/listinfo/xrblock >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From internet-drafts@ietf.org Wed Feb 12 22:24:00 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9131A010E; Wed, 12 Feb 2014 22:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 DPQh1veHOf0R; Wed, 12 Feb 2014 22:23:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB161A00F5; Wed, 12 Feb 2014 22:23:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213062357.5473.86156.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 22:23:57 -0800 Cc: xrblock@ietf.org Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 13 Feb 2014 06:24:00 -0000 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) for Post-Repair Loss Count Metrics Authors : Rachel Huang Varun Singh Filename : draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01.txt Pages : 9 Date : 2014-02-12 Abstract: This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows reporting of post-repair loss count metrics for a range of RTP applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rachel.huang@huawei.com Wed Feb 12 22:33:54 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354CD1A0115 for ; Wed, 12 Feb 2014 22:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 EJ8xIGhtuj-Y for ; Wed, 12 Feb 2014 22:33:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC27E1A010F for ; Wed, 12 Feb 2014 22:33:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB49257; Thu, 13 Feb 2014 06:33:50 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 06:32:24 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 06:33:24 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 14:33:21 +0800 From: "Huangyihong (Rachel)" To: xrblock Thread-Topic: New Version Notification for draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01.txt Thread-Index: AQHPKIQ0tDGJLSa5Ek2W3D9M0Tn32Zqyt3RA Date: Thu, 13 Feb 2014 06:33:21 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591F209@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [xrblock] FW: New Version Notification for draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 13 Feb 2014 06:33:54 -0000 SGkgZm9sa3MsDQoNCldlIGhhdmUganVzdCB1cGRhdGVkIHRoZSBkcmFmdCB0byBhZGRyZXNzIHRo ZSBjb21tZW50cyBmcm9tIFFpbiwgQ29saW4gYW5kIFJvbmkuIFRoYW5rIHlvdSBndXlzIGFuZCBw bGVhc2UgY2hlY2sgd2hldGhlciB5b3VyIGlzc3VlcyBhcmUgc29sdmVkLiBBbnkgZnVydGhlciBj b21tZW50cyBhcmUgYWxzbyB3ZWxjb21lZC4NCg0KQmVzdCByZWdhcmRzLA0KUmFjaGVsDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDEzLCAyMDE0IDI6MjQgUE0NClRvOiBWYXJ1biBTaW5naDsgSHVhbmd5aWhvbmcgKFJhY2hl bCk7IFZhcnVuIFNpbmdoOyBIdWFuZ3lpaG9uZyAoUmFjaGVsKQ0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wb3N0LXJlcGFp ci1sb3NzLWNvdW50LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRm LXhyYmxvY2stcnRjcC14ci1wb3N0LXJlcGFpci1sb3NzLWNvdW50LTAxLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSYWNoZWwgSHVhbmcgYW5kIHBvc3RlZCB0byB0aGUN CklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBv c3QtcmVwYWlyLWxvc3MtY291bnQNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlSVFAgQ29udHJvbCBQ cm90b2NvbCAoUlRDUCkgRXh0ZW5kZWQgUmVwb3J0IChYUikgZm9yIFBvc3QtUmVwYWlyIExvc3Mg Q291bnQgTWV0cmljcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMi0xMw0KR3JvdXA6CQl4cmJsb2Nr DQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wb3N0LXJlcGFpci1sb3NzLWNvdW50 LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBvc3QtcmVwYWlyLWxvc3MtY291bnQvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi14cmJsb2Nr LXJ0Y3AteHItcG9zdC1yZXBhaXItbG9zcy1jb3VudC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBv c3QtcmVwYWlyLWxvc3MtY291bnQtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYW4gUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEV4dGVuZGVkIFJlcG9ydA0KICAg KFhSKSBCbG9jayB0aGF0IGFsbG93cyByZXBvcnRpbmcgb2YgcG9zdC1yZXBhaXIgbG9zcyBjb3Vu dCBtZXRyaWNzDQogICBmb3IgYSByYW5nZSBvZiBSVFAgYXBwbGljYXRpb25zLg0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From internet-drafts@ietf.org Thu Feb 13 05:37:28 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56501A0240; Thu, 13 Feb 2014 05:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 bCwCwTTimf7z; Thu, 13 Feb 2014 05:37:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC591A017E; Thu, 13 Feb 2014 05:37:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213133722.2397.73722.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 05:37:22 -0800 Cc: xrblock@ietf.org Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-01.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 13 Feb 2014 13:37:29 -0000 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) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics reporting Authors : Jiangang Tong Claire Bi Roni Even Qin Wu Rachel Huang Filename : draft-ietf-xrblock-rtcp-xr-psi-decodability-01.txt Pages : 11 Date : 2014-02-13 Abstract: An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/Multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR Block are related to Program specific information carried in MPEG TS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-psi-decodability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-psi-decodability-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Feb 13 06:08:58 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED031A026C; Thu, 13 Feb 2014 06:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 iWi6u-9-rCKL; Thu, 13 Feb 2014 06:08:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 336CA1A025B; Thu, 13 Feb 2014 06:08:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213140854.26817.26859.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 06:08:54 -0800 Cc: xrblock@ietf.org Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-14.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 13 Feb 2014 14:08:58 -0000 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 MOS Metric Reporting Authors : Alan Clark Qin Wu Roland Schott Glen Zorn Filename : draft-ietf-xrblock-rtcp-xr-qoe-14.txt Pages : 25 Date : 2014-02-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 mean opinion score (MOS) 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-qoe-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Thu Feb 13 06:13:22 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149281A0286 for ; Thu, 13 Feb 2014 06:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 y9slppslEboF for ; Thu, 13 Feb 2014 06:13:18 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F91A0273 for ; Thu, 13 Feb 2014 06:13:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwOAA7S/FKHCzI1/2dsb2JhbABZgkIjIThXqCkIlxuBFhZ0gicBAQMSG14BDAkVViYBBBsBGYdjAQyWUoRSrGkXjkiCZw9mgRQEnxuLNIMtgio X-IronPort-AV: E=Sophos;i="4.95,838,1384318800"; d="scan'208,217";a="49434549" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Feb 2014 09:13:16 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 13 Feb 2014 09:00:22 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 15:13:15 +0100 From: "Romascanu, Dan (Dan)" To: "xrblock@ietf.org" Thread-Topic: ietf-89 preliminary agenda Thread-Index: Ac8oxbulryuyiDDUTMKMvxCKsxHHQw== Date: Thu, 13 Feb 2014 14:13:14 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E40AAC8@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AAC8AZFFEXMB04globa_" MIME-Version: 1.0 Subject: [xrblock] ietf-89 preliminary agenda X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 13 Feb 2014 14:13:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AAC8AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have loaded the preliminary agenda for the WG meeting at IETF-89 at http:= //www.ietf.org/proceedings/89/agenda/agenda-89-xrblock. This is based upon = the requests we received until now. If you believe that there are other ite= ms that need discussion at the IETF meeting please let Shida and me know . Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AAC8AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have loaded the preliminary agenda for the WG meet= ing at IETF-89 at htt= p://www.ietf.org/proceedings/89/agenda/agenda-89-xrblock. This is based= upon the requests we received until now. If you believe that there are oth= er items that need discussion at the IETF meeting please let Shida and me know .

 

Thanks and Regards,

 

Dan

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E40AAC8AZFFEXMB04globa_-- From internet-drafts@ietf.org Thu Feb 13 08:38:39 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06EF1A0333; Thu, 13 Feb 2014 08:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9Vz1fBPs6MdL; Thu, 13 Feb 2014 08:38:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC41A0370; Thu, 13 Feb 2014 08:38:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213163826.2754.68980.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 08:38:26 -0800 Cc: xrblock@ietf.org Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-15.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 13 Feb 2014 16:38:40 -0000 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 MOS Metric Reporting Authors : Alan Clark Qin Wu Roland Schott Glen Zorn Filename : draft-ietf-xrblock-rtcp-xr-qoe-15.txt Pages : 25 Date : 2014-02-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 mean opinion score (MOS) 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-qoe-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 04:36:31 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D951A0228 for ; Fri, 14 Feb 2014 04:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 FyEQiPU7VX8L for ; Fri, 14 Feb 2014 04:36:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7E61A015B for ; Fri, 14 Feb 2014 04:36:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD18159; Fri, 14 Feb 2014 12:36:22 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 12:35:11 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 12:36:14 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 20:36:08 +0800 From: "Huangyihong (Rachel)" To: xrblock Thread-Topic: New Version Notification for draft-huang-xrblock-rtcweb-rtcp-xr-metrics-03.txt Thread-Index: AQHPKYALxeoKKaaWQUSJH+ti/gN7aZq0rScA Date: Fri, 14 Feb 2014 12:36:08 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591F8A9@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/8nQDVB35jYPJUidFVxUPCxDqwgg Subject: [xrblock] FW: New Version Notification for draft-huang-xrblock-rtcweb-rtcp-xr-metrics-03.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 14 Feb 2014 12:36:28 -0000 SGkgYWxsLA0KDQpXZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWh1YW5n LXhyYmxvY2stcnRjd2ViLXJ0Y3AteHItbWV0cmljcy4gVGhlIG1haW4gY2hhbmdlcyBhcmU6DQox LiBleHBsYWlucyBob3cgc3RhdHMgbWV0cmljcyBhcmUgdXNlZCBpbiBXZWJSVEMuDQoyLiBjbGFz c2lmaWVzIHRoZSBtZXRyaWNzIGludG8gMyBjYXRlZ29yaWVzLg0KMy4gcmVtb3ZlcyByZXRyYW5z bWlzc2lvbiBtZXRyaWNzIChzb21lIG92ZXJsYXBwaW5nIHVzYWdlIHdpdGggcG9zdC1yZXBhaXIg bWV0cmljcykuDQo0LiBhZGRzIEVDTiByZWxhdGVkIG1ldHJpY3MgZm9yIGRpc2N1c3Npb24uDQpZ b3VyIHJldmlldyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuIFRoYW5rcy4NCg0KQmVzdCByZWdh cmRzLA0KUmFjaGVsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDg6MjcgUE0NClRvOiBWYXJ1biBTaW5naDsg Um9uaSBFdmVuOyBEYW4gUm9tYXNjYW51OyBWYXJ1biBTaW5naDsgUm9uaSBFdmVuOyBIdWFuZ3lp aG9uZyAoUmFjaGVsKTsgRGVuZyBMaW5nbGk7IERhbiBSb21hc2NhbnU7IExpbmdsaSBEZW5nOyBI dWFuZ3lpaG9uZyAoUmFjaGVsKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1odWFuZy14cmJsb2NrLXJ0Y3dlYi1ydGNwLXhyLW1ldHJpY3MtMDMudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1YW5nLXhyYmxvY2stcnRjd2ViLXJ0Y3AteHIt bWV0cmljcy0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFjaGVs IEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1odWFuZy14cmJsb2NrLXJ0Y3dlYi1ydGNwLXhyLW1ldHJpY3MNClJldmlzaW9uOgkwMw0KVGl0 bGU6CQlDb25zaWRlcmF0aW9ucyBmb3IgU2VsZWN0aW5nIFJUQ1AgRXh0ZW5kZWQgUmVwb3J0IChY UikgTWV0cmljcyBmb3IgdGhlIFJUQ1dFQiBTdGF0aXN0aWNzIEFQSQ0KRG9jdW1lbnQgZGF0ZToJ MjAxNC0wMi0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTMNClVS TDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1o dWFuZy14cmJsb2NrLXJ0Y3dlYi1ydGNwLXhyLW1ldHJpY3MtMDMudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVhbmcteHJibG9jay1y dGN3ZWItcnRjcC14ci1tZXRyaWNzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWh1YW5nLXhyYmxvY2stcnRjd2ViLXJ0Y3AteHItbWV0cmljcy0wMw0K RGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWh1 YW5nLXhyYmxvY2stcnRjd2ViLXJ0Y3AteHItbWV0cmljcy0wMw0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIG1vbml0b3JpbmcgZmVhdHVyZXMgcmVsYXRlZCB0byBSVENX RUIuIEl0DQogICBwcm92aWRlcyBhIGxpc3Qgb2YgUlRDUCBYUiBtZXRyaWNzIHRoYXQgYXJlIHVz ZWZ1bCBhbmQgbWF5IG5lZWQgdG8gYmUNCiAgIHN1cHBvcnRlZCBpbiBzb21lIFJUQ1dFQiBpbXBs ZW1lbnRhdGlvbnMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Feb 18 02:32:10 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E021A047E for ; Tue, 18 Feb 2014 02:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FILL_THIS_FORM_FRAUD_PHISH=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 MmXwJxLQqJiX for ; Tue, 18 Feb 2014 02:32:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D2F521A0656 for ; Tue, 18 Feb 2014 02:32:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBG13390; Tue, 18 Feb 2014 10:32:01 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 10:31:50 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 10:31:58 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 18:31:53 +0800 From: Qin Wu To: "xrblock@ietf.org" Thread-Topic: Ted Lemon's No Objection on draft-ietf-xrblock-rtcp-xr-qoe-15: (with COMMENT) Thread-Index: AQHPKNrb0lc+imJ7nE6cvpCFAQsBn5q6z+XQ Date: Tue, 18 Feb 2014 10:31:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/eua8B4jWsYwb-T0HC75eqYuvXgc Cc: "xrblock-chairs@tools.ietf.org" Subject: [xrblock] FW: Ted Lemon's No Objection on draft-ietf-xrblock-rtcp-xr-qoe-15: (with COMMENT) X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 18 Feb 2014 10:32:10 -0000 SGksIGFsbDoNCk1heSBJIGFzayBwZW9wbGUgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIGNoYW5nZXMg d2UgbWFkZSBpbiB2LSgwMTQpIGFuZCB2LSgwMTUpLg0KVGhlIGRpZmYgaXMNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTE0 LnR4dA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXhyYmxv Y2stcnRjcC14ci1xb2UtMTUudHh0DQpUaGVzZSBwcm9wb3NlZCBjaGFuZ2VzIGFkZHJlc3MgdHdv IEFEcyBESVNDVVNTZXMgZHVyaW5nIElFU0cgcmV2aWV3Lg0KQ2hhbmdlIDE6IE1ha2UgbWV0cmlj IG5hbWUgcmVwcmVzZW50ZWQgdXNpbmcgUkZDNjM5MCB0ZW1wbGF0ZSBtb3JlIHNwZWNpZmljLg0K Q2hhbmdlIDI6IEZvcmJpZGRlbiB1c2luZyBzYW1wbGVkIHZhbHVlIGJhc2VkIG9uIFRlZCdzIHN1 Z2dlc3Rpb24uDQpDaGFuZ2UgMzogIENsYXJpZnkgaG93IHRvIGRlYWwgd2l0aCB0aGUgZXJyb3Ig ZHVlIHRvIGV4dGVuc2lvbiBkaXJlY3Rpb24NCiAgIGluY29tcGF0aWJsZSB3aXRoIHRoZSBzdHJl YW0gZGlyZWN0aW9uLg0KU29tZSB0eXBvIGluIHYtKDAxNSkgd2FzIGNhdWdodCBieSBUZWQgYW5k IG1lbnRpb25lZCBiZWxvdy4gDQoNCkFkZGl0aW9uYWwgY29tbWVudHMgZnJvbSBQZXRlIGhhc24n dCBiZWVuIGFkZHJlc3NlZCBhbmQgYWdyZWVkIGJ5IGF1dGhvcnMgb2YgZHJhZnQuDQpPbmUgY29t bWVudCBpcyBhYm91dCB0aGUgY29udGFjdHMgZm9yIElFVEYNCnN0YW5kYXJkcyB0cmFjayByZWdp c3RlcmVkIGl0ZW0uDQpJIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5nZQ0KT0xE IFRFWFQ6DQoiDQo1LjMuICBUaGUgU0RQIGNhbGdleHRtYXAgQXR0cmlidXRlDQoNCiAgIFRoaXMg c2VjdGlvbiBjb250YWlucyB0aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgYnkgW1JGQzQ1NjZdIGZv ciBhbg0KICAgU0RQIGF0dHJpYnV0ZS4NCiAgIG8gIGNvbnRhY3QgbmFtZSwgZW1haWwgYWRkcmVz czogaWV0Zg0KIg0KTkVXIFRFWFQ6DQoiDQo1LjMuICBUaGUgU0RQIGNhbGdleHRtYXAgQXR0cmli dXRlDQoNCiAgIFRoaXMgc2VjdGlvbiBjb250YWlucyB0aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQg YnkgW1JGQzQ1NjZdIGZvciBhbg0KICAgU0RQIGF0dHJpYnV0ZS4NCiAgIG8gIGNvbnRhY3QgbmFt ZSwgZW1haWwgYWRkcmVzczogUkFJIEFyZWEgRGlyZWN0b3JzDQogICAgICA8cmFpLWFkc0B0b29s cy5pZXRmLm9yZz4NCiINCg0KVGhlIHNlY29uZCBjb21tZW50IGlzIGFib3V0IG51bWVyaWMgZm9y bWF0IHJlcHJlc2VudGF0aW9uIGZvciBNb1MgU2NvcmUgdmFsdWUuDQpQZXRlIHRoaW5rcyAiTW9T IHNjb3JlIG11bHRpcGx5IGJ5IDEwIiBpcyB1c2VkIHRvIHN1cHBvcnQgZmxvYXQtcG9pbnQgdmFs dWUgcmVwcmVzZW50YXRpb24uDQpzaW5jZSB3ZSBoYXZlIG51bWVyaWMgZm9ybWF0IHJlcHJlc2Vu dGF0aW9uIGZvciBNb1MgU2NvcmUgdmFsdWUsDQpOdW1lcmljIGZvcm1hdCBzdXBwb3J0cyBmbG9h dC1wb2ludCB2YWx1ZSByZXByZXNlbnRhdGlvbiwgdGhlcmVmb3JlIHdlIGRvbid0IG5lZWQNCk1v UyBzY29yZSBtdWx0aXBseSBieSAxMC4NCkFsYW4gd2lsbCBwcm92aWRlIGlucHV0IHRvIGFkZHJl c3MgdGhlIHNlY29uZCBjb21tZW50Lg0KV2Ugd2lsbCBpc3N1ZSBhbiB1cGRhdGUgd2hlbiBhdXRo b3JzIHJlYWNoIGFncmVlbWVudCBvbiBob3cgdG8gYWRkcmVzcyBQZXRlJ3MgdHdvIGNvbW1lbnRz Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRl ZCBMZW1vbiBbbWFpbHRvOnRlZC5sZW1vbkBub21pbnVtLmNvbV0gDQpTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDE0LCAyMDE0IDEyOjQ0IEFNDQpUbzogVGhlIElFU0cNCkNjOiB4cmJsb2NrLWNoYWly c0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xzLmll dGYub3JnDQpTdWJqZWN0OiBUZWQgTGVtb24ncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi14 cmJsb2NrLXJ0Y3AteHItcW9lLTE1OiAod2l0aCBDT01NRU5UKQ0KDQpUZWQgTGVtb24gaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXhyYmxv Y2stcnRjcC14ci1xb2UtMTU6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVm ZXIgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UvDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBZnRlciB0aGUgbW9zdCByZWNlbnQgdXBkYXRl IHRvIDQuMiwgdGhlIHRleHQgaXMgc3RpbGwgc2xpZ2h0bHkgYnJva2VuOg0KDQogIHVuZGVyc3Rh bmQgdGhlIGV4dGVuc2lvbiBTSE9VTEQgTk9UIGluY2x1ZGUgaXQgZnJvbSB0aGUgU0RQIGFuc3dl cg0KDQpJIGJlbGlldmUgdGhhdCB0aGlzIHNob3VsZCBiZSAiU0hPVUxEIE5PVCBpbmNsdWRlIGl0 IGluIHRoZSBTRFAgYW5zd2VyIg0KaW5zdGVhZC4gICBUaGUgc2FtZSBlcnJvciByZXBlYXRzIGlu IHRoZSBuZXh0IHBhcmFncmFwaC4NCg0KLS0tDQoNCkZvcm1lciBESVNDVVNTLCB3aGljaCBoYXMg YmVlbiBhZGRyZXNzZWQ6DQoNCkluIHNlY3Rpb24gNC4yLCB0aGlyZCBwYXJhZ3JhcGggKG5vdCBj b3VudGluZyBidWxsZXQgaXRlbXMgYWJvdmUgaXQpOg0KDQogICBTZWdtZW50IGV4dGVuc2lvbnMs IHdpdGggdGhlaXIgZGlyZWN0aW9ucywgTUFZIGJlIHNpZ25hbGVkIGZvciBhbg0KICAgImluYWN0 aXZlIiBzdHJlYW0uICBJdCBpcyBhbiBlcnJvciB0byB1c2UgYW4gZXh0ZW5zaW9uIGRpcmVjdGlv bg0KICAgaW5jb21wYXRpYmxlIHdpdGggdGhlIHN0cmVhbSBkaXJlY3Rpb24gKGUuZy4sIGEgInNl bmRvbmx5IiBhdHRyaWJ1dGUNCiAgIGZvciBhICJyZWN2b25seSIgc3RyZWFtKS4NCg0KSG93IGlz IHRoaXMgZXJyb3IgaGFuZGxlZD8gICBZb3UgYW4gYWRkcmVzcyB0aGlzIERJU0NVU1MgcG9pbnQg YnkgYWRkaW5nDQp0ZXh0IHRoYXQgc2F5cyBob3csIG9yIHBvaW50aW5nIG91dCB3aHkgaXQgaXNu J3QgYSBwcm9ibGVtLg0KDQpDb21tZW50cyB0aGF0IGhhdmUgYmVlbiBhZGRyZXNzZWQ6DQoNClBh Z2UgNiwgZmlyc3QgcGFyYWdyYXBoOg0KICAgbWVhc3VyZW1lbnQgdGVjaG5pcXVlcyBhbGxvd3Mg bXVjaCBsYXJnZSBzY2FsZSBtZWFzdXJlbWVudHMgdG8NCg0KVGhpcyBpcyBvYnZpb3VzbHkgYSB0 eXBvOyBjb3VsZCBiZSBtdWNoIGxhcmdlciBzY2FsZSBtZWFzdXJlbWVudHMgb3IgbXVjaA0KbGFy Z2Ugc2NhbGUgbWVhc3VyZW1lbnQuICAgTWlnaHQgd2FudCB0byBkaXNhbWJpZ3VhdGUgYmVmb3Jl IHRoZSBjb3B5ZWRpdA0KaGFwcGVucyB0byBhdm9pZCBtaXN1bmRlcnN0YW5kaW5ncy4NCg0KICAg ICAgSW4gdGhpcyBkb2N1bWVudCwgTU9TIE1ldHJpY3MgTUFZIGJlIHJlcG9ydGVkIGZvciBpbnRl cnZhbHMgb3INCiAgICAgIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIG1lZGlhIHN0cmVhbSAoY3Vt dWxhdGl2ZSkgaG93ZXZlciBpdA0KICAgICAgaXMgbm90IHJlY29tbWVuZGVkIHRoYXQgc2FtcGxl ZCB2YWx1ZXMgYXJlIHVzZWQuDQoNClNlY3Rpb24gMy4yLCBqdXN0IGFib3ZlIHRoZSBSZXNlcnZl ZCBoZWFkaW5nOg0KICAgICAgSW4gdGhpcyBkb2N1bWVudCwgTU9TIE1ldHJpY3MgTUFZIGJlIHJl cG9ydGVkIGZvciBpbnRlcnZhbHMgb3INCiAgICAgIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIG1l ZGlhIHN0cmVhbSAoY3VtdWxhdGl2ZSkgaG93ZXZlciBpdA0KICAgICAgaXMgbm90IHJlY29tbWVu ZGVkIHRoYXQgc2FtcGxlZCB2YWx1ZXMgYXJlIHVzZWQuDQoNCkl0IG1pZ2h0IGJlIGJldHRlciB0 byBmb3JiaWQgc2FtcGxlZCB2YWx1ZXMgaWYgdGhleSBhcmVuJ3QgdXNlZnVsLCBzbw0KdGhhdCBp bXBsZW1lbnRhdGlvbnMgZG9uJ3QgaGF2ZSB0byBoYW5kbGUgdGhlbS4gICBKdXN0IGEgc3VnZ2Vz dGlvbuKAlHlvdQ0Ka25vdyBiZXR0ZXIgdGhhbiBJLiAgIE5vIG5lZWQgdG8gZXhwbGFpbiBpZiB5 b3UgZGlzYWdyZWUuDQoNCg0K From nobody Sun Feb 23 04:59:06 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34261A040C for ; Sun, 23 Feb 2014 04:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 r_bC_fE63jyD for ; Sun, 23 Feb 2014 04:59:02 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 787DC1A0403 for ; Sun, 23 Feb 2014 04:59:02 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAGLvCVOHCzIm/2dsb2JhbABZgkIjITtXwF2BBhZ0gicBAQMSG14BDAkVViYBBBsah2MBDJc/hFKrTBMEjhAjg1yBFASfJINwh0eDLYIq X-IronPort-AV: E=Sophos; i="4.97,529,1389762000"; d="scan'208,217"; a="50684904" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Feb 2014 07:59:02 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 23 Feb 2014 07:45:57 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Sun, 23 Feb 2014 13:59:00 +0100 From: "Romascanu, Dan (Dan)" To: "xrblock@ietf.org" Thread-Topic: important information for the xrblock meeting in London Thread-Index: Ac8wlwSbQ+jScLfQS9uzUChYyh/1YA== Date: Sun, 23 Feb 2014 12:58:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E433732@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E433732AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/bmOwX_kk2qK4rnuzLLmpEhCaMHc Subject: [xrblock] important information for the xrblock meeting in London X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 23 Feb 2014 12:59:04 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E433732AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The preliminary agenda for the XRBLOCK meeting in London is available at ht= tps://datatracker.ietf.org/meeting/89/agenda/xrblock/. Submission deadline = for the final agenda is tomorrow Monday 2/14 - so please let us know if the= re are any changes or additions. We need two note takers for the minutes. Early volunteering would be highly= appreciated. Thanks and Regards, Shida and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E433732AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The preliminary agenda for the XRBLOCK meeting in Lo= ndon is available at https://datatracker.ietf.org/meeting/89/agenda/xrblock= /. Submission deadline for the final agenda is tomorrow Monday 2/14 –= so please let us know if there are any changes or additions.

 

We need two note takers for the minutes. Early volun= teering would be highly appreciated.

 

Thanks and Regards,

 

Shida and Dan

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E433732AZFFEXMB04globa_-- From nobody Sun Feb 23 09:33:41 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927411A0687 for ; Sun, 23 Feb 2014 09:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 BVAI2A314Zz8 for ; Sun, 23 Feb 2014 09:33:38 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A449C1A0674 for ; Sun, 23 Feb 2014 09:33:38 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id uy17so3078612igb.3 for ; Sun, 23 Feb 2014 09:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=URC64XO4GyLnINc9LruFnBTMDPhE2VPT1Gz+p1MVGxs=; b=sAnRFkATVdOsFuqW8epm/nUVlD13X9l2gG+Aq8O7vmJlSKfnhPAAdiTYTaBOKxoAGk aSPl2G43zvHkeXqg2OSTFT3MSRWd0RyslUxoIO+YUvaNw7ukh/Ox4fkJ2Pg4dNjRYljZ bQcgClg00PZVqnFWtSaiCN16tGuuMlViNnehli3ZNNfa5p3MdupUi3YBuAlgGs/hFVbU YnuYZcTsmOCGm1a4lip8LlM6k9HyRr6niAts3ZVGDYhzAwHWiIzABsutrtZENtrbkh6m OZlZX6oKLX8ZxTRDpE16CC3yuWKEKhexrWx9dEMTo8SAR+W6cvlrBjBzub0vpoZLuFSv aGEQ== X-Received: by 10.42.16.199 with SMTP id q7mr11492254ica.16.1393176818340; Sun, 23 Feb 2014 09:33:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.128.195 with HTTP; Sun, 23 Feb 2014 09:33:18 -0800 (PST) From: Varun Singh Date: Sun, 23 Feb 2014 19:33:18 +0200 Message-ID: To: "xrblock@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/OoQPGSYLYwg1G-oB8ZHxo91NkL8 Subject: [xrblock] FW: New Version Notification for draft-singh-xrblock-webrtc-additional-stats-02.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 23 Feb 2014 17:33:40 -0000 Hi all, We updated the document based on the feedback from Vancouver. - Added burst-loss metric Cheers, Varun --- A new version of I-D, draft-singh-xrblock-webrtc-additional-stats-02.txt has been successfully submitted by Varun Singh and posted to the IETF repository. Name: draft-singh-xrblock-webrtc-additional-stats Revision: 02 Title: Additional RTP Control Protocol (RTCP) Extended Report (XR) Metrics for WebRTC Statistics API Document date: 2014-02-14 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-singh-xrblock-webrtc-additional-stats-02.txt Status: https://datatracker.ietf.org/doc/draft-singh-xrblock-webrtc-additional-stats/ Htmlized: http://tools.ietf.org/html/draft-singh-xrblock-webrtc-additional-stats-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-singh-xrblock-webrtc-additional-stats-02 Abstract: This document describes a list of additional identifiers used in WebRTC's Javascript statistics API. These identifiers are a set of RTCP XR metrics related to the transport of multimedia flows. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- http://www.netlab.tkk.fi/~varun/ From nobody Tue Feb 25 18:39:33 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26F1A0304 for ; Tue, 25 Feb 2014 18:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 Z_A2bJC6S8Zy for ; Tue, 25 Feb 2014 18:39:31 -0800 (PST) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C21A0341 for ; Tue, 25 Feb 2014 18:39:30 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta06.emeryville.ca.mail.comcast.net with comcast id WpFl1n0090QkzPwA6qfW1s; Wed, 26 Feb 2014 02:39:30 +0000 Received: from mail-yh0-f46.google.com ([209.85.213.46]) by omta02.emeryville.ca.mail.comcast.net with comcast id WqdV1n00L10dfBD8NqdWfv; Wed, 26 Feb 2014 02:37:30 +0000 Received: by mail-yh0-f46.google.com with SMTP id v1so316612yhn.33 for ; Tue, 25 Feb 2014 18:37:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N9ux+APgihWtUKa1SplLMUFCOheMzl0ujNP+zGMmgi8=; b=P0df3dG9wWj4z5rEG/3Jh0srUSGu3F31cv7OfP66WQQiAymyHiHOll1ADqRWfHxJgn cJZe1hSpcjpetsPl/nxoo0VkyNlsRHvkMIdDsVoadxzDgVLblQCfsglU0ryclxUMjl5H Y4Asg/m7JqnnESEeZHVkmUkU7yvlo8JStyUgaxz1o6q5dAEGiUe7pM0NGwEvs4hjeJqu DGjmmnQi7K1UuYvxALz0+lFwqwHcO08qcsUvjAdMoYVs4ZCPi8wb+gu7J1nXbgsQ2lKs W3P1hr7MZw1PH1w8R/TnCnt9gFFPsQT4kbPloIOWpM/7c6m7HdSp5JLz4yxXoOUZP0W3 L1LA== MIME-Version: 1.0 X-Received: by 10.236.151.198 with SMTP id b46mr4146620yhk.3.1393382249749; Tue, 25 Feb 2014 18:37:29 -0800 (PST) Received: by 10.170.216.197 with HTTP; Tue, 25 Feb 2014 18:37:29 -0800 (PST) In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB4591B6A4@nkgeml501-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB4591B6A4@nkgeml501-mbs.china.huawei.com> Date: Tue, 25 Feb 2014 19:37:29 -0700 Message-ID: From: Kevin Gross To: "Huangyihong (Rachel)" Content-Type: multipart/alternative; boundary=20cf301cc5aa0862bf04f34616ad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393382370; bh=N9ux+APgihWtUKa1SplLMUFCOheMzl0ujNP+zGMmgi8=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=CkjoCjTQf1Tw9TU/7SuiodX9gZQ8icpGQruLXUg5WA0sGRmMnkcTrG5mxywnOCz0B Q5qztmiFcZKKJKDljr4KhERngZxkhhXI/cfPMBnmuLRX02u0IXFwaCaJlNBT79Nf9S m5R/PaKJM3Y1rskkFbsZ2mW6UisrwpVk4aPV8L0bdUZJHDoGFU/7taOmlpw5XFCiBT 3qD4KC2KYvEQTbCbw1Kbyjcz4GqzOyQxHa139vvCXIjrnWGFfDrBMo2W+2F67Y96nr jXmzHbCf1F1iHEJLPo5SQRunJaZoLu78TjtGdsY4TUAF/nxHn2dbJHbPJPr/iO/HC5 SNwVhl4yAXxGQ== Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/m7Ub9NpWOeSVKGkX-_HVhEA6beg Cc: "Jayaprabhu Nadarajan -X \(janadara - HCL TECHNOLOGIES LIMITED at Cisco\)" , "xrblock@ietf.org" Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 02:39:33 -0000 --20cf301cc5aa0862bf04f34616ad Content-Type: text/plain; charset=ISO-8859-1 I can see the potential utility of this but I'd like to see it explained in the introduction. All we have now is "As the number of IPTV deployments continue to increase, it becomes necessary for the operator to collect various information on the streams that are being delivered to the user." Please add definitions of what it means to be recording and what it means to be watching. The former is pretty obvious but the latter less so. A couple technical comments: Are you sure we need to worry about rollover of these counters? 2^31 seconds is 68 years. Consider moving the V and R flags into the "rsvd" field so that the "time watched" and "time recorded" fields can be interpreted as 32-bit numbers without fuss. Kevin Gross - AVA Networks On Wed, Jan 15, 2014 at 7:56 PM, Huangyihong (Rachel) < rachel.huang@huawei.com> wrote: > Hi Jp, > > > > Like RTCP SR/RR, RTCP XR is designed to covey the detailed QoS/QoE > information for RTP, which could reflect the problems in RTP transmission. > So the metrics defined in RTCP XR are usually closely related to RTP > stream, and are standard and universal metrics. In this draft, the viewship > metrics seem not so closely related to RTP streams, rather, they are > produced by actions of users. IMHO, this kind of information could be > conveyed by other ways, such as signaling. So why RTCP XR? > > > > Best regards, > > Rachel > > > > *From:* xrblock [mailto:xrblock-bounces@ietf.org] *On Behalf Of *Jayaprabhu > Nadarajan -X (janadara - HCL TECHNOLOGIES LIMITED at Cisco) > *Sent:* Wednesday, January 15, 2014 8:18 PM > *To:* xrblock@ietf.org > *Subject:* Re: [xrblock] Mail regarding > draft-jayaprabhu-xrblock-rtcp-xr-viewership > > > > Dear All, > > > > I have submitted an internet draft, > draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt > > > > URL: *http://www.ietf.org/internet-drafts/draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt > * > > > > > > Is there any comments on the contents of the draft or any queries related > to the scope ? > > > > Regards, > > Jp > > > > *From:* Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LIMITED at > Cisco) > *Sent:* Wednesday, December 18, 2013 2:36 PM > *To:* 'xrblock@ietf.org' > *Subject:* Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership > > > > Dear All, > > > > I have submitted an internet draft, > draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt > > > > URL: > http://www.ietf.org/internet-drafts/draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt > > > > Could you please provide your comments/opinions regarding this I-D. > Following is the brief introduction about this block > > > > This document defines a new report block type within the framework of RTP > Control Protocol (RTCP) Extended Reports (XRs) that allows the reporting of > the usage pattern of a receiver in a RTP session. As the number of IPTV > deployments continue to increase, it becomes necessary for the operator to > collect various information on the streams that are being delivered to the > user. This document defines a new report block type for the Extended Report > (XR) packet type of the RTP Control Protocol (RTCP) which allows IPTV > clients to report to a server on the usage pattern of the stream that is > being delivered to them. > > > > Thanks > > > > Regards, > > Jayaprabhu > > > > > > > > > > > > > > > > > > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock > > --20cf301cc5aa0862bf04f34616ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can see the potential utility of this but I'd like t= o see it explained in the introduction. All we have now is "As the number of IPTV deploymen= ts continue to increase, it becomes necessary for the operator to collect various informa= tion on the s= treams that are being delivered to the user."

Please add definitions of what it means to be recording and = what it means to be watching. The former is pretty obvious but the latter l= ess so.

A c= ouple technical comments:

Are you sure we need to worry about rollover of thes= e counters? 2^31 seconds is 68 years.

Consider= moving the V and R flags into the "rsvd" field so that the "= ;time watched" and "time recorded" fields can be interpreted= as 32-bit numbers without fuss.


Kevin Gross - AVA Networks


On Wed, Jan 15, 2014 at 7:56 PM, Huangyi= hong (Rachel) <rachel.huang@huawei.com> wrote:

Hi Jp,

=A0

Like RTCP SR/RR, RTCP = XR is designed to covey the detailed QoS/QoE information for RTP, which cou= ld reflect the problems in RTP transmission. So the metrics defined in RTCP= XR are usually closely related to RTP stream, and are standard and universal metrics. In this draft, the viewshi= p metrics seem not so closely related to RTP streams, rather, they are prod= uced by actions of users. IMHO, this kind of information could be conveyed = by other ways, such as signaling. So why RTCP XR?

=A0

Best regards,

Rachel

=A0

From: xrblock = [mailto:xrblo= ck-bounces@ietf.org] On Behalf Of Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LI= MITED at Cisco)
Sent: Wednesday, January 15, 2014 8:18 PM
To: xrblock@ie= tf.org
Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-= xr-viewership

=A0

Dear All,

=A0

I have submitted an in= ternet draft, draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt

=A0

URL: =A0 =A0 =A0 =A0 = =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-jayaprabhu-xrblock-rtcp= -xr-viewership-00.txt

=A0

=A0

Is there any comments = on the contents of the draft =A0or any queries related to the scope ?

=A0

Regards,=

Jp

=A0

From: Jayaprab= hu Nadarajan -X (janadara - HCL TECHNOLOGIES LIMITED at Cisco)
Sent: Wednesday, December 18, 2013 2:36 PM
To: 'xrblo= ck@ietf.org'
Subject: Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership<= u>

=A0

Dear All,

=A0

I have submitted an internet draft, draft-jayaprabhu= -xrblock-rtcp-xr-viewership-00.txt

=A0=

URL: =A0 = =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.org/inte= rnet-drafts/draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt

=A0

Could you please provide your comments/opinions rega= rding this I-D. Following is the brief introduction about this block=

=A0

This document defines a new report block type within= the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) that a= llows the reporting of the usage pattern of a receiver in a RTP session. = =A0As the number of IPTV deployments continue to increase, it becomes necessary = for the operator to collect various information on the streams that are bei= ng delivered to the user. This document defines a new report block type for= the Extended Report (XR) packet type of the=A0 RTP Control Protocol (RTCP) which allows IPTV clients to re= port to a server on the usage pattern of the stream that is being delivered= to them.

=A0

Thanks

=A0

Regards,

Jayaprabhu

=A0

=A0

=A0

=A0

=A0

=A0

=A0=A0

=A0


_______________________________________________
xrblock mailing list
xrblock@ietf.org
https://www.ietf.org/mailman/listinfo/xrblock


--20cf301cc5aa0862bf04f34616ad-- From nobody Wed Feb 26 06:56:59 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0C21A0641; Wed, 26 Feb 2014 06:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 lPfzVjNVAV1P; Wed, 26 Feb 2014 06:56:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 717811A0353; Wed, 26 Feb 2014 06:56:51 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226145651.23103.30879.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 06:56:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/0XTfK6P02iO2ckHC9VzS8TEHW_M Cc: xrblock@ietf.org Subject: [xrblock] I-D ACTION:draft-ietf-xrblock-rtcp-xr-synchronization-09.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 14:56:54 -0000 --NextPart 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 Synchronization Delay and Offset Metrics Reporting Author(s) : H. Asaeda, et al Filename : draft-ietf-xrblock-rtcp-xr-synchronization Pages : 15 Date : 2014-02-26 This document defines two RTP Control Protocol (RTCP) Extended Report (XR) Blocks that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-synchronization-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xrblock-rtcp-xr-synchronization"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-26065651.I-D@ietf.org> --NextPart-- From nobody Wed Feb 26 07:13:55 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08F1A0670; Wed, 26 Feb 2014 07:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 NL4Z4NNJlQP9; Wed, 26 Feb 2014 07:13:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3900A1A0424; Wed, 26 Feb 2014 07:13:48 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226151348.7594.44741.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 07:13:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/wiSGkr9ig8Q5Mlh65mUpqAL9p1Q Cc: xrblock@ietf.org Subject: [xrblock] I-D ACTION:draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 15:13:50 -0000 --NextPart 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) for Bytes Discarded Metric Author(s) : V. Singh, et al Filename : draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric Pages : 12 Date : 2014-02-26 The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-26071348.I-D@ietf.org> --NextPart-- From nobody Wed Feb 26 07:27:11 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB4A1A0677; Wed, 26 Feb 2014 07:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 lpzhW0Xw7Uk2; Wed, 26 Feb 2014 07:26:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5B1A065A; Wed, 26 Feb 2014 07:26:56 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226152656.7555.84521.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 07:26:56 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/d4tf2eCM7RTSP6WO2wCwb_5HfHw Cc: xrblock@ietf.org Subject: [xrblock] I-D ACTION:draft-ietf-xrblock-rtcp-xr-qoe-16.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 15:27:00 -0000 --NextPart 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 MOS Metric Reporting Author(s) : A. Clark, et al Filename : draft-ietf-xrblock-rtcp-xr-qoe Pages : 26 Date : 2014-02-26 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 mean opinion score (MOS) Metrics for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-qoe-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xrblock-rtcp-xr-qoe"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-26072656.I-D@ietf.org> --NextPart-- From nobody Wed Feb 26 08:01:13 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8FB1A0231 for ; Wed, 26 Feb 2014 08:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ek_4KeOjw-wR for ; Wed, 26 Feb 2014 08:01:03 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9652A1A066E for ; Wed, 26 Feb 2014 08:01:03 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id uy17so2430285igb.3 for ; Wed, 26 Feb 2014 08:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=OrT3HqtqVKBIFxZ9ciB+IykZkXeZsReZ1xw1NSaT9mU=; b=EfM0TfuV6d3Z3al4+4a6PisP0PN0JECT6M21+lioT/eQbI4u5LrkND3bst5VBDD0df JXOp2y86CaGzM7MxOTh2Cn7XLhd1hEYubpqxULiAafyLHWnpRrP627KHVAgSY90OubS+ O00OsOoadY0ttF+gFfjEYisQdJdTOjbzu/L2WvBc2LIvM+WdOVmFmYuMcpRSJUsbnSj8 x+//biv0vQhGId3CsrvhYd+lwO6v7C+oOj/7qRRB6a5ERW3Oj2ZWF3AS9EiLu+skkeF2 vv9RpTshWYQ20nV/bE7j7t3nA0wXfAS75h3ydrPwkx5dHuoA/LCrohKWdswf0451p0yz ouuw== X-Received: by 10.42.65.73 with SMTP id k9mr202846ici.44.1393430462347; Wed, 26 Feb 2014 08:01:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.128.195 with HTTP; Wed, 26 Feb 2014 08:00:41 -0800 (PST) In-Reply-To: <20140226151348.7594.44741.idtracker@ietfa.amsl.com> References: <20140226151348.7594.44741.idtracker@ietfa.amsl.com> From: Varun Singh Date: Wed, 26 Feb 2014 18:00:41 +0200 Message-ID: To: "xrblock@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/T2F3f1I_IGN8Xt6kdefND01Ohtk Subject: Re: [xrblock] I-D ACTION:draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 16:01:08 -0000 Hi, An updated draft was posted based on the comments received from the IESG review. Diff link: http://tools.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02 The updates are: - update refs to RFC7097 instead of discard-rle - IANA contact information changed to RAI ADs - minor language nits - Added information on use of discarded packets and discarded bytes (Section 4.1) When reporting several metrics in a single RTCP packet, the reporting intervals for the report blocks are synchronized, therefore the media receiver may choose to additionally send the Discarded Packets [RFC7002] or Discard RLE [RFC7097] Report Block to assist the media sender in correlating the bytes discarded to the packets discarded in that particular interval. - Examples of possible attacks added in the security descriptions section. (Section 6) [see diff url] Cheers, Varun On Wed, Feb 26, 2014 at 5:13 PM, wrote: > 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) for Bytes Discarded Metric > Author(s) : V. Singh, et al > Filename : draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric > Pages : 12 > Date : 2014-02-26 > > The RTP Control Protocol (RTCP) is used in conjunction with the Real- > time Transport Protocol (RTP) in to provide a variety of short-term > and long-term reception statistics. The available reporting may > include aggregate information across longer periods of time as well > as individual packet reporting. This document specifies a report > computing the bytes discarded from the de-jitter buffer after > successful reception. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock > -- http://www.netlab.tkk.fi/~varun/ From nobody Wed Feb 26 08:56:47 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6763B1A0680; Wed, 26 Feb 2014 08:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 xM51TQGs94-o; Wed, 26 Feb 2014 08:56:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4907F1A0161; Wed, 26 Feb 2014 08:56:34 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226165634.14008.26126.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 08:56:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/wmOT_GnZaTNcdfRtYx549IJAY-U Cc: xrblock chair , xrblock mailing list , RFC Editor Subject: [xrblock] Protocol Action: 'RTP Control Protocol (RTCP) Extended Report (XR) for Bytes Discarded Metric' to Proposed Standard (draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt) X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 16:56:42 -0000 The IESG has approved the following document: - 'RTP Control Protocol (RTCP) Extended Report (XR) for Bytes Discarded Metric' (draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt) as Proposed Standard This document is the product of the Metric Blocks for use with RTCP's Extended Report Framework Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric/ Technical Summary This draft defines a new block type to augment those defined in [RFC3611] for use in a range of RTP applications. The new block type supports the report computing the bytes discarded from the de-jitter buffer after successful reception. Working Group Summary There were several points of debate within the working group; however, none were particularly rough and authors and commentators came up with the text that resolves any issues thus consensus was achieved in all cases. Document Quality This document has been reviewed by numerous people within XRBLOCK through three rounds of WGLCs (Including two that took place when it was part of RFC7097) the document resolved any outstanding issues. The document has been reviewed by SDP directorate post WGLC for SDP extensions defined, any issues raised were resolved. The document has been reviewed by PM-DIR and the existence of this document addresses the issue raised (separating this document from RFC7097). Personnel Shida Schubert is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director. From nobody Wed Feb 26 09:19:59 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0246F1A00D9; Wed, 26 Feb 2014 09:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Qz3oBqNHSUHt; Wed, 26 Feb 2014 09:19:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B06721A070F; Wed, 26 Feb 2014 09:19:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226171940.26026.35710.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 09:19:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/ES3vABn-vkvM4DO3CnnmUZVbOoQ Cc: xrblock chair , xrblock mailing list , RFC Editor Subject: [xrblock] Protocol Action: 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting' to Proposed Standard (draft-ietf-xrblock-rtcp-xr-synchronization-09.txt) X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 17:19:51 -0000 The IESG has approved the following document: - 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting' (draft-ietf-xrblock-rtcp-xr-synchronization-09.txt) as Proposed Standard This document is the product of the Metric Blocks for use with RTCP's Extended Report Framework Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-synchronization/ Technical Summary This draft defines a new block type to augment those defined in [RFC3611] for use in a range of RTP applications. The new block type supports the report computing the bytes discarded from the de-jitter buffer after successful reception. Working Group Summary There were several points of debate within the working group; however, none were particularly rough and authors and commentators came up with the text that resolves any issues thus consensus was achieved in all cases. Document Quality This document has been reviewed by numerous people within XRBLOCK through two rounds of WGLCs, the document resolved any outstanding issues. The document has been reviewed by SDP directorate post WGLC for SDP extensions defined, any issues raised were resolved. The document has been reviewed by PM directorate post WGLC and any issues raised were resolved. Personnel Shida Schubert is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director. From nobody Wed Feb 26 18:43:26 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8871A039A for ; Wed, 26 Feb 2014 18:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 g1EfdFMQtV8M for ; Wed, 26 Feb 2014 18:43:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8A01A072F for ; Wed, 26 Feb 2014 18:43:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBO20066; Thu, 27 Feb 2014 02:43:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Feb 2014 02:42:53 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Feb 2014 02:43:04 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 27 Feb 2014 10:42:52 +0800 From: Qin Wu To: Kevin Gross , "Huangyihong (Rachel)" Thread-Topic: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership Thread-Index: AQHPMpv+AVOfKTlZo06lcIxCx/KBp5rIZL9A Date: Thu, 27 Feb 2014 02:42:52 +0000 Message-ID: References: <51E6A56BD6A85142B9D172C87FC3ABBB4591B6A4@nkgeml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA844FEC5Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/fjLk7EsMUmLVXCzQzFt2wtNofaw Cc: "Jayaprabhu Nadarajan -X \(janadara - HCL TECHNOLOGIES LIMITED at Cisco\)" , "xrblock@ietf.org" Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 27 Feb 2014 02:43:20 -0000 --_000_B8F9A780D330094D99AF023C5877DABA844FEC5Fnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding what is recorded and what is watched, It will be great the author= of draft-jayaprabhu can clarify what use cases will look like? How these use cases related to SIP-Based Media Recording use cases defined = in section-4 of rfc6341? Regards! -Qin From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Kevin Gross Sent: Wednesday, February 26, 2014 10:37 AM To: Huangyihong (Rachel) Cc: Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LIMITED at Cisco);= xrblock@ietf.org Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-view= ership I can see the potential utility of this but I'd like to see it explained in= the introduction. All we have now is "As the number of IPTV deployments co= ntinue to increase, it becomes necessary for the operator to collect variou= s information on the streams that are being delivered to the user." Please add definitions of what it means to be recording and what it means t= o be watching. The former is pretty obvious but the latter less so. A couple technical comments: Are you sure we need to worry about rollover of these counters? 2^31 second= s is 68 years. Consider moving the V and R flags into the "rsvd" field so that the "time w= atched" and "time recorded" fields can be interpreted as 32-bit numbers wit= hout fuss. Kevin Gross - AVA Networks On Wed, Jan 15, 2014 at 7:56 PM, Huangyihong (Rachel) > wrote: Hi Jp, Like RTCP SR/RR, RTCP XR is designed to covey the detailed QoS/QoE informat= ion for RTP, which could reflect the problems in RTP transmission. So the m= etrics defined in RTCP XR are usually closely related to RTP stream, and ar= e standard and universal metrics. In this draft, the viewship metrics seem = not so closely related to RTP streams, rather, they are produced by actions= of users. IMHO, this kind of information could be conveyed by other ways, = such as signaling. So why RTCP XR? Best regards, Rachel From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LIM= ITED at Cisco) Sent: Wednesday, January 15, 2014 8:18 PM To: xrblock@ietf.org Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-view= ership Dear All, I have submitted an internet draft, draft-jayaprabhu-xrblock-rtcp-xr-viewer= ship-00.txt URL: http://www.ietf.org/internet-drafts/draft-jayaprabhu-xrblo= ck-rtcp-xr-viewership-00.txt Is there any comments on the contents of the draft or any queries related = to the scope ? Regards, Jp From: Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LIMITED at Cisco= ) Sent: Wednesday, December 18, 2013 2:36 PM To: 'xrblock@ietf.org' Subject: Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership Dear All, I have submitted an internet draft, draft-jayaprabhu-xrblock-rtcp-xr-viewer= ship-00.txt URL: http://www.ietf.org/internet-drafts/draft-jayaprabhu-xrblo= ck-rtcp-xr-viewership-00.txt Could you please provide your comments/opinions regarding this I-D. Followi= ng is the brief introduction about this block This document defines a new report block type within the framework of RTP C= ontrol Protocol (RTCP) Extended Reports (XRs) that allows the reporting of = the usage pattern of a receiver in a RTP session. As the number of IPTV de= ployments continue to increase, it becomes necessary for the operator to co= llect various information on the streams that are being delivered to the us= er. This document defines a new report block type for the Extended Report (= XR) packet type of the RTP Control Protocol (RTCP) which allows IPTV clien= ts to report to a server on the usage pattern of the stream that is being d= elivered to them. Thanks Regards, Jayaprabhu _______________________________________________ xrblock mailing list xrblock@ietf.org https://www.ietf.org/mailman/listinfo/xrblock --_000_B8F9A780D330094D99AF023C5877DABA844FEC5Fnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding what is recorde= d and what is watched, It will be great the author of draft-jayaprabhu can = clarify what use cases will look like?

How these use cases relat= ed to SIP-Based Media Recording use cases defined in section-4 of rfc6341?=

 <= /p>

Regards!

-Qin

 <= /p>

From: xrblock = [mailto:xrblock-bounces@ietf.org] On Behalf Of Kevin Gross
Sent: Wednesday, February 26, 2014 10:37 AM
To: Huangyihong (Rachel)
Cc: Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LIMITED at = Cisco); xrblock@ietf.org
Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-= xr-viewership

 

I can see the potential utility of this but I'd like= to see it explained in the introduction. All we have now is "As the number of IPTV deployments continue to increase,= it becomes necessary for the operator to collect various information on the streams that are being delivered to the= user."

 

Please add definitions of what it means to be record= ing and what it means to be watching. The former is pretty obvious but the = latter less so.

 

A couple technical comme= nts:

 

Are you sure we need to = worry about rollover of these counters? 2^31 seconds is 68 years.

 

Consider moving the V an= d R flags into the "rsvd" field so that the "time watched&qu= ot; and "time recorded" fields can be interpreted as 32-bit numbe= rs without fuss.

 

 

Kevin Gross - AVA Networks

 

On Wed, Jan 15, 2014 at 7:56 PM, Huangyihong (Rachel= ) <rachel.h= uang@huawei.com> wrote:

Hi Jp,

 

Like RTCP SR/RR, RTCP XR is designed= to covey the detailed QoS/QoE information for RTP, which could reflect the= problems in RTP transmission. So the metrics defined in RTCP XR are usually closely related to RTP stream, and = are standard and universal metrics. In this draft, the viewship metrics see= m not so closely related to RTP streams, rather, they are produced by actio= ns of users. IMHO, this kind of information could be conveyed by other ways, such as signaling. So why RTC= P XR?

 

Best regards,

Rachel

 

From: xrblock [mailto:xrblock-bounces@iet= f.org] On Behalf Of Jayaprabhu Nadarajan -X (janadara - HCL TECHNOLOGIES LI= MITED at Cisco)
Sent: Wednesday, January 15, 2014 8:18 PM
To: xrblock@ie= tf.org
Subject: Re: [xrblock] Mail regarding draft-jayaprabhu-xrblock-rtcp-= xr-viewership

 

Dear All,

 

I have submitted an internet draft, = draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt

 

URL:         &nb= sp;   http://www.ietf.org/internet-drafts/draft-jayaprabhu-xrbloc= k-rtcp-xr-viewership-00.txt

 

 

Is there any comments on the content= s of the draft  or any queries related to the scope ?

 

Regards,

Jp

 

From: Jayaprabhu Nadarajan -= X (janadara - HCL TECHNOLOGIES LIMITED at Cisco)
Sent: Wednesday, December 18, 2013 2:36 PM
To: 'xrblock@i= etf.org'
Subject: Mail regarding draft-jayaprabhu-xrblock-rtcp-xr-viewership<= /span>

 

Dear All,

 

I have submitted an internet draft, draft-jayaprabhu-xrblock-rtcp-= xr-viewership-00.txt

 =

URL:      = ;       http://www.ietf.org/internet-dr= afts/draft-jayaprabhu-xrblock-rtcp-xr-viewership-00.txt

 

Could you please provide your comments/opinions regarding this I-D= . Following is the brief introduction about this block

 

This document defines a new report block type within the framework= of RTP Control Protocol (RTCP) Extended Reports (XRs) that allows the repo= rting of the usage pattern of a receiver in a RTP session.  As the number of IPTV deployments continue to incr= ease, it becomes necessary for the operator to collect various information = on the streams that are being delivered to the user. This document defines = a new report block type for the Extended Report (XR) packet type of the  RTP Control Protocol (RTCP) which all= ows IPTV clients to report to a server on the usage pattern of the stream t= hat is being delivered to them.

 

Thanks

 

Regards,

Jayaprabhu

 

 

 

 

 

 

  

 


_______________________________________________
xrblock mailing list
xrblock@ietf.org
https://www.ietf.org/mailman/listinfo/xrblock

 

--_000_B8F9A780D330094D99AF023C5877DABA844FEC5Fnkgeml501mbschi_-- From nobody Thu Feb 27 03:47:19 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91EC1A0278; Thu, 27 Feb 2014 03:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 qeDEhf0dkaO3; Thu, 27 Feb 2014 03:47:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96A1A0221; Thu, 27 Feb 2014 03:47:13 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140227114713.23956.49630.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2014 03:47:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/rBgX31gskfKWCZ4GL9V4X5yTMdQ Cc: xrblock@ietf.org Subject: [xrblock] I-D ACTION:draft-ietf-xrblock-rtcp-xr-qoe-17.txt X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 27 Feb 2014 11:47:19 -0000 --NextPart 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 MOS Metric Reporting Author(s) : A. Clark, et al Filename : draft-ietf-xrblock-rtcp-xr-qoe Pages : 26 Date : 2014-02-27 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 mean opinion score (MOS) Metrics for use in a range of RTP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-qoe-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xrblock-rtcp-xr-qoe"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-27034713.I-D@ietf.org> --NextPart-- From nobody Thu Feb 27 04:12:51 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E921A0154; Thu, 27 Feb 2014 04:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 vmTUkNkc7Kj6; Thu, 27 Feb 2014 04:12:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6FE1A0267; Thu, 27 Feb 2014 04:12:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140227121246.8883.30861.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2014 04:12:46 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/DF7foiRfJH0pMTvhB11Rtjeij2w Cc: xrblock chair , xrblock mailing list , RFC Editor Subject: [xrblock] Protocol Action: 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric Reporting' to Proposed Standard (draft-ietf-xrblock-rtcp-xr-qoe-17.txt) X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 27 Feb 2014 12:12:49 -0000 The IESG has approved the following document: - 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric Reporting' (draft-ietf-xrblock-rtcp-xr-qoe-17.txt) as Proposed Standard This document is the product of the Metric Blocks for use with RTCP's Extended Report Framework Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/ Technical Summary 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 MOS Metrics for use in a range of RTP applications. Working Group Summary The WG reviewed carefully the document several times and there is good support behind it. Document Quality Two vendors indicated that they have similar functionality in their code and intentions to implement the standard block when approved. There was one important change to notice which resulted from the SDP Expert Review which led to the change of the title of the document from QoE to MOS Metric reporting, which defines better the scope of the document. Personnel Dan Romascanu is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director. From nobody Thu Feb 27 04:16:21 2014 Return-Path: X-Original-To: xrblock@ietfa.amsl.com Delivered-To: xrblock@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307791A0267 for ; Thu, 27 Feb 2014 04:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 E5xgEpKQucvN for ; Thu, 27 Feb 2014 04:16:18 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 572651A025F for ; Thu, 27 Feb 2014 04:16:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACIsD1OHCzIm/2dsb2JhbABagmUhO1fAOE+BGhZ0giUBAQEBAwEBAQ8oMQMXBAIBCA0EBAEBCxQFBAcnCxQJCAIEEwgah1cBDJ50q1cXjiM4BoMdgRQEmWqFQIs3gW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,554,1389762000"; d="scan'208";a="51177927" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Feb 2014 07:16:16 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 27 Feb 2014 07:03:03 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 07:16:15 -0500 From: "Romascanu, Dan (Dan)" To: "xrblock@ietf.org" Thread-Topic: [xrblock] Protocol Action: 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric Reporting' to Proposed Standard (draft-ietf-xrblock-rtcp-xr-qoe-17.txt) Thread-Index: AQHPM7VBejOADaR3hUSoLd2tqoti6ZrJA6hw Date: Thu, 27 Feb 2014 12:16:14 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E43B9E5@AZ-FFEXMB04.global.avaya.com> References: <20140227121246.8883.30861.idtracker@ietfa.amsl.com> In-Reply-To: <20140227121246.8883.30861.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/uxo_W2qHhhIVKx7vabLZCpgwrvk Subject: Re: [xrblock] Protocol Action: 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric Reporting' to Proposed Standard (draft-ietf-xrblock-rtcp-xr-qoe-17.txt) X-BeenThere: xrblock@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 27 Feb 2014 12:16:20 -0000 Special thanks to the authors and congratulations to the whole WG for the a= pproval of this document.=20 Regards, Dan > -----Original Message----- > From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of The IESG > Sent: Thursday, February 27, 2014 2:13 PM > To: IETF-Announce > Cc: xrblock chair; xrblock mailing list; RFC Editor > Subject: [xrblock] Protocol Action: 'RTP Control Protocol (RTCP) Extended > Report (XR) Blocks for MOS Metric Reporting' to Proposed Standard (draft- > ietf-xrblock-rtcp-xr-qoe-17.txt) >=20 > The IESG has approved the following document: > - 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric > Reporting' > (draft-ietf-xrblock-rtcp-xr-qoe-17.txt) as Proposed Standard >=20 > This document is the product of the Metric Blocks for use with RTCP's > Extended Report Framework Working Group. >=20 > The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > 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 MOS Metrics for use in a range of RTP > applications. >=20 > Working Group Summary >=20 > The WG reviewed carefully the document several times and there is good > support behind it. >=20 > Document Quality >=20 > Two vendors indicated that they have similar functionality in their code = and > intentions to implement the standard block when approved. > There was one important change to notice which resulted from the SDP > Expert Review which led to the change of the title of the document from Q= oE > to MOS Metric reporting, which defines better the scope of the document. >=20 > Personnel >=20 > Dan Romascanu is the Document Shepherd. Gonzalo Camarillo is the > Responsible Area Director. >=20 > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock