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

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Sep 2010 09:30:32 +0100

Geoff,

I support this work going forward, but am unlikely to be able to make  
this call, due to other commitments that day.

Cheers,
Colin

On 25 Aug 2010, at 11:09, <[email-masked]> <[email-masked]> wrote:
> All
>
> At the Maastricht AVT meeting discussion on draft-hunt-avt- 
> monarch-01 there was a proposal for a call to discuss and agree what  
> is required in a monitoring architecture for RTP. Depending on what  
> is agreed on this call, there may be further calls to progress the  
> work.
>
> I would like to propose an initial 1 hour call starting at some time  
> between 12:00 and 15:00 UTC on Tuesday 14th September. Within this  
> window, I will choose a best-fit start time depending on  
> participants' time zones and preferences. [I believe 12:00 UTC is  
> 05:00 US West Coast, 08:00 US East Coast, 13:00 UK, 14:00 Central  
> European, 14:00 Israel (DST ends 12-Sep), 16:30 India, 19:00 China.]
>
> If you are interested in participating in this call, please email me  
> direct no later than 6th September to let me know your preferred  
> start time and any suggestions for specific topics you would like to  
> discuss on the call. I will send out the best-fit start time, dial- 
> in details and an initial agenda no later than 8th September
>
> Thanks
> Geoff Hunt
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 13 Sep 2010 06:30:29 -0700

I am not sure whether this is within the scope of this work but I personally think this has a lot of use cases and benefits.

We recently published a paper on this:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5430139

Googling "network tomography" or "fault isolation" also brings up other useful references.

On the tagging side, I think it has to be discussed more thoroughly. 

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, September 13, 2010 4:22 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP
> 
> 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
> 
>