Subject: [xrblock] Fw: I-D Action:draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt

From: Qin Wu <[email-masked]>
Date: Fri, 13 Apr 2012 15:18:00 +0800

On 13 April , 2012 3:14 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           : Measurement Identity and information Reporting using SDES item and XR Block
> Author(s)       : Geoff Hunt
>                          Alan Clark
>                          Qin Wu
> Filename        : draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt
> Pages           : 15
> Date            : 2012-04-13
> 
>   This document defines an RTP Control Protocol (RTCP) Source
>   Description (SDES) item and an RTCP Extended Report (XR) Block
>   carrying parameters that identify and describe a measurement period,
>   to which one or more other RTCP XR Report Blocks may refer.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt

[Qin]: One more update to measurement identity draft based on Kevin's recent comments on the list.
- Add some explaination text to clarify the definition of extended sequence number.
- A few editorial changes.

---

From: Kevin Gross <[email-masked]>
Date: Fri, 13 Apr 2012 15:39:01 -0600

Qin,

Your new draft references RFC 3550 without providing a section number.
Where exactly is "extended sequence number" discussed in RFC 3550?

Kevin Gross

On Fri, Apr 13, 2012 at 1:18 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: Mon, 16 Apr 2012 11:53:24 +0800

You should look at the definition of "extended highest sequence number received" in the section 6.4.1 of RFC3550.
This definition explains what the extended sequence number means. The measurement identity draft only need to 
get consisten with this defintion.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: [email-masked] 
  Sent: Saturday, April 14, 2012 5:39 AM
  Subject: Re: [xrblock] Fw: I-D Action:draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt

  Qin,

  Your new draft references RFC 3550 without providing a section number. Where exactly is "extended sequence number" discussed in RFC 3550?

  Kevin Gross

---

From: Glen Zorn <[email-masked]>
Date: Mon, 16 Apr 2012 18:09:00 +0700

On 04/16/2012 10:53 AM, Qin Wu wrote:
> You should look at the definition of "extended highest sequence number 
> received" in the section 6.4.1 of RFC3550.

Nevertheless, a more explicit reference (i.e., including the section 
number) couldn't hurt.

>     *From:* Kevin Gross <mailto:[email-masked]>
>     *To:* Qin Wu <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Saturday, April 14, 2012 5:39 AM
>     *Subject:* Re: [xrblock] Fw: I-D
>     Action:draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt
>
>     Qin,
>
>     Your new draft references RFC 3550 without providing a section
>     number. Where exactly is "extended sequence number" discussed in
>     RFC 3550?
>
>     Kevin Gross
>
...

---

From: Kevin Gross <[email-masked]>
Date: Mon, 16 Apr 2012 09:24:41 -0600

Thanks Qin.

I have now studied the material in 3550 and find that it is more of a goose
chase than concise help.  So I'm not sure it is helpful to mention 3550,
section 6.4.1 or Annex A.1 to which 6.4.1 refers. The definition detail
you've added in the 05 revision is quite helpful, however. One important
caveat for extended sequence numbers that's mentioned in RFC 3550 but does
not appear in your new definition is the fact that the MS 16-bits will
differs for devices depending when they started monitoring the session.

In conclusion, I'm comfortable leaving things as you have them in the 05
version of the draft. If we want to improve it, I offer the following:

The extended sequence number is expressed as the low 16 bits value
containing the sequence number received in an RTP data packet and the most
significant 16 bits value containing the corresponding count of sequence
number cycles. Note that different participants of the same session may
generate different extensions to the sequence number if the they joined the
session at different times. For additional information on
extended sequence numbers see "extended highest sequence number received"
definition in RFC 3550 section 6.4.1 and RFC 3550 Appendix A.1.

Kevin Gross

On Mon, Apr 16, 2012 at 5:09 AM, Glen Zorn <[email-masked]> wrote:

>>    Action:draft-ietf-xrblock-**rtcp-xr-meas-identity-05.txt
>>
>>    Qin,
>>

---

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

Reasonable to me.

---

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

----- Original Message ----- 
  From: Kevin Gross 
  To: [email-masked] 
  Sent: Monday, April 16, 2012 11:24 PM
  Subject: Re: [xrblock] Fw: I-DAction:draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt

  Thanks Qin.

  I have now studied the material in 3550 and find that it is more of a goose chase than concise help.  So I'm not sure it is helpful to mention 3550, section 6.4.1 or Annex A.1 to which 6.4.1 refers. The definition detail you've added in the 05 revision is quite helpful, 

[Qin]:Okay.
  however, One important caveat for extended sequence numbers that's mentioned in RFC 3550 but does not appear in your new definition is the fact that the MS 16-bits will differs for devices depending when they started monitoring the session.

[Qin]: That's not my interpretation from reading RFC3550 Appendix A.1, my interpretation is RTP data packet is typically received from one source. However the media receiver  may also receiver RTP data packet from another new source in the middle of session. In this use, only source changes or SSRC changes.

Secondly, the Delay metric reporting is per SSRC reporting, if source changes, Delay metric with differerent SSRC should be reported.

  In conclusion, I'm comfortable leaving things as you have them in the 05 version of the draft. If we want to improve it, I offer the following:

    The extended sequence number is expressed as the low 16 bits value containing the sequence number received in an RTP data packet and the most significant 16 bits value containing the corresponding count of sequence number cycles. Note that different participants of the same session may generate different extensions to the sequence number if the they joined the session at different times. For additional information on extended sequence numbers see "extended highest sequence number received" definition in RFC 3550 section 6.4.1 and RFC 3550 Appendix A.1.
[Qin]: The note you add in the middle is, in my understanding ambiguous and not necessary as I explained above. I suggest to remove the sentence from "Note that" to "...at different times". So the proposed change will be like:
"
The extended sequence number is expressed as the low 16 bits value containing the sequence number received in an RTP data packet and the most significant 16 bits value containing the corresponding count of sequence number cycles.  For additional information on extended sequence numbers see "extended highest sequence number received" definition in RFC 3550 section 6.4.1 and RFC 3550 Appendix A.1.
"

  Kevin Gross

    Nevertheless, a more explicit reference (i.e., including the section number) couldn't hurt.

      Regards!
      -Qin

         ----- Original Message -----

         Qin,

         Kevin Gross

    ...

------------------------------------------------------------------------------

---

From: Kevin Gross <[email-masked]>
Date: Fri, 20 Apr 2012 08:55:50 -0600

Qin,

For technical reason you take issue with inclusion of the sentence, "Note
that different participants of the same session may generate different
extensions to the sequence number if the they joined the session at
different times."

Please be aware that this is an almost exact quote from the  "extended
highest sequence number received" definition in RFC 3550 section 6.4.1 that
we're referencing, "Note that different receivers within the same session
will generate different extensions to the sequence number if their start
times differ significantly."

I believe RFC 3550 is correct on this point.

No changes need to be made to the the draft around this. I just want to
clarify the source of the statement and make sure that you don't make any
edits that contradict RFC 3550.

Kevin Gross

On Tue, Apr 17, 2012 at 8:01 PM, Qin Wu <[email-masked]> wrote:

> **
> *From:* Kevin Gross <[email-masked]>
> *To:* [email-masked]
> *Sent:* Monday, April 16, 2012 11:24 PM
> *Subject:* Re: [xrblock] Fw:
> I-DAction:draft-ietf-xrblock-rtcp-xr-meas-identity-05.txt
>
> Thanks Qin.
>
> I have now studied the material in 3550 and find that it is more of a
> goose chase than concise help.  So I'm not sure it is helpful to mention
> 3550, section 6.4.1 or Annex A.1 to which 6.4.1 refers. The definition
> detail you've added in the 05 revision is quite helpful,
>
>
> [Qin]:Okay.
>
> however, One important caveat for extended sequence numbers that's
> mentioned in RFC 3550 but does not appear in your new definition is the
> fact that the MS 16-bits will differs for devices depending when they
> started monitoring the session.
>
>
> [Qin]: That's not my interpretation from reading RFC3550 Appendix A.1, my
> interpretation is RTP data packet is typically received from one source.
> However the media receiver  may also receiver RTP data packet from another
> new source in the middle of session. In this use, only source changes or
> SSRC changes.
>
> Secondly, the Delay metric reporting is per SSRC reporting, if source
> changes, Delay metric with differerent SSRC should be reported.
>
> [Qin]: The note you add in the middle is, in my understanding ambiguous
> and not necessary as I explained above. I suggest to remove the sentence
> from "Note that" to "...at different times". So the proposed change will be
> like:
> "
> number cycles.  For additional information on extended sequence numbers see
> "extended highest sequence number received" definition in RFC 3550 section
> 6.4.1 and RFC 3550 Appendix A.1.
> "
>
>
> Kevin Gross
>
>  ------------------------------
>