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

Rachel,

One quick reply inline. 
Colin

On 11 Feb 2014, at 03:35, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:
> 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. 

That could be fine, provided “primary source packet” is defined clearly in the draft.

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

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