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

[Qin Wu <[e-mail]>]

Hi,
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Romascanu, Dan (Dan) ; Varun Singh ; [e-mail] 
  Sent: Saturday, December 22, 2012 6:19 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt


  Discussion below...


  On Mon, Dec 17, 2012 at 6:38 PM, Qin Wu <[e-mail]> wrote:


      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.


  [KG] I've seen recent discussion from others that leads me to wonder whether they're going to be OK with it. I hope this proposal can get a more thorough review before being included in the draft.

[Qin]: Good.


      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.

    "


  [KG] I did not claim there was anything broken in the draft so I am confused that you claim to have fixed it. If your "Yes" reply was in response to "Is requirement to discard reports with unexpected length common practice with these reports?" it would be helpful to point out a draft or two on which you've modeled this behavior.

[Qin]:Sorry for my misunderstanding what you said above. My answer to your question "Is requirement to discard reports with unexpected length common practice with these reports?" . The reason we add "The block MUST be discarded if the block length is set to a different value." is becos somebody raised commments to say "what the receiver will do if the block lenght is set to a different value". I assume it was Dan. That's why we bring this proposal. currently this proposal applies to burst gap loss draft, burst gap discard draft, jb draft and discard draft.To be consistent with RFC3611,already published RFC6798 and my answer to your question, it looks to me the proposed text "The block MUST be discarded if the block length is
 set to a different value." doesn't need.





      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.


  We need a definition for the "exactly on time". Exactly on time according to whom and with respect to what? 

[Qin]:It relies on "implementation specific time window" just like burst gap loss, burst discard did, i.e., if a packet arrives within this window and can be successuflly played out, this packet will be the packet that arrive exactly on time. please see the term "Received, Lost and Discarded" in the section 2.1 of burst gap loss draft for "implementation specific time window"

  The other reference point is playout time. This also needs to be defined. Playout of first byte in the payload?

[Qin]: I agree with you, your understanding to the playout time is more accurate.
      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.
    "


  I need more information before making a proposal. Who do we expect will use Jitter buffer nominal delay information and for what purpose? 
[Qin]: Network manager may want to measure what impact the jitter buffer have on a VOIP service or IPTV service or we can say jitter buffer metric is one important quality of service factor in
assessment of the end to end network performance including both transport performance and end system performance or in evaluation of the user perception of the service in end to end mode.
      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"


  I can't evaluate this proposal until I understand who we expect will use Jitter buffer maximum delay information and for what purpose.

[Qin]:See above.


      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.

    "

  This looks like an improvement but I can't fully evaluate the proposal until we address the issues above and have a better definition for Jitter buffer nominal delay.
[Qin]: Okay.