Subject: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 3 Jul 2012 19:59:33 +0000

During IESG evaluation of the draft, two issues have been raised that, as document shepherd, I feel require additional input from the working group.
First, section 3.1 of the draft currently reads follows:

   3.1. APSI: Application Specific Identifier SDES Item
   Application specific identifier is an additional identifier which is
   useful in the context of a specific application, e.g. an MPEG-2
   transport identifier [MPEG2].  This item MUST be ignored by
   applications that are not configured to make use of it.  The
   identifier is variable length.  Its length is described by the length
   field.  The value of the length field does not include the two octet
   SDES item header.  If no identifier is provided, the length field
   MUST be set to zero.

The question is, why set the length field to 0 instead of omitting the SDES item entirely? As the APSI identifier is the only piece information conveyed by this SDES item, it seems more appropriate to omit it altogether. If there is a good reason to do otherwise, an explanation of that  reason should be added as justification.

Second, the cumulative duration is defined in section 4.1 as follows:

   Measurement Duration (Cumulative) : 32 bits
      The duration, expressed in units of 1/65536 seconds, of the
      reporting interval applicable to Cumulative reports which use this
      Measurement Information block.  The value of this field can be
      calculated by the receiver of the RTP media stream, for example,
      based on received RTP media packets or using RTCP method described
      in [RFC3550]. 

The units for the measurement was changed from millisecond to 1/65536 based on working group input. A side effect of this however, is that the maximum cumulative duration that can be expressed is 18.2 hours. This does not seem sufficient, as the cumulative duration may be up to the length of the RTP session. The proposal is to increase the field from 32 bits to 64 bits.

Comments on both of these issues would be greatly appreciated.

Cheers,
Charles

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Jul 2012 10:19:13 +0800

Hi,Charles:
I agree we should discuss how to fix these issues on XRBLOCK list. Below is my proposed changes and input.
Some of my proposed changes have already been posted to IESG mailing list.

Regards!
-Qin
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 04, 2012 3:59 AM
Subject: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07

> The question is, why set the length field to 0 instead of omitting the SDES item entirely? As the APSI identifier is the only piece information conveyed by this SDES item, it seems more appropriate…

[Qin]: Agree to omit it altogether rather than set the lenght field to 0 since early APSI is one metric carried in the measurement information now it is separated out and carried using one new SDES item.
My proposed change in IESG also is to delete the last sentence " If no identifier is provided, the length field
MUST be set to zero." from the section 3.1.

> The units for the measurement was changed from millisecond to 1/65536 based on working group input. A side effect of this however, is that the maximum cumulative duration that can be expressed is 18.2 hours. This does not seem sufficient, as the cumulative duration may be up to the length of the RTP session.The proposal is to increase the field from 32 bits to 64 bits.

[Qin]: Agree, we should not limit the cumulative duration to less than 18.2 hours. The proposal looks good to me.
Here is my input to fix this issue:
OLD TEXT:
"
      Measurement Duration (Cumulative) : 32 bits
      The duration, expressed in units of 1/65536 seconds, of the
      reporting interval applicable to Cumulative reports which use this
      Measurement Information block.  The value of this field can be
      calculated by the receiver of the RTP media stream, for example,
      based on received RTP media packets or using RTCP method described
      in [RFC3550]. 

"
NEW TEXT:
"
      Measurement Duration (Cumulative) : 64 bits
      The duration of the reporting interval applicable to Cumulative reports which use this
      Measurement Information block.  The value of this field is represented using a 64-bit 
      NTP-format timestamp as defined in [RFC5905], which is 64-bit unsigned fixed-point
      number with the integer part in the first 32 bits and the fractional part  in the last 32 bits. 
      It can be calculated by the receiver of the RTP media stream, for example, based on 
      received RTP media packets or using RTCP method described in [RFC3550]. 

"

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

---

From: Glen Zorn <[email-masked]>
Date: Wed, 04 Jul 2012 11:47:41 +0700

On Wed, 2012-07-04 at 10:19 +0800, Qin Wu wrote:

...

>       received RTP media packets or using RTCP method described in [RFC3550]. 

