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

From: Qin Wu <[email-masked]>
Date: Fri, 6 Apr 2012 17:29:43 +0800

On 06 April, 2012 5:23 PM, [email-masked] 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           : RTCP XR Report Block for Delay metric Reporting
> Author(s)       : Geoff Hunt
>                          Alan Clark
>                          Kevin Gross
>                          Qin Wu
> Filename        : draft-ietf-xrblock-rtcp-xr-delay-02.txt
> Pages           : 14
> Date            : 2012-04-06
> 
>   This document defines an RTCP XR Report Block that allows the
>   reporting of Delay metrics for use in a range of RTP applications.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-delay-02.txt

This version addresses the open issue we discussed in the Paris meeting.

- Change 16 bit metric in Report Block into 32 bit metric
- Change metric unit in ms to 1/65536 second.

---

From: Kevin Gross <[email-masked]>
Date: Thu, 12 Apr 2012 17:31:31 -0600

I'm afraid there are still significant problems with this draft.

Glen Zorn submitted useful comments on 3 February. You (Qin) and he (Glen)
had additional correspondence on 6 February and you agreed to make changes.
It doesn't appear that any of these agreed changes were made.

Section 1.2: ...[RFC3611] defines...

Section 3.2: Remove 0xFFFE special value in Mean Network Round Trip Delay, End
System Delay, Min Network Round Trip Delay and Max Network Round Trip
Delay. New 32-bit values can represent delays up to 65536 seconds (18
hours) and so would not be expected to overflow. Change special unavailable
value to 0xFFFFFFFF.

On 8 February I suggested and justified a 64-bit value for End System
Delay. You replied on 16 March with agreement. The field is 32 bits in the
latest draft.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Fri, Apr 6, 2012 at 3:29 AM, Qin Wu <[email-masked]> 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.
> >
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Apr 2012 10:28:16 +0800

Hi,Kevin:
Thank for your valuable and timely comments.:-)
please see my replies inline below.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Friday, April 13, 2012 7:31 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

  Glen Zorn submitted useful comments on 3 February. You (Qin) and he (Glen) had additional correspondence on 6 February and you agreed to make changes. It doesn't appear that any of these agreed changes were made.
[Qin]: My fault, I forgot to incorporate these comments into the update.
I will fix this in the new version, thanks.
  Section 1.2: ...[RFC3611] defines...
[Qin]: That's one nits, I will remove additional space before "[RFC3611] defines".

  Section 3.2: Remove 0xFFFE special value in Mean Network Round Trip Delay, End System Delay, Min Network Round Trip Delay and Max Network Round Trip Delay. New 32-bit values can represent delays up to 65536 seconds (18 hours) and so would not be expected to overflow. Change special unavailable value to 0xFFFFFFFF.
[Qin]: My fault, I forgot to update this part when we expand 16bit metric into 32bit metric. I agree to change unavailable value to 0xFFFFFFF. However I am thinking it is no harm and safe to keep the overrange value 0xFFFFFFFE, So I propose the following change:
OLD Text:
"
     If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be
      reported to indicate an over-range measurement.  If the
      measurement is unavailable, the value 0xFFFF SHOULD be reported.

"
New Text:
"
     If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE SHOULD be
      reported to indicate an over-range measurement.  If the
      measurement is unavailable, the value 0xFFFFFFFF SHOULD be reported.

"
What do you think of it?

  On 8 February I suggested and justified a 64-bit value for End System Delay. You replied on 16 March with agreement. The field is 32 bits in the latest draft.
[Qin]: Sorry, do I misundertand your proposal you gave before Paris meeting regarding End system delay metric?
I check your message posting on 8 February as follows:

http://www.ietf.org/mail-archive/web/xrblock/current/msg00364.html

I fail to see your justification to use 64-bit value for End system delay?
what range do you think is needed for end system delay? 
Isn't enough to use 32bit for End System Delay? 

Kevin Gross

  +1-303-447-0517
  Media Network Consultant

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

---

From: Kevin Gross <[email-masked]>
Date: Thu, 12 Apr 2012 21:38:57 -0600

Qin,

In section 1.2, the current draft reads ... [RFC3611] defined... I am
suggesting change to  ... [RFC3611] defines...

The harm in keeping the overflow values is unnecessary complexity. I
encourage you to justify the need for this if you intend to keep it.

I actually sent two messages to the reflector on 8 February. You've linked
to and responded to the first. On closer inspection, you never replied to
the second and I can't even find record of it in the archives. Here is the
message:

