Subject: [xrblock] (Bursts and Gaps) Open issue 2: potential metrics block extension

From: [email-masked]
Date: Tue, 20 Dec 2011 11:39:41 +0800 (CST)

Hi, folks:

Following the mailing list discussion regarding whether potential metrics is needed in the Bursts and Gaps drafts

http://www.ietf.org/mail-archive/web/xrblock/current/msg00139.html

We have briefly discussed these potential metrics that could be added to burst gap metrics, proposed by Alan in the Taipei meeting.

Unfortuntely this issue hadn't been concluded in the IETF 82 meeting.

For the way forward to burst gap discard draft and burst gap loss draft, we like to discuss the relation between

these potential extension and burst gap drafts and decide which should be included and which not.

a. Max burst length
In the meeting, we were asked to clarify run-length be used for calculating max burst. After reading draft-ietf-xrblock-rtcp-xr-discard-rle-metrics,

we are aware that the difference between rle discard and burst gap discard has been well clarified in the introduction section of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.

Also we believe run length encoding discard is one way to calcualte max burst length.

In the burst gap discard draft, if there are 4 burst and 5 gaps,  burst gap discard metric block can be used to report sum of burst durations and squares of burst durations. However

However none of these metrics are used to report Max burst length. It is true that Max burst length represents the “worst” period from a QoE perspective ,However I think Max burst lengh should not be part of burst gap discard metric block or burst gap loss metric block.
Since we use threshold to divide RTP stream into gap and burst. All the other metric we include in the burst gap discard and burst gap loss are used to calculate burst loss rate, gap loss rate, burst discard rate, gap discard rate, burst duration mean, burst duration dev. Use burst druation mean and burst duration dev, we can indicate estimate

how large the max burst length is. So Max burst length is not needed in the burst gap drafts.

b. Average burst

In the meeting, we were also asked to clarify whether there is a need to add average burst. Our answer is no, as we explained  in the (a), the metrics included in the burst gap loss and burst gap discard

will be finally used to calculate burst duration mean and
burst duration variance. Therefore Average burst can be estimated using burst duration mean. we don't need to add average burst into the existing draft-ietf-rtcp-xr-burst-gap-discard and draft-ietf-rtcp-xr-burst-gap-loss, instead, we should put into a new separate
metric blocks. These new separate metric blocks have already been defined in the draft-zorn-xrblock-al-stat, i.e., Burst/Gap Discard Summary Statistics Block and Burst/Gap Loss Summary Statistics Block.

c.Time Since Last Burst

On the list, Alan proposed to add time since last burst into burst gap draft, the reason provided by him is it is helpful to know when the last substantial loss/discard burst occurred relative to the report time.

We agree it is useful. However we realize it is not easy for us to directly measure Time since last burst if we rely on RLE discard and don't keep track of packets sequence number  in the interval

one way to calculate this metric is to rely on run length encoding discard metric in the draft-ietf-xrblock-rtcp-xr-discard-rle-metrics. On the other hand, the data we carried in the burst gap drafts are all used to calculate statistics summary of burst gap, however time since last burst is not used to calculate statistics summary of burst gap, therefore time since last burst is not part of burst gap draft and therefore is not needed.

Therefore my conclusion is each of them are very useful. However it is not a good idea to put them all into burst gap drafts since some of them can be estimated implicitely(e.g., Max burst length, Avrage burst), some of them is not easy to calculate and not has the same purpose as other measurement results included in the burst gap discard and loss.

That's what we understanding to these potential metrics block extension, let me know if you have different opinion.

Regards!

Sunshine and Jing

Shanghai Research Institute of China Telecom