Re: [xrblock] FW: [pm-dir] RFC 6390 REVIEW of https://www.ietf.org/id/draft-ietf-xrblock-independent-burst-gap-discard-00.txt

Hi Jan,

Just back from vacation, and reading the mailing list.
Thank you for reviewing the document.
Comments are inline.

Regards.
Varun

> From: Jan Novak [mailto:jjjnovak@hotmail.com]
> Sent: Friday, January 08, 2016 2:44 AM
> To: Romascanu, Dan (Dan); MORTON, ALFRED C (AL); pm-dir@ietf.org
> Cc: shida@ntt-at.com; Benoit Claise bclaise@cisco.com; alissa@cooperw.in
> Subject: [pm-dir] RFC 6390 REVIEW of
> https://www.ietf.org/id/draft-ietf-xrblock-independent-burst-gap-discard-00.txt
>
>
>
> Hi,
>
>
>
> I have read through this draft and browsed through the related RFC7002 and
> 7003 used as references
>
> with the following conclusions/observations:
>
>
>
> Conclusion:
>
> This document emphasis (and also RFC7002/3) is on specifying the report
> packet format or simply reporting some values but
>
> not really specifying what the exported values are. Two of the
> metrics/values seem to be just simple counters/numbers (e.g.
>
> not really needing more definitions), the other two are referenced to be
> defined in RFC7002/7003 . RFC6390 does not really
>
> feel applicable for any of these three documents - there ought to be another
> document describing what all the metrics are,
>
> defining them in RFC6390 normative format and describing how and where they
> are measured unless there already is another
>
> document defining them - if so, it should be referenced here instead of
> 7002/7003.
>

Will again have a look at the documents and get back to you on this.

>
>
> Observations:
>
> 1) The term "discard burst" seems to be crucial for all the metrics but none
> of the three documents contains any
>
>      definition other than just the reader's intuitive notion of its meaning
>

I believe we want to use the guidance given in RFC3611 for burst loss
definition,
which relies on 16 packets as a burst:

   A Gmin value of 16 is RECOMMENDED, as it results in gap
   characteristics that correspond to good quality (i.e., low packet
   loss rate, a minimum distance of 16 received packets between lost
   packets), and hence differentiates nicely between good and poor
   quality periods.

However, this is a recommendation, and can be modified without
signaling. If we want to make it explicit, then this would need to be
signaled as an 8-bit number.

> 2) The two metrics "Packets Discarded in Bursts" and "Discard Count" are
> referenced to the same section of
>
>     RFC7002 which contains exactly same wording as this document for
> "Discard Count" with no further definition.
>
>     I am not familiar with RTP quality metrics so just assume that there
> could be other packet losses/packet discards
>
>     than during the discard bursts to make the two values different.
>

I am not sure but let me try to explain (and see if this would need to
be folded back into the document):

Losses are packets that are not received, meanwhile, discards are
packets that are received but removed by the RTP Receiver from the
playout on reception.
The packet may be discarded due to early or late arrival (i.e.,
compared to the playout time), or be a duplicate.

>  3)  Similarly "Total Packets Expected in Bursts" is referenced to RFC7003
> with exactly same wording as this
>
>     document - assuming that the term "discarded bursts" is a typo for
> "discard burst"
>

Will make it consistent with other documents.

>
>
> Jan
>
>
>
> The climate of Edinburgh is such that the weak succumb young ... and the
> strong envy them.
>
>                                     Dr. Johnson
>
>
>
>
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
>

-- 
http://www.callstats.io