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

From: [email-masked]
Date: Wed, 12 Oct 2011 20:15:48 -0700

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&#39;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-01.txt
	Pages           : 13
	Date            : 2011-10-12

   This document defines a RTCP SDES item and a RTCP XR Block carrying
   parameters which identify a measurement, 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-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

---

From: Qin Wu <[email-masked]>
Date: Thu, 13 Oct 2011 16:28:20 +0800

Here is version 01.
http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt
This revision adds  the XR Block format to convey additional measurement informtation. We are still using SDES item format to carry APSI. This was brought up by Colin.

These additional measurement information is still useful becos draft-ietf-avt-rtcp-xr-burst-gap-discard-02 and draft-ietf-avt-rtcp-xr-burst-gap-loss-02
depends on this information to calculate the whole number of packets expected.

For diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 13, 2011 11:15 AM
Subject: [xrblock] I-D Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Oct 2011 11:17:14 +0100

Qin,

Thanks - this addresses most of my comments on the previous version. 

I'm still somewhat unconvinced that we need a separate report to convey measurement duration, rather than including it in each report block. It can avoid duplication, I agree, but at the cost of potential ambiguity if the measurement duration block is not sent. My preference is to accept the potential duplication, to avoid the failure condition, but it would be interesting to hear other opinions.

Colin

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 13 Oct 2011 13:12:52 +0200

My opinion:

When we would use the measurement identity SDES item, measurement information XR block, together with an associated set of a number of metric XR blocks, - e.g. in performance monitoring and reporting architecture as a network overlay -, then the measurement duration (cumulative & interval) would be normally common characteristics across all metrics.

Don't see the use case for metric-individual measurement duration settings.

Thus, could be kept in the measurement information XR block in my opinion.

My .03 €,
Albrecht

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Donnerstag, 13. Oktober 2011 12:17
> To: Qin Wu
> Cc: [email-masked]
> Subject: Re: [xrblock] I-D 
> Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt
> 
> Qin,
> 
> I'm still somewhat unconvinced that we need a separate report 
> to convey measurement duration, rather than including it in 
> each report block. It can avoid duplication, I agree, but at 
> the cost of potential ambiguity if the measurement duration 
> block is not sent. My preference is to accept the potential 
> duplication, to avoid the failure condition, but it would be 
> interesting to hear other opinions.
> 
> Colin
> 
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-meas-id
> > entity-01.txt This revision adds  the XR Block format to convey 
> > additional measurement informtation. We are still using 
> SDES item format to carry APSI. This was brought up by Colin.
> > 
> > These additional measurement information is still useful becos 
> > draft-ietf-avt-rtcp-xr-burst-gap-discard-02 and 
> > draft-ietf-avt-rtcp-xr-burst-gap-loss-02
> > Subject: [xrblock] I-D 
> > Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt
> > 
> > 
> >> 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&#39;s Extended Report 
> Framework Working Group of the IETF.
> >> 
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-meas-id
> >> entity-01.txt _______________________________________________
> >> xrblock mailing list
> >> [email-masked]

---

From: "Rachel Huang(yihong)" <[email-masked]>
Date: Thu, 13 Oct 2011 14:50:34 +0000

The intention that we use the measurement identity is to reduce the duplicated fields in every metric XR blocks, to save bandwidth when we're monitoring. It will benefit those systems whose resources are not rich, for example, systems with low-bitrate links. While in those systems, the RTCP XR packets may not be able to compound together, which has been described in [RFC5506]. And in this case, these RTCP XR blocks may have to be sent with measurement indentity block one by one, and I don't think it can achieve the original intention. 
So I agree with Colin. my opinion is that we don't need to involve important fields (like durations) which are closely connected with metric XR blocks.

______________________________________
发件人: [email-masked] [[email-masked]] 代表 Schwarz, Albrecht (Albrecht) [[email-masked]]
发送时间: 2011年10月13日 19:12
到: Colin Perkins; Qin Wu
Cc: [email-masked]
主题: Re: [xrblock]       I-D     Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

My opinion:

My .03 �,
Albrecht

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 13 Oct 2011 18:18:12 +0200

Two comments Rachel:
1) Well, that's not a general observation, rather a specific use case, given by a condition of limited transport capacity.
Leading to two type of IP access networks ("because if there's a bottleneck, then in the network access"), one type with strict limitations on the available RTCP transport capacity for measurement reports, and one type without strict limitations.

As a side note: the measurement point may be also located on network level, e.g. in a gateway, without your condition of limited transport.

2) Could you provide some guidance concerning expected transport capacity? I.e., what's your estimated ratio between the RTP media traffic and associated RTCP XR measurement traffic?
I know, it's dependent on the number of metric types etc, but I've think you should provide some quantitative figures, especially concerning your expected bandwidth savings ("single, large compound packet vs multiple ..."). 

Thanks,
Albrecht

