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

From: "Roni Even" <[email-masked]>
Date: Mon, 10 Feb 2014 12:44:43 +0200

Hi,

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

Roni Even

---

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Feb 2014 23:39:59 +0000

Hi,

On 10 Feb 2014, at 10:44, Roni Even <[email-masked]> wrote:
> 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/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 11 Feb 2014 02:56:59 +0000

Hi Roni,

Thank you for your comments. Please see inline.

Best regards,
Rachel

From: xrblock [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Monday, February 10, 2014 6:45 PM
To: 'xrblock'
Subject: [xrblock] review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count

Hi,

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?
           [Rachel]: The delay is raised in [RFC5725]. Yes, I think it indicates 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
           [Rachel]: Will fix it.  Thanks.

Roni Even

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 11 Feb 2014 03:35:21 +0000

Hi Colin,

Thanks for your comments. Please see inline.

Best regards,
Rachel

> -----Original Message-----
> From: xrblock [mailto:[email-masked]] 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,
> 
> > 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
> 

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Feb 2014 22:25:47 +0000

Rachel,

One quick reply inline. 
Colin

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

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 12 Feb 2014 03:06:36 +0000

Hi Colin,

How about the following definition?

"primary source packet: the original RTP packet sent from the RTP sender for the first time. A primary source packet may be lost when transporting. The lost one can be repaired by mechanisms like FEC or retransmission."

Best regards,
Rachel

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2014 6:26 AM
> To: Huangyihong (Rachel)
> Cc: Roni Even; xrblock
> > 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.
>