Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06

Hi Alissa,

Thanks for the comments. Please see inline.

BR,
Rachel

-----邮件原件-----
发件人: xrblock [mailto:xrblock-bounces@ietf.org] 代表 Alissa Cooper
发送时间: 2014年12月9日 8:55
收件人: xrblock@ietf.org
主题: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06

I have reviewed this draft in preparation for IETF LC and I have some comments and questions before proceeding with the LC announcement.

= Section 3 =
"When comparing this metric
  with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as
  noted in [RFC5725]: Some packets will not be repaired in current RTCP
  interval. Thus it is RECOMMENDED that this report block should be
  generated for those source packets that have no further chance of
  being repaired.”

The analogous text in RFC 5725 specifies both the recommended behavior and the behavior that is not recommended:

"To avoid any ambiguity in the evaluation, it is RECOMMENDED that the post-repair
  Loss RLE be generated for the source packets that have no further
  chance of being repaired.  If the loss-repair method(s) may still
  recover one or more missing source packets, the post-repair Loss RLE
  SHOULD NOT be sent until the loss-recovery process has been
  completed.”

It seems like this document should also specify what is not recommended, otherwise it seems a little vague. Another approach could be to say "Thus it is RECOMMENDED that this report block should be generated only for those source packets that have no further chance of being repaired and not for any other packets."

[Rachel]: All right. It will be addressed in the new version.

"But a potential ambiguity may result from sequence
  number range inconsistent. The sequence number range reported by RTCP
  SR/RR may contain some sequence numbers of packets for which repair
  might still be possible. To address this issue, we use begin sequence
  number and end sequence number to explicitly indicate the actual
  sequence number range that this RTCP XR report block reports on as
  the measurement timing.”

I don’t really understand what the stated ambiguity is here, or how it is addressed by including begin_seq and end_seq. As long as the “unrepaired loss count” field is defined as number of packets lost for which repair is no longer possible, what is inconsistent or ambiguous, and how does specifying the sequence number range change anything?

[Rachel]: If we don't use begin sequence number and end sequence number, this report block must rely on the Measurement Information Block [RFC6776] to indicate the measurement period, which is also shared with other metrics that may also be pre-pair metrics. For a pre-pair measurement period, number of packets lost = "unrepaired loss count" + "repaired loss count" + to be repaired loss count. But we have recommended that our report block should be only generated for those post-repair packets, because we have to compare the post-repair metrics with pre-pair metrics to show how good the repair mechanisms is. That means the lost packets to be repaired later are not counted. Thus we have to use different measurement period (the separate begin and end sequence numbers) from those who use the Measurement Information Block. 

"Note that this metric must be measured in the primary source RTP packets.”

I’m not sure what this means.

[Rachel]: Section 2 have specified the primary source RTP packet. The primary source RTP packets are original RTP packets sent from the RTP sender for the first time. A lost primary source RTP packet can be repaired by other non-primary source RTP packets, like retransmission RTP packets or FEC packets. The metrics in this report block only measure the primary source RTP packets, and don’t' consider other RTP packets.

= Appendix A =
Doesn’t it sort of defeat the purpose of the 6390 template to fill out a template with a bunch of links back to the definitions of the fields in other parts of the document, rather than putting those definitions directly in the template? I mean, isn’t the point of the template to have all of the information concisely reported in one place?

[Rachel]: I referenced previous RFCs, like [RFC7243] [RFC7294]. But it's okay for me to have those definitions directly copied in the template if you want. 

== Nits to be resolved with any IETF LC comments ==

= Section 1 =
RTCP SR/RR ― expand SR/RR on first use

s/cumulative number of packet lost/cumulative number of packets lost/

s/a range of RTP application/a range of RTP applications/

OLD
The metrics defined in this document belongs to the class of
  transport-related metrics defined in [RFC6792]. And it is in
  accordance with the guidelines in [RFC6390] and [RFC6792].

NEW
The metrics defined in this document belong to the class of
  transport-related metrics defined in [RFC6792] and are specified in
  accordance with the guidelines in [RFC6390] and [RFC6792].

= Section 3 =
s/in current RTCP interval/in the current RTCP interval/

= Section 4.2 =
s/for unilateral parameter/for unilateral parameters/ _______________________________________________

[Rachel]: All are accepted^^.

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