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

[Roni even <[e-mail]>]

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 [[e-mail]]
Sent: Sunday, November 13, 2011 5:27
To: Alan Clark
Cc: Qin Wu; Roni even; [e-mail]
Subject: Re: [xrblock]  Measurement Duration, extended first and last sequence number of interval and Interval Metric flag

On 13 Nov 2011, at 10:18, Alan Clark wrote:

> 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.

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

Colin


> (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" <[e-mail]> wrote:
>
>> Hi, Roni:
>> See below.
>>
>> Regards!
>> -Qin
>> ________________________________________
>> 发件人: Roni even
>> 发送时间: 2011年11月13日 0:37
>> 到: Qin Wu; [e-mail]
>> 主题: RE: [xrblock] Measurement Duration, extended first and last sequence
>> number of interval and Interval Metric flag
>>
>> Qin,
>> Inline
>> Roni
>>
>> ________________________________________
>> From: Qin Wu
>> Sent: Saturday, November 12, 2011 17:52
>> To: Roni even; [e-mail]
>> 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.
>>
>> 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
>> 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.
>>
>> [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.
>>
>> 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.
>> 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?
>>
>> 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
>>
>> 发件人: [e-mail] [[e-mail]] 代表 Roni even
>> [[e-mail]]
>> 发送时间: 2011年11月12日 20:47
>> 到: [e-mail]
>> 主题: [xrblock] Measurement Duration, extended first and last sequence number of
>> interval and Interval Metric flag
>>
>>
>> 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
> _______________________________________________
> xrblock mailing
>> list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock
>
>
>
>
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock



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