<html>

<body>

<h1 align="center">QoS Monitoring for MBone Diagnostics</h1>

<h3 align="center">

<br>Dr JLRobinson & JStewart

<br>Communications Research Centre

<br>Ottawa

<br>

<br>http://www.merci.crc.doc.ca/

<br>

<br>30 May 1997

</h3>

<h2>1.0 Introduction</h2>

        <p>The multicasting capability that is beginning to be deployed on the Internet offers 

efficient network support for emerging interactive real-time applications but in reality MBone 

audio/video conferencing is currently the only commonly deployed multicast application. Hence 

most trials of Internet multicasting take place in the context of MBone experimentation. 

        <p>Anyone who has participated in an MBone event will no doubt have noticed, especially in 

global events, that the technology is not mature. A short list of the things to be done includes:

<ul>

<li>multicast routing protocols are under development - PIM, DVMRP, MOSPF, etc.

<li>resource reservation is under development - RSVP, COS,  etc.

<li>lots of MBone application components are still prototypes - SDR, RAT, RTP, etc.

</ul>

and 

<ul>

<li>the IETF is heavily involved in all sorts of  research on real-time and multicast technology - IETF 

Working Groups: MBoneD, MMUSIC, AVT, BMWG, etc..

</ul>

        <p>Despite the enthusiasm for the MBone, in Europe at least, the MBone is considered still to 

be an experiment.  The MICE Project [1] played an important role in the initial deployment of 

experimental MBone capability in Europe during 1991-1995. Some of the MICE partners, with the 

Communications Research Centre (CRC) Ottawa, are carrying on MBone R&D under a European 

Union sponsored research Project called MERCI (Multimedia European Research Conferencing 

Integration).  The overall objective of the MERCI Project is to develop the MBone 

videoconferencing technology so that it is usable by non-experts.

        <p>One of the missing components that is essential for the success of the MBone is the ability 

to manage and control the videoconference sessions and the MBone network. Contributing to this, 

one of the MERCI research activities is a study of Quality-of-Service (QoS) monitoring for MBone 

diagnostics. Existing protocols (e.g. IPmc, RTP) contain MBone QoS measurement functionality that 

provides a useful starting point for the study. An MBone monitoring and diagnostic tool, 

combining network level (IPmc/ICMP/IGMP) and transport level (RTP/RTCP) QoS measurements, 

has been designed at CRC and a prototype is under development.

        <p>In this paper, after briefly introducing the MERCI Project, QoS architectures and the 

performance parameters and metrics that are appropriate for MBone QoS management will be 

discussed. The prototype QoS monitoring tool that is under development at CRC will then be 

introduced. The first phase of our program has concentrated on monitoring with RTP/RTCP and 

this will be used to illustrate our approach. The paper will conclude with a review of the results 

from our study and initial implementation and a brief description of our future plans.

<h2>2.0 The MERCI Project</h2>

        <p>MERCI (Multimedia European Research Conferencing Integration) is a European Union 

4th Framework Telematics R&D Project with the overall objective of providing the technology 

components to allow proper deployment of the tools for multimedia collaboration. A principle 

focus of MERCI is on MBone multi-media conferencing tools. Under the preceding Project (MICE) 

some members of this community of researchers made important contributions to the development 

of the MBone protocols and applications and they played a central role in the deployment of 

MBone in Europe. That work is continuing in MERCI.

        <p>The partners  in the Consortium (Figure 1) include the Communication Research Centre 

in Ottawa, the University College London (UCL), the French National Institute for Research in 

Computer Science and Control (INRIA), the Swedish Royal Institute of Technology (KTH), Oslo 

University in Norway, the German National Research Centre for Computer Science (GMD) and the 

Stuttgart University Supercomputer Center (RUS). A Canadian research organisation such as CRC 

can participate in this type of European Research Project as an official partner because of the 

Science and Technology Agreement signed by Canada and the European Union (EU) in 1995.

<p><img src="Figure1.JPEG">

<em><p>Figure 1: The MERCI Partners</em>

<p>The research themes in MERCI include the multicast multi-media conferencing tools (VAT, RAT, 

VIC, IVS, SDR), the switching and protocol infrastructure that provides the real-time and multicast 

