Subject: [xrblock] Measurement Duration, extended first and last sequence number of interval and Interval Metric flag

From: Roni even <[email-masked]>
Date: Sat, 12 Nov 2011 12:47:51 +0000

Hi,
Currently the relation between the measure identity block and the report block are not specified. Previously the text in all the report blocks stated that the measurement interval and the extended first and last sequence numbers in the relevant identity block were used to calculate the values in the individual reports. I assume this information is still needed by the monitoring system in order to know what is the reporting period. The tag was used to link the different reports with a specific measurement block.
Now we took out the tag and I think we need to agree if we want each report to have these values or have the identity block with the value applicable to a couple of reports.
If we want to have the measurement identity block we need to define the linkage and the reliability of this block.  So in my view the open questions are

1.       Should these values (the measurement interval and the extended first and last sequence numbers) be part of each report block

2.       Do we want to have a measurement identity block that will provide these values to more than one report

3.       Should we have the two options (yes to 1 and 2)

I think that we can have both if we specify that these values must always be the last ones in the report block and based on the length you can know if they exist.
If they exist they are the relevant ones and if not the measurement identity can be used.

I think that the reliability of the measurement identity  is important and it should probably be mandatory to send it as part of a compound packet that include this block and the report blocks that are based on it. Anyhow if we do not have a tag it will be difficult to link the measurement identity to a report block.

I also think that we will need some text explaining the use of these values (measurement interval and the extended first and last sequence numbers ) in the monitoring architecture draft or the measurement identity draft if we intend to have a measurement identity block

Roni

---

From: Alan Clark <[email-masked]>
Date: Sat, 12 Nov 2011 08:14:28 -0500

Hi Roni

As you suggest, the tag was there for good reason. The RTCP message size
could get very large and the XR blocks may be sent in more than one message.

My vote would be to put the tag back in place and use it for the report
block to measurement identity as originally intended

Best Regards

Alan

On 11/12/11 7:47 AM, "Roni even" <[email-masked]> wrote:

> Hi,  
> Currently the relation between the measure identity block and the report block
> are not specified. Previously the text in all the report blocks stated that
> the measurement interval and the extended first and last sequence numbers in
> the relevant identity block were used to calculate the values in the
> individual reports. I assume this information is still needed by the
> monitoring system in order to know what is the reporting period. The tag was
> used to link the different reports with a specific measurement block.
> Now we took out the tag and I think we need to agree if we want each report to
> have these values or have the identity block with the value applicable to a
> couple of reports.
> If we want to have the measurement identity block we need to define the
> linkage and the reliability of this block.  So in my view the open questions
> are
>  
> 1.      Should these values (the measurement interval and the extended first
> and last sequence numbers) be part of each report block
> 
> I think that we can have both if we specify that these values must always be
> the last ones in the report block and based on the length you can know if they
> exist.
> I think that the reliability of the measurement identity  is important and it
> should probably be mandatory to send it as part of a compound packet that
> include this block and the report blocks that are based on it. Anyhow if we do
> not have a tag it will be difficult to link the measurement identity to a
> report block.
>  
>  
> I also think that we will need some text explaining the use of these values
> (measurement interval and the extended first and last sequence numbers ) in
> the monitoring architecture draft or the measurement identity draft if we
> intend to have a measurement identity block
>  
>  
> Roni
>  
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Sat, 12 Nov 2011 15:52:53 +0000

Hi, Roni:
I am not sure we still need to use tag since each metric block has SSRC and each measurement information XR Block has SSRC, SSRC will be used to identify, group, correlate different participants between metric blocks or betwen metric block and measurement information XR block. 
 
When one RTCP compound packet carry more than one measurement information XR blocks with other relevant metric blocks, it doesn't matter which order should be chosen for the multiple measurement information XR Blocks. I think this has been discussed for many times. Shall we break this again?

