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

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

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Wednesday, February 12, 2014 6:26 AM
> To: Huangyihong (Rachel)
> Cc: Roni Even; xrblock
> Subject: 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/
> 
> 