network service required by those applications (RTP, DVMRP, RSVP, IPv6,...), and the usability of 

this technology. Over the course of the Project a series of multimedia conferencing events, 

including Scientific Seminars, Distance Learning Initiatives and Surgical Workshops, have been 

planned to test and validate the prototype technologies and to study human factors issues and 

Conference Room ergonomics. As well, private videoconferences are held regularly by the 

partners for project co-ordination and to test and assess the technology.

        <p>In Europe there has been a tight linkage between the MBone, the European ATM Test 

Networks and the Internet. The MICE/MBone was a prime user of the ATM Test Network and that 

infrastructure was embedded in the European Internet  (for experimental MBone use only). The 

MERCI partners are continuing this arrangement using the EU JAMES Project to experiment with 

expanded and improved international MBone infrastructure by integrating the emerging high 

speed networking facilities provided by ATM (Figure 2).

<p><img src="Figure2.JPEG">

<em><p>Figure 2: the CANTAT-3 link to the European MERCI/JAMES MBone</em>

        <p>CRC has an agreement with Teleglobe Canada Inc by which CRC researchers can make 

use of the CANTAT-3 trans-Atlantic submarine cable for research projects. This agreement has 

been used for transport protocol performance characterisation experiments between the DRX 

laboratories at CRC and DeTeBerkom in Berlin [2] and has been used for a number of trials between 

the CRC BADLab and European partners under the EU ACTS Programme and the G-7 GIBN initiative. 

Recognising that a direct broadband connection from Canada to Europe could greatly enhance our 

MBone connectivity CRC has obtained permission from Teleglobe Canada to use the CANTAT-3 to 

connect CRC to the Supercomputer Center in Stuttgart, Germany and thence to the 

MERCI/JAMES/MBone.

        <p>While a JAMES/CANTAT-3 high speed backbone is ideal for MERCI purposes this is a 

valuable resource and a private research network that cannot be available constantly for the 

Project. This has motivated the MERCI partners to rely on the global MBone as an alternative, less 

reliable and lower bandwidth network, that can be used throughout the Project to connect the 

partners.

        <p>In Canada, it is only very recently that, with the CANARIE Multicast Project [3] (and soon 

the CA*Net II), multicast has become possible on the Canadian Internet infrastructure. This has 

not been yet a viable means for CRC to connect to the global MBone. CRC, because of a cooperative 

agreement for multicast studies with the Canadian Department of National Defence, is fortunate to 

have direct access, via the DRENet, to a major Internet/MBone access point in the USA. An 

illustration of the various Internet/MBone access routes from CRC is shown in Figure 3. We are 

continually seeking other routes to the European MBone and, as a contribution to the MERCI 

Project, we are measuring the performance and investigating the multicast routing paths on those 

connections.

<p><img src="Figure3.GIF">

<p><em>Figure 3: Network Routes between CRC and the MERCI Partners in Europe</em>

<h2>3.0 MBone QoS Monitoring </h2>

<h3>3.1 Introduction</h3>

        <p>It is well recognised that multicast diagnostic tools are needed for the following settings: 

customer service or support, network or system administration, network operations center; 

however instrumentation of the multicast Internet is a work in progress. Monitoring and 

diagnostic tools have been under development over the last few years and prototypes are available 

on-line (ShareWare) from various Internet repositories. An overview of those tools can be found 

in [4]. These tools rely on one or more of the following facilities: RTCP source and receiver reports, 

SNMP MIBs, IGMP trace facility, IGMP ASK_NEIGHBORS  message, routing arbiter database, internal 

structures (Table 1).

<p><table border>

<th>Facility</th>        <th>Diagnostic Tool</th><tr>

<td> RTCP source and receiver reports</td><td>RTPMon MSessMon RTPquality RTPdump RTPcast/RTPlisten Duppkts</td><tr>

<td> SNMP MIBs</td>        <td>multicast heartbeat mconfig MStat MView MRTree</td><tr>

<td> IGMP trace facility</td> <td>MTrace</td><tr>

<td> IGMP ASK_NEIGHBORS message</td>        <td>mrinfo MRTree Map-MBone MRMap</td><tr>

<td> Routing arbiter Database</td> <td> asn asname</td><tr>

<td> Internal structures</td> <td> TCPDump NetStat</td><tr>