One additional change I would request is 64-bit (1/(2^32) second)
resolution for _end system delay_ report. In IDMS, this was the area where
we determined additional resolution was required for certain
alignment-critical audio applications I have
documented<https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit>
and
have been previously vetted at AVTCORE.

I also think the definition of this metric could use some clarification.
I'm happy to contribute new text once I'm clear myself on what is being
specified here. It appears as though a conceptual a measurement of a device
in loopback mode through a network with 0 RTT is being described. If so,
that's fine for a full-duplex device but I wonder how to measure this for a
device that only sends or a device that only receives.

Kevin Gross

On Thu, Apr 12, 2012 at 8:28 PM, Qin Wu <[email-masked]> wrote:

> **
> *From:* Kevin Gross <[email-masked]>
> *To:* Qin Wu <[email-masked]>
> *Cc:* [email-masked]
> *Sent:* Friday, April 13, 2012 7:31 AM
> *Subject:* Re: [xrblock] Fw: I-D Action:
> draft-ietf-xrblock-rtcp-xr-delay-02.txt
>
> Section 3.2: Remove 0xFFFE special value in Mean Network Round Trip
> Delay, End System Delay, Min Network Round Trip Delay and Max Network
> Round Trip Delay. New 32-bit values can represent delays up to 65536
> seconds (18 hours) and so would not be expected to overflow. Change special
> unavailable value to 0xFFFFFFFF.
>
> [Qin]: My fault, I forgot to update this part when we expand 16bit metric
> into 32bit metric. I agree to change unavailable value to 0xFFFFFFF.
> However I am thinking it is no harm and safe to keep the overrange value
> 0xFFFFFFFE, So I propose the following change:
> OLD Text:
> "
> [Qin]: Sorry, do I misundertand your proposal you gave before Paris
> meeting regarding End system delay metric?

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Apr 2012 13:23:44 +0800

Hi,
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Friday, April 13, 2012 11:38 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

  Qin,

  In section 1.2, the current draft reads ... [RFC3611] defined... I am suggesting change to  ... [RFC3611] defines...
[Qin]: I see, thank for your clarification.

  The harm in keeping the overflow values is unnecessary complexity. I encourage you to justify the need for this if you intend to keep it.

[Qin]: My justification, is end system delay may be even longer than network round trip delay, when we allocate same 32 bit space for both network round trip delay metric and end system delay metric,
we should be careful the end system delay may be over-ranged.

>I actually sent two messages to the reflector on 8 February. You've linked to and responded to the first. On closer inspection, you never replied to the second and I can't even find record of it in the >archives. Here is the message:

    One additional change I would request is 64-bit (1/(2^32) second) resolution for _end system delay_ report. In IDMS, this was the area where we determined additional resolution was required for certain alignment-critical audio applications I have documented and have been previously vetted at AVTCORE.
[Qin]: In your proposal, end system delay has the larger maximum value (i.e.,2^32 seconds) than the network round trip delay. Also end system delay has higher resultion(1/2^32 sec) than network round trip delay (1/2^16 seconds).However,why end system delay need higher resolution than network round trip delay? It is a little weired to me to have one high resolution metric 
and 3 other low resolutin metrics in the same report block?

    I also think the definition of this metric could use some clarification. I'm happy to contribute new text once I'm clear myself on what is being specified here. It appears as though a conceptual a measurement of a device in loopback mode through a network with 0 RTT is being described. If so, that's fine for a full-duplex device but I wonder how to measure this for a device that only sends or a device that only receives.

  Kevin Gross

    Hi,Kevin:

    Regards!
    -Qin
      ----- Original Message ----- 
      From: Kevin Gross 
      To: Qin Wu 
      Cc: [email-masked] 
      Sent: Friday, April 13, 2012 7:31 AM
      Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

    "
    New Text:
    "

    "
    What do you think of it?

    Kevin Gross

      +1-303-447-0517
      Media Network Consultant

---

From: Kevin Gross <[email-masked]>
Date: Fri, 13 Apr 2012 08:29:06 -0600

Qin,

End system delay may be seconds longer that RTT. It would have to be hours
longer to bump up against current limits. On Earth, I can't think of any
case where RTT or end system delay would approach 18 hours. What cases do
you have in mind where this could happen?

The purposed of 64-bit end system delay field is to increase precision
beyond 15 us. The applications enumerated in the linked
document<https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit>desire
an extremely accurate measurement of the total end-to-end delay.
The asymmetry in required precision here is caused by the fact that end
system delay is a precise constant chosen by the receiver whereas RTT and
varies statistically based on network conditions. The extension of the
integer portion of the field is unnecessary - we could go with a 48-bit
field if we felt space constrained. The 64-bit format proposed is a
standard NTP timestamp.

