Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03

From: Colin Perkins <[email-masked]>
Date: Wed, 11 Jun 2014 18:07:18 +0100

On 28 May 2014, at 14:12, Romascanu, Dan (Dan) <[email-masked]> wrote:
> This is a Working Group Last Call for the Internet-Draft ‘RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics’ - http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03.txt.
>  
> Please send your comments to the WG mail list before 6/11 COB. If you are happy with the current I-D and support sending it to the IESG for consideration as Standards Track document please send a short mail stating  this.

I think this metric is appropriate, and the document is generally in good shape. I support publication. However, I do have some minor comments:

- The 2nd paragraph of the Introduction includes the text “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. 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.” This text is entirely appropriate, and needs to be in the draft, but it doesn’t read like introductory material, since it specifies requirements. I suggest this part of the 2nd paragraph of the Introduction move into Section 3 of the draft (with the remainder of the 2nd paragraph of the Introduction staying where it is). 

- The 2nd paragraph of the Introduction concludes by stating that “metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of [RFC3550]”. Can you explain why not? Surely the entire point of this metric is to directly compare the pre-repair and post-repair loss, to see how well a repair scheme is working?

- Section 2 contains a reference to [RFC2119]. The references have [KEYWORDS] but not [RFC2119].

- Section 5 contains references to [I-D.ietf-avtcore-srtp-not-mandatory] and [I-D.ietf-avtcore-rtp-security-options]. Neither appears in the References section. Both have now been published as RFCs.

Colin

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 12 Jun 2014 02:23:14 +0000

Hi Colin

Thank you for the careful review. Please see my answers inline.

BR,
Rachel

> -----Original Message-----
> From: xrblock [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, June 12, 2014 1:07 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [xrblock] WGLC for
> draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03
> 
> > This is a Working Group Last Call for the Internet-Draft 'RTP Control Protocol
> (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics' -
> http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03.txt.
> >
> > Please send your comments to the WG mail list before 6/11 COB. If you are
> happy with the current I-D and support sending it to the IESG for consideration
> as Standards Track document please send a short mail stating  this.
> 
> I think this metric is appropriate, and the document is generally in good shape.
> I support publication. However, I do have some minor comments:
> 
> - The 2nd paragraph of the Introduction includes the text "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. 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." This
> text is entirely appropriate, and needs to be in the draft, but it doesn't read
> like introductory material, since it specifies requirements. I suggest this part of
> the 2nd paragraph of the Introduction move into Section 3 of the draft (with the
> remainder of the 2nd paragraph of the Introduction staying where it is).

[Rachel]: Good suggestion. Will do.
> 
> - The 2nd paragraph of the Introduction concludes by stating that "metrics in
> this report block MUST NOT be directly compared with the pre-repair loss
> metric of [RFC3550]". Can you explain why not? Surely the entire point of this
> metric is to directly compare the pre-repair and post-repair loss, to see how
> well a repair scheme is working?

[Rachel]: This report block has the same reporting interval with standard SR/RR, but the lost packet contained in loss metric of SR/RR may not be all repaired. Some of them may be repaired in the next interval or next several interval. The metrics in our report block count those repaired packets and packets that can't be repaired, which can reflect the effect of repair mechanisms and the final lost packets. They can't be directly compared with the loss metric in SR/RR, because the repaired loss count + packets count that can't be repaired may be less than the loss metric from SR/RR.

> - Section 5 contains references to [I-D.ietf-avtcore-srtp-not-mandatory] and
> [I-D.ietf-avtcore-rtp-security-options]. Neither appears in the References
> section. Both have now been published as RFCs.

[Rachel]: Good catch. Will fix it
> 
> Colin
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 Jun 2014 12:01:09 +0100

Rachel,

On 12 Jun 2014, at 03:23, Huangyihong (Rachel) <[email-masked]> wrote:
> [Rachel]: This report block has the same reporting interval with standard SR/RR, but the lost packet contained in loss metric of SR/RR may not be all repaired. Some of them may be repaired in the next interval or next several interval. The metrics in our report block count those repaired packets and packets that can't be repaired, which can reflect the effect of repair mechanisms and the final lost packets. They can’t be directly compared with the loss metric in SR/RR, because the repaired loss count + packets count that can't be repaired may be less than the loss metric from SR/RR.

That makes sense. I think you should include such an explanation in the draft.

Colin

---

From: Varun Singh <[email-masked]>
Date: Thu, 12 Jun 2014 14:02:16 +0300

Hi Colin,

Thanks for the review, discussing one comment inline.

Cheers,
Varun

> - The 2nd paragraph of the Introduction concludes by stating that “metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of [RFC3550]”. Can you explain why not?…

To compare the performance the endpoint can just calculate:
repaired/(unrepaired+repaired)?
The main reason for not comparing is that the begin_seq and end_seq
may not correspond to the sequence number HSN_prev_rr and HSN_now_rr,
if they did then the difference between the cumulative number of
packets lost would show the performance of the repair scheme.

Also if the begin_seq is the first packet of the session and the
end_seq is the last packets received, then the cumulative number of
packets lost could be directly compared with the repaired packets

cumulative number of packets lost = lost packets that cannot be
repaired + repaired loss packets + to be repaired lost packet.
For example, cumulative loss from the beginning of the session.
1 =  0 + 0 + 1
4 =  1 + 1 + 2
6 =  2 + 3 + 1

Does this make sense? Does the above explanation need to be some how
incorporated in to the draft?

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 Jun 2014 12:09:02 +0100

Hi Varun,

On 12 Jun 2014, at 12:02, Varun Singh <[email-masked]> wrote:
…
> For example, cumulative loss from the beginning of the session.

Yes, it makes sense. I do think you should include an explanation along these lines in the draft.

Cheers,
Colin

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