<caption>Table 1: Multicast Diagnostic Tools Categorised by Facilities Utilised</caption>

</table>

        <p>With our MERCI partners we have been investigating these tools, concentrating initially 

on those that support QoS monitoring. In general we have found that expert understanding is 

essential to interpret the information and displays that are generated by the tools. Furthermore, 

for even very basic and limited management and control of MBone sessions constant human 

intervention is needed. This does not satisfy our aim to support non-expert users and has motivated 

us to rethink multicast QoS monitoring from first principles. 

        <p>We describe below a formal QoS Framework (Section 3.2), a categorisation of traffic 

characteristics based on conference session types (Section 3.3) and a consideration of the QoS 

information that can be obtained directly from the existing protocols (Chapter 4).  This is the 

foundation on which we describe the requirement for QoS management and the possibilities for 

simplified QoS monitoring and diagnostics.

<h3>3.2 QoS Framework</h3>

<h4>3.2.1 QoS Architectures </h4>

        <p>In distributed multimedia systems it is essential that all the end-to-end elements work 

together to achieve the desired application level behaviour. Meeting QoS guarantees is a 

fundamental issue that must be addressed. A QoS architecture provides the broad framework that is 

needed for an overall characterisation of the QoS management required for successful multimedia 

communications. That QoS framework must provide a specification of: flow synchronisation; flow 

performance; level of service; QoS management policy; and cost of service with the related 

categories of QoS parameters shown in Table 2. More details can be found in the excellent state-of-

the-art reviews presented in [5] and [6].

<p><table border>

<th>Category</th>        <th>parameter examples</th><tr>

<td>synchronisation oriented</td>        <td>skew between sequences</td><tr>

<td>performance oriented</td>        <td>bit rate and delay</td><tr>

<td>format oriented</td>        <td>video resolution, frame

rate</td><tr>

<td>user oriented</td>        <td>subjective image and sound

quality</td><tr>

<td>cost oriented</td>        <td>connection and transmission

charges</td><tr>

<caption>Table 2: Categories of QoS Parameters</caption>

</table>

        <p>The real QoS choices available to the user depend on all the system components: the 

operating system, the transport system (transport processes and communications flow) and the 

application (media sources and I/O devices) (Figure 4).

<p><img src="Figure4.JPEG">

<p><em>Figure 4: Communications Model for QoS Negotiation</em>

        <p>The basic QoS constraints on media sources and operating systems relate to their real-

time behaviour . Operating system QoS parameters can be identified at different levels of 

abstraction where the lowest level parameters include performance, scheduling and memory size. 

For the transport processes and communications flow the essential QoS parameters can be defined 

in relationship to a three level view of the communications protocol hierarchy (Figure 5). This is 

the perspective that is most easily related to our interest in monitoring QoS with network and 

transport protocol QoS information.

<p><img src="Figure5.JPEG">

<p><em>Figure 5: Three Level View of Communications Protocol Hierarchy</em>

<p>The lowest level manages QoS parameters to provide bandwidth and acceptable delay. The 

top level protocols support an overall QoS negotiation between the components involved. The 

middle level (network & transport) manages QoS handling over multiple networks. A QoS 

characterisation at the network and transport levels can be based on a flow performance 

specification with metrics computed from the performance oriented category of QoS parameters 

(Table 2). This is the subject of the next Section.

<h4>3.2.2 Performance Parameters & Metrics</h4>

        <p>The Internet was initially designed to provide a connectionless, unreliable service and 

hence there was little interest at first in issues such as performance characteristics and 

guarantees. Recently however, the trends towards commercialisation of the service and provision 

of real-time services have forced a growing interest in defining performance metrics and 

measurement methodologies [7,8,9].

        <p>For successful multimedia communications parameters that specify the flow 

performance are an essential element of the base from which mechanisms to provide real-time 

multimedia flows can be defined and developed. For basic QoS characterisation of a communication 

channel three measures are essential: throughput, delay and loss rates [10]. Several metrics 

associated with channel stability can be derived from these, examples are loss rate variation and 

delay (interarrival) jitter. We will return to this and provide some rigorous definitions in Section 

4.2.

<h3>3.3 TeleConference Traffic Characteristics</h3>

        <p>A general understanding of the traffic characteristics of a video-teleconference can be 