You have not addressed my comment/question about how end system delay is
defined. Can you or one of the other authors clarify the current
definition? Would it be helpful for me to propose an improvement?

Kevin Gross

On Thu, Apr 12, 2012 at 11:23 PM, Qin Wu <[email-masked]> wrote:

> *Sent:* Friday, April 13, 2012 11:38 AM
> [Qin]: My justification, is end system delay may be even longer than
> network round trip delay, when we allocate same 32 bit space for both
> network round trip delay metric and end system delay metric,
> >I actually sent two messages to the reflector on 8 February. You've
> linked to and responded to the first. On closer inspection, you never
> replied to the second and I can't even find record of it in the >archives.
> Here is the message:
>
>
> alignment-critical audio applications I have documented<https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit> and
>  [Qin]: In your proposal, end system delay has the larger maximum
> value (i.e.,2^32 seconds) than the network round trip delay. Also end
> system delay has higher resultion(1/2^32 sec) than network round trip delay
> (1/2^16 seconds).However,why end system delay need higher resolution than
> network round trip delay? It is a little weired to me to have one high
> resolution metric
>> Glen Zorn submitted useful comments on 3 February. You (Qin) and he
>> (Glen) had additional correspondence on 6 February and you agreed to make
>> changes. It doesn't appear that any of these agreed changes were made.
>>

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Apr 2012 12:49:11 +0800

Hi,Kevin:
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Friday, April 13, 2012 10:29 PM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

  Qin,

  End system delay may be seconds longer that RTT. It would have to be hours longer to bump up against current limits. On Earth, I can't think of any case where RTT or end system delay would approach 18 hours. 

[Qin]: Great, it looks my worries about overrange of end system delay is not necessary.

  What cases do you have in mind where this could happen?
[Qin]: No. My misunderstandig is that I thought you have, :-).

  The purposed of 64-bit end system delay field is to increase precision beyond 15 us. The applications enumerated in the linked document desire an extremely accurate measurement of the total end-to-end delay. The asymmetry in required precision here is caused by the fact that end system delay is a precise constant chosen by the receiver whereas RTT and varies statistically based on network conditions. The extension of the integer portion of the field is unnecessary - we could go with a 48-bit field if we felt space constrained. The 64-bit format proposed is a standard NTP timestamp.
[Qin]: Thank for your clarification. So your proposal is using 64bit NTP timestamp format for end system delay. This format includes 32bit integter part and 32 bit fractional part.
Comparing with 32bit end system delay in units of 1/65536 seconds, your proposal not only has higer precision but also has larger range. That is to say,
The unit for end system delay will be changed from 1/2^16 second to 1/2^32 second
The highest value for end system delay will be changed from 2^16 seconds(i.e.,18 hours around) to 2^32 seconds (i.e.,136 years around), 
It seems this contradicts with what you claim that end systme delay will not approach 18 hours.
would you like to confirm and clarify this?

  You have not addressed my comment/question about how end system delay is defined. Can you or one of the other authors clarify the current definition? Would it be helpful for me to propose an improvement?
[Qin]: It is clearly stated in the defintion of end system delay. Choose 1/65536 seconds as unit, the 32bits end system delay is expressed in units of 1/65536 seconds.
That is to say, 32 bits end system delay chooses the the middle 32 bits of NTP timestamp format as its own format and includes 16 bit integer part and 16 bit fractional part.

  Kevin Gross

    Hi,
      ----- Original Message ----- 
      From: Kevin Gross 
      To: Qin Wu 
      Cc: [email-masked] 
      Sent: Friday, April 13, 2012 11:38 AM
      Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

      Qin, 

      Kevin Gross

        Hi,Kevin:

        Regards!
        -Qin
          ----- Original Message ----- 
          From: Kevin Gross 
          To: Qin Wu 
          Cc: [email-masked] 

        "
        New Text:
        "

        "
        What do you think of it?

        Kevin Gross

          +1-303-447-0517
          Media Network Consultant

---

From: Kevin Gross <[email-masked]>
Date: Mon, 16 Apr 2012 08:15:37 -0600

Responses below

Kevin Gross

On Sun, Apr 15, 2012 at 10:49 PM, Qin Wu <[email-masked]> wrote:

> *Sent:* Friday, April 13, 2012 10:29 PM
> beyond 15 us. The applications enumerated in the linked document<https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit>desire an extremely accurate measurement of the total end-to-end delay.
> [Qin]: Thank for your clarification. So your proposal is using 64bit NTP
> timestamp format for end system delay. This format includes 32bit integter
> part and 32 bit fractional part.
> Comparing with 32bit end system delay in units of 1/65536 seconds, your
> proposal not only has higer precision but also has larger range. That is to
> say,
> The highest value for end system delay will be changed from 2^16
> seconds(i.e.,18 hours around) to 2^32 seconds (i.e.,136 years around),