Also I am not sure all the metric block should use measurement interval and the extended first and last sequence number to calculate the values in the individual reports.
I only remember in Gap Loss rate metric specified in both draft-ietf-xrblock-rtcp-xr-burst-gap-loss and draft-zorn-xrbock-rtcp-xr-al-stats use extended first and last sequence number
to calcualte the packet expected. If I miss the other use case, please point to me.

So to my understanding, it looks some of metric blocks are densely coupled with measurement information XR block defined draft-ietf-xrblock-meas-identity, some of other metric block
are loosly coupled with measurement information xr block. Unless the monitoring system should know the measurement interval each time it receives a RTCP compound packet containing XR blocks.
I think measurement information XR block don't need to be sent very frequently.

If  any failure case happens, we can ask monitoring system discard the XR block without measurement interval sent together. Does this make sense?

Regards!
-Qin

发件人: [email-masked] [[email-masked]] 代表 Roni even [[email-masked]]
发送时间: 2011年11月12日 20:47
到: [email-masked]
主题: [xrblock] Measurement Duration, extended first and last sequence number of interval and Interval Metric flag

Hi, 

Roni

---

From: Roni even <[email-masked]>
Date: Sat, 12 Nov 2011 16:37:56 +0000

Qin,
Inline
Roni

________________________________________
From: Qin Wu
Sent: Saturday, November 12, 2011 17:52
To: Roni even; [email-masked]
Cc: Qin Wu
Subject: 答复: [xrblock] Measurement Duration, extended first and last sequence number of interval and Interval Metric flag

Hi, Roni:
I am not sure we still need to use tag since each metric block has SSRC and each measurement information XR Block has SSRC, SSRC will be used to identify, group, correlate different participants between metric blocks or between metric block and measurement information XR block.

RE: this is OK

Also I am not sure all the metric block should use measurement interval and the extended first and last sequence number to calculate the values in the individual reports.
I only remember in Gap Loss rate metric specified in both draft-ietf-xrblock-rtcp-xr-burst-gap-loss and draft-zorn-xrbock-rtcp-xr-al-stats use extended first and last sequence number
to calculate the packet expected. If I miss the other use case, please point to me.

RE:
In Post repair
"Number of packets lost: 32 bits
      Number of packets lost over the period (Interval or Cumulative)
      covered by this report, after application of repair procedures.
      Where repair procedures may achieve partial repair of a packet, a
      packet which is only partially repaired SHOULD be counted as lost.
      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.
      Note that the number of packets expected in the period covered by
      the metric (whether interval or cumulative) is available from the
      difference between a pair of extended sequence numbers in the
      Measurement Identity block, so need not be repeated in this block."
If you want to know the precentage.

Same for xr-discard also in gap discard (derived metrics)
I think that the monitoring system will want to know the period of the report .

RE: So you are suggesting that the measurement identity will not be sent with every XR report compound packet. In this case I think it may be better to have the information in the XR-report. So the sender will either send a compound packet with measure identity or reports with the period and if required the first and last packet or instead the number of packet expected in the period.

Regards!
-Qin

Hi,

Roni

---

From: Qin Wu <[email-masked]>
Date: Sat, 12 Nov 2011 17:14:47 +0000

Hi, Roni:
See below.

Regards!
-Qin
________________________________________
发件人: Roni even
发送时间: 2011年11月13日 0:37
到: Qin Wu; [email-masked]
主题: RE: [xrblock] Measurement Duration, extended first and last sequence number of interval and Interval Metric flag

Qin,
Inline
Roni

Hi, Roni:

RE: this is OK

RE:
In Post repair

[Qin]: Number of packet lost is defined in draft-ietf-avt-rtcp-xr-postrepair-loss-02. 
However it looks draft-ietf-avt-rtcp-xr-postrepair-loss-02 has been abandoned
and hasn't be chartered into XRBLOCK WG scope. That is to say this draft is dead or there is other alternative draft to replace it.

