Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count

Hi Colin,

Thanks for your comments. Please see inline.

Best regards,
Rachel

> -----Original Message-----
> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin
> Perkins
> Sent: Tuesday, February 11, 2014 7:40 AM
> To: Roni Even
> Cc: xrblock
> Subject: Re: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-
> repair-loss-count
> 
> Hi,
> 
> On 10 Feb 2014, at 10:44, Roni Even <ron.even.tlv@gmail.com> wrote:
> > I reviewed the draft and it looks OK some small comments
> >
> > 1.       Section 1 discuss the delay of the reporting to allow for
> the repair to take place. There may be a difference in the delay
> between conversional services and streaming application. Is the delay
> related to the jitter buffer size?
> > 2.       In section 3 "begin_seq", I am not sure why you have two
> options and why not use the RFC3611 definition
> 
> I agree with Roni that the definitions of begin_seq and end_seq are
> hard to follow in this draft.

Will fix this.

> 
> It's also not clear why the un-repaired loss count and repaired loss
> count fields are 32 bits in size. For the end_seq field to be
> unambiguous it has to be within a single RTP sequence number cycle of
> the begin_seq field. This implies that at most 2^16 packets can be lost
> in a single reporting interval, so the loss counts can be reduced to 16
> bits, saving four octets overall.
> 
Good point. 16-bit is sufficient. 

> Both metrics say "this metric must be measured in the primary source
> stream", but the draft doesn't define what is meant by the primary
> source stream. The phrasing would lead me to think the FEC and/or
> retransmission is sent separately to the media, but we have some
> formats that send FEC in the same packet stream (and in some cases in
> the same packets) as the original media; the distinction between
> primary source stream and repair stream is unclear in these cases.
> 
How about changing to "primary source packets"? Even if FEC/retransmission is the same packet with primary source content, this packet is also primary source packet and should be measured. 

> The phrase "lost packets that haven't finished repairing" is not clear,
> since a packet has either been repaired or not, and isn't generally in
> the process of being repaired. A clearer wording may be "packets for
> which repair might still be possible"? It might be helpful to
> explicitly define the conditions under which a packet is considered no
> longer possible to repair.

Good suggestion. Thanks.

> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock