Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 20 Jan 2012 14:20:47 -0800

(As WG Co-Chair)

This is an announcement of XRBLOCK WG last call on "RTCP XR Report Block
for Delay metric Reporting" prior to requesting publication of the
document as a proposed standard. 

This is a two week working group last call. Please send your comments,
including nits, to the list by the 3rd of February. 

If you read the draft and you see no issues, concerns, or nits, please
express the fact that you have no issue progressing the draft on the
list as well. 

The latest version can be found here:
http://tools.ietf.org/wg/xrblock/draft-ietf-xrblock-rtcp-xr-delay/

Cheers,
Charles

---

From: "Roni Even" <[email-masked]>
Date: Sat, 28 Jan 2012 11:57:18 +0200

Hi,
I read  the draft and have no issues
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: Saturday, January 21, 2012 12:21 AM
> To: [email-masked]
> Subject: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay
> 
> (As WG Co-Chair)
> 
> This is an announcement of XRBLOCK WG last call on "RTCP XR Report
> Block for Delay metric Reporting" prior to requesting publication of
> the document as a proposed standard.
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Shida Schubert <[email-masked]>
Date: Sun, 29 Jan 2012 19:23:03 +0900

Folks;

 The WGLC for this draft is ending in less than a week 
and we have only received one feedback. I highly 
encourage people to read the draft and provide comments 
or if you have read the current version already and you found 
no issue express it on the list. 

 Many Thanks
  Shida (As Co-Chair)

---

From: Varun Singh <[email-masked]>
Date: Sun, 29 Jan 2012 12:59:50 +0100

Hi,

There is a nit:

 Interval Metric flag (I): 2 bit

      This field is used to indicate whether the Basic Loss/Discard
      metrics ...

Replace Basic loss/discard metric with delay metric.

Otherwise the draft looks okay.

Cheers,
Varun

On Jan 29, 2012, at 11:23, Shida Schubert <[email-masked]> wrote:

Folks;

Many Thanks
 Shida (As Co-Chair)

(As WG Co-Chair)

list as well.

Cheers,

Charles

xrblock mailing list

[email-masked]

---

From: Kevin Gross <[email-masked]>
Date: Sun, 29 Jan 2012 17:19:08 -0700

I would like to suggest that milliseconds are too crude a measurement for
modern IP networks. IP forwarding is accomplished in a small number of
microseconds by current hardware. Many applications operate locally and are
not significantly burdened by the speed of light. Live media and financial
processing applications do take advantage of this performance and would
benefit from improved resolution in these metrics. I would suggest
microsecond precision would be minimally adequate.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Jan 2012 15:51:47 +0800

Agree, will fix this.
  ----- Original Message ----- 
  From: Varun Singh 
  To: Shida Schubert 
  Cc: xrblock 
  Sent: Sunday, January 29, 2012 7:59 PM
  Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

  Hi,

  There is a nit:

      This field is used to indicate whether the Basic Loss/Discard
      metrics ...Replace Basic loss/discard metric with delay metric. 

  Cheers,
  Varun

    Folks;

    Many Thanks
     Shida (As Co-Chair)

      (As WG Co-Chair)

      list as well. 

      Cheers,

      Charles

      xrblock mailing list

      [email-masked]

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Jan 2012 15:51:31 +0800

Hi, Kevin:
The round trip delay metric defined in the draft-ietf-xrblock-rtcp-xr-delay is determined using RTCP SR/RR in RFC3550.
according to the following formula:
round-trip delay = (A - LSR - DLSR)
or using RTCP RRTR/DLRR in RFC3611 according to the following formula:
round -trip delay=(A-LRR-DLRR)

The measurement method for round trip delay is defined in the section 6.4.1 or figure 2 of RFC3550.

With the current measurement method defined in the RFC3550, microsecond precision requirement is hard to be satisifed, since
the measurement precision of the delay metric is limited to far less than the Minimum precision of LSR or DLSR in the above formula. The LSR and DLSR precision
is 1/2^16 second that is greater than 1 microsecond.

Hope this clarifies.

Regards!
-Qin
----- Original Message ----- 
  From: Kevin Gross 
  To: xrblock 
  Sent: Monday, January 30, 2012 8:19 AM
  Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

  I would like to suggest that milliseconds are too crude a measurement for modern IP networks. IP forwarding is accomplished in a small number of microseconds by current hardware. Many applications operate locally and are not significantly burdened by the speed of light. Live media and financial processing applications do take advantage of this performance and would benefit from improved resolution in these metrics. I would suggest microsecond precision would be minimally adequate.

  Kevin Gross

  +1-303-447-0517
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org

    Folks;

     Many Thanks
     Shida (As Co-Chair)

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Jan 2012 21:59:40 +0000

On 20 Jan 2012, at 22:20, Charles Eckel (eckelcu) wrote:
> This is an announcement of XRBLOCK WG last call on "RTCP XR Report Block for Delay metric Reporting" prior to requesting publication of the document as a proposed standard. 
> 

In general, this looks fine. I have some minor comments:

- Reference [MEASI] is required to be sent by Section 3, and so should be a normative reference.

- Section 3.2, clarify that the block MUST be ignored if the block length is different to 3 (since this is invalid).

- Section 3.2, since many of the metrics are calculated based on SR/RR values, it might make sense to report them in 1/65536 of a second units, rather than in milliseconds, to match the definition of the LSR and DLSR fields in RTCP SR/RR packets (and avoid rounding errors).

I also noticed a number of editorial issues:

- The Title and Abstract should both expand "RTCP XR Report Block" to "RTP Control Protocol (RTCP) Extended Report (XR) Block". 

- This has a dependency on the monarch draft, and so should wait in the RFC Editor queue until that's complete. This should possibly be a normative dependency, which would require moving reference [MONARCH] into Section 8.1, and updating Section 1.1 to remove "(work in progress)" since this would wait for monarch.

- The subsection headings in Sections 1 and 2 serve little purpose, and could be removed. 

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 31 Jan 2012 11:23:53 +0800

Hi, Colin:
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Charles Eckel" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 31, 2012 5:59 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay

> - Reference [MEASI] is required to be sent by Section 3, and so should be a normative reference.

[Qin]: Okay.

> - Section 3.2, clarify that the block MUST be ignored if the block length is different to 3 (since this is invalid).

[Qin]: Good point and will do this in the update.

> - Section 3.2, since many of the metrics are calculated based on SR/RR values, it might make sense to report them in 1/65536 of a second units, rather than in milliseconds, to match the definition…

[Qin]: That's a good proposal unless we have better measurement method than that using SR/RR. 
In that case, the report value can be simply calculated by (A-LSR)*65536-DLSR.

> - The Title and Abstract should both expand "RTCP XR Report Block" to "RTP Control Protocol (RTCP) Extended Report (XR) Block". 

[Qin]: Okay.

> - This has a dependency on the monarch draft, and so should wait in the RFC Editor queue until that's complete. This should possibly be a normative dependency, which would require moving reference…

[Qin]: Fair.

> - The subsection headings in Sections 1 and 2 serve little purpose, and could be removed. 

[Qin]: Agree.