> From: Rachel Huang(yihong) [mailto:[email-masked]] 
> Sent: Donnerstag, 13. Oktober 2011 16:51
> To: Schwarz, Albrecht (Albrecht); Colin Perkins; Qin Wu
> Cc: [email-masked]
> Subject: 答复: [xrblock] I-D 
> The intention that we use the measurement identity is to 
> reduce the duplicated fields in every metric XR blocks, to 
> save bandwidth when we're monitoring. It will benefit those 
> systems whose resources are not rich, for example, systems 
> with low-bitrate links. While in those systems, the RTCP XR 
> packets may not be able to compound together, which has been 
> described in [RFC5506]. And in this case, these RTCP XR 
> blocks may have to be sent with measurement indentity block 
> one by one, and I don't think it can achieve the original intention. 
> So I agree with Colin. my opinion is that we don't need to 
> involve important fields (like durations) which are closely 
> connected with metric XR blocks.
> 
> 发件人: [email-masked] [[email-masked]] 代表 
> Schwarz, Albrecht (Albrecht) [[email-masked]]
> 发送时间: 2011年10月13日 19:12
> 到: Colin Perkins; Qin Wu
> Cc: [email-masked]
> 主题: Re: [xrblock]       I-D     
> When we would use the measurement identity SDES item, 
> measurement information XR block, together with an associated 
> set of a number of metric XR blocks, - e.g. in performance 
> monitoring and reporting architecture as a network overlay -, 
> then the measurement duration (cumulative & interval) would 
> be normally common characteristics across all metrics.
> 
> > I'm still somewhat unconvinced that we need a separate report to 
> > convey measurement duration, rather than including it in 
> each report 
> > block. It can avoid duplication, I agree, but at the cost 
> of potential 
> > ambiguity if the measurement duration block is not sent. My 
> preference 
> > is to accept the potential duplication, to avoid the failure 
> > condition, but it would be interesting to hear other opinions.
> >
> > Colin
> >
> >
> >
> > Internet-Drafts directories. This draft is a work item of 
> the Metric 
> > Blocks for use with RTCP&#39;s Extended Report Framework 
> Working Group 
> > of the IETF.
> > >>

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Oct 2011 08:50:21 +0800

Good justification!

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Oct 2011 09:11:56 +0800

Hi, Colin:
Firstly, I think the mesurement duration is common to all the metrics blocks, irrespective it is Interval or a Cumulative metric.So as Albrecht said, it should be okay
to include measurement duration in the measurement information block.

Secondly, if the measurement duration is not used or unavailable, we can set the value of measurment duration to 0xFFFFFFFF in the block.

Thirdly, if one metric block does not rely on measurement information block to calculate its metric parameters or does not use information in the measurement information block , 
we don't need send measurement information block with that metric block each time.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 13, 2011 6:17 PM
Subject: Re: [xrblock] I-D Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

Qin,

Colin

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

---

From: "Rachel Huang(yihong)" <[email-masked]>
Date: Fri, 14 Oct 2011 12:44:59 +0000

Hi, Albrecht,

Thanks for your comments. Please see my answers inline.

Best Regards!
Rachel

________________________________________
发件人: Schwarz, Albrecht (Albrecht) [[email-masked]]
发送时间: 2011年10月14日 0:18
到: Rachel Huang(yihong); Colin Perkins; Qin Wu
Cc: [email-masked]
主题: RE: [xrblock]       I-D     Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

Two comments Rachel:

[rachel] I think the xr blocks are not only used by the monitoring boxes in the nextwork to report status, but also used by the endpoints who may be located in an access network of limited transport, e.g. radio access networks.

[rachel] Maybe I didn't clarify myself so clearly before. I didn't mean using measurement identity block was not efficient. It does, most times. But it is not so flexible when we involve some fields which are connected closely with metric blocks. We have to send these metric blocks together with measurement identity block every time. But the figure what I prefer to see is that measurement identity block is a informational one, which can be sent occasionally and have not to be sended with xr metric blocks together. In that case, when there is no resources limitation, we can compound as much as possible metric blocks. When there is limitation, we can send proper number of metric blocks, may be one, two....ten, or other numbers which depends on the condition. Of course, sending measurement identity together with the xr metric blocks can also satisfiy the requirement, but small packets are more robust to poor radio conditions than large packets, I think. Besides, it's more flexible when there are multiple measurement duration requirement.

Thanks,
Albrecht

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Oct 2011 17:11:24 +0100

Qin,

I agree with your comments, but they don't answer my concern.

If the duration of a measurement is sent in the same RTCP XR block as the measurement, then it will always be available when the measurement is received. However, if the duration of a measurement is sent in a measurement identity RTCP XR Block, separate to the actual measurement, then there is a chance that a measurement will be received without its associated measurement identity. What do you do in that case? I think those failure modes need to be documented if you are to introduce a measurement identity block.

Colin

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Oct 2011 14:52:15 +0800

Regarding the case you mentioned, I think this is a tradeoff we should keep in mind when we use separate measurement information XR Block.
that is to say, we should be certain if separated measurement information XR Block is required to be sent with measurement included in other Metric Block.

Also I have two counter questions:
1.Do we have use case how measurement duration is used, e.g., using measuremnt duration to calculate the metrics that is carried in the metric block?
2. Is measurement druation changed frequently? 
If measurment duration is not changed frequently, I think we can rely on the past observation on measurement duration.
If change of measurement duration happens, we can require measurement duration must be sent with each metric that is relevant.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 18, 2011 12:11 AM
Subject: Re: [xrblock] I-D Action:draft-ietf-xrblock-rtcp-xr-meas-identity-01.txt

Qin,

Colin