[Qin]: Agree. Since burst  gap discard, xr-discard are more related to burst gap loss draft.

RE: So you are suggesting that the measurement identity will not be sent with every XR report compound packet. In this case I think it may be better to have the information in the XR-report. 
So the sender will either send a compound packet with measure identity xr reports with the period and if required the first and last packet or instead the number of packet expected in the period.

[Qin]: Yes, for example , PDV metrid defined in PDV draft doesn not need to send with measurement information xr block if we view it as sample metric.
also delay metric defined in xr delay draft is also loosely coupled with measurement information xr block. So it seems we should case by case to consider if measurement information xr block should
be sent with other metric block.

Regards!
-Qin

Hi,

Roni

---

From: Alan Clark <[email-masked]>
Date: Sat, 12 Nov 2011 21:18:16 -0500

Qin

(i) The SSRC defines the stream but not the measurement interval.

(ii) The metric block has to either be in the same compound RTCP packet as
the measurement identification block or be associated by a tag.

(iii) Some networks limit the size of the RTCP packet that can be passed
through SBC's or similar systems. This means that it may not be practical to
put all the metrics blocks into a single RTCP packet.

(iv) There are limitations on the frequency with which RTCP packets can be
sent. If it is required that the measurement identification be carried in
the same RTCP packet as the metrics blocks then you could not carry more
than one set of interval data within an RTCP packet.  For example, what if
you wanted to use a measurement interval of 3 seconds but you could only
send an RTCP packet every 6 seconds?

The Tag provides an efficient way to relate metrics blocks that may be
carried in more than one RTCP packet, or alternatively to allow more than
one set of interval data to be carried within a single RTCP packet.

Is there a particular problem that the Tag introduces? I personally can't
see any downside to the use of tags but can see several benefits.

Best Regards

Alan

On 11/12/11 12:14 PM, "Qin Wu" <[email-masked]> wrote:

> 主题: RE: [xrblock] Measurement Duration, extended first and last sequence
> number of interval and Interval Metric flag
> 
> Qin,
> Inline
> Roni
> 
> Subject: 答复: [xrblock] Measurement Duration, extended first and last sequence
> number of interval and Interval Metric flag
> 
> Hi, Roni:
> I am not sure we still need to use tag since each metric block has SSRC and
> each measurement information XR Block has SSRC, SSRC will be used to identify,
> group, correlate different participants between metric blocks or between
> metric block and measurement information XR block.
> 
> When one RTCP compound packet carry more than one measurement information XR
> blocks with other relevant metric blocks, it doesn't matter which order should
> be chosen for the multiple measurement information XR Blocks. I think this has
> been discussed for many times. Shall we break this again?
> 
> RE: this is OK
> 
> Also I am not sure all the metric block should use measurement interval and
> the extended first and last sequence number to calculate the values in the
> individual reports.
> I only remember in Gap Loss rate metric specified in both
> draft-ietf-xrblock-rtcp-xr-burst-gap-loss and
> draft-zorn-xrbock-rtcp-xr-al-stats use extended first and last sequence number
> [Qin]: Number of packet lost is defined in
> draft-ietf-avt-rtcp-xr-postrepair-loss-02.
> and hasn't be chartered into XRBLOCK WG scope. That is to say this draft is
> dead or there is other alternative draft to replace it.
> 
> So to my understanding, it looks some of metric blocks are densely coupled
> with measurement information XR block defined
> draft-ietf-xrblock-meas-identity, some of other metric block
> are loosly coupled with measurement information xr block. Unless the
> monitoring system should know the measurement interval each time it receives a
> RTCP compound packet containing XR blocks.
> If  any failure case happens, we can ask monitoring system discard the XR
> block without measurement interval sent together. Does this make sense?
> 
> RE: So you are suggesting that the measurement identity will not be sent with
> every XR report compound packet. In this case I think it may be better to have
> the information in the XR-report.
> So the sender will either send a compound packet with measure identity xr
> reports with the period and if required the first and last packet or instead
> the number of packet expected in the period.
> 
> [Qin]: Yes, for example , PDV metrid defined in PDV draft doesn not need to
> send with measurement information xr block if we view it as sample metric.
> also delay metric defined in xr delay draft is also loosely coupled with
> measurement information xr block. So it seems we should case by case to
> consider if measurement information xr block should
xrblock mailing
> list
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Sun, 13 Nov 2011 11:27:50 +0800

