Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP

From: <[email-masked]>
Date: Mon, 13 Sep 2010 14:22:16 +0100

All

Qin mailed me to ask for a clarification of this obscure agenda item:

>      - measurement correlation keys

The thinking is as follows - we can discuss further on the call if people agree there's a requirement (and possibly a solution) in scope of our work:

The agenda item about measurement correlation keys relates to making multiple measurements at different locations across a multi-segment (maybe multi-provider) network, e.g. at several SBCs. This is motivated by a wish to localise sources of impairment, at least at the level of a network segment.

If measurements are transported in RTCP then they remain associated with the session they monitor, and there is bandwidth available to make, and to transport, measurements for every session.

However some (UK) experts have suggested making measurements on only a sample of sessions. This is typically associated with transporting measurements in a management layer, to minimise the volume of data and the associated processing.

If the measurements are to have any value for fault localisation, it's almost essential to make, and then compare, measurements on a stream made over the same time period at the first and last nodes of a network segment. If streams are sampled independently at these two nodes, particularly if the probability that a given stream will be sampled is rather low, there could be very few streams for which two measurements are available (one at each node). If so it would be difficult to determine whether an impairment seen at the egress node from a network segment was introduced before entry to the network segment, or within the segment.

Part of a solution to this problem is to find a variable (which could be a composite of fields already present in packet headers) which is available to every node through which a stream passes, so that a common function operating on this key will always produce the same result ("sample" or "don't sample") in every node.

Another part of a solution to the problem is to tag the resulting measurements going "northbound" to management systems so that measurements made on the same stream may be correlated within management systems, so that results for a given stream taken at successive nodes may be collected and compared.

Regards
Geoff

---

From: Qin Wu <[email-masked]>
Date: Tue, 14 Sep 2010 10:23:28 +0800

Hi,
It looks more like SQL primary key which can be used to locate the specified stream.
Two typical usages would be fault localization and fault isolation. 
I think it is worth being further discussed. But we should more focus on RTP or RTCP XR.
I am not sure how this information can be carried in RTP packet or RTCP XR. How much additional overhead
is introduced into the RTP packet comparing with the avantages you mentioned. Is there any other specifications 
that support using such information?

Regards!
-Qin

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 13, 2010 9:22 PM
Subject: RE: Audio to discuss monitoring architecture for RTP

All

Regards
Geoff