[kg] I'm sorry if I was not clear with respect to my 64-bit proposal. We
would be fine using 16 bits for seconds and 32 bits for fractional seconds.
This would result in a 48-bit field. I suggest we use a 64-bit field. Even
though the MS 16 bits will always be 0, the 64-bit field keeps everything
word aligned and, more importantly, 64 bits is a standard NTP timestamp
format.

> [Qin]: It is clearly stated in the defintion of end system delay. Choose
> 1/65536 seconds as unit, the 32bits end system delay is expressed in units
> of 1/65536 seconds.
> That is to say, 32 bits end system delay chooses the the middle 32 bits of
> NTP timestamp format as its own format and includes 16 bit integer part and
> 16 bit fractional part.
>

[kg] Here's the definition of end-system delay from the draft:

The End System Delay is the internal round trip delay within the
reporting endpoint, expressed in units of 1/65536 seconds. This
value is calculated using the nominal value of the jitter buffer
delay plus the accumulation/ encoding and decoding / playout delay
associated with the codec being used.

That's clear for transceivers. It does not accommodate a device that only
sends or only receives. Do those devices simply not report a end-system
delay? If so, that should be mentioned.

Beyond that, I'm concerned that round-trip end-system delay may not be what
applications are particularly interested in. For receivers, applications
are interested in time from RTP timestamp to presentation to the user. For
senders I think they're interested in time from digitization to RTP
timestamping. These reports could be use to synchronize audio and video.
What use do you anticipate an application will make of a round-trip
end-system delay measurement?

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Apr 2012 20:30:19 +0800

Hi,Kevin:
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Monday, April 16, 2012 10:15 PM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

  Responses below

  Kevin Gross

    Hi,Kevin:
      ----- Original Message ----- 
      From: Kevin Gross 
      To: Qin Wu 
      Cc: [email-masked] 
      Sent: Friday, April 13, 2012 10:29 PM
      Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

  [kg] I'm sorry if I was not clear with respect to my 64-bit proposal. We would be fine using 16 bits for seconds and 32 bits for fractional seconds. This would result in a 48-bit field. I suggest we use a 64-bit field. Even though the MS 16 bits will always be 0, the 64-bit field keeps everything word aligned and, more importantly, 64 bits is a standard NTP timestamp format.
[Qin]: Agree and make sense to me. I like to accept your proposal for 64bits NTP timestamp format if I heard no objection on the list.
      You have not addressed my comment/question about how end system delay is defined. Can you or one of the other authors clarify the current definition? Would it be helpful for me to propose an improvement?
    [Qin]: It is clearly stated in the defintion of end system delay. Choose 1/65536 seconds as unit, the 32bits end system delay is expressed in units of 1/65536 seconds.
    That is to say, 32 bits end system delay chooses the the middle 32 bits of NTP timestamp format as its own format and includes 16 bit integer part and 16 bit fractional part.

  That's clear for transceivers. It does not accommodate a device that only sends or only receives. Do those devices simply not report a end-system delay? If so, that should be mentioned.
[Qin]: My understanding is it should accommodate a device that only sends or only receivers. This metric (i.e., end system delay )is up to specific implentation for measurement or estimation, e.g.,
Each end point can get the other side end point delay by out band signaling or estimation.
If an implementation is unable to provide sum of delay from two end points, the value 0 MUST be set for this metric. You may look at section 4.7.3 of RFC3611 for the similar rationale.
  Beyond that, I'm concerned that round-trip end-system delay may not be what applications are particularly interested in. For receivers, applications are interested in time from RTP timestamp to presentation to the user. For senders I think they're interested in time from digitization to RTP timestamping. These reports could be use to synchronize audio and video. What use do you anticipate an application will make of a round-trip end-system delay measurement?
[Qin]:  media stream is sent from the sender to the receiver, therefore Receiver and sender belong to the same system..Simply reporting receiving direction end point delay or sending direction end point delay doesn't really helps to reflect the whole system delay pertaining to this media stream due to
encoding, decoding and playout processing. In some cases for one system, the sender may be very power in encoding, in some other cases the receiver may be very power in decoding and playout, therefore choose the balanced metric between sending direction endpoint delay and receiving direction endpoint delay for each stream is very important. 
e.g., media stream 1 flows from sender A to reciever A, sender A has sending direction endpoint delay 36000ms, the receiver A has receiving direction endpoint delay 24000ms
       media stream 2 flows from sender B to reciever B,  send B has sending direction endpoint delay 30000ms, the receiver B has the receiving direction endpoint delay 72000ms,