> the measurement identification block or be associated by a tag.

The SSRC could be used as the tag, no? That's how other RTCP blocks are related to each other.

Colin

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

---

From: Roni even <[email-masked]>
Date: Sun, 13 Nov 2011 07:32:03 +0000

Hi Colin,
the SSRC can define the stream but not the RTCP XR reports that provide information about this specific time interval. There may be multiple measurements blocks with the same SSRC. So you can link them by tag or by putting them in order in the same RTCP compound packet so that the measure block with a specific SSRC provides the measurement information to all report blocks following him until the next measurement information block with the same SSRC

Roni

________________________________________
From: Colin Perkins [[email-masked]]
Sent: Sunday, November 13, 2011 5:27
To: Alan Clark
Cc: Qin Wu; Roni even; [email-masked]
Subject: Re: [xrblock]  Measurement Duration, extended first and last sequence number of interval and Interval Metric flag

Colin

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

---

From: "Roni Even" <[email-masked]>
Date: Sun, 20 Nov 2011 13:46:36 +0200

Hi Alan,
The view is that the identity block precedes the report blocks for the same
time period, so if there are two time periods in the same compound packet
there will be two identity blocks. 
If a the number of report blocks need to span over more than one RTCP report
packet, the identity block will be duplicated in the second RTCP compound
packet. This will address the issue of robustness against packet loss since
there will be an identity block in each RTCP compound packet
Roni Even 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alan Clark
> Sent: Sunday, November 13, 2011 4:18 AM
> To: Qin Wu; Roni even; [email-masked]
> Subject: Re: [xrblock] 答复: Measurement Duration, extended first and
> last sequence number of interval and Interval Metric flag
> 
> Qin
> 
> (ii) The metric block has to either be in the same compound RTCP packet
> as the measurement identification block or be associated by a tag.
> 
> (iii) Some networks limit the size of the RTCP packet that can be
> passed through SBC's or similar systems. This means that it may not be
> practical to put all the metrics blocks into a single RTCP packet.
> 
> (iv) There are limitations on the frequency with which RTCP packets can
> be sent. If it is required that the measurement identification be
> carried in the same RTCP packet as the metrics blocks then you could
> not carry more than one set of interval data within an RTCP packet.
> For example, what if you wanted to use a measurement interval of 3
> seconds but you could only send an RTCP packet every 6 seconds?
> 
> carried in more than one RTCP packet, or alternatively to allow more
> than one set of interval data to be carried within a single RTCP
> packet.
> 
> Is there a particular problem that the Tag introduces? I personally
> can't see any downside to the use of tags but can see several benefits.
> 
> Best Regards
> 
> Alan
> 
> 
> 
> 
> > 主题: RE: [xrblock] Measurement Duration, extended first and last
> > sequence number of interval and Interval Metric flag
> >
> > Qin,
> > Inline
> > Roni
> >
> > Subject: 答复: [xrblock] Measurement Duration, extended first and
> last
> > sequence number of interval and Interval Metric flag
> >
> > Hi, Roni:
> > I am not sure we still need to use tag since each metric block has
> > SSRC and each measurement information XR Block has SSRC, SSRC will be
> > used to identify, group, correlate different participants between
> > metric blocks or between metric block and measurement information XR
> block.
> >
> > When one RTCP compound packet carry more than one measurement
> > information XR blocks with other relevant metric blocks, it doesn't
> > matter which order should be chosen for the multiple measurement
> > information XR Blocks. I think this has been discussed for many
> times. Shall we break this again?
> >
> > RE: this is OK
> >
> > Also I am not sure all the metric block should use measurement
> > interval and the extended first and last sequence number to calculate
> > the values in the individual reports.
> > draft-zorn-xrbock-rtcp-xr-al-stats use extended first and last
> > sequence number to calculate the packet expected. If I miss the other
> > use case, please point to me.
> >
> > RE:
> > In Post repair
> > However it looks draft-ietf-avt-rtcp-xr-postrepair-loss-02 has been
> > abandoned and hasn't be chartered into XRBLOCK WG scope. That is to
> > say this draft is dead or there is other alternative draft to replace
> it.
> >
> > Same for xr-discard also in gap discard (derived metrics) I think
> that
> > the monitoring system will want to know the period of the report .
> >
> > [Qin]: Agree. Since burst  gap discard, xr-discard are more related
> to
> > burst gap loss draft.
> >
> > So to my understanding, it looks some of metric blocks are densely
> > coupled with measurement information XR block defined
> > draft-ietf-xrblock-meas-identity, some of other metric block are
> > loosly coupled with measurement information xr block. Unless the
> > monitoring system should know the measurement interval each time it
> > receives a RTCP compound packet containing XR blocks.
> > If  any failure case happens, we can ask monitoring system discard
> the
> > XR block without measurement interval sent together. Does this make
> sense?
> >
> > RE: So you are suggesting that the measurement identity will not be
> > sent with every XR report compound packet. In this case I think it
> may
> > be better to have the information in the XR-report.
> > So the sender will either send a compound packet with measure
> identity
> > xr reports with the period and if required the first and last packet
> > or instead the number of packet expected in the period.
> >
> > [Qin]: Yes, for example , PDV metrid defined in PDV draft doesn not
> > need to send with measurement information xr block if we view it as
> sample metric.
> > also delay metric defined in xr delay draft is also loosely coupled
> > with measurement information xr block. So it seems we should case by
> > case to consider if measurement information xr block should be sent
> > with other metric block.
> >
> > Regards!
> > -Qin
> >
> > 发件人: [email-masked] [[email-masked]] 代表 Roni
> even
> > [[email-masked]]
> > 发送时间: 2011年11月12日 20:47
> > 到: [email-masked]
> > 主题: [xrblock] Measurement Duration, extended first and last
> sequence
> > Currently the relation between the measure identity block and the
> > report block are not specified. Previously the text in all the report
> > blocks stated that the measurement interval and the extended first
> and
> > last sequence numbers in the relevant identity block were used to
> > calculate the values in the individual reports. I assume this
> > information is still needed by the monitoring system in order to know
> > what is the reporting period. The tag was used to link the different
> reports with a specific measurement block.
> > Now we took out the tag and I think we need to agree if we want each
> > report to have these values or have the identity block with the value
> > applicable to a couple of reports.
> > If we want to have the measurement identity block we need to define
> > the linkage and the reliability of this block.  So in my view the
> open
> > questions are
> >
> > 2.       Do we want to have a measurement identity block that will
> provide
> > these values to more than one report
> > I think that we can have both if we specify that these values must
> > always be the last ones in the report block and based on the length
> > you can know if they exist.
> > I think that the reliability of the measurement identity  is
> important
> > and it should probably be mandatory to send it as part of a compound
> > packet that include this block and the report blocks that are based
> on
> > it. Anyhow if we do not have a tag it will be difficult to link the
> > measurement identity to a report block.
> >
> >
> > I also think that we will need some text explaining the use of these
> > values (measurement interval and the extended first and last sequence
> > numbers ) in the monitoring architecture draft or the measurement
> > identity draft if we intend to have a measurement identity block
> >
> >
> > Roni