A fine idea, but the question in my mind is why we don't simply
standardize on NTP format for all time values...

...

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Jul 2012 13:55:07 +0800

----- Original Message ----- 
  From: Glen Zorn 
  To: [email-masked] 
  Sent: Wednesday, July 04, 2012 12:47 PM
  Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07

  ...

"
NEW TEXT:
"

"

A fine idea, but the question in my mind is why we don't simply standardize on NTP format for all time values...

[Qin]: If my intepretation is correct, your question is why not apply NTP format to Measurement Duration (Interval) as well?
My understanding is:
the maximum measurement duration (Interval) 18.2 hours is more than enough,it is not necessary to get in line with 64 bit measurement duration (cumulative).
Another benefit for not applying NTP format to Measurement Duration (Interval) is to make good use of 32bit space allocated and reduce overhead waste.
... 

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 4 Jul 2012 12:18:11 +0200

One other option which I will just throw into the ring is that one could divide the existing 32 bits into 2 fields, one of which is a value and the other a multiplier. This has certainly been done in other protocols.

Depends how much one feels the need to save bits.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 04 July 2012 06:55
To: Glen Zorn; [email-masked]
Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07

----- Original Message -----
From: Glen Zorn<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Sent: Wednesday, July 04, 2012 12:47 PM
Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07

...

OLD TEXT:

"

      in [RFC3550].

"

NEW TEXT:

"

"

________________________________

---

From: Colin Perkins <[email-masked]>
Date: Wed, 4 Jul 2012 21:57:46 +0100

Keith,

I'd argue that using a familiar time format (32 or 64 bits NTP-format value as used in other bits of RTCP) is more important than saving 32 bits here.

Colin

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Jul 2012 10:28:10 +0800

+1,
Agree with Colin. 

Regards!
-Qin
  ----- Original Message ----- 
  From: Colin Perkins 
  To: DRAGE, Keith (Keith) 
  Cc: Qin Wu ; Glen Zorn ; [email-masked] 
  Sent: Thursday, July 05, 2012 4:57 AM
  Subject: Re: [xrblock] IESG evaluation comments for draft-ietf-xrblock-rtcp-xr-meas-identity-07

  Keith,

  Colin

    Keith

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

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

      From: Glen Zorn 

      To: [email-masked] 

      ...

 > Second, the cumulative duration is defined in section 4.1 as follows:> >   Measurement Duration (Cumulative) : 32 bits>      The duration, expressed in units of 1/65536 seconds, of the>      reporting interval applicable to Cumulative reports which use this>      Measurement Information block.  The value of this field can be>      calculated by the receiver of the RTP media stream, for example,>      based on received RTP media packets or using RTCP method described>      in [RFC3550]. > > The units for the measurement was changed from millisecond to 1/65536 based on working group input. A side effect of this however, is that the maximum cumulative duration that can be expressed is 18.2 hours. This does not seem sufficient, as the cumulative duration may be up to the length of the RTP session.The proposal is to increase the field from 32 bits to 64 bits. [Qin]: Agree, we should not limit the cumulative duration to less than 18.2 hours. The proposal looks good to me.Here is my input to fix this issue:OLD TEXT:"      Measurement Duration (Cumulative) : 32 bits      The duration, expressed in units of 1/65536 seconds, of the      reporting interval applicable to Cumulative reports which use this      Measurement Information block.  The value of this field can be      calculated by the receiver of the RTP media stream, for example,      based on received RTP media packets or using RTCP method described      in [RFC3550].  "NEW TEXT:"      Measurement Duration (Cumulative) : 64 bits      The duration of the reporting interval applicable to Cumulative reports which use this      Measurement Information block.  The value of this field is represented using a 64-bit       NTP-format timestamp as defined in [RFC5905], which is 64-bit unsigned fixed-point      number with the integer part in the first 32 bits and the fractional part  in the last 32 bits.       It can be calculated by the receiver of the RTP media stream, for example, based on       received RTP media packets or using RTCP method described in [RFC3550].  " A fine idea, but the question in my mind is why we don't simply standardize on NTP format for all time values...

    My understanding is:

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

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