so which stream has better performance from end system delay perspective?

---

From: Glen Zorn <[email-masked]>
Date: Tue, 17 Apr 2012 19:44:07 +0700

On 04/17/2012 07:30 PM, Qin Wu wrote:
...

>     The purposed of 64-bit end system delay field is to increase
>     precision beyond 15 us. The applications enumerated in the linked
>     document
>     <https://docs.google.com/document/d/1ANYd-MkQUtJi5_B8uwOwfazB0p1Qmr6X6r85dsmUTgo/edit>
>     desire an extremely accurate measurement of the total end-to-end
>     delay. The asymmetry in required precision here is caused by the
>     fact that end system delay is a precise constant chosen by the
>     receiver whereas RTT and varies statistically based on network
>     conditions. The extension of the integer portion of the field is
>     unnecessary - we could go with a 48-bit field if we felt space
>     constrained. The 64-bit format proposed is a standard NTP timestamp.
>
>         [Qin]: Thank for your clarification. So your proposal is using
>         64bit NTP timestamp format for end system delay. This format
>         includes 32bit integter part and 32 bit fractional part.
>         Comparing with 32bit end system delay in units of 1/65536
>         seconds, your proposal not only has higer precision but also
>         has larger range. That is to say,
>         The highest value for end system delay will be changed from
>         2^16 seconds(i.e.,18 hours around) to 2^32 seconds (i.e.,136
>         years around),
>     [kg] I'm sorry if I was not clear with respect to my 64-bit
>     proposal. We would be fine using 16 bits for seconds and 32 bits
>     for fractional seconds. This would result in a 48-bit field. I
>     suggest we use a 64-bit field. Even though the MS 16 bits will
>     always be 0, the 64-bit field keeps everything word aligned and,
>     more importantly, 64 bits is a standard NTP timestamp format.
>
> [Qin]: Agree and make sense to me. I like to accept your proposal for 
> 64bits NTP timestamp format if I heard no objection on the list.

I'm strongly in favor of of it.
>
>             You have not addressed my comment/question about how end
>             system delay is defined. Can you or one of the
>             other authors clarify the current definition? Would it be
>             helpful for me to propose an improvement?
>
>         [Qin]: It is clearly stated in the defintion of end system
>         delay. Choose 1/65536 seconds as unit, the 32bits end system
>         delay is expressed in units of 1/65536 seconds.
>         That is to say, 32 bits end system delay chooses the the
>         middle 32 bits of NTP timestamp format as its own format and
>         includes 16 bit integer part and 16 bit fractional part.
>
>
>     That's clear for transceivers. It does not accommodate a device
>     that only sends or only receives. Do those devices simply not
>     report a end-system delay? If so, that should be mentioned.
>
> [Qin]: My understanding is it should accommodate a device that only 
> sends or only receivers. This metric (i.e., end system delay )is up to 
> specific implentation for measurement or estimation, e.g.,
> If an implementation is unable to provide sum of delay from two end 
> points, the value 0 MUST be set for this metric. You may look at 
> section 4.7.3 of RFC3611 for the similar rationale.

It might be clarifying to change "plus the accumulation/ encoding and 
decoding / playout delay" to "plus the accumulation/encoding and/or 
decoding/playout delay"

...

---

From: Qin Wu <[email-masked]>
Date: Wed, 18 Apr 2012 10:19:06 +0800

Hi, Glen and Kevin:
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Kevin Gross" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 17, 2012 8:44 PM
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-delay-02.txt

> decoding / playout delay" to "plus the accumulation/encoding and/or 

[Qin]: Your proposal seems like a compromized solution, i.e.,support both one way metrics and round trip metrics.
However this draft aims at "only round trip time metrics" rather than one way metric.
Please look at the section 1.1, paragraph 1, it said:
"
 The new block type
   supports the reporting of the mean, minimum and maximum values of the
   network round-trip delay between RTP interfaces in peer RTP end
   systems as measured, for example, using the RTCP method described in
   [RFC3550].  It also supports reporting of the component of the round-
   trip delay internal to the local RTP system.
"
Here, "the component of the round-
   trip delay internal to the local RTP system" is referred to as end system delay.
Apparantly, end system delay is round trip metric.

If you think it is also useful to support one way metric, I suggest to define this one way metric
in the  seperate draft, i.e.,draft-wu-xrblock-rtcp-xr-one-way-delay. This draft focus on one way delay metric reporting.
Hope this clarifies.