Subject: [xrblock] WGLC request for Measurement Identity and information draft

From: Qin Wu <[email-masked]>
Date: Wed, 07 Dec 2011 19:51:05 +0800

Hi, folks:
Following the discussion in the Taipei, we believe this draft has already been ready for WGLC.
It is time for chairs review and moving forward.

Regards!
-Qin

---

From: Shida Schubert <[email-masked]>
Date: Wed, 7 Dec 2011 23:06:56 +0900

Qin;

 As you can see from the minutes, I thought we agreed 
to rev the draft before the WGLC. 

  - Author will include text about what kind of metrics 
   should use the identity block and an explanation that 
   drafts utilizing this draft (block) should include  
   guidance that measurement blocks should be ignored when  
   the identity block is missing.

 If the draft already covers what was agreed at the 
meeting then please let me know.

 We can go into WGLC as soon as we get the above 
text included in the draft.

 Regards
  Shida (As WG chair)

On Dec 7, 2011, at 8:51 PM, Qin Wu wrote:

> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Thu, 08 Dec 2011 09:18:24 +0800

Hi, Shida:
I think any metric blocks that rely on an  interval duration metric in the measurement Identity and
 information draft must be discarded if that interval duration metric  has not been received.
So I believe we should add the above clarification text into each metric block draft  that highly 
depends on measurement identity and information draft, rather than implement any clarification text
 in the measurement identity and information draft.
e.g., I have already added relevant clarification text into both PDV draft and Delay.
Therefore no change is needed to this draft.
Hope this clarify.

Regards!
-Qin
  ----- Original Message ----- 
  From: Shida Schubert 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Wednesday, December 07, 2011 10:06 PM
  Subject: Re: [xrblock] WGLC request for Measurement Identity and informationdraft

  Qin;

   Regards
    Shida (As WG chair)

    Hi, folks:

    Regards!
    -Qin

------------------------------------------------------------------------------

---

From: Shida Schubert <[email-masked]>
Date: Thu, 8 Dec 2011 23:11:57 +0900

Qin;

 So are you saying that we need not add any guideline like 
text in the measurement identity draft, for any future draft that 
will be relying on measurement identity?

 How would the author of draft relying on measurement identity 
know such text (text you added to pdv/delay draft) is needed? 
I think it is useful to have some guideline text in the measurement 
identity draft itself and I thought that was the conclusion at the 
meeting..

 I really don't have any strong opinions here, I am just trying to 
confirm the conclusion at the meeting. 

 Regards
  Shida

---

From: Qin Wu <[email-masked]>
Date: Fri, 09 Dec 2011 14:35:33 +0800

Hi, Shida and all:
There is one guideline rule in the section 5.3 of MONARCH draft:
"
 If the measurement interval for a metric is different from the RTCP
   reporting interval, then this measurement duration in the [MI] SHOULD
   be used to specify the interval. 
"
This rule SHOULD apply to any new metric blocks we are going to define.
I think this guideline from MONACH draft can help the user to know if 
measurement information block (in the draft-ietf-xrblock-rtcp-xr-meas-identity) is needed.

For the existing XR block specified in the RFC3611, if they carry "beg sequence number" and "end sequence number",
I think also the measurement information block is not needed for these existing XR Blocks such as Loss RLE Report, Duplication RLE Report,
Packet Receipt Times Report Block, Statistics Summary Report Block specified in the RFC3611.

Another guideline I think it might be useful is if any metric we defined in the 
 new XR block draft is calculated from  measurement information defined in draft-ietf-xrblock-rtcp-xr-meas-identity, then
measurement information block is really needed for this new XR Blocks. Two examples we have are:
1. Burst/Gap Loss Summsary Statistics Block defined in the draft-zorn-xrblock-rtcp-xr-al-stat
Burst Loss Rate in the Burst/Gap Loss Summary Statistics Block is calculated by:
(number of packets lost - Packets Lost in Bursts) / (Packets
      Expected - Total Packets expected in Bursts)

      where Packets Expected is calculated as the difference
      between "extended last sequence number" and "extended first
      sequence number" (Interval or Cumulative) provided in the
      Measurement Identity and Information block of draft-ietf-xrblock-rtcp-xr-meas-identity.
 
2. Burst/Gap Discard Summsary Statistics Block defined in the draft-zorn-xrblock-rtcp-xr-al-stat
Burst Discard Rate in the Burst/Gap Discard Summary Statistics Block is calculated by:
(number of packets Discarded - Packets Discard  in Bursts) / (Packets
      Expected - Total Packets expected in Bursts)

      where Packets Expected is calculated as the difference
      between "extended last sequence number" and "extended first
      sequence number" (Interval or Cumulative) provided in the
      Measurement Identity and Information block of draft-ietf-xrblock-rtcp-xr-meas-identity. 

