Subject: [xrblock] PM Dir review of Discard RLE Draft

From: Varun Singh <[email-masked]>
Date: Sun, 21 Jul 2013 12:00:16 +0300

Discard RLE [1] was recently reviewed by PM Dir [2], some issues were
raised, which require input from the WG.

PM Dir:
The main concern is that the draft contains two reporting blocks:
Discard RLE and Bytes discarded. First, the current title just mentions
the Discard RLE and not discarded bytes. Second, the discarded bytes
may be a better fit with discarded packets draft.

The question in this case is, which choice does the WG prefer?
1. update the title of the discarded RLE draft and add the appropriate
RFC6390 templates.

2. Merge the discarded bytes with the discarded packets, however,
the discarded packets draft is in RFC editor queue.

3. Make a new draft for discarded bytes?

Cheers,
Varun

[1]
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06
[2] http://www.ietf.org/mail-archive/web/pm-dir/current/msg00571.html

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Jul 2013 10:30:12 +0000

Regarding the second approach:
It seems Byte discarded block in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06doesn't need to be sent with measurement identity block [RFC6776], it can be sent with RTCP Receiver Report (RR).
While packet discard count block in the draft-ietf-xrblock-rtcp-xr-discard-15 MUST be sent with measurement identity block. If not, packet discard count block
MUST be discarded.

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of Varun Singh
Sent: Sunday, July 21, 2013 5:00 PM
To: [email-masked]
Subject: [xrblock] PM Dir review of Discard RLE Draft

Discard RLE [1] was recently reviewed by PM Dir [2], some issues were raised, which require input from the WG.

PM Dir:

Cheers,
Varun

[1] http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06
[2] http://www.ietf.org/mail-archive/web/pm-dir/current/msg00571.html

---

From: Varun Singh <[email-masked]>
Date: Mon, 22 Jul 2013 23:58:42 +0300

Hi Qin,

