Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt

[Qin Wu <[e-mail]>]

Hi, Kevin:
Thank for your feedback and valuable review. Please see my reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Romascanu, Dan (Dan) ; Varun Singh ; [e-mail] 
  Sent: Tuesday, December 18, 2012 5:41 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt


  Sorry for the delay in getting these comments published. I had originally reviewed version 01. Some of my minor comments were resolved in this new version and so are not included here.




  Section 1.2


  RFC 3611 is still in force - 
  s/[RFC3611] defined/[RFC3611] defines


[Qin]:Okay.

  Section 1.3


  Missing conjunction - 
  s/guidelines in [RFC6390][RFC6792]/guidelines in [RFC6390] and [RFC6792]



[Qin]:Okay.

  Section 3.2


  Jitter Buffer Configuration
  I think the two reporting options are potentially over simplification of how these systems can work. An adaptive receiver has to adapt to maximum latency and to delay variation. The former is accomplish by adjusting the playout delay, the latter by reallocating buffer space. I suggest we might want to report these behaviors separately, for example:
    00 - fixed jitter buffer and delay
    10 - adaptive playout delay
    01 - adaptive buffer size
    11 - adaptive delay and size

[Qin]:Sounds good to me.


  Block length
  Is requirement to discard reports with unexpected length common practice with these reports? The alternative is to allow reports to be revised to increased size with appended data. Original implementations then ignore anything beyond the original size. It's a little more flexible but maybe we don't want to go there. I've checked RFC 3611 and don't see any guidance on this. It would be nice to specify consistent behavior around this for all reports.

[Qin]:Yes. I have fixed this with adding the following sentence to say:
"
The block MUST be discarded if the block length is

      set to a different value.

"


  Jitter buffer nominal delay
  Needs to specify reference points for reported delay: From receipt to playout? From RTP timestamp to playout?

[Qin]:One reference point is the packet that arrives exact on time.
  If one of the reference points is a playout time, and depending on expected use cases, higher resolution may be justified here.
[Qin]:What's your suggested change? How about adding the following sentence to say:
"
It is calculated based on the difference between the receipt time and playout time for the packet that 
arrives exactly on time.
"
  Jitter buffer maximum delay
  Needs to specify reference points for reported delay: From receipt to playout? From RTP timestamp to playout?

[Qin]: How about adding the following sentence to say:
"
Jitter buffer maximum delay is calculated based on the difference between the receipt time and playout time
for the earliest arriving packet"


  Another clarification - 
  s/correspond to the nominal size./correspond to the size of the jitter buffer.

[Qin]: Make sense to me.


  Jitter buffer high water mark
  Explain whether this applies to fixed jitter buffer or only to adaptive.
[Qin]: I think "Jitter buffer high water mark" applies to adaptive jitter buffer implementation.
its value MUST be set to jitter buffer maximum delay for fixed jitter buffer implementations.
How about adding one sentence to say:
"
This parameter MUST be provided for
 adaptive jitter buffer implementations and its value MUST be
 set to JB maximum for fixed jitter buffer implementations.

"




  Jitter buffer low water mark
  Explain whether this applies to fixed jitter buffer or only to adaptive.

[Qin]:Same proposed change above.



  Kevin Gross
  [phone]
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org




  On Mon, Nov 26, 2012 at 5:51 PM, Qin Wu <[e-mail]> wrote:

    Sorry, I forgot what Kevin said in the last presentation.
    I think Dan's proposal looks good.:-)

    Regards!
    -Qin

    ----- Original Message -----
    From: "Romascanu, Dan (Dan)" <[e-mail]>
    To: "Varun Singh" <[e-mail]>
    Cc: "Qin Wu" <[e-mail]>; <[e-mail]>
    Sent: Monday, November 26, 2012 9:25 PM
    Subject: RE: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt


    Indeed, this was Kevin Gross.

    The question is whether Kevin's comments could be made during the WGLC, or they are severe enough to make us wait before issuing a LC. I hope that Kevin can answer this.

    Thanks and Regards,

    Dan



    > -----Original Message-----
    > From: Varun Singh [mailto:[e-mail]]
    > Sent: Monday, November 26, 2012 3:18 PM
    > To: Romascanu, Dan (Dan)
    > Cc: Qin Wu; [e-mail]
    > Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-
    > 02.txt
    >
    > Hi,
    >
    > AFAIR, someone (maybe Kevin Gross) remarked that he had some comments on
    > the draft.
    >
    > Regards,
    > Varun
    >
    > ----
    > http://www.netlab.tkk.fi/~varun
    >
    > On 26.11.2012, at 18.10, "Romascanu, Dan (Dan)" <[e-mail]>
    > wrote:
    >
    > > Thanks, Qin.
    > >
    > > Unless somebody has good reasons to object we shall issue the last
    > call in the coming days.
    > >
    > > Regards,
    > >
    > > Dan
    > >
    > >
    > >
    > >> -----Original Message-----
    > >> From: [e-mail] [mailto:[e-mail]] On
    > >> Behalf Of Qin Wu
    > >> Sent: Monday, November 26, 2012 10:57 AM
    > >> To: [e-mail]
    > >> Subject: [xrblock] Fw: I-D Action:
    > >> draft-ietf-xrblock-rtcp-xr-jb-02.txt
    > >>
    > >> On 26 November , 2012 4:54 PM, [e-mail] wrote:
    > >>>
    > >>> A New Internet-Draft is available from the on-line Internet-Drafts
    > >> directories.
    > >>> This draft is a work item of the Metric Blocks for use with RTCP's
    > >> Extended Report Framework Working Group of the IETF.
    > >>>
    > >>> Title           : RTP Control Protocol (RTCP) Extended Report (XR)
    > >> Block for Jitter Buffer Metric Reporting
    > >>> Author(s)       : Alan Clark
    > >>>                         Varun Singh
    > >>>                         Qin Wu
    > >>> Filename        : draft-ietf-xrblock-rtcp-xr-jb-02.txt
    > >>> Pages           : 14
    > >>> Date            : 2012-11-26
    > >>>
    > >>> Abstract:
    > >>>  This document defines an RTP Control Protocol (RTCP) Extended
    > >>> Report
    > >>>  (XR) Block that allows the reporting of Jitter Buffer metrics for a
    > >>> range of RTP applications.
    > >>>
    > >>>
    > >>> The IETF datatracker status page for this draft is:
    > >>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-jb
    > >>
    > >>
    > >> [Qin]: I believe this version address resolve the comments discussed
    > >> in the last Atalanta IETF meeting and now is ready for WGLC.
    > >> _______________________________________________
    > >> xrblock mailing list
    > >> [e-mail]
    > >> https://www.ietf.org/mailman/listinfo/xrblock
    > > _______________________________________________
    > > xrblock mailing list
    > > [e-mail]
    > > https://www.ietf.org/mailman/listinfo/xrblock
    _______________________________________________
    xrblock mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/xrblock