derived by considering a typical session involving multiple participants exchanging multimedia 

information interactively in real-time. Every participant will receive and possibly transmit at 

least audio and video.  Based on factors such as the size of the audience and the style of 

participation (passive reception, occasional transmission, etc.) three types of conference sessions 

(Broadcast, Seminar & Conference) that generate different traffic patterns can be distinguished 

(Figure 6). User expectations and traffic patterns are different in each case and hence it is useful 

to categorise the session type when considering monitoring requirements.

        <p>Broadcast sessions (e.g. shuttle launch, product announcement, TV) attract a potentially 

very large number of viewers. The transmitting station is interested in information about the 

community of receivers and the quality of their connections. Receivers on the other hand are 

primarily interested only in information about their connection to the transmitter.

        <p>In a seminar session, due to the specialised nature of the topic, the participating 

community is unlikely to be more than 100 participants. There will be a subset of receiver stations 

that will be occasional transmitters, for example during the questions & answer time, using at least 

one of audio or the shared work-space. For these stations the quality of the connection to the main 

transmission site is very important. Once a question is being asked (transmitted) the connection to 

all the other receiving participants will be temporarily of interest.

        <p>In a conference type session the number of participant is likely to be relatively small, 

probably never more than 10-12 active members. Every connection is of concern to all others and 

all stations are both transmitters and receivers.

<p><img src="Figure6.GIF">

<p><em>Figure 6: Conference Session Types</em>

<h2>4.0 Monitoring MBone QoS with RTCP</h2>

<h3>4.1 RTCP (RFC 1889)</h3>

        <p>The real-time transport protocol (RTP) defined in RFC 1889 [11] provides end-to-end 

delivery services for data with real-time characteristics, such as interactive audio and video. RTP 

supports data transfer to multiple destinations using multicast distribution and provides basic 

services for media synchronisation and for QoS feedback. Applications typically run RTP on top of 

UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the 

transport protocol functionality. The underlying protocol must provide multiplexing of the data 

and control packets, for example using separate port numbers with UDP.  RTP represents a new 

style of protocol following the principles of application level framing and integrated layer 

processing proposed in [12].  By itself it does not provide any mechanism to ensure timely delivery 

or provide other quality-of-service guarantees.

        <p>RTP consists of two closely-linked parts: the real-time transport protocol (RTP), to carry 

data that has real-time properties; and the RTP control protocol (RTCP), to monitor the quality of 

service and to convey information about the participants in an on-going session. . RTCP is based 

on the periodic transmission of control packets to all participants in the session, using the same 

distribution mechanism as the data packets.

        <p>RTCP performs three mandatory functions:

<ol>

<li>The primary function is to provide feedback on the quality of the data distribution. 

<li>RTCP carries an identifier for an RTP source called the canonical name (CNAME) to keep track 

of each participant and to associate multiple data streams from a given participant in a set of 

related RTP sessions, for example to synchronize audio and video.

<li>The first two functions require that all participants send RTCP packets, therefore the rate must 

be controlled in order for RTP to scale up to a large number of participants. By having each 

participant send its control packets to all the others, each can independently observe the number 

of participants. This number is used to calculate the rate at which the control packets are sent.

</ol>

<h3>4.2  QoS Information in RTCP Packets</h3>

        <p>Each RTCP packet begins with a fixed part (8 octet header) that is followed by structured 

elements of variable length according to the packet type. RTP receivers provide reception quality 

feedback using RTCP report packets which may take one of two forms depending upon whether or 

not the receiver is also a sender. The only difference between the sender report (SR) and receiver 

report (RR), besides the packet type code, is that the sender report includes a 20-byte sender 

information section for use by active senders. The SR is issued if a site has sent any data packets 

during the interval since issuing the last report or the previous one, otherwise the RR is issued.

        <p>Both the SR and RR contain zero or more reception report blocks depending on the 

number of other sources heard by this sender since the last report. Each reception report block 

conveys statistics on the reception of RTP data packets from a single synchronization source. This 

uses the timestamp and sequence numbers carried in the RTP data packet headers. The QoS 

parameters and metrics that are carried in RTP data and RTCP SR & SR packets are shown in Table 

3.

<p><table border>

