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

[Colin Perkins <[e-mail]>]

Hi,

On 10 Feb 2014, at 10:44, Roni Even <[e-mail]> 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. 

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. 

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.

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. 

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