RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting
RFC 6843
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Gonzalo Camarillo; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
Nicely written document. Just one non-blocking comment that you needn't respond to.
-- Section 3.2 --
A very minor point, but I find the double-parenthesised explanation of the Interval Metric Flag to be somewhat awkward. I will suggest this, but if you don't want to change it that's also fine:
NEW
This field is used to indicate whether the Delay metrics are
Sampled, Interval or Cumulative metrics:
I=10: Interval Duration - the reported value applies to the most
recent measurement interval duration between successive metrics
reports.
I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative measurements.
I=01: Sampled Value - the reported value is a sampled instantaneous
value.
END
(Benoît Claise; former steering group member) (was Discuss) No Objection
Thanks for addressing my comments, copied over here, for historical reasons:
In one of my previous DISCUSS-DISCUSS on xr-block, we settle on:
- RFC 6390 template is required for new perf metric definition
- RFC 6390 template is a nice-to-have when we refer to an existing
perf metric
Nice-to-have because the performance metric reference doesn't
always include all the required information about: measurement
points, measurement timing, use and applications, reporting model,
etc... but focus only on the "Method of Measurement or
Calculation"
It might not be fair to change the requirements on this document, while it left the WG some time ago. So I'm ready to let go without the RFC6390 template (http://tools.ietf.org/html/rfc6390#section-5.4.4)
So I'm not opposed to the publication of this document for THAT reason. Note that I will be stricter with future documents.
However, back to this document. You should do a better job of documenting what is required, both from an implementer point of view, and the performance metrics semantic, for someone who might want to(re)- use the metric.
Feel free to discuss with me if I can be of any help
For example: the measurement period is mentioned multiple times in the metric definitions
Mean Network Round Trip Delay: 32 bits
The Mean Network Round Trip Delay is the mean value of the RTP-to-
RTP interface round trip delay over the measurement period,
expressed in units of 1/65536 seconds.
However, you don't mention where to find it.
I guess it relates to the measurement interval mentioned in
This metric block
relies on the measurement interval in the Measurement Information
block indicating the span of the report and SHOULD be sent in the
same compound RTCP packet as the measurement information block.
Assuming that the readers understand that the two different names are related, it doesn't tell where to find this information. Is this in http://datatracker.ietf.org/doc/rfc6776/ ?
For example,
Min Network Round Trip Delay: 32 bits
The Min Network Round Trip Delay is the minimum value of the RTP-
to-RTP interface round trip delay over the measurement period,
expressed in units of 1/65536 seconds. This value is typically
determined using RTCP SR/RR. It also can be determined using RTCP
Receiver Reference Time Report Block and DLRR Report Block.
The last two sentences. Why not be a little bit more explicit, telling exactly which fields need to be taken into consideration from RTCP SR/SR and from DLRR report block.
(Brian Haberman; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) No Objection
- 3.2: Is the reference to 3611, section 4.1 correct as a definition for SSRC? - Not a comment on this draft, but rfc 3611 says that XR packets should not be encrypted. Has anyone looked to see if the information leaked by reporting like this could expose information about encrypted e.g. VoIP traffic? For example, the SSRC will be sent in this report in clear, so one might wonder if that could help someone attack elsewhere. Since the xrblock WG are doing a bunch of these, I guess it migth be worth some thought to see if there are any bad security effects with all of that.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection