Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Dec 2012 22:48:44 +0100

On 29 Nov 2012, at 13:55, Romascanu, Dan (Dan) wrote:
> This is a Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-summary-stat-03.txt.  
> 
> Please read and review this document, and send your comments, questions and concerns to the WG list before December 13, 2012. If you have no comments and you believe that the document is ready for submission to the IESG as a Standards Track document please send a short message as well to help us in determining the level of review and consensus. 

Section 3.2.2 of the draft cites draft-ietf-xrblock-rtcp-xr-discard and suggests that the gap discard rate is based on the value of DT=3 packets, but there was some discussion at IETF 85 about removing DT=3, since it’s redundant with the sum of DT=1 and DT=2. Was that discussion resolved?

Otherwise, I just had some minor comments:

- Section 3.2 references draft-ietf-xrblock-rtcp-xr-discard, which is not a burst/gap metric draft, in the context of burst/gap metrics. This is confusing, and it would help to separate the discussion of the burst/gap discard metrics from the reference to the non-burst/gap discard draft.

- Section 4.1.2: the term “derivation frame” is unclear. 

- Section 5.2 is insufficient, and needs to be updated in a manner analogous to the other recent RTCP XR blocks.

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Dec 2012 15:02:34 +0800

Hi, Colin:
Thank for your comments, please see my reply inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 12, 2012 5:48 AM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

[Qin]: I remembered you proposed in the meeting to remove DT=3, instead using the sum of DT=1 and DT=2 to calculate the total number of packet discard. But I am a little doubt after the meeting since the merit of keeping DT=3 is it will be more simple to know the total number of discard based on one instance of discard count block with DT=3 
however I am okay with your proposal now since it did cause redundance and introduce complexing to check if value of DT=3 equal to sum value of  DT=1 and DT=2.
So if the consensus is to remove DT=3 from draft-ietf-xrblock-rtcp-xr-summary-stat, instead, using sum of DT=1 and DT=2, I think we should also remove DT=3 from the draft-ietf-xrblock-rtcp-xr-discard, am I right?

[Qin]: I believe you are right and will separate this from the 1st paragraph of  section 3.2.

[Qin]: It should be changed into "derived frame" to get consistent with Picture Type definition in the section 2.1.
We divide Picture type into "key frame" and "derived frame" 

[Qin]: Okay.
-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Glen Zorn <[email-masked]>
Date: Wed, 12 Dec 2012 14:08:01 +0700

> Section 3.2.2 of the draft cites draft-ietf-xrblock-rtcp-xr-discard and suggests that the gap discard rate is based on the value of DT=3 packets, but there was some discussion at IETF 85 about remo…

In order for this metric to be meaningful, exactly one of the following 
conditions must hold:

  * the packet contains a block with DT=3

OR

  * the packet contains 2 blocks with DT=1 and DT=2, respectively

If we are going to force the latter in this case, is there any argument 
for keeping DT=3 in the other draft?

Personally, if we include DT=3 in draft-ietf-xrblock-rtcp-xr-discard, I 
would like the flexibility to use it here - saves space, etc.

> - Section 3.2 references draft-ietf-xrblock-rtcp-xr-discard, which is not a burst/gap metric draft, in the context of burst/gap metrics.

I believe that the reference is in the context of /discards/, not 
burst/gap metrics and is completely appropriate.  If you found it 
confusing, can you suggest a better wording?

> This is confusing, and it would help to separate the discussion of the burst/gap discard metrics from the reference to the non-burst/gap discard draft.
>

Maybe a reference would help?

> - Section 5.2 is insufficient, and needs to be updated in a manner analogous to the other recent RTCP XR blocks.

Can you be a bit more specific?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Dec 2012 12:52:27 +0000

I have a few comments, please see below: 

1. I believe that [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss], [I-D.ietf-xrblock-rtcp-xr-discard], and [RFC6776] must be Normative references. 

- Burst gap loss metrics defined in [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] are used in calculation of fields in Burst/Gap Discard Summary Statistics Block.
- Burst/Gap Loss Block defined in [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] is used in the calculation of Burst Duration Mean and Burst Duration variance
- Discard Count Block defined in [I-D.ietf-xrblock-rtcp-xr-discard] is used in the calculation of Gap Discard Rate
- Also in the formula of Gap Discard Rate "extended last sequence number" and "extended first sequence number" provided in the Measurement Information block from [RFC6776] are used

In order to understand and the formulas and build the implementations for this I-D these references are mandatory reading, and for this document to be stable the references also need to be stable - so they must be Normative

2. Sections 3.1.2 - the definition of Interval Metric Flag is 2 bits, three values codified to send. What happens at the receiver if the 4th (illegal) value I=00 is received? 

3. Same question about the Interval Metric Type defined in 3.2.2. And if we are here, why is one named Interval Metric Flag (3.1.2) and the other Interval Metric Type (3.2.2)? they seem to be the same thing

4. The introduction section makes no reference to the definition of the associated SDP parameters (which is mentioned in the Abstract but not here)

5. No need to mention the authors names in the Introduction when refering to [RFC3611] and [RFC 6792]

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, November 29, 2012 2:55 PM
> To: [email-masked]
> Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03
> 
> 
> Please read and review this document, and send your comments, questions
> and concerns to the WG list before December 13, 2012. If you have no
> comments and you believe that the document is ready for submission to
> the IESG as a Standards Track document please send a short message as
> well to help us in determining the level of review and consensus.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Dec 2012 13:35:43 +0000

One more comment on this document: 

6. what is the behavior of the receiver if a value other than 3 or 7 respectively is received? 

Regards,

Dan

> Sent: Thursday, December 13, 2012 2:52 PM
> To: [email-masked]
> 1. I believe that [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], [I-
> D.ietf-xrblock-rtcp-xr-burst-gap-loss], [I-D.ietf-xrblock-rtcp-xr-
> discard], and [RFC6776] must be Normative references.
> 
> - Burst gap loss metrics defined in [I-D.ietf-xrblock-rtcp-xr-burst-gap-
> discard] are used in calculation of fields in Burst/Gap Discard Summary
> Statistics Block.
> - Burst/Gap Loss Block defined in [I-D.ietf-xrblock-rtcp-xr-burst-gap-
> loss] is used in the calculation of Burst Duration Mean and Burst
> Duration variance
> - Discard Count Block defined in [I-D.ietf-xrblock-rtcp-xr-discard] is
> used in the calculation of Gap Discard Rate
> - Also in the formula of Gap Discard Rate "extended last sequence
> number" and "extended first sequence number" provided in the Measurement
> Information block from [RFC6776] are used
> 
> In order to understand and the formulas and build the implementations
> for this I-D these references are mandatory reading, and for this
> document to be stable the references also need to be stable - so they
> must be Normative
> 
> 2. Sections 3.1.2 - the definition of Interval Metric Flag is 2 bits,
> three values codified to send. What happens at the receiver if the 4th
> (illegal) value I=00 is received?
> 
> 3. Same question about the Interval Metric Type defined in 3.2.2. And if
> we are here, why is one named Interval Metric Flag (3.1.2) and the other
> Interval Metric Type (3.2.2)? they seem to be the same thing
> 
> 4. The introduction section makes no reference to the definition of the
> associated SDP parameters (which is mentioned in the Abstract but not
> here)
> 
> > This is a Working Group Last Call for
> > http://www.ietf.org/id/draft-ietf-
> > xrblock-rtcp-xr-summary-stat-03.txt.
> >
> > Please read and review this document, and send your comments,
> > questions and concerns to the WG list before December 13, 2012. If you
> > have no comments and you believe that the document is ready for
> > submission to the IESG as a Standards Track document please send a
> > short message as well to help us in determining the level of review
> and consensus.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 12:44:51 +0800

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 13, 2012 9:35 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

> 6. what is the behavior of the receiver if a value other than 3 or 7 respectively is received? 

[Qin]: We will append a sentence in the block length definition part to say:
"
The block MUST be discarded if the block length is
 set to a different value.

"

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 13:09:27 +0800

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 13, 2012 8:52 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

> In order to understand and the formulas and build the implementations for this I-D these references are mandatory reading, and for this document to be stable the references also need to be stable -…

[Qin]: Good point. we will take your point in the update.
> 2. Sections 3.1.2 - the definition of Interval Metric Flag is 2 bits, three values codified to send. What happens at the receiver if the 4th (illegal) value I=00 is received? 

[Qin]: We may add a sentence to say, "In this document, the  value I=00 is the reserved value and MUST NOT be used."

> 3. Same question about the Interval Metric Type defined in 3.2.2. And if we are here, why is one named Interval Metric Flag (3.1.2) and the other Interval Metric Type (3.2.2)? they seem to be the s…

[Qin]: Good catch, to be consistent between two places, we will use "Interval Metric Flag".
> 4. The introduction section makes no reference to the definition of the associated SDP parameters (which is mentioned in the Abstract but not here)

[Qin]: To be consistent between abstract and Introduction, I like to remove SDP part from Abstract.

[Qin]: Okay.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 14 Dec 2012 12:49:57 +0700

On 12/13/2012 07:52 PM, Romascanu, Dan (Dan) wrote:

...

 > refering to [RFC3611] and [RFC 6792]

What would you prefer?

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 14 Dec 2012 06:20:50 +0000

Just mention the references, as done in most places. 

Regards,

Dan

________________________________________
From: Glen Zorn [[email-masked]]
Sent: Friday, December 14, 2012 7:49 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

...

What would you prefer?

...

---

From: Glen Zorn <[email-masked]>
Date: Fri, 14 Dec 2012 15:48:46 +0700

> Just mention the references, as  done in most places.

"[RFC3611]" is a "reference" and as such has no intrinsic meaning 
whatsoever: it could just as well be "*****" or  "[1]" or 
"[chickensoup]".  Its sole purpose is to point to a "citation", in this case

               Friedman, T., Caceres, R., and A. Clark, "RTP Control
               Protocol Extended Reports (RTCP XR)", RFC 3611,
               November 2003.

You would prefer, apparently, that the draft read:

    This draft defines three new block types to augment those defined in
    [RFC3611] for use in a range of RTP applications.

This construct uses the arbitrary string "[RFC3611]" as a noun and 
states that something (block types) are defined in that arbitrary 
string, which is obviously nonsense.  Note that neither the "reference" 
nor the "citation" define any block types: only the actual document does 
that.  An example from C programming:

int i, j;
int *p;
int **pp;

p=&i;
pp=&p;
i = 3;

Saying "This draft defines three new block types to augment those 
defined in [RFC3611]" is the equivalent of claiming that pp is equal to 3.

...