Re: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10: (with DISCUSS and COMMENT)

[Varun Singh <[e-mail]>]

Hi Benoit,

Thank you for reviewing the proposal, comments inline.


> On 16 Feb 2015, at 11:14, Benoit Claise <[e-mail]> wrote:
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The following MUST versus RECOMMENDED is still an issue
> 
>  post-repair loss count: 16 bits
> 
>      Total number of packets finally lost after applying one or more
>      loss-repair methods, e.g., FEC and/or retransmission, during the
>      actual sequence number range indicated by begin_seq and end_seq.
>      This metric MUST NOT count the lost packets for which repair might
>      still be possible. 
> 
> This goes against
> 
> 2. Interval report
> 
>   Some implementations may align the begin_seq and end_seq number with
>   the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
>   This is NOT RECOMMENDED as packets that are not yet repaired in this
>   current RTCP interval and may repaired in the future will not be
>   reported in subsequent reports.
> 


The not recommended is if the receiver strictly aligns the begin_seq and end_seq to 
the HSNs of consecutive reports. Example below:

a) HSN is 20, begin_seq is 10 end_seq is 20.
b) HSN is 30, begin_seq is 20 end_seq is 30.
If 17 and 19 were packets lost and not yet repaired in a) and 
subsequently repaired in b) then it won't be reported because the 
sequence numbers do not belong in b)’s interval, but to the previous 
begin and end seq, therefore it is not recommended to align the begin_seq 
and end_seq to HSN of consecutive RTCP reports, unless repairs occur 
within that interval. 

Hence, (hopefully the next paragraph in the section clarifies) receivers 
should prefer begin_ and end_seq use longer than an RTCP interval.


> 
> I understand the explanations you provided in the past. The only logical
> solution is to change the "MUST NOT" with "NOT RECOMMENDED"
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> Thanks, the draft improved.
> However, There are still sentences that I had to read multiple times, to
> "get" them. I believe that I have spent enough time on this draft by now.
> So will not comment on those.
> 
> -
> 
>   in 6 still to be repaired lost packet = cumulative number of packets
>   lost - cumulative post-repair loss count -  cumulative repaired loss
>   count
> 
> "in 6”?

I assume this is an .nroff error, indent 6 spaces? 

> 
> - Why doesn't this section 3 mention "repaired loss count"?
> 

I am not sure what you mean, however 3.1 has the following:

repaired loss count: 16 bits

      Total number of packets fully repaired after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      Note that this metric MUST measure only primary source RTP
      packets.