I am not sure we need additional guideline to say in the measurement identity and information draft since
we already have a general guideline in the MONARCH draft for this.

Let me know what do you think of it?

Regards!
-Qin
 
----- Original Message ----- 
  From: Shida Schubert 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Thursday, December 08, 2011 10:11 PM
  Subject: Re: [xrblock] WGLC request for Measurement Identity and informationdraft

  Qin;

   Regards
    Shida 

    Hi, Shida:

    Regards!
    -Qin
      ----- Original Message -----
      From: Shida Schubert
      To: Qin Wu
      Cc: [email-masked]
      Sent: Wednesday, December 07, 2011 10:06 PM
      Subject: Re: [xrblock] WGLC request for Measurement Identity and informationdraft

      Qin;

       Regards
        Shida (As WG chair)

        Hi, folks:

        Regards!
        -Qin

--------------------------------------------------------------------------

---

From: Shida Schubert <[email-masked]>
Date: Mon, 12 Dec 2011 18:11:08 +0900

Hi Qin;

 Okay, let's give people few days and if we hear 
no objection to your input, I will send out an e-mail 
to commence the WGLC. 

 Regards
  Shida

---

From: Colin Perkins <[email-masked]>
Date: Mon, 12 Dec 2011 16:50:00 +0000

Qin,

It might be useful if Section 5.3 of draft-ietf-avtcore-monarch-08 contained a sentence saying that "New RTCP XR metric blocks that rely on the Measurement Interval block [MI] MUST specify the response in case the new RTCP XR metric block is received without an associated measurement interval block; in most cases, it is expected that the correct response it to discard the received metric."

Colin

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 13 Dec 2011 10:17:56 +0800

Hi, Colin:
Your proposal looks reasonable to me, Thanks!

Regards!
-Qin
  ----- Original Message ----- 
  From: Colin Perkins 
  To: Qin Wu 
  Cc: Shida Schubert ; [email-masked] 
  Sent: Tuesday, December 13, 2011 12:50 AM
  Subject: Re: [xrblock] WGLC request for Measurement Identity and informationdraft

  Qin,

  It might be useful if Section 5.3 of draft-ietf-avtcore-monarch-08 contained a sentence saying that "New RTCP XR metric blocks that rely on the Measurement Interval block [MI] MUST specify the response in case the new RTCP XR metric block is received without an associated measurement interval block; in most cases, it is expected that the correct response is to discard the received metric."

  Colin

    Regards!
    -Qin

    ----- Original Message -----
      From: Shida Schubert
      To: Qin Wu
      Cc: [email-masked]
      Sent: Thursday, December 08, 2011 10:11 PM
      Subject: Re: [xrblock] WGLC request for Measurement Identity and informationdraft

      Qin;

       Regards
        Shida 

        Hi, Shida:

        Regards!
        -Qin
          ----- Original Message -----
          From: Shida Schubert
          To: Qin Wu
          Cc: [email-masked]

          Qin;

           Regards
            Shida (As WG chair)

            Hi, folks:

            Regards!
            -Qin

----------------------------------------------------------------------

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 13 Dec 2011 13:51:09 -0800

Hi Qin,

The following clarification was shared by Roni:

-------------
The view is that the identity block precedes the report blocks for the
same
time period, so if there are two time periods in the same compound
packet
there will be two identity blocks. 
If a the number of report blocks need to span over more than one RTCP
report
packet, the identity block will be duplicated in the second RTCP
compound
packet. This will address the issue of robustness against packet loss
since
there will be an identity block in each RTCP compound packet
Roni Even
------------

I think it would be beneficial to include this clarification within the
text of the draft.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Qin Wu
> Sent: Wednesday, December 07, 2011 3:51 AM
> To: [email-masked]
> Subject: [xrblock] WGLC request for Measurement Identity and
informationdraft

---

From: Qin Wu <[email-masked]>
Date: Wed, 14 Dec 2011 10:17:44 +0800

Hi, Charles:
Thank for your valuable comment.
I have already included such clarification into the section 5.3 of MONARCH draft (version -08).
Hope this addresses your concern.

-Qin
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 14, 2011 5:51 AM
Subject: RE: [xrblock] WGLC request for Measurement Identity and informationdraft

Hi Qin,

-------------

Cheers,
Charles

Behalf Of Qin Wu
informationdraft

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 14 Dec 2011 15:12:36 -0800

Hi Qin,

Thanks for the pointer. What I see specified in section 5.3 of the
MONARCH draft (version -08) addresses when multiple metric blocks are
carried in one RTCP XR packet, reporting on the same stream from the
same source for the same time period. However, it does not address the
situation in which there are multiple time periods in the same compound
packet.

Cheers,
Charles