In the media sender section the draft, it allow both forms of reporting:

   The sender SHOULD accept the Bytes Discarded Report Block only if it
   is received in a compound RTCP receiver report or if it is preceded
   by a measurement identity block [RFC6776
<http://tools.ietf.org/html/rfc6776>].  Under all other
   circumstances it MUST ignore the block.

If the block is merged, we could either allow both forms or just
allowing RFC6776

measurement identity block. I do not have a strong opinion, but prefer if both

forms of reporting are allowed (using RTCP RR or RFC6776).

Cheers,

Varun

On Mon, Jul 22, 2013 at 1:30 PM, Qin Wu <[email-masked]> wrote:

>  Regarding the second approach:****
>
> It seems Byte discarded block in
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06doesn’t need to be sent
> with measurement identity block [RFC6776], it can be sent with RTCP
> Receiver Report (RR).****
>
> While packet discard count block in the
> draft-ietf-xrblock-rtcp-xr-discard-15 MUST be sent with measurement
> identity block. If not, packet discard count block****
>
> MUST be discarded.****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Varun Singh
> *Sent:* Sunday, July 21, 2013 5:00 PM
> *To:* [email-masked]
> *Subject:* [xrblock] PM Dir review of Discard RLE Draft****
>
> ** **
>
> raised, which require input from the WG.****
>
>
> PM Dir:****
>
> The main concern is that the draft contains two reporting blocks: ****
>
> Discard RLE and Bytes discarded. First, the current title just mentions **
> **
>
> the Discard RLE and not discarded bytes. Second, the discarded bytes ****
>
> may be a better fit with discarded packets draft. ****
>
> ** **
>
> The question in this case is, which choice does the WG prefer?****
>
> 1. update the title of the discarded RLE draft and add the appropriate ***
> *
>
> RFC6390 templates.****
>
> ** **
>
> 2. Merge the discarded bytes with the discarded packets, however, ****
>
> the discarded packets draft is in RFC editor queue.****
>
> ** **
>
> 3. Make a new draft for discarded bytes?****
>
> ** **
>
> ** **
>
> Cheers,****
>
> Varun****
>
> ** **
>
> ** **
>
> [1]
> ****
> ****
> ** **

-- 
http://www.netlab.tkk.fi/~varun/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 23 Jul 2013 01:05:29 +0000

Hi Varun,

Why not we choosing choice 1 to modify the name of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.  And we also change the current name of draft-ietf-xrblock-rtcp-xr-discard to RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Packet Count metric Reporting. So that no significant changes will be made to the discard draft and we can let it move on. I believe this method will be no harm to both documents.

Best regards,
Rachel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Varun Singh
Sent: Tuesday, July 23, 2013 4:59 AM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

   by a measurement identity block [RFC6776<http://tools.ietf.org/html/rfc6776>].  Under all other

If the block is merged, we could either allow both forms or just allowing RFC6776

Cheers,

Varun

On Mon, Jul 22, 2013 at 1:30 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Regarding the second approach:
It seems Byte discarded block in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06doesn't need to be sent with measurement identity block [RFC6776], it can be sent with RTCP Receiver Report (RR).
While packet discard count block in the draft-ietf-xrblock-rtcp-xr-discard-15 MUST be sent with measurement identity block. If not, packet discard count block
MUST be discarded.

Regards!
-Qin
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Varun Singh
Sent: Sunday, July 21, 2013 5:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [xrblock] PM Dir review of Discard RLE Draft

PM Dir:

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Jul 2013 03:18:02 +0000

I prefer not adding such complexity(i.e., distinguishing different behavior for deal with byte discarded block and packet discarded block) to discard draft which sits in RFC Queue if we take this approach.
what we need to do is to add 1 bit flag in the block header to indicate whether the discard count is byte discard count or packet discard count.
In this case, the impact we bring on discard draft will be very few. We can simply ask AD to send RFC Editor note to RFC Editors and implement
this minor change if WG consensus on this change is formed.

However I don't know the real procedure we should follow if one draft in RFC Queue needs to be changed.

Regards!
-Qin

From: Varun Singh [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 4:59 AM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun

---

From: Varun Singh <[email-masked]>
Date: Tue, 23 Jul 2013 12:20:02 +0300

Hi Qin,

Apart from the 1-bit flag and related description, we'll need to
also add a RFC6390 template to the appendix.

Cheers,
Varun

On Tue, Jul 23, 2013 at 6:18 AM, Qin Wu <[email-masked]> wrote:

>  I prefer not adding such complexity(i.e., distinguishing different
> behavior for deal with byte discarded block and packet discarded block) to
> discard draft which sits in RFC Queue if we take this approach.****
>
> what we need to do is to add 1 bit flag in the block header to indicate
> whether the discard count is byte discard count or packet discard count.**
> **
>
> In this case, the impact we bring on discard draft will be very few. We
> can simply ask AD to send RFC Editor note to RFC Editors and implement****
>
> this minor change if WG consensus on this change is formed.****
>
> ** **
>
> However I don’t know the real procedure we should follow if one draft in
> RFC Queue needs to be changed.****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> ** **
>
> *From:* Varun Singh [mailto:[email-masked]]
> *Sent:* Tuesday, July 23, 2013 4:59 AM
> *To:* Qin Wu
> *Cc:* [email-masked]
> *Subject:* Re: [xrblock] PM Dir review of Discard RLE Draft****
>
>  ** **
>
> Hi Qin,****
>
> ** **
>
> In the media sender section the draft, it allow both forms of reporting:**
> **
>
> ** **
>
>    The sender SHOULD accept the Bytes Discarded Report Block only if it****
>
>    is received in a compound RTCP receiver report or if it is preceded****
>
>    by a measurement identity block [RFC6776 <http://tools.ietf.org/html/rfc6776>].  Under all other****
>
>    circumstances it MUST ignore the block.****
>
> ** **
>
> If the block is merged, we could either allow both forms or just allowing RFC6776 ****
>
> measurement identity block. I do not have a strong opinion, but prefer if both ****
>
> forms of reporting are allowed (using RTCP RR or RFC6776).****
>
> ** **
>
> ** **
>
> ** **
>
> Cheers,****
>
> Varun****
>
>  ** **
>
> On Mon, Jul 22, 2013 at 1:30 PM, Qin Wu <[email-masked]> wrote:****
>
> http://www.netlab.tkk.fi/~varun/ ****
>

---

From: Varun Singh <[email-masked]>
Date: Tue, 23 Jul 2013 12:31:20 +0300

Hi Rachel,

As you suggest, it is quite straightforward to incorporate PM Directorate
reviews into the -07 document,
however, the main argument is the discarded bytes fits better with
discarded packet count instead of
Discard RLE. Hence, the email for input from the WG, this will also be
discussed at the Berlin meeting.

Cheers,
Varun

On Tue, Jul 23, 2013 at 4:05 AM, Huangyihong (Rachel) <
[email-masked]> wrote:

>  Hi Varun,****
>
> ** **
>
> Why not we choosing choice 1 to modify the name of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.
>  And we also change the current name of draft-ietf-xrblock-rtcp-xr-discard
> to RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard
> Packet Count metric Reporting. So that no significant changes will be
> made to the discard draft and we can let it move on. I believe this method
> will be no harm to both documents. ****
>
> ** **
>
> Best regards,****
>
> Rachel****
>
> ** **
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Jul 2013 09:39:56 +0000

Discard draft has already applied RFC6390 template in the appendix.
What we need to do is to update RFC6390 template in the appendix to
make sure it  supports bytes discarded reporting as well.

Regards!
-Qin
From: Varun Singh [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 5:20 PM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

Cheers,
Varun

On Tue, Jul 23, 2013 at 6:18 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Regards!
-Qin

From: Varun Singh [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 23, 2013 4:59 AM
To: Qin Wu
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Jul 2013 03:17:59 +0000

Hi, all:
If we really like to take the second approach, here is my proposed change:
1. Section 1.1, Paragraph 1, the 2nd sentence:
OLD TEXT:
"
The new block type supports the reporting of the number
of packets which are received correctly but are never
played out, typically because they arrive too
late to be played out (buffer underflow) or too early (buffer
overflow).
"
NEW TEXT:
"
The new block type supports the reporting of the number
of packets or bytes which are received correctly but are never
played out, typically because they arrive too
late to be played out (buffer underflow) or too early (buffer
overflow).
"
2. Section 2.1, terms "Received, Lost and Discarded"
OLD TEXT:
"
The Discard Count Metric counts only discarded packets.
"
NEW TEXT:
"
The Discard Count Metric counts only discarded packets or bytes.
"

3. Section 3, 1st paragraph, the 1st sentence:
OLD TEXT:
"
Metrics in this block report on the number of packets discarded in
   the stream arriving at the RTP end system.
"
NEW TEXT:
"
Metrics in this block report on the number of packets or bytes discarded in
the stream arriving at the RTP end system.
"
4. Section 3.1, Figure 1:
OLD Figure:
"
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BT=PDC    | I |DT |  resv.|      block length = 2         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SSRC of Source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        discard count                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: Report Block Structure
   Reserved (resv): 4 bits

      These bits are reserved.  They MUST be set to zero by senders and
      ignored by receivers (See RFC6709 section 4.2).

"
NEW Figure: (The changes are

a.       add a new flag bit 'P' in the block header to indicate whether it is  Byte discard or packet discard

b.      Add description for new flag bit 'P'

c.       change the length of Reserved field from 4bit to 3bit)
"
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BT=PDC    | I |P|DT |resv.|      block length = 2         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SSRC of Source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        discard count                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: Report Block Structure

  Packet or Byte Discarded Flag(P): 1 bit

   The 'P' flag is used to indicate whether the discard count report
   is Packet discard count report or Byte discard count report.  The
   value is set to '1' if Packet discard count is reported.  Otherwise,
   the value is set to '0'.

   Reserved (resv): 3 bits

      These bits are reserved.  They MUST be set to zero by senders and
      ignored by receivers (See RFC6709 section 4.2).

"
5. Section 3.1, Discard count definition:
OLD TEXT:
"
   discard count

      Number of packets discarded over the period (Interval or
      Cumulative) covered by this report.

"
NEW TEXT:
"
   discard count

      For packet discard count report, the value is the Number
      of packets discarded over the period (Interval or
      Cumulative) covered by this report.
       For byte discard count report, the value is the number
      of bytes discarded over the period(Interval or cumulative)
       covered by this report.
"
6. Appendix
OLD TEXT:
"
Appendix A.  Metrics represented using RFC6390 Template

   RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
   number, when assigned.

   a.  Number of packets discarded Metric

       *  Metric Name: Number of RTP packets discarded Metric

       *  Metric Description: Number of RTP packets discarded over the
          period covered by this report.

       *  Method of Measurement or Calculation: See section 3.2, number
          of packets discarded definition [RFCXXXX].

       *  Units of Measurement: See section 3.2, number of packets
          discarded definition [RFCXXXX].

       *  Measurement Point(s) with Potential Measurement Domain: See
          section 3, 1st paragraph [RFCXXXX].

       *  Measurement Timing: See section 3, 1st paragraph [RFCXXXX] for
          measurement timing and section 3.2 [RFCXXXX] for Interval
          Metric flag.

       *  Use and applications: See section 1.4 [RFCXXXX].

       *  Reporting model: See RFC3611.

"
NEW TEXT:
"
Appendix A.  Metrics represented using RFC6390 Template

   RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
   number, when assigned.

   a.  Discard count Metric

       *  Metric Name: Discard count in RTP Metric

       *  Metric Description: Number of RTP packets or bytes discarded over the
          period covered by this report.

       *  Method of Measurement or Calculation: See section 3.2, discard count definition [RFCXXXX].

       *  Units of Measurement: See section 3.2, discard count definition [RFCXXXX].

       *  Measurement Point(s) with Potential Measurement Domain: See
          section 3, 1st paragraph [RFCXXXX].

       *  Measurement Timing: See section 3, 1st paragraph [RFCXXXX] for
          measurement timing and section 3.2 [RFCXXXX] for Interval
          Metric flag.

       *  Use and applications: See section 1.4 [RFCXXXX].

       *  Reporting model: See RFC3611.

"

Regards!
-Qin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Tuesday, July 23, 2013 5:40 PM
To: Varun Singh
Cc: [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Regards!
-Qin

Hi Qin,

Cheers,
Varun

Regards!
-Qin

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun

---

From: Varun Singh <[email-masked]>
Date: Thu, 25 Jul 2013 11:58:13 +0300

Hi Qin,

Thank you for the proposal,

Based on comments from Alan's review:

I had updated the description of bytes discarded to:

   The 'number of bytes discarded' is a 32-bit unsigned integer value
   indicating the total number of bytes discarded.  Bytes discarded
   corresponds to the RTP payload size of every RTP packet that is
   discarded (due to early or late arrival).  Hence, the bytes discarded
   ignores the size of any RTP header extensions and the size of the
   padding bits.  Also the discarded packet is associated to the
   interval in which it was discarded and not when it was expected.

The reason for the change was to explicitly state what is counted
as discarded and when?

The proposal is missing the SDP and IANA bits:

- SDP signaling

      xr-format       =/ xr-discard-bytes
      xr-discard-bytes = "discard-bytes"

The parameter 'discard-bytes' to indicate support for the Bytes Discarded
Report Block
defined in <section>.

- XR Report Block Registration needs to be updated

- SDP Parameter Registration needs to be updated

I am attaching the updated -07 (temporary) draft, it covers the feedback
received until now,
and is more inline with the 1st approach.

Cheers,
Varun

On Thu, Jul 25, 2013 at 6:17 AM, Qin Wu <[email-masked]> wrote:

>  Hi, all:****
> 1. Section 1.1, Paragraph 1, the 2nd sentence:****
>
> OLD TEXT:****
>
> “****
>
> The new block type supports the reporting of the number ****
>
> of packets which are received correctly but are never ****
>
> played out, typically because they arrive too****
>
> late to be played out (buffer underflow) or too early (buffer****
>
> overflow).****
>
> ”****
>
> NEW TEXT:****
>
> “****
>
> The new block type supports the reporting of the number****
>
> of packets or bytes which are received correctly but are never****
>
> played out, typically because they arrive too****
>
> late to be played out (buffer underflow) or too early (buffer****
>
> overflow).****
>
> ”****
>
> 2. Section 2.1, terms “Received, Lost and Discarded”****
>
> OLD TEXT:****
>
> “****
>
> The Discard Count Metric counts only discarded packets.****
>
> ”****
>
> NEW TEXT:****
>
> “****
>
> The Discard Count Metric counts only discarded packets or bytes.****
>
> ”****
>
> ** **
>
> 3. Section 3, 1st paragraph, the 1st sentence:****
>
> OLD TEXT:****
>
> “****
>
> Metrics in this block report on the number of packets discarded in****
>
>    the stream arriving at the RTP end system.  ****
>
> ”****
>
> NEW TEXT:****
>
> “****
>
> Metrics in this block report on the number of packets or bytes discarded
> in****
>
> the stream arriving at the RTP end system.  ****
>
> ”****
>
> 4. Section 3.1, Figure 1:****
>
> OLD Figure:****
>
> “****
>
>         0                   1                   2                   3****
>
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1***
> *
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
>        |     BT=PDC    | I |DT |  resv.|      block length = 2         |**
> **
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
>        |                        SSRC of Source                         |**
> **
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
>        |                        discard count                          |**
> **
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
> ** **
>
>                      Figure 1: Report Block Structure****
>
>    Reserved (resv): 4 bits****
>
> ** **
>
>       These bits are reserved.  They MUST be set to zero by senders and***
> *
>
>       ignored by receivers (See RFC6709 section 4.2).****
>
> ** **
>
> ** **
>
> ”****
>
> NEW Figure: (The changes are ****
>
> **a.       **add a new flag bit ‘P’ in the block header to indicate
> whether it is  Byte discard or packet discard****
>
> **b.      **Add description for new flag bit ‘P’****
>
> **c.       **change the length of Reserved field from 4bit to 3bit)****
>
> “****
>
>         0                   1                   2                   3****
>
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1***
> *
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
>        |     BT=PDC    | I |P|DT |resv.|      block length = 2         |**
> **
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
>        |                        SSRC of Source                         |**
> **
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
>        |                        discard count                          |**
> **
>
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+**
> **
>
> ** **
>
>                      Figure 1: Report Block Structure****
>
> ** **
>
>   Packet or Byte Discarded Flag(P): 1 bit****
>
> ** **
>
>    The 'P' flag is used to indicate whether the discard count report****
>
>    is Packet discard count report or Byte discard count report.  The****
>
>    value is set to '1' if Packet discard count is reported.  Otherwise,***
> *
>
>    the value is set to '0'. ****
>
> ** **
>
>    Reserved (resv): 3 bits****
>
> ** **
>
>       These bits are reserved.  They MUST be set to zero by senders and***
> *
>
>       ignored by receivers (See RFC6709 section 4.2).****
>
> ** **
>
> ** **
>
> ”****
>
> 5. Section 3.1, Discard count definition:****
>
> OLD TEXT:****
>
> “****
>
>    discard count****
>
> ** **
>
>       Number of packets discarded over the period (Interval or****
>
>       Cumulative) covered by this report.****
>
> ** **
>
> ”****
>
> NEW TEXT:****
>
> “****
>
>    discard count****
>
> ** **
>
>       For packet discard count report, the value is the Number****
>
>       of packets discarded over the period (Interval or****
>
>       Cumulative) covered by this report.****
>
>        For byte discard count report, the value is the number ****
>
>       of bytes discarded over the period(Interval or cumulative)****
>
>        covered by this report.****
>
> ”****
>
> 6. Appendix****
>
> OLD TEXT:
> “****
>
> Appendix A.  Metrics represented using RFC6390 Template****
>
> ** **
>
>    RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC****
>
>    number, when assigned.****
>
> ** **
>
>    a.  Number of packets discarded Metric****
>
> ** **
>
> ** **
>
>        *  Metric Name: Number of RTP packets discarded Metric****
>
> ** **
>
> ** **
>
>        *  Metric Description: Number of RTP packets discarded over the****
>
>           period covered by this report.****
>
> ** **
>
> ** **
>
>        *  Method of Measurement or Calculation: See section 3.2, number***
> *
>
>           of packets discarded definition [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Units of Measurement: See section 3.2, number of packets****
>
>           discarded definition [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Measurement Point(s) with Potential Measurement Domain: See****
>
>           section 3, 1st paragraph [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Measurement Timing: See section 3, 1st paragraph [RFCXXXX] for**
> **
>
>           measurement timing and section 3.2 [RFCXXXX] for Interval****
>
>           Metric flag.****
>
> ** **
>
> ** **
>
>        *  Use and applications: See section 1.4 [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Reporting model: See RFC3611.****
>
> ** **
>
> ”****
>
> NEW TEXT:****
>
> “****
>
> Appendix A.  Metrics represented using RFC6390 Template****
>
> ** **
>
>    RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC****
>
>    number, when assigned.****
>
> ** **
>
>    a.  Discard count Metric****
>
> ** **
>
> ** **
>
>        *  Metric Name: Discard count in RTP Metric****
>
> ** **
>
> ** **
>
>        *  Metric Description: Number of RTP packets or bytes discarded
> over the****
>
>           period covered by this report.****
>
> ** **
>
> ** **
>
>        *  Method of Measurement or Calculation: See section 3.2, discard
> count definition [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Units of Measurement: See section 3.2, discard count definition
> [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Measurement Point(s) with Potential Measurement Domain: See****
>
>           section 3, 1st paragraph [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Measurement Timing: See section 3, 1st paragraph [RFCXXXX] for**
> **
>
>           measurement timing and section 3.2 [RFCXXXX] for Interval****
>
>           Metric flag.****
>
> ** **
>
> ** **
>
>        *  Use and applications: See section 1.4 [RFCXXXX].****
>
> ** **
>
> ** **
>
>        *  Reporting model: See RFC3611.****
>
> ** **
>
> ”****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> ** **
>
> Behalf Of *Qin Wu
> *Sent:* Tuesday, July 23, 2013 5:40 PM
> *To:* Varun Singh
>
> *Cc:* [email-masked]
> Discard draft has already applied RFC6390 template in the appendix.****
>
> What we need to do is to update RFC6390 template in the appendix to ****
>
> make sure it  supports bytes discarded reporting as well.****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *Sent:* Tuesday, July 23, 2013 5:20 PM
> *To:* Qin Wu
> *Cc:* [email-masked]
> Apart from the 1-bit flag and related description, we'll need to ****
>
> also add a RFC6390 template to the appendix.****
>
> ** **
>
> Cheers,****
>
> Varun****
>
> ** **
>
> On Tue, Jul 23, 2013 at 6:18 AM, Qin Wu <[email-masked]> wrote:****
>
> *From:* Varun Singh [mailto:[email-masked]] ****
>
> *Cc:* [email-masked]****
>

---

From: Varun Singh <[email-masked]>
Date: Thu, 25 Jul 2013 12:01:51 +0300

Hi Qin,

On the RFC6390 template, if following the second approach does it
require two sections? I am no expert but one each for
Discarded Packet Count Metric and Discarded Bytes Metric?

Cheers,
Varun

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jul 2013 09:03:15 +0000

Yes, these are two distinct metrics.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Varun Singh
Sent: Thursday, July 25, 2013 12:02 PM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

Cheers,
Varun

On Thu, Jul 25, 2013 at 6:17 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi, all:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<tel:1%202%203%204%205%206%207%208%209%200%201>

"

c.       change the length of Reserved field from 4bit to 3bit)
"
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<tel:1%202%203%204%205%206%207%208%209%200%201>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BT=PDC    | I |P|DT |resv.|      block length = 2         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SSRC of Source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        discard count                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved (resv): 3 bits

"

"
NEW TEXT:
"
   discard count

"
NEW TEXT:
"

   a.  Discard count Metric

"

Regards!
-Qin

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wu
Sent: Tuesday, July 23, 2013 5:40 PM
To: Varun Singh

Regards!
-Qin

Hi Qin,

Cheers,
Varun

Regards!
-Qin

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Jul 2013 09:21:10 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Varun Singh
Sent: Thursday, July 25, 2013 4:58 PM
To: Qin Wu
Cc: Jörg Ott; [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

[Qin]: Okay, we can put this sentence into 'discard count' definition.

- SDP signaling

The parameter 'discard-bytes' to indicate support for the Bytes Discarded Report Block
defined in <section>.

[Qin]: umm, how about follow the example of RFC6798, change SDP signaling in section 4.1 as follows:
OLD TEXT:
"
   xr-format =/ xr-pdc-block
   xr-pdc-block = "pkt-discard-count"
"
NEW TEXT:
"
   xr-format =/ xr-dc-block
   xr-dc-block = "discard-count" [","dctype]
        dctype = "dc=" ("0" ; bytes discard count block
                                      /"1" ; packet discard count block

                                    / 1*2DIGIT); Value 2~15 are valid and reserved for future use

   DIGIT          = <as defined in Section 3.4 of [RFC5234]<http://tools.ietf.org/html/rfc5234#section-3.4>>

"

[Qin]: If we agree the above SDP signaling change, I think we don't need to change IANA registration
Since byte discard count metric and packet discard count metric share the same block type and block format.

I am attaching the updated -07 (temporary) draft, it covers the feedback received until now,
and is more inline with the 1st approach.

Cheers,
Varun

"

   Reserved (resv): 3 bits

"

"
NEW TEXT:
"
   discard count

"
NEW TEXT:
"

   a.  Discard count Metric

"

Regards!
-Qin

Regards!
-Qin

Hi Qin,

Cheers,
Varun

Regards!
-Qin

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Jul 2013 09:27:02 +0000

Okay, we can split it into two metrics, the proposed change is as follows:
OLD TEXT:
"
Appendix A.  Metrics represented using RFC6390 Template

"

NEW TEXT:
"

   a.  Packet Discard count Metric

       *  Metric Name: RTP Packet Discard count Metric

   b.  Byte Discard count Metric

       *  Metric Name: RTP Byte Discard count Metric

       *  Metric Description: Number of RTP bytes discarded over the
          period covered by this report.

"

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, July 25, 2013 5:03 PM
To: Varun Singh; Qin Wu
Cc: [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Regards,

Dan

Hi Qin,

Cheers,
Varun

"

   Reserved (resv): 3 bits

"

"
NEW TEXT:
"
   discard count

"
NEW TEXT:
"

   a.  Discard count Metric

"

Regards!
-Qin

Regards!
-Qin

Hi Qin,

Cheers,
Varun

Regards!
-Qin

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Jul 2013 09:35:45 +0000

Sorry, I think we still need to update SDP parameter registration
OLD TEXT:
"
5.2<http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-15#section-5.2>.  New RTCP XR SDP Parameter

   This document also registers a new parameter "pkt-discard-count" in
   the " RTP Control Protocol Extended Reports (RTCP XR) Session
   Description Protocol (SDP) Parameters Registry ".

"
NEW TEXT:
"
5.2<http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-15#section-5.2>.  New RTCP XR SDP Parameter

   This document also registers a new parameter "discard-count" in
   the " RTP Control Protocol Extended Reports (RTCP XR) Session
   Description Protocol (SDP) Parameters Registry ".

"

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, July 25, 2013 5:21 PM
To: Varun Singh
Cc: Jörg Ott; [email-masked]
Subject: Re: [xrblock] PM Dir review of Discard RLE Draft

Hi Qin,

- SDP signaling

"

Cheers,
Varun

"

   Reserved (resv): 3 bits

"

"
NEW TEXT:
"
   discard count

"
NEW TEXT:
"

   a.  Discard count Metric

"

Regards!
-Qin

Regards!
-Qin

Hi Qin,

Cheers,
Varun

Regards!
-Qin

Hi Qin,

Cheers,

Varun

Regards!
-Qin

PM Dir:

Cheers,
Varun