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

[Alissa Cooper <[e-mail]>]

Hi Rachel,

Thanks, responses inline.

On Dec 8, 2014, at 7:23 PM, Huangyihong (Rachel) <[e-mail]> wrote:

> "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. 

Ok. I would suggest the following change to clarify:

OLD
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.

NEW
   This block needs to specify its own measurement period to avoid ambiguity in calculating the post-repair loss count. The sequence number range reported by RTCP
   SR/RR may contain some sequence numbers of packets for which repair
   might still be possible. To avoid the ambiguity, 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.

> 
> "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.

Ok. I would suggest:

"Note that this metric must measure only primary source RTP packets."

Also, does that “must” need to be a normative MUST for interoperability?

> 
> = 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. 

Well, I guess I did not ask about this for those RFCs, but I would like to understand better what the point of the template is if all the templates end up linking the reader back to various sections of the document.

Alissa

> 
> == 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock