Project Title: MERCI

Title of Deliverable: Seminar Deliverable IV

Deliverable ID: D11.4

Produced by Workpackage: WP 11

Contractual Date of Delivery: 30. November 1997

Author(s): Andreas Rozek, University of Stuttgart
et al.

1. 1. Introduction *

   1.1 The Multimedia Recording *

   2. The MERCI High-Quality MBone Setup *

   2.1 Multicast Setup with Route Filtering *

   2.2 Current Topology *

   2.3 Monitoring Tools and Concepts *

   3. Electronic Project Meetings *

   4. MERCI Seminars *

   4.1 CRAY T3E Programming Course *

   4.2 Weighted Proportional Fairness and Differential End-to-End Services *

   4.3 Certification Services - TrustFactory *

   5. Summary *

   6. Acknowledgements *

   7. References *

Introduction

Main idea of the Seminar Workpackage is to test the MERCI tools under practical conditions, especially those of a distant learning/teaching scenario. This test covers everything from hard- and software installation and usage over network set-up and operation to the preparation of a seminar and the lecture itself.

The intention of this deliverable is to describe the activities during the past six months (including any problems that occurred and how MERCI solved them) and to demonstrate the current state of software-based audio/video-conferencing over the MBone within the project.

1. The Multimedia Recording

In order to give a realistic demonstration of seminars and regular electronic project meetings, this little paper is accompanied by a disk-based seminar recording taken with the Multimedia Conference Recorder (MMCR) at UCL. Please note that this recording is not a videotape but consists of the packets that were transmitted during the session and you’ll need the same set of MBone tools (together with the MMCR) to watch the playback.

Please contact the MERCI Project Manager to get access to the recording.

3. The MERCI High-Quality MBone Setup

The reporting period of this deliverable is characterised by a stabilised and well-understood high-quality MBone setup between MERCI partners. As this setup seems to have converged to an operational state now, the following chapter will describe the actual configuration and explain how the project was able to obtain a high transmission quality.

1. Multicast Setup with Route Filtering

In the beginning, the MERCI project had plenty of problems due to overloaded networks and crowded MBone routers. This excessive load was caused by numerous other multicast sessions that were simultaneously held by people outside the project and which also competed for the scarce resources within the network. The only way to get rid of these concurrent sessions was to set up an isolated MBone and to configure all relevant routers in a way that prevented foreign traffic from leaking into the MERCI environment.

Initially, all participating routers actually had to be isolated from the normal MBone in order to achieve the abovementioned segregation. However, this approach wasn’t technically feasible for every site as it required both separate routing equipment as well as dedicated network connections (i.e. ATM PVCs). Sometimes, it was even necessary to detach a whole subnet from the normal MBone not to provide even the slightest hole for foreign traffic – a rather unpopular step as this also affected people outside the project. And still any carelessness would cause the transmission quality to go down while making it difficult to locate the source of the error.

Meanwhile, every partner is using a workstation-based MBone router running software release 3.9 which allows for route filtering. It is therefore now possible to instruct every router to propagate routes from well-known sites only – as a consequence, sites outside the project cannot receive any MERCI traffic.

While there is no more need to separate the MERCI setup from the normal multicast infrastructure it is now necessary to deal with the insufficiencies of the normal MBone. Above all, routing loops caused by "wild" tunnels or improperly chosen metric and threshold values in multicast router configurations could significantly affect the overall transmission quality. It turned out that these problems particularly occurred within the German MBone (which is not yet centrally administrated) and had to be solved during a special "configuration session" with participants from several universities in Baden-Württemberg.

In the meantime, the whole configuration is well understood and provides sufficient transmission and routing capacity for MERCI sessions with high-quality audio and video streams (it is now more important to upgrade the participating workstations rather than to improve the network) However, it still requires a lot of discipline in view of the possible configuration errors: the network addresses of all foreseen session participants have to be known well in advance in order to configure the MERCI routers for a conference. Incorrect addresses may prevent sites from joining a session, they may lead to situations where certain partners are visible to some other participants (but not all) or where it is only possible to receive data but not to send it (or vice-versa). Further, it may happen, that traffic from/to certain sites follow an unforeseen path (with lower transmission quality) if there are multiple "entry points" into the high-quality setup. All these problems are not necessarily easy to detect and to solve, and it took some time to gain the experience required to maintain such a configuration...

2. Current Topology

The following figure illustrates the actual configuration of the MERCI High-Quality MBone. It shows all multicast routers together with the tunnels in between but does not mention any of the permitted subnets "behind" these routers.

The link between UCL and ULB (Université Libre de Bruxelles) has been prepared for the technical review in October only and was used for a live demonstration of the enhanced MERCI tools. INRIA is connected to UCL using a satellite link with a capacity of up to 4 Mbps (INRIA has equipment to send DSB traffic which may then be received at UCL, traffic in the opposite direction still uses the "normal" international MBone). Traffic between GMD and RUS is transmitted over the ATM-based German research network – sometimes using a direct tunnel, sometimes using the normal German MBone. Until end of November, CRC is coming across the CANTAT-3 link between Ottawa and Sylt (Germany) and connecting to a multicast router at Berkom in Berlin, where the traffic is injected into the German MBone and enters the MERCI setup at RUS. Although the transmission quality turned out to be good enough most of the time, the ATM PVC between CRC and Berkom has been extended for RUS directly during "special events" (such as the Technical Audit in Brussels), in order to avoid potential packet loss within the German MBone. Following the MERCI project, the Canadian partners will have to use the normal MBone again unless another solution can be found.



Figure 2.1: Actual Topology of the MERCI High-Quality MBone

Resource reservation (e.g., by means of RSVP) has not yet been taken into account as there are too few routers and applications that support this technique.

3. Monitoring Tools and Concepts

The Communication Research Center in Ottawa, Canada, has developed MultiMON, a real-time monitor that collects, analyses and displays the IP multicast traffic within the subnet of a MultiMON Server. The tool is designed as a client/server application which allows the data collectors (Servers) to be distant from their GUI front ends (Clients).

MultiMON is especially useful, when a close look at the traffic between several sites is needed and may help finding the source of packet losses or any routing problems. Figure 2.2 shows snapshots from a MERCI session preparation for the Technical Review in Brussels (hence the presence of the EuroDemo site)



Figure 2.2: An Audio/Video session to be observed by MultiMON

The tool allows to observe several multimedia streams simultaneously and handles both RTP and RTCP streams. The left half of figure 2.3 shows the basic server window which informs about which server is used to collect traffic data (and, thus, which subnet is to be monitored) and the observed RTP/RTCP streams. The RTCP part of a multimedia channel is then used to collect information about RTP media types, participating users and sender/receiver statistics (right half of figure 2.3).

Figure 2.3: MultiMON Server Window (left) and Participants List (right)

Apart from information about an individual stream it is often also important to observe a session as a whole. The left half of figure 2.4 gives an overview of the bandwidth consumed by all streams of a session at a given time (which allows to easily check whether a given link is capable of carrying the whole traffic) while the detail view in the right half informs about throughput fluctuations in a particular stream.



Figure 2.4: Bandwidth Overview (left) and Stream Details (right)

Last not least, MultiMON allows to observe the traffic between two participants. Figure 2.5 plots the packet rate of a given stream (which turned out to be rather constant) (left window) and the total packet count for another one (right window). The latter graph also shows a significant amount of duplicate packets which might be an indication for a routing loop in the multicast setup.



Figure 2.5: Observation of the Packet Flow between two given Sites

In short, MultiMON is a good monitoring and visualisation tool that presents a variety of vital information which may be used to check the quality of a multimedia transmission.

4. Electronic Project Meetings

Throughout the whole duration of MERCI the project had regular electronic meetings (once in two weeks) in order to co-ordinate the partner’s efforts and to test both network and tools. This chapter shall inform about the current status of MERCI conferencing tools and introduce MPoll which doesn’t seem to have been mentioned before.

Figure 3.1 shows the snapshots of two VIC windows taken during a "typical" project meeting. Even from the print it becomes obvious that – given a proper environmental lighting at the sender’s site - the imaging quality has improved as it is now possible to send at higher bandwidths and decrease the compression ratio.



Figure 3.1: Video from UCL (left) and GMD (right) as received at RUS

It might be worth mentioning that the Silicon Graphics workstation used to produce these pictures was equipped with 8bit graphics only - if you compare them with figure (blabla) you will recognise a significant difference in the image quality. The reason is that the latter was taken from a workstation with 24bit graphics which usually gives a much better video quality.

The audio quality of RAT (the Robust Audio Tool developed at UCL) has also increased a lot (although this cannot be proved during a high-quality MERCI session): when used over lossy networks, the voice of a remote partner remains understandable even at high loss rates.

MERCI meetings would have been nothing without NTE, the shared Network Text Editor developed at UCL. Figure 3.2 shows a snapshot taken during a „typical" MERCI session: initially loaded with the agenda of the current meeting, the editor was used to fill in the blank regions during the conference in order to produce the meeting minutes „on the fly".



Figure 3.2: a „typical" NTE session

In order to get some feedback from the user during a multimedia conference, the MPoll tool has been developed at CRC. Similar to a multiple choice test, that program allows to define questions together with a number of different answers for every question and to distribute them among the participants of a session. Every partner may then choose one of the given replies and inform the others about his/her vote – the actual voting results are always visible to everybody. Figure 3.3 shows a (not so) typical situation: the main window gives an overview of all currently active questions - in a MERCI project meeting one of them usually deals with the approval of recent minutes. The second question was created by a Canadian partner who had to get up early in the morning in order to join the meeting and turned out to look (and sound) rather sleepy. This occasion was used to demonstrate the MPoll tool and show how to modify an already published question (in this case: how to extend the set of given answers).





Figure 3.3: The CRC MPoll tool on a PC running Windows 95

5. MERCI Seminars

The following chapter is dedicated to the various seminars which have been held during the reporting period. It briefly describes the session itself and its distribution (e.g., over the normal MBone or the project-internal high-quality setup), shows a few snapshots taken at different sites (in order to document the reception quality as well as the "look" of MBone tools on different platforms) and mentions the problems which have been encountered (if any).

1. CRAY T3E Programming Course

In the beginning of June 1997, one day out of a 3-day course on "Programming the Cray T3E Supercomputer" was sent across the normal MBone from a seminar room at RUS. It has been an experiment insofar as multiple speakers were involved and the resulting session lasted several hours. The session was publicly announced in SDR, but turned out to be too specific to attract a large audience. Instead, many people just tuned in for some minutes and then left the conference. Figure 4.1 shows a snapshot of RAT taken from a SPARCstation with MOTIF at UCL.



Figure 4.1 RAT Snapshot taken at UCL

Perhaps the most challenging problem was to convert the various data formats of slides prepared by various speakers into a format (and size) suitable for the whiteboard – especially, as most of the originals came to the last minute. Figure 4.2 shows a snapshot of WB with a "typical" slide which has been prepared using Microsoft PowerPoint and then converted to PostScript. Experience has shown that many speakers made use of "fancy" effects offered by the presentation or drawing tool of their choice (such as Microsoft PowerPoint or SGI ShowCase) and included (large) raster images or colour wedges in their slides which then turned out to produce rather huge PostScript files. And all of them refused to do without these effects, whether because of a certain "corporate identity" which had to be respected or because of a lack of time. Many people did not take care of the font sizes and filled their foils with too much text in too small letters. And very few speakers could be convinced to use a video beamer instead of an overhead projector (which lead to the situation that the actual sequence of slides was different from the one that had been announced before) One speaker even jumped(!) back and forth between two overhead projectors and came up with additional (unannounced) slides which then had to be transmitted as a video image.



Figure 4.2 WB with a "typical" PowerPoint slide, as received at UCL



Figure 4.3 WB with a typical PostScript slide, as received at UCL

While the problems mentioned here were more of psychological rather than technical nature, the whole seminar showed how to set up seminars with multiple people from numerous companies using different tools to prepare their talk – and not willing to take care of any constraints imposed by multicast conferencing tools. The experiences gained during this session influenced the whiteboard development at RUS and another trial scheduled for the beginning of 1998 will show whether that application will be able to cope with the problems mentioned above.

2. Weighted Proportional Fairness and Differential End-to-End Services

On November, 26^th, Jon Crowcroft, Professor of Networked Systems in the Computer Science Department at UCL, gave this seminar as part of a series of Berkeley Multimedia and Graphics Seminars. The session was sent to MERCI partners as well as to University of California, Berkeley. There, at UCB, the session was recorded using the MMCR tool for being shown in a local lecture room and transmitted over the normal MBone at a more convenient time.

It is worth mentioning that packets were recorded rather than a video of the whole session. As a consequence, a high transmission quality was required since the final auditory had to live with the total packet loss of both the initial session and the later playback. For that reason, between UCL and UCB, the UCL connection to the CAIRN network (an ATM PVC with 500 kbps) was used for the seminar while the MERCI partners used their standard High-Quality setup. The following figure shall illustrate the traffic flow during both sessions.



Figure 4.4: Traffic Flow during Live and Playback Sessions

The recording session was „announced" shortly before its actual start in order to allow for an easy set-up of MBone tools (the same parameters were used for the recording and the playback session)



Figure 4.5: Seminar Announcement in SDR

The seminar itself was transmitted with excellent quality. Figure 4.6 shows two screen shots taken from a SPARCstation with 24bit graphics illustrating the video quality at GMD in Darmstadt.



Figure 4.6: VIC snapshots: Jon Crowcroft, UCL (left) and L.A.Rowe, UCB (right)

During the session itself, almost no packets were lost (as shown in the figure below) The relatively high total number of missing video packets was caused by problems during the preparation phase of the seminar.



Figure 4.7: Statistics calculated by VIC (left and middle) and RAT (right)

3. Certification Services - TrustFactory

On November, 28^th, Petra Glöckner from GMD, Darmstadt (Germany) gave a seminar on „Digital Id Services" which have been developed in the context of ICE-TEL, a TELEMATICS project that had to set up a distributed european security infrastructure.



Figure 4.8: WB with title slide as received at RUS

The seminar was publicly announced within SDR in order to allow interested people from outside the project to participate. The session was therefore transmitted over the normal MBone and then injected into the MERCI high-quality setup which also gave a possibility to check the capacity of the German production networks. It turned out that the seminar could be received without major problems.



Figure 4.9: VIC (left) and RAT (right) windows as seen at RUS



Figure 4.10: WB slide with arrows pointing at interesting parts (as seen at RUS)

Figure 4.9 and 4.10 show typical snapshots of all the tools involved to document the session (rather than to show anything special).

6. Summary

1. Acknowledgements

UCL, London: Dr. Colin Perkins (screen snapshots)

UCL, London: Roy Bennett (screen snapshots and proof-reading)

GMD, Darmstadt: Dr. Elfriede Hinsch (screen snapshots)

CRC, Ottawa: John Robinson and John Stewart (MultiMON)

2. References

[4] The RAT (Robust-Audio Tool) Home Page