> From: Qin Wu [mailto:[email-masked]]
> Sent: Tuesday, December 13, 2011 6:18 PM
> To: Charles Eckel (eckelcu); [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Dec 2011 10:16:56 +0800

Hi, Charles:
Sorry for my late reply due to a short business trip.

In the section 5.3 of MONARCH draft (-08), we do address this case using the following
clarification text:
"
 If  the measurement interval for a metric is different from the RTCP
 reporting interval, then this measurement duration in the [MI] SHOULD
 be used to specify the interval.
"
That is to say, if one RTCP reporting inteval includes two measurement intervals, in each measurement
interval, we should include measurement information block to specify such interval.
Does this address your comment? 

Regards!
-Qin
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 15, 2011 7:12 AM
Subject: RE: [xrblock] WGLC request for Measurement Identity and informationdraft

Hi Qin,

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 16 Dec 2011 09:54:05 -0800

Hi Qin,

I think the existing text leaves some room for ambiguity as it could be
interpreted as meaning that you have two choices for the interval, the
RTCP report interval, or the value conveyed in the MI block. I think the
key concepts that are missing are the ability to have multiple MI blocks
in a single RTCP packets, and the importance of the ordering of the MI
blocks and the corresponding metric blocks within that packet. If you
have metrics corresponding to more than one interval and you want to
include them within a single compound RTCP packet, you need or order
them as follows:

MI-1
Metric based on MI-1
Metric based on MI-1
.
.
MI-2
Metric based on MI-2
Metric based on MI-2
.
.
MI-n
Metric based on MI-n
.
.

Cheers,
Charles

> Sent: Thursday, December 15, 2011 6:17 PM

---

From: Qin Wu <[email-masked]>
Date: Mon, 19 Dec 2011 10:18:05 +0800

Charles:
That's a good point. I remembered this was discussed before on the list regarding if we have case where we can't just use SSRC to group metrics.
I also raised this before on the avtcore list. 
It looks to me in most cases, RTCP report interval should be greater than or equal to measurement interval (i.e., the value conveyed in the MI block)
but not twice greater than the measurement interval.

If one single compound RTCP packet really carries metrics corresponding to more than one measurement interval,
I think, as you indicated, we should rely on the MI's order to group them since they share the same SSRC. That is to say,
the metric blocks associated with MI should always follow MI if we have more than one MIs carried in the same
compound RTCP packet. 

If you think this clarification addresses your comment, I will put them into the new version of Monarch draft. 
Does this make sense to you?

Regards!
-Qin

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 19 Dec 2011 09:04:34 -0800

Works for me. Thanks.

Charles

> Sent: Sunday, December 18, 2011 6:18 PM
> That's a good point. I remembered this was discussed before on the
list regarding if we have case
> where we can't just use SSRC to group metrics.
> It looks to me in most cases, RTCP report interval should be greater
than or equal to measurement
> interval (i.e., the value conveyed in the MI block)
> If one single compound RTCP packet really carries metrics
corresponding to more than one measurement
> interval,
> I think, as you indicated, we should rely on the MI's order to group
them since they share the same
> SSRC. That is to say,
> the metric blocks associated with MI should always follow MI if we
have more than one MIs carried in
> the same
> compound RTCP packet.
> 
> If you think this clarification addresses your comment, I will put
them into the new version of
> Monarch draft.
> >> That is to say, if one RTCP reporting inteval includes two
measurement
> > intervals, in each measurement
> >> interval, we should include measurement information block to
specify
> > such interval.
> >> > I have already included such clarification into the section 5.3
of
> >> MONARCH draft (version -08).
> >> > The view is that the identity block precedes the report blocks
for
> > the
> >> > I think it would be beneficial to include this clarification
within
> >> the
> >> > > From: [email-masked]
[mailto:[email-masked]]
> > On
> >> > > Following the discussion in the Taipei, we believe this draft
has
> >> > already been ready for WGLC.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 19 Dec 2011 22:23:33 +0000

Qin,

> It is time for chairs review and moving forward.

Two minor nits I noticed, that should be fixed before WG last call:

Section 3.1 says “Where the identifier is less than 32 bits, the identifier SHOULD be mapped into the most significant bits of the field”. It’s not clear why this is needed, since individual items aren’t 32-bit aligned in SDES packets. I suggest removing this sentence. 

In Section 4.1, the figure shows “block length = 6” but the text says “the block length is equal to 7”.

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 20 Dec 2011 08:54:17 +0800

Hi, Colin:
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 20, 2011 6:23 AM
Subject: Re: [xrblock] WGLC request for Measurement Identity and informationdraft

Qin,

[Qin]: Okay, that makes sense to me.

[Qin]: Good point, that should be fixed into 6. Thanks.

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 20 Dec 2011 09:01:43 +0800

Hi,

>Two minor nits I noticed, that should be fixed before WG last call:

[Qin]: Last call has already begun. I like to address these two nits after LC. Thanks.

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