<th>RTP</t>        <th>RTCP SR</th>        <th>RTCP RR</th><tr>

<td>t<sub>Tx</sub><sup>j</sup></td>        <td>t<sub>Tx</sub><sup>SR</sup></td><td>J<sub>i</sub></td><tr>

<td>Seq#</td>        <td>N<sub>Tx</sub></td>        <td>delta-t<sub>LSR</sub></td><tr>

<td></td><td></td><td>Fr<sup>ij</sup><sub>LOST</sub></td><tr>

<td></td><td></td><td>t<sub>LSR</sub></td><tr>

<caption>Table 3: QoS Measures Carried in RTP Packets</caption>

</table>

A list of the QoS parameters associated with the RTP/RTCP packet flow is given in Table 4.

<p><table border>

<th>packet counts</th><tr>

<td>N<sub>Rx</sub></td>        <td>number of RTP packets received</td><tr>

<td>N<sub>Tx</sub></td> <td>number of RTP packets sent</td><tr>

<th>sequence number (Seq#) counts</th><tr>

<td>S<sub>MAX</sub></td>        <td>highest sequence number received</td><tr>

<td>S<sub>BASE</sub></td>        <td>first sequence number received</td><tr>

<td>S<sub>WRAP</sub></td>        <td>count of sequence number wraparounds</td><tr>

<th>time stamps</th><tr>

<td>t<sub>Tx</sub><sup>SR</sup></td>        <td>NTP timestamp on transmission of an RTCP SR</td><tr>

<td>t<sub>Rx</sub><sup>SR/RR</sup></td>        <td>NTP timestamp on reception of an RTCP SR or 

RR</td><tr>

<td>t<sub>Rx</sub><sup>j</sup></td>        <td>timestamp at reception of RTP packet j</td><tr>

<td>t<sub>Tx</sub><sup>j</sup></td>        <td>timestamp on transmission of RTP packet j</td><tr>

<caption>Table 4: RTP/RTCP QoS Parameters</caption>

</table>

<h5>QoS Metrics</h5>

        <p>Using the time stamps, the sequence numbers, and the count and time-stamp of incoming 

packets a number of QoS metrics can be computed. Packet counts and sequence numbers are used 

for throughput and loss rates; timestamps are used for delay and jitter.

<h5>Loss</h5>

<p>The <em>number of packets lost</em>  - N<sub>LOST</sub>

<p>N<sub>LOST</sub> = N<sub>E</sub> - 

N<sub>Rx</sub> = S<sub>MAX</sub> + 

S<sub>WRAP</sub> - 

S<sub>BASE</sub> + 1 - N<sub>Rx</sub>

where the number of packets expected (NE) can be calculated using the sequence numbers of the incoming RTP packets.

<p><a name="Spot1">

The <em>RTP packet loss fraction over the time interval (i,j)</em>

<a href="#Foot1">Footnote 1</a> -

Fr<sup>ij</sup><sub>LOST</sub>

<p>Fr<sup>ij</sup><sub>LOST</sub> = 

(N<sup>i</sup><sub>LOST</sub> - 

N<sup>j</sup><sub>LOST</sub>) / 

(N<sup>i</sup><sub>E</sub> - 

N<sup>j</sup><sub>E</sub>)

<h5>Delay</h5>

<p>The <em>RTP transmission delay</em> - delta-t<sub>RTP</sub>

<p>delta-t<sub>RTP</sub> = t<sub>Rx</sub> - t<sub>Tx</sub>

<p><em>The RTCP transmission delay</em> - delta-t<sub>RTCP</sub>

<p>delta-t<sub>RTCP</sub> = t<sub>Rx</sub><sup>SR</sup> - t<sub>Tx</sub><sup>SR</sup>

<p>using the RTCP SR NTP timestamp and

with tTxSR measured at the receiver.

<p>and

<p>the <em>round trip delay</em> - delta-T

<p>delta-T = t<sub>Rx</sub><sup>RR</sup> - 

t<sub>LSR</sub> - 

delta-t<sub>LSR.</sub>

<p>with the time of the last sender report 

t<sub>LSR</sub> = 

t<sub>Rx</sub><sup>SR</sup>, 

and the DLSR timestamp  

(delta-tLSR) providing a measure of the processing delay in the receiver.

<p><a name="Spot2">

<p>The <em>Interarrival Jitter</em> <a href="#Foot2">Footnote 2</a> - 

J<sub>i</sub>

<p>J<sub>i</sub> = 

J<sub>i-1</sub> + 

alpha-(|D<sub>i I-1</sub>| - 

J<sub>i-1</sub>)

<p>where

<p>D<sub>ij</sub>  =

delta-t<sup>i</sup><sub>RTP</sub> - 

delta-t<sup>j</sup><sub>RTP</sub>

<h3>4.3 QoS Monitoring with RTCP</h3>

        <p>Using RTCP mechanisms, feedback on the quality of the data distribution is available not 

only to the sender but also for other receivers and third-party monitors (Figure 7). This feedback 

function is performed by the RTCP sender and receiver reports. 

        <p>The sender may modify its transmissions based on the feedback. For example, the direct 

use of feedback for control of adaptive encoding is described in [13, 14]. It is also critical for the 

sender to get feedback from the receivers to diagnose faults in the distribution.

        <p>Network managers and network service provider who are not otherwise involved in the 

session can use profile-independent third-party monitors that receive only the RTCP packets and 

not the corresponding RTP data packets to evaluate the performance of their networks and to 

diagnose network problems.

<p><img src="Figure7.JPEG">

<p><em>Figure 7: RTCP Packet Flow</em>

        <p>A sender report contains cumulative counters for packets and bytes sent which a 

receiver can use to estimate the actual transmitted data rate. The reception report blocks returned 

by the receivers contain information on the highest sequence number received, the number of 

packets lost, a measure of interarrival jitter and timestamps needed to compute an estimate of the 

round-trip delay between a sender and the receiver issuing the report.

        <p>Cumulative counts are used in both the sender information and receiver report blocks so 

that differences may be calculated between any two reports to make measurements over both 

short and long time periods, and to provide resilience against the loss of a report. The difference 

between the last two reports received can be used to estimate the recent quality of the distribution.

        <p>The interarrival jitter field provides a second short-term measure of network congestion. 

Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The 

jitter measure may indicate congestion before it leads to packet loss. Since the interarrival jitter 

field is only a snapshot of the jitter at the time of a report, it may be necessary to analyze a 

number of reports from one receiver over time or from multiple receivers, e.g., within a single 

network.

        <p>From the sender information, a third-party monitor can calculate the average payload 

data rate and the average packet rate over an interval without receiving the data. Taking the ratio 

of the two gives the average payload size. If it can be assumed that packet loss is independent of 

packet size, then the number of packets received by a particular receiver times the average 

payload size (or the corresponding packet size) gives the apparent throughput available to that 

receiver.

</h2>5.0 MERCInari</h2>

<h3>5.1 Introduction</h3>

        <p>An MBone monitoring platform (MERCInari - MERCI network active recording interface) 

is under development at CRC to monitor QoS during multicast events and to provide performance 

statistics for diagnostics.  The ultimate goal for MERCInari is to assist users, network managers and 

protocol developers by combining: RTCP, ICMP and SNMP capture; presentation of performance in 

real-time; and recording of statistics for later replay and analysis.  This report covers the first 

phase of the MERCInari development where only RTP/RTCP and the flow performance parameters 

that can be obtained from that protocol have been considered.

<h3>5.2 MERCInari Design</h3>

The components in the design of our monitoring system are shown in Figure 8.

<p><img src="Figure8.GIF">

<p><em>Figure 8: MERCInari Platform Design</em>

<p>These components are:

<ul>

<li>physical network access with a Network Interface Tap to enable reception of network traffic.

<li>a packet trap & filter  to monitor the local network and retrieve packets destined to/from a 

specific network address or addresses.

<li>an extractor/forwarder to retrieve appropriate data (performance statistics) from the packets 

and deliver to various application modules as appropriate

<li>application modules consisting of:

<ul>

<li>a record/playback process that records selected data from the network to disk  for playback to 

analysis programs (to use for example to refine protocol design).

<li>a real-time pipe:  a path for real-time flow of statistics to the analyzer/display

 (this could also be a route for information to be passed to automated network control processes).

<li>an analyzer & GUI display to provide graphical presentations of performance in real-time, that 

are understandable to an operator, and after storage and analysis to support development.

<li>a forwarding process specifically to provide a direct feed to the conference tools (video/audio) 

(where the statistics can be used to adjust encoding, fps, etc. to dynamically optimize the use of the 

available network service.)

</ul>

<li>an active query process to generate ICMP and/or IGMP queries. Triggered initially by a user; 

the eventual goal is to let the active monitoring system generate queries that may allow it to 

interpret networking performance enhancements/degradation.

</ul>

<p>The monitoring process will ideally introduce as little interference as possible into the tasks 

being monitored, hence the monitoring program is run on a WorkStation that is not actively 

involved in the MBone session. The monitoring platform will be normally based close to an 

actively participating MBone WorkStation to simplify the gathering of information directly 

to/from a contributing session user, but physical co-location is not a requirement.

<h3>5.3 MERCInari v 1.0</h3>

        <p>MERCInari v1.0 has been developed on a UNIX platform. The programs have been written 

in tcl/tk. The Packet Trap is based on the public domain tool TCPDump [16]. The program for 

graphically displaying the statistics is XPlot [17]. Version 1.0 is a preliminary implementation that 

can be used only in the record/playback mode to extract and display  RTCP QoS information. This 

experience has been important to us as a proof of concept and it has been used with our partners 

at UCL to investigate the RTCP implementation in the Robust Audio Tool (RAT). 

<p>When MERCInari is started the main control panel (Figure 9) is launched to display a list of the 

participants that are active in the session that is being monitored.

<p><img src="Figure9.GIF">

<p><em>Figure 9: The Main Control Panel of MERCInari v1.0</em>

        <p>The SSRC button will spawn a control panel (Figure 10) that identifies the participant 

with the information from the source description (SDES) type RTCP packet. This panel can be used 

to access detailed information about all the SRs and RRs that have been sent by the user.

<p><img src="Figure_10.GIF">

<p><em>Figure 10: Participant Identification and Packet Viewer</em>

        <p><The "initiate plot" button in the main Panel will generate graphs from the QoS 

information that has been collected. These are useful in characterising the QoS performance as 

well as for analysis of the behaviour of the RTP implementation. Figure 11 is an example, showing 

the time evolution of the packet-count from the SRs (top curve) and packet-loss from the RRs 

(bottom curve) that were exchanged for a video channel between a sender in France and a 

receiver in Canada. It was unexpected behaviour detected in graphs such as this that led us to our 

critique of the UCL RAT/RTCP implementation.

        <p><MERCInari v1.0 has been made available for public release and can be found in the 

MERCI software repository at

<a href=�http://www.merci.cs.ucl.ac.uk�>http://www.merci.cs.ucl.ac.uk.</a>

<p><img src="Figure_11.GIF">

<p><em>Figure 11: Packet Count vs. NTP time</em>

<h2>6.0 Concluding Comments</h2>

        <p>Several categories of conference session types have been distinguished and their traffic 

characteristics described. This provides a useful basis for understanding the variability in 

requirements for QoS monitoring. At the same time we have completed a study of RTCP placing the 

RTCP QoS features within a broader QoS framework. Ideas drawn from these initiatives underlay 

the design of our QoS monitor (MERCInari).

        <p>We are now proceeding with the development of a new version of the tool. The next 

release will be based on a new software design using the client-server capabilities of the 

distributed processing tcl (tcl-dp) [18]. The main new feature will be the ability to display 

information in real-time so that the variation in the QoS can be monitored over the duration of a 

session. MERCInari v2.0 is scheduled for release in late August.

        <p>Our experience so far encourages us to continue pursuing this approach for MBone QoS 

management. We are planning the addition of network protocol functionality (ICMP, IGMP). We 

also plan to continue developing a theoretical understanding that locates these ideas within the 

broader context provided by emerging QoS architectures.

<h2>Acknowledgments</h2>

        <p>We acknowledge the support of Teleglobe Canada, the CANARIE TNOC and Deutsche 

Telekom/DeTeBerkom, Berlin in providing the trans-Atlantic ATM connection. We also 

acknowledge the support of CRAD/DND Canada in providing us with the DRENet connection to the 

global MBone.

        <p>Our partners in the MERCI Project have been supportive in various ways and we 

acknowledge there encouragement and support. We wish to particularly thank Peter Kirstein, 

Panos Gavros and Colin Perkins at University College London for their help.

<h2>References</h2>

<p>[1] Multimedia integrated conferencing for European researchers (MICE): piloting activities 

and the conference management and multiplexing centre, M.J.Handley, P.T.Kirstein, M.A.Sasse, 

Computer Networks and ISDN Systems 26 (1993)

<p>[2] Transport Flow Control and Connection Admission Policies for Reliable Applications over 

ATM WAN, L.Lamont, I. Miloucheva, W.Stering, CRC Report No. CRC-RP-96-007, April 1996

[3] CANARIE MultiCast Test Project, http://www.wnet.ca/multicast/.

<p>[4] Multicast Debugging Handbook, draft-ietf-MBoned-mdh-00.txt, 23 March 1997, D.Thaler, 

B.Aboba

<p>[5] A Survey of Quality of Service Architectures, C. Aurrecoechea, A. Campbell, L. Hauw, Center 

for Telecommunication Research, Columbia University

<p>[6] Distributed Multimedia and QoS: A Survey, A.Vogel, B.Kerherve, G.von Bochnann, J.Gescei, 

IEEE MultiMedia, Summer 1995

<p>[7] Towards a Framework for Defining Internet Performance Metrics, INET'96, V.Paxson

<p>[8] Terminology for IP Multicast Benchmarking, draft-ietf-bmwg-mcast-00.txt, Nov.'96, 

K.Dubray

<p>[9] Framework for IP Provider Metrics,  draft-ietf-bmwg-ippm-framework-00.txt, Nov.'96, 

G.Almes, W.Cerveny, P.Krishnaswamy, J.Mahdavi, M.Mathis, V.Paxson

<p>[10] TIP's Performance Quality of Service, S.Bocking, IEEE Communications Magazine, August 

1995

<p>[11] RTP: A Transport Protocol for Real-Time Applications, RFC 1889-January 1996,

IETF AVT WG: H.Schulzrinne, S.Casner, R.Frederick, V.Jacobson

<p>[12] D. D. Clark and D. L. Tennenhouse, "Architectural considerations for a new generation of 

protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , 

(Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, 

Vol. 20(4), Sept. 1990.

<p>[13] J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback control for multicast video 

distribution in the internet," in SIGCOMM Symposium on Communications Architectures and 

Protocols , (London, England), pp. 58--67, ACM, Aug. 1994.

<p>[14] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of multimedia applications 

based on RTP," Computer Communications , Jan. 1996.

<p>[15] J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: 

Macmillan, 1987.

<p>[16] TCPDump, ftp://ftp.ee.lbl.gov/libpcap.tar.Z & ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

<p>[17] Xplot, ftp://mercury.lcs.mit.edu/pub/shep/xplot.tar.gz

<p>[18] tcl-dp, http://www.cs.cornell.edu/Info/Projects/zeno/Projects/Tcl-DP.html

<p><a name="Foot1">

<em>Footnote 1</em> In addition to the cumulative counts which allow long-term packet loss measurements using 

differences between reports, the fraction lost field provides a short-term measurement from a 

single report. This becomes more important as the size of a session scales up enough that reception 

state information might not be kept for all receivers or the interval between reports becomes long 

enough that only one report might have been received from a particular receiver.

<p>Loss rate per second can be calculated from differences over the interval between two reports 

using the NTP timestamp. Since that timestamp is independent of the clock rate for the data 

encoding, it is possible to implement encoding- and profile-independent quality monitors.

<a href="#Spot1">Back to main text.</a>

<p><a name="Foot2">

<em>Footnote 2</em> The interarrival jitter field provides a second short-term measure of network 

congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient 

congestion. The jitter measure may indicate congestion before it leads to packet loss. Since the 

interarrival jitter field is only a snapshot of the jitter at the time of a report, it may be necessary 

to analyze a number of reports from one receiver over time or from multiple receivers, e.g., 

within a single network.

This algorithm is the optimal first- order estimator and the gain parameter value delta=1/16 is 

recommended to 

give a good noise reduction ratio while maintaining a reasonable rate of convergence [15].

<a href="#Spot2">Back to main text.</a>

</body>

</html>