Notes for Multicast Interlocutors
The modified agenda and other public announcements were integrated with
documents on the main Conference server.
A separate set of document for the direct participants,
accessed through a
single introductory document,
were put up at NLM and privately announced.
Notes for the chairs of multicast sessions were also emailed
to the chairs in ASCII format.
An ASCII announcement was posted to WWW-related groups in
Usenet news.
A similar announcement was mailed to participants in past SIGNIDR meetings
as well as NLM and NIH personnel.
Considerable thought was given to the sociological aspects of integrating
remote MBONE participants into the sessions,
thus the invention of an intermediary, the interlocutor,
acting on behalf of remote participants.
Recording of Multicasted Sessions
A subset of sessions that were multicasted were recorded on video tape.
As of this writing, the tapes are being transcribed and edited.
Plans are underway to rebroadcast these sessions over MBONE,
once at a time suitable for the western hemisphere,
and again at a time suitable for the eastern hemisphere.
Summary of Technical Problems
The single biggest problem associated with the multicast was the
poor Internet connection.
The Internet access provider completely failed to provide the promised
MBONE tunnel, and failed to answer repeated email and telephone messages
on the Sunday prior to the meeting.
The lack of response from the provider also prevented adequate advance
practice and testing.
The tunnel provided by the NLM was used as a fallback.
Access to the Internet was such that a greatly increased number of routers
was required to reach outside points on the network.
Jules Aronson determined that
18-27 hops
were required to
get from the Conference site to the NLM
(under optimal circumstances, this number would be less than 16).
This resulted in deteriorated reception of MBONE audio and video.
It also led some attendees to erroneously conclude that poor network
performance at the conference was due to the multicasting activities.
Video was transmitted at 85-128 kbps, which should account for 6-8 percent
of the bandwidth of a single T1 line;
audio consumed considerably less that this figure.
NLM personnel were under the impression that the two T1 lines for the
Conference were to be in simultaneous use;
it was discovered retroactively that this was not the case.
Because of inadequate time to contact participants in advance,
presenters were not prepared with visual materials optimized for capture by
video camera.
In particular, there were complaints from remote viewers about the
use of white letters on a blue background (the white letters developed halos),
and the use of pastel lettering and gray backgrounds.
The technical setup was unstable.
Numerous poorly coordinated groups were working at cross-purposes,
and it was often difficult to ascertain who was responsible for specific
activities.
For example, on multiple occasions,
multicasting equipment was decabled, by persons unknown,
while left unattended.
On another occasion, the Internet connection of the multicasting
machine was lost due to improper decabling of equipment from a router
in the commercial display area.
Lack of a way of contacting key outside personnel
(such as Jules Aronson and Steve Casner) was frustrating;
email was too slow for many instances,
and the UNIX talk program could
only be relied upon if the person in question was in front of the
workstation connected to.
Use of a telephone would have been difficult without disruption to the
sessions.
Ambient noise in the vicinity of the multicasting
workstation was often a problem,
especially when trying to get technical and reception information
from remote sites just prior to the start of a session.
An operator headset with earphones and microphone would have been very useful.
Each unit should have had a flashlight as well.
The machine was placed on a traditional AV cart, which was uncomfortable to
use: there was no surface on which to type, and one had to crane one's
neck to see the monitor.
The MBONE video was transmitted using nv version 3.3 beta.
An unanticipated problem arose: video could not be received by remote
sites still using nv version 3.2.
Several remote sites attempted to alert other users to this problem
by advertising the fact that 3.3 should be used,
along with the IP address of the host where nv version 3.3 beta
could be obtained.
There are so many details to be seen to in simply keeping vat and
nv running normally,
that the job of interlocutor should be separate from that of multicasting
host operator.
A third person watching over both was also helpful.
Some attendees expressed fears that the multicasting activities were
responsible for various networking problems they had experienced
during the course of the conference.
The multicasting units should have log books
(we used Rodgers' printed schedule for this).
The automated start-up scripts worked well and were very useful.
On several occasions,
the operator forgot to dump the session attendee logs,
carrying over the attendee list into the subsequent session.
Summary of Daily Activities
Sunday 16 October (Setup Day)
The conference network was not sufficiently operational to allow testing.
There was a communication failure between the network provider and NCSA's
network personnel in establishing the need to provide a MBONE tunnel.
A SunVideo card was installed in the second SPARCstation 20.
Set-up activities halted at about 2 AM.
Monday, October 17 (Tutorial Day)
We set up for multicasting in the Great Hall.
We installed one of the SPARCstation 20s in the Conference office
(the Music Room) as a tunnel machine, and the other in the Great Hall.
There was considerable difficulty getting a usable audio feed into the
SPARCstation from the room's audio system.
After about three hours of frenetic effort, we established an excellent feed.
The Internet access provider was still not responding;
we decided to connect to the MBONE by tunneling to the NLM.
Video setup went very smoothly.
Inspection of the Grant Park Room made it clear that the planned multicast
of the Astronomy session could not proceed:
the room was broad and shallow, with multiple columns.
The only place the video camera could be located was in the doorway.
We changed the schedule, multicasting the Publishing session in the
Gold Room instead.
We modified the HTML schedules on the conference Web server.
Union personnel left before we had time to do advance set-up in the
Gold Room.
The sd announcement for the meeting was no longer present;
Rodgers left mail for Jules Aronson at the NLM,
who restored it the next day
(host billings had rebooted,
and sd was thus no longer running).
Finally, when the IP addresses of the various subnets were known,
the multicasting scripts had to be modified,
and the multicasting accounts on both machines had to be modified.
Set-up activities halted at about 3 AM.
Tuesday, October 18 (Conference Day 1)
We arrived at 7:30 AM to prepare for the multicast.
The 10BaseT connection to the multicasting host was now gone,
and the audio feed from the hall no longer worked.
Frantic efforts restored both of these,
and multicasting was in action 30 seconds before the plenary began.
This did not allow sufficient testing to determine who was receiving
the session.
It was not until after the conclusion of the morning sessions
that we realized that although the program was being well received at the NLM,
it did not appear to be going elsewhere.
Jules Aronson at the NLM worked with SURAnet by telephone,
and by the end of the day had determined that the MBONE routing tables
in use at SURAnet were missing many routes.
This was rectified overnight.
Plenary Session
8:30 - 10:00 CDT (13:30 - 15:00 UTC)
Great Hall (Hardin, Peters, Berners-Lee)
Lack of a light on the speaker led to dull video.
Session 1: Publishing
10:15 - 11:45 CDT (15:15 - 16:45 UTC)
Gold Room (Stuart Weibel)
The original plan called for union personnel to work on the audio feed
to the machine early in the morning, but no one showed up until 9:00 am. Since
the first machine was already in use,
the second SPARCstation was wheeled down from the Music Room
into the Gold Room and set up minutes before the session began.
Multicasting began 10 minutes late.
Simms and Ng decided to use the Sun microphone for audio capture,
and that worked reasonably well.
The video feed worked well.
Session 2: Authoring Tools
2:15 - 3:45 CDT (19:15 - 20:45 UTC)
Gold Room (Yuri Rubinsky)
Session 3: Commercial Transactions on the WWW (Panel)
4:00 - 5:30 CDT (21:00 - 22:30 UTC)
Great Hall (Allan Schiffman)
Wednesday, 19 October (Conference Day 2)
Plenary Session
8:30 - 10:00 CDT (13:30 - 15:00 UTC)
Great Hall (Hardin, Goldstein, Chaum)
The SURAnet routing table having been solved, and the Great Hall
SPARCstation being left alone over night, there was time for adequate
pre-session solicitation of reception.
Reports of excellent audio and video reception came in from Boston,
NLM, California, other U.S. sites, Australia, and Scotland,
The microphone on the multicasting workstation in the Gold Room
was stolen overnight.
Session 1: Computer Supported Cooperative Work
10:15 - 11:45 CDT
(15:15 - 16:45 UTC) Plaza Room (Weymouth)
Multicasting reached its zenith at this session.
A question from Michael Mealling at Georgia Institute of Technology
was the first MBONE question to be received,
and it was smoothly intercalated into the question period.
The chairperson was very adept at working with the MBONE crew.
Herve Recipon at the NLM (130.14.25.160) briefly broke into the multicast with
a second video stream (this was an accident on his part).
Session 2: K-12 Education
2:15 - 3:45 CDT (19:15 - 20:45 UTC)
Plaza Room (Flannagan)
Session 3: WWW Security: The Big Picture (Panel)
4:00 - 5:30 CDT (21:00 - 22:30 UTC)
Great Hall (Allan Schiffman)
Thursday, 20 October (Developers Day)
Session 1: HTML and SGML
8:30 - 10:00 CDT (13:30 - 15:00 UTC)
Gold Room (Berners-Lee)
Session 2: CERN-MIT-NCSA
10:15 - 11:45 CDT (15:15 - 16:45 UTC)
Gold Room (Berners-Lee, Hardin, Cailliau)
During this sessions, things began to unravel badly.
The sd announcement for the conference was no longer visible,
although sd was running on host billings at the NLM.
This turned out to be an error on the part of Jules Aronson,
who set too short an expiration date when he last modified the announcement.
We began to advertise the conference from the multicasting machine.
According to complaining messages from the field,
we may have made mistakes in the announced multicasting address.
The multicasting host's network connection was lost suddenly
when workers decabling from a router in the commercial demonstration
area left a segment of cable unterminated.
Fortunately, we were able to quickly locate Steve Mitchell,
who fixed this problem.
Finally, sd showed an announcement for a multicast,
from the White House,
of Vice President Gore's announcement of the opening of the
White House WWW server.
Numerous conference personnel wanted to be able to project this multicast
on screen in the Gold Room.
Rodgers advised against trying to do this on such short notice,
but the video projector and audio support personnel sprung into
action on 15 minutes notice.
They were not able to get the SPARCstation 20 video output synchronized with
the three-gun video projector on hand.
One of the contractor's video connector boxes blew out.
Tony Baylis quickly moved his video camera forward and pointed it at the
workstation screen, and this was successfully connected to the projector.
The resulting image was very poor.
Attempts to connect to the White House and NLM servers repeatedly failed,
with access messages from Mosaic.
NASA Langley began transmitting video of an image of the White House home page
on the conference video channel, and this was shown on screen.
Due to all of the confusion, we were not attending to the audio transmission
and several times the outgoing conference audio
was muted for prolonged periods.
Meanwhile, in the Great Hall,
Simms and Ng worked furiously to set up the other multicasting machine
to receive the White House session.
After 20 minutes,
it became clear that the chaotic network and cabling situation
made it impossible to proceed without interrupting the ongoing session.
The
multicast from the White House
itself was delayed,
and eventually cancelled.
Session 3: Web Programming Interfaces
1:00 - 2:30 CDT (18:00 - 19:30 UTC)
Gold Room (Thompson)
We chatted briefly with several speakers to warn them that their projected
workstation displays,
using pastel colors on gray background,
would not carry well over the MBONE.
These displays were not clearly visible even in the meeting hall.
Although they stated that it really did not matter if people could read
the displays,
they did modify the colors, resulting in greatly improved visibility.
Session 4: Ask the Mosaic Developers
2:45 - 4:15 CDT (19:45 - 21:15 UTC)
Gold Room (McLaren)
This session had problems with audio quality.
The chair's portable microphone worked well,
but the two hand-held microphones did not appear to be feeding
into the signal received by the multicasting workstation,
despite the repeated insistence by the audio personnel that they were.
We eventually gave up and simply took the audio feed from the Sun microphone
attached to the workstation.
Even here, there were differences in the behavior of the vat VU meter
between the portable and hand-held microphones,
with the latter giving lower readings even though they sounded similar in
volume in the hall
(the hand-helds sounded as if they had more pronounced bass;
there was a boomy quality to the sound).
Here, we had excellent help from remote participant Simon Cooper
at Rutgers (scooper@rutgers.edu).
The chair made a good effort at soliciting remote questions,
and one was successfully received from the BBN site in Boston.
End of Conference
In breaking down the equipment at the end of the conference,
Rodgers forgot to reinstall the small back-panel cover for the
S-bus slot in which the SunVideo card had been located
(on the host in which the card was installed by myself on Sunday);
the panel was returned later to Jason Ng.
The Great Hall machine was powered down accidentally,
prior to Rodgers being able to copy log files
(Simms had already copied them to an account at NCSA,
however, so they were not lost).
Participant Survey
Log files obtained from the MBONE program vat
suggested that 302 distinct hosts had connected to the conference multicast.
Given the number of viewers at each site,
roughly 400 persons must have viewed the multicasting activity at some time
during the conference.
In over 50 instances,
the vat log file did not contain a valid email address;
a Bourne shell script was written to help construct an email address from
the information provided.
Three days after the meeting,
a survey was sent by electronic mail to 302 addresses.
Approximately 50 of the messages were returned unreceived for a variety of
reasons (including: hosts down, address incorrect,
technical problems with mail at receiving site).
Forty-one responses were received.
Refer to the
summary of responses
in Appendix 2.
Recommendations
- Continue to multicast the International WWW Conferences.
Despite considerable technical difficulties associated with the Chicago
session, there is overwhelming support for continued multicasting,
and clear benefits in terms of advancing the aims of the IW3C2.
- Consider multicasting two simultaneous sessions.
With the use of very low bandwidth video, audio,
and a low bandwidth multicasting Web browser,
more than two simultaneous sessions might be possible.
- Plan for multicasting from the outset of preparations for the meeting.
Pay particular attention to the following:
- Program selection.
Given that only one or two sessions can be multicasted concurrently,
carefully select the sessions that are to be multicasted.
These will generally be the sessions expected to be the most popular.
Be certain that chairpersons and presenters are aware well in advance
that their session will be multicasted,
and provide them with appropriate instructions about preparation
of their visual materials,
and about appropriate behavior during the session.
- Room selection.
The technical setup will be more stable if the multicasting workstation
does not have to be moved between rooms.
Try to limit multicasting to one or two rooms in which the hardware can
be left for the duration of the meeting.
Avoid rooms that are not appropriate for multicasting due to their
size, dimensions, or inadequate technical amenities
(lighting, or audio, video, or network facilities).
Room selection and program selection are correlated:
if only the most popular sessions are multicasted,
these will generally be held in the larger conference rooms.
-
- Announce the multicasting schedule and plans well in advance,
to appropriate Usenet groups, to selected email addresses,
on any WWW servers announcing the meeting, and in any printed announcements.
Solicit the participation of remote conference sites,
in which a workstation receiving the multicast is used to supply audio and
video to multiple persons.
- Record all multicasted sessions.
These sessions should be multicasted at a later date,
at times suitable for both the eastern and western hemispheres.
- Improve the technical capabilities of the multicast:
- Always have at least one more multicasting workstation on hand
than the number of sessions to be multicasted at a given time.
- Integrate a multicasting WWW browser into the program, which
can be used by remote participants to view the presenters materials
(see proposal in Appendix 5).
Publicize its availability well in advance of the meeting.
Although a number of survey respondents suggested using the MBONE whiteboard,
this is not likely to be successful in a meeting in which WWW browsers
are in continual use, and where the presenters have little whiteboard
experience.
- Use the video camera to capture initial and concluding shots of
the meeting room, but otherwise leave it aimed at the presenter and
local questioners.
Avoid moving the camera otherwise.
Be certain that there is sufficient light on the speaker's face to make
it visible to the remote viewers.
- If possible, use a camera which allows the overlay of text
(many consumer grade video cameras do this); use this text to display
the name of the speaker and session, and the local or UTC time.
- Take steps to ensure better audio quality.
Ideally, all audio setups should be tested well
in advance of the multicast.
- Be certain that the Internet access provider provides a topologically
proximate network connection, and a stable MBONE tunnel site.
Require the provider to demonstrate this connection in advance of the meeting.
Include these requirement in any contracts with the provider.
- Rehearse in advance;
in particular, practice integrating remote questions into a meeting.
- Do not attempt any sudden changes in the multicasting setup which
have not been thoroughly rehearsed in advance.
- Use at least two persons at a multicasting workstation at all times:
one to operate the multicasting software tools,
and one to act as interlocutor (the local "stand-in" for remote participants).
- Several improvements to vat,
the principal MBONE audio tool, would be very useful:
- The log file output does not provide reliable email address
information.
The tool should impose some sort of discipline on participants so that
email and talk could be used more reliably to contact
remote participants,
both during and after a multicast.
- There are numerous settings, and their utility is not clear;
supply detailed documentation about how to use vat
in a realistic meeting.
- Include programmable "metabuttons," that is,
buttons which set all of the other settings of vat
to pre-determined values,
which can be labeled as desired.
These could be used to create settings such as "operator to mbone,"
"question from mbone." "transmit session to mbone," etc.
- Improve the physical arrangements for the multicasting workstation:
- Use a cart or table which provides a normal work surface,
- Site the workstation near the session chairperson.
- Provide the operator with a headset (combined earphones and microphone)
to avoid ambient noise when trying to solicit reception information
from remote attendees.
- Provide each multicasting station with a flexible-necked
low intensity desk lamp and flashlight.
- Label all cables, and tape them to the workstation in such a way
that they can not be casually removed,
and labeled with a sign indicating that they should not be removed
without the express permission of the multicasting operator
or meeting organizer.
Bring a supply of removable reusable cable labels, tape, and marker pens.
- Integrate the multicasting component with the local session in a
visible way, and allocate sufficient time for the chairperson to describe
the multicasting process to local and remote participants at the start
of a session. A video switch box which allows the chair and multicast
operator to switch the projector between the presenter's workstation and
the multicasting workstation would help in this regard.
- Provide all presenters will instructions on preparations of their
presentation materials. Many of the materials presented at the meeting
were inadequate for local use, let alone for multicasting. Express these
instructions forcefully, so that they are taken seriously by presenters.
Perhaps the threat of random advance screenings of materials would be of
help.
- Consider ways in which multicasting technology or unicasting
teleconferencing might be used to reinvent the traditional conference.
APPENDICES
Appendix 1: Output from Traceroute
Aronson ran the UNIX traceroute program several times during the
multicast;
this revealed that the conference's Internet connection was circuitous,
requiring from 18-24 hops to reach the NLM.
This many transits through routers would result in a substantial increase
in the number of lost packets, and hence degradation of multicasting reception.
traceroute 198.133.26.230
traceroute to 198.133.26.230 (198.133.26.230), 30 hops max, 40 byte packets
1 csb-gw.nlm.nih.gov (130.14.30.182) 19 ms 2 ms 2 ms
2 130.14.90.225 (130.14.90.225) 6 ms 3 ms 2 ms
3 wtn1-occs-c1.sura.net (192.221.19.25) 4 ms 10 ms 6 ms
4 128.167.21.8 (128.167.21.8) 12 ms 7 ms 5 ms
5 128.167.3.2 (128.167.3.2) 14 ms 14 ms 30 ms
6 gnu-ctv-c1.sura.net (128.167.158.2) 35 ms 32 ms 40 ms
7 atu1-gnu-c1.sura.net (128.167.157.1) 40 ms 30 ms 53 ms
8 * atu2-atu1-ce.sura.net (192.221.1.101) 48 ms 73 ms
9 tau1-atu2-c1.sura.net (128.167.125.2) 101 ms 58 ms 79 ms
10 aub-tau1-c1.sura.net (128.167.124.2) 58 ms 61 ms *
11 ibmt-aub-c1.sura.net (192.221.32.6) 64 ms 74 ms 58 ms
12 atl1-br1.ga.us.ibm.net (165.87.4.1) 102 ms 111 ms 113 ms
13 atl1-br2.ga.us.ibm.net (165.87.4.2) 137 ms 148 ms 129 ms
14 beth1-br2.md.us.ibm.net (165.87.3.2) 176 ms 84 ms 106 ms
15 * beth1-br1-mf0.md.us.ibm.net (165.87.3.254) 85 ms 63 ms
16 wp1-br1.ny.us.ibm.net (165.87.2.1) 84 ms 67 ms 92 ms
17 * * *
18 * * *
19 wp1-br5.ny.us.ibm.net (165.87.2.5) 80 ms 86 ms 89 ms
20 wp1-br4.ny.us.ibm.net (165.87.2.4) 66 ms 128 ms 94 ms
21 * * *
22 * * wp1-br2.ny.us.ibm.net (165.87.2.2) 144 ms
23 chi1-br1.il.us.ibm.net (165.87.7.1) 147 ms 121 ms *
24 * * *
25 * * show1-cr1.ny.us.ibm.net (165.87.199.4) 140 ms
26 198.133.24.1 (198.133.24.1) 162 ms 112 ms 135 ms
27 198.133.26.230 (198.133.26.230) 110 ms 338 ms 262 ms
traceroute 198.133.26.230
traceroute to 198.133.26.230 (198.133.26.230), 30 hops max, 40 byte packets
1 csb-gw.nlm.nih.gov (130.14.30.182) 61 ms 2 ms 2 ms
2 130.14.90.225 (130.14.90.225) 3 ms 2 ms 2 ms
3 wtn1-occs-c1.sura.net (192.221.19.25) 8 ms 22 ms 5 ms
4 128.167.21.8 (128.167.21.8) 6 ms 31 ms *
5 128.167.3.2 (128.167.3.2) 32 ms 56 ms *
6 gnu-ctv-c1.sura.net (128.167.158.2) 38 ms 101 ms 52 ms
7 atu1-gnu-c1.sura.net (128.167.157.1) 91 ms 52 ms 60 ms
8 atu2-atu1-ce.sura.net (192.221.1.101) 50 ms 52 ms 51 ms
9 * tau1-atu2-c1.sura.net (128.167.125.2) 93 ms 47 ms
10 aub-tau1-c1.sura.net (128.167.124.2) 115 ms 162 ms 249 ms
11 ibmt-aub-c1.sura.net (192.221.32.6) 236 ms 273 ms *
12 atl1-br1.ga.us.ibm.net (165.87.4.1) 279 ms 223 ms 255 ms
13 atl1-br2.ga.us.ibm.net (165.87.4.2) 204 ms 178 ms 195 ms
14 beth1-br2.md.us.ibm.net (165.87.3.2) 238 ms 190 ms 137 ms
15 beth1-br1-mf0.md.us.ibm.net (165.87.3.254) 80 ms 85 ms 98 ms
16 * * wp1-br1.ny.us.ibm.net (165.87.2.1) 136 ms
17 wp1-br7.ny.us.ibm.net (165.87.2.7) 159 ms 133 ms 89 ms
18 wp1-br6.ny.us.ibm.net (165.87.2.6) 95 ms * 137 ms
19 * * wp1-br5.ny.us.ibm.net (165.87.2.5) 144 ms
20 * wp1-br4.ny.us.ibm.net (165.87.2.4) 209 ms 204 ms
21 wp1-br3.ny.us.ibm.net (165.87.2.3) 180 ms * 73 ms
22 wp1-br2.ny.us.ibm.net (165.87.2.2) 114 ms 93 ms 97 ms
23 * chi1-br1.il.us.ibm.net (165.87.7.1) 187 ms 168 ms
24 * chi1-br2-mf0.il.us.ibm.net (165.87.7.253) 110 ms 116 ms
25 show1-cr1.ny.us.ibm.net (165.87.199.4) 152 ms * *
26 198.133.24.1 (198.133.24.1) 276 ms 183 ms 217 ms
27 * 198.133.26.230 (198.133.26.230) 224 ms *
traceroute 198.133.26.230
traceroute to 198.133.26.230 (198.133.26.230), 30 hops max, 40 byte packets
1 csb-gw.nlm.nih.gov (130.14.30.182) 8 ms 2 ms 2 ms
2 130.14.90.225 (130.14.90.225) 6 ms 3 ms 2 ms
3 wtn1-occs-c1.sura.net (192.221.19.25) 10 ms 38 ms 9 ms
4 * 128.167.21.8 (128.167.21.8) 13 ms 13 ms
5 128.167.3.2 (128.167.3.2) 16 ms 19 ms 18 ms
6 gnu-ctv-c1.sura.net (128.167.158.2) 37 ms 35 ms 33 ms
7 128.167.157.1 (128.167.157.1) 71 ms 38 ms 37 ms
8 atu2-atu1-ce.sura.net (192.221.1.101) 33 ms 30 ms 59 ms
9 * 128.167.125.2 (128.167.125.2) 79 ms 65 ms
10 128.167.124.2 (128.167.124.2) 50 ms 61 ms 77 ms
11 ibmt-aub-c1.sura.net (192.221.32.6) 51 ms 72 ms 66 ms
12 atl1-br1.ga.us.ibm.net (165.87.4.1) 117 ms 87 ms 100 ms
13 dallas1-br1.tx.us.ibm.net (165.87.6.1) 134 ms * 113 ms
14 dallas1-br2-mf0.tx.us.ibm.net (165.87.6.253) 195 ms 147 ms 140 ms
15 chi1-br2.il.us.ibm.net (165.87.7.2) 109 ms 138 ms *
16 show-cr1.ny.us.ibm.net (165.87.199.4) 121 ms 174 ms 140 ms
17 198.133.24.1 (198.133.24.1) 192 ms 171 ms 152 ms
18 * 198.133.26.230 (198.133.26.230) 141 ms 94 ms
Appendix 2: Summary of the Remote Participant Survey
The survey was sent to
approximately 302 addresses.
Results from the 41 surveys returned
are summarized below.
The information obtained from respondents does not fully represent
the impact of multicasting;
for example, we know from direct contact during the first day of the conference
that at Bolt-Beranek and Newman (Boston area),
75 people attended a remote conference room
(but received little or no multicasting on that day).
Minor obvious spelling and grammatical mistakes were corrected,
other replies were left as received:
PART 1: GENERAL QUESTIONS
- Your name and email address (optional):
- Jules Aronson (aronson@nlm.nih.gov)
- Charles Bacon (crtb@helix.nih.gov)
- Dirk Boenning (boenning@igd.fhg.de)
- Ted Brunner (ted.brunner@tek.com)
- Don Brutzman (brutzman@nps.navy.mil)
- Stephen Campbell (stephen@mrrl.lut.ac.uk)
- Reuben R. Cano (cano@xrd.dfrf.nasa.gov)
- Matt Crawford (crawdad@fnal.gov)
- Jonathan Epstein (epstein@ncbi.nlm.nih.gov)
- Steven Fellini (Steven_Fellini@nih.gov)
- Tim Finin (finin@cs.umbc.edu)
- Lapique Francis (lapique@sic.epfl.ch)
- Jay Glicksman (jay@eit.com)
- Marge Gunter (mgq@snoopy.ctd.ornl.gov, mgq@ornl.gov)
- Tad Guy (E.E.Guy@LaRC.NASA.GOV)
- Martin Hamilton (martin@mrrl.lut.ac.uk)
- Bob Healy (healy@bnl.gov)
- Hanan Herzog (herzog@lbl.gov)
- Steve Hopper (hopper@cs.ucsd.edu)
- Kipp Jones (kipp@cc.gatech.edu)
- David L. Kensiski (kensiski@nas.nasa.gov)
- Jon Knight (J.P.Knight@lut.ac.uk)
- Mark Leininger (markl@dcdmbl.fnal.gov)
- Larry Littlefield (larryl@bellevue.hp.com)
- Edward N. May (may@anl.gov)
- James Myers (jd_myers@pnl.gov)
- Charles Nicholas (nicholas@cs.umbc.edu)
- Linsey O'Brien (lbob@bbn.com)
- Francis Ouellette (francis@ncbi.nlm.nih.gov aka francis@borduas)
- Herve Recipon (recipon@ncbi.nlm.nih.gov)
- Lane Robert (lar@usl.edu)
- Peter J. Scott (pjs@euclid.jpl.nasa.gov)
- Paul Stewart (stewart@hibp.ecse.rpi.edu)
- David Surtees (D.P.Surtees@ncl.ac.uk)
- Jean-Christophe Touvet (Jean-Christophe.Touvet@inria.fr)
- Thomas Vogel (vogel@hrz.th-darmstadt.de)
- Rene Wilhelm (Wilhelm@nikhef.nl)
- David CM Wood (dcmwood@spot.colorado.edu)
- Graeme Wood (Graeme.Wood@ucs.ed.ac.uk)
- Rose Marie Woodsmall (rose@ncbi.nlm.nih.gov)
- Shelby Yang (yang@cs.indiana.edu)
- Institutional affiliation [redundant entries removed]:
- BBN, Inc.
- Brookhaven National Lab
- Computing Services, The University of Edinburgh
- Department of Computer Studies, Loughborough University of Technology
- Dutch National Institute for Nuclear and High-Energy Physics
- EIT
- Fermilab
- Georgia Institute of Technology
- HPSCS/CFB/DCRT/NIH/PHS/DHHS/US
- Hewlett Packard Co.
- High Energy Physics Div, Argonne National Lab
- INRIA (Institut National de la Recherche en Informatique et Automatique)
- Indiana University
- Jet Propulsion Laboratory
- Lawrence Berkeley Laboratory (LBL)
- MRRL, Computer Studies, Loughborough University
- NASA Langley Research Center
- NCBI/NLM/NIH
- NIH/DCRT
- National Library of Medicine, NIH
- Naval Postgraduate School
- Oak Ridge National Laboratory
- PRC Inc., NASA Dryden FRC, Edwards,CA
- Pacific Northwest Laboratory
- Rensselaer Polytechnic Institute
- Sterling Software (NASA Ames Research Center)
- Swiss Federal Institute of Technology
- Technical University Darmstadt (Technische Hochschule Darmstadt)
- Tektronix (Communication Systems Research Lab)
- University Computing Service, Newcastle University, UK
- University of Colorado - Boulder
- University of Maryland Baltimore County (UMBC)
- University of Southwestern Louisiana
- Your geographical location [redundant entries removed]:
- Beaverton, OR
- Bethesda, MD
- Baltimore, MD
- Cambridge, MA
- Richland, WA
- Pasadena, CA
- Monterey, CA
- Argonne, IL
- Lausanne, Switzerland
- Berkeley, CA
- Darmstadt, Germany
- United Kingdom
- Atlanta, GA
- Edinburgh, Scotland
- Amsterdam, Netherlands
- Oak Ridge, TN
- Loughborough, UK
- Upton (Long Island), NY
- Lafayette, LA
- Bldg. 38A, Rm. 8N805 (NIH)
- Loughborough, England, UK
- Bloomington, Indiana
- Moffett Field, CA (near Sunnyvale, South Bay)
- Illinois
- Hampton, Virginia, USA
- Bellevue, WA (near Seattle)
- Boulder, Colorado
- Troy, New York, USA
- Menlo Park, CA
- France, near Paris
- Newcastle, UK
- Your Internet access provider [redundant entries removed]:
- Alternet
- BARRnet (Bay Area Regional Research Net)
- Campus internet
- DFN (Deutsche Forschungsnetz eV)
- ESNet
- Hewlett Packard Co. or unknown
- JANET
- LaNet (State of Louisiana), which gets its access from SuraNet
- Los Nettos
- NASA Science Internet (NSI) & SURAnet
- NEARNet
- NLM
- NSFnet
- NSI
- PSI
- RENATER (France Telecom)
- SURAnet
- SURFnet
- SWITCH
- UKERNA
- University, SuperJanet
- Westnet
- XLINK
- Number of people who viewed or listened to the conference, at any time,
via the computer receiving the MBONE multicast at your site
[number viewing: number of replies]:
- 1: 17 (in 4 cases, there were occasionally others)
- 2: 3
- 3: 6 (probably includes several of those listed for smaller groups;
occasionally, others as well)
- 4: 2 (in one case, short time viewers)
- 5 (probably includes several of those listed above)
- 6: 1 (as many as 10, plus viewers elsewhere on campus)
- 7: 1
- 10: 2 (2 are estimates)
- 20: 1 (varied from 5-20)
Comments:
- question unclear ... "THE computer"?? Up to 2 at a time
viewed at my workstation ... more people at other workstations
- We had multiple computers listening, at least 3 on my floor.
- Did you (or any of the other viewers) try to register for the WWW
Conference?
- Yes: [6/36]
- No: [30/36]
Comments:
- no, but we sent a couple of regular attendees
- Reason for your interest in participating in the MBONE multicast:
- Mainly interested in the WWW Conference: [6/37]
- Interested both in the Conference and in multicasting: [29/37]
- Mainly interested in MBONE multicasting: [2/37]
- Type of hardware you were using [redundant entries removed]:
- DEC 3000-300
- HP 9000 712 desktop
- HP 9000 715/75 workstation
- HP 9000 750 MBONE tunnel server
- IBM ValuePoint running FreeBSD-1.1.5.1
- Macintosh
- SGI workstations (various)
- SGI Indy, some with IRIX 5.2
- SGI Indigo
- SGI Indigo 2
- SGI Indigo R4000
- Sun SPARCstation 2, some with SunOS 4.1.3
- Sun SPARCstation 5, Parallax Powervideo
- Sun SPARCstation 5, Sun frame buffer, camera and microphone
- Sun SPARCstation 10, some with Solaris, others with SunOS 4.1.3
- Sun SPARCstation 20
- Sun SPARCcenter 1000
- Sun SPARCstation ELC, some with SunOS 4.1.3_U1
- Sun SPARCstation LX
- Sun SPARCstation IPC
- Sun SPARCstation IPX
- Was your site equipped with a microphone for sending MBONE audio?
- Yes: [34/37]
- No: [3/37]
- If and only if your answer to the above question was "yes:"
- Did you attempt to participate verbally with a question?
- Yes: [3/34]
- No: [31/34]
- Did you attempt to communicate verbally during periods of testing,
or when the multicasting staff solicited reception reports?
- Yes: [13/34]
- No: [21/34]
- Was your site equipped with a television camera for sending MBONE video?
- Yes: [17/36]
- No: [19/36]
- If and only if your answer to the above question was "yes:"
Did you attempt to multicast video at any time during the event?
- Yes: [0/16]
- No: [16/16]
- How did you first become aware of this multicasting event?
- WWW Conf. Web server documents: [8]
- MBONE sd announcement: [11]
- Usenet news announcement: [4]
- Email announcement: [15]
- Other: [7]
Comments:
- colleague at NCBI
- I participated at the conference in Chicago,
but missed the Thursday developer's day
- NIH Calendar of Events
- sys admin
- from colleagues
- colleague informed me it would be multicast
- colleague who was planning the meeting
- Colleagues
- How well were questions from remote participants integrated into the
meeting?
- Well integrated: [8/29]
- Adequately integrated: [14/29]
- Poorly integrated: [7/29]
Comments:
- E for effort, however
- Most presenters did not have adequate advance warning to prepare their
visual materials in such a way as to be optimal for MBONE video
transmission. The overall impact of the visual materials was:
- Acceptable if not optimal: [8/33]
- Poor but still somewhat useful: [21/33]
- Nearly useless: [4/33]
Comments:
- BUT EXCITING TO SEE LIVE !
- I never received the video at my site, just audio
- Never received video -- old version of nv
- camera shots of overheads suck, in general
- Of any useful information imparted to you by the multicast:
- Most information was conveyed via the video portion of the program: [2/33]
- Equivalent amounts of information were conveyed via video and audio: [15/33]
- Most information was conveyed via the audio portion of the program: [16/33]
- How would you rate the potential utility of a multicasting version of a Web
browser (such as NCSA Mosaic) which would allow remote participants to
view the presenter's visual materials in synchrony with the presenter?
- Very useful: [26/36]
- Moderately useful: [7/36]
- Not useful: [3/36]
Comments:
- Not useful at this prototyping level
- This would make the visuals smaller
- or howabout the whiteboard?
- Although I'm not sure I understand the question
- Your overall assessment of the value of the multicasting effort:
- Very useful: [22/36]
- Moderately useful: [12/36]
Comments:
- I would say 'very' if it had gone (technically) better.
(sorry guys, nice first try though .... 'sept first day:-( )
- Not useful: [2/36]
- Should multicasting be a part of future Web conferences:
- Strongly support future multicasting: [33/36]
- Moderately support future multicasting: [3/36]
- Neither for nor against: [0/36]
- Moderately against future multicasting: [0/36]
- Strongly against future multicasting: [0/36]
- Comments about the selection of sessions to be multicasted:
- We should be allowed to choose a channel ... meaning that multiple
sessions should be covered, and we can make the choice which one
to follow.
- Good selection, the K-12 program was good. 8-)
- Bit hard to say, as we only ended up seeing half of them :-(
- It would be nice if some information regarding the current
speaker and current session could be included in the
broadcast. It was difficult to tell who the speakers were
due to the low quality video, and intermittent audio.
- Any sessions at all! At this stage, we're like guests at the
demonstration of Mr. Edison's new Light Bulb. We don't come
with a book to read at night, rather to stare at the light!
- Ideally I'd like to see all sessions (:-) ), but the proposed range
seemed a pretty good selection.
- Unfortunately, I only found time to view a very little bit of the
conference; and parts of that were interrupted by signal loss. I'm
basing some of my input on the previous W3 conf mbone broadcast.
- Would have liked to see the biomedical session. Did not see entire
program listing, so don't know what else I missed.
- Reasonable.
- I realize that there numerous issues involved here, not the
least of which is bandwidth, but I would like to see all
technical conferences available via multicast. That way,
even those who haven't the time our resources to attend the
conference can still participate.
- Well, none of sessions multicast were of people from our facility. :-)
Would prefer multiple sessions multicast simultaneously (apparently there
were sessions of more interest to me that were not transmitted).
- the K-12 sessions wasn't interesting; would have liked to see some
of the more technical sessions
- Good.
- All sessions should be available.
- Good.
- Good, but I wanted more :-)
- Do you have any thoughts about how multicasting or related technologies
relate to traditional conferences, or about ways in which these technologies
could be used to enhance current conferences or to create new forms of
conferencing? Comments here:
- I found this to be a very new exciting way to participate in a
conference. With multiple session coverage, well advertized schedule
and close adherance to time .. we could 'tune in' to the talks and
discussions of interest, and save lots of time on travel/expenses.
This is something I would encourage strongly within the biology
community.
- Shared whiteboard would have been very useful - e.g. for general
feedback, and specifically for interaction with the speakers. There
are a lot of concepts that are hard to describe in words, but easily
drawn ...
- I think it can be a great way to get the information to a much
larger crowd. I think the quality needs to improve in order
for a larger number of people to participate. I think the
T1 connection in Chicago was pretty flaky, which could account
for the drop outs, but it was very difficult to follow the
sessions due to this.
- There are many problems associated with multicasting existing conferences:
- conference control and management (who is allowed to talk)
- charging fees for remote attendance
- getting presenters to provide pre-prepared slides for loading etc.etc.etc.
- Multicasting can be very useful when you are interested in a
particular session but are not able to attend the whole conference.
- This may come to pass via the ordinary Cabal TV routes, rather
than the Internet. The delay and dropout rates characteristic of
today's Internet are not suited to TV and audio. But that would
be a rather heretical approach, wouldn't it?
- Well, there's no way I could have got the conference even if I'd had the
time for it; I'm only a research student and my grant doesn't stretch to
international conferences on subjects that aren't directly related to my
Ph.D. subject matter. Also, it's usually handy to be able to join in a
conference and still be able to carry on working, reading email, doing
NetNews, etc, etc while listening in.
- I think the ultimate goal should be for everyone who participates, to
participate electronically, and to eliminate the need to travel and be
physically present. That goes for both the "attendees" and the
"presenters". Some may wish to remove themselves from the office
environment, in order to devote their full attention to the conference.
But that same goal could be attained by having a room dedicated to
participation via mbone at the local site.
- In some ways, I felt like I WAS at the conference. I would like to be
able to see bits and pieces of several meetings (MLA, SCAMC, ASIS in
particular) without physically going to the meeting every year.
I don't think it would take away from attendance at the meetings --
most organizations cannot and do not send the entire staff every year.
It would enhance rather than detract.
- Well, I find the open forum on the conference and the net do not mix well
at the moment. I am sure that more care (sorry I know you'll hate me for
this) at the broadcast end would improve things. There tends to be a home
movie feel to it, Cameras wave about madly leading to unnecessarily picture
update. Greater compression of dynamic range on the mic's, since it is
practically all spoken content, would help. tie-clip mic's low light
cameras... I know some of this would be too expensive but most would not
(eg tripod and lock for the cameras. Whiteboard/mosaic for the slides
would be great, the cameras could rest on the speaker then.
- Multicasting conferencing is convenient and helpful for those who
cannot go to the conference for some reason. However, there is a concern
that it may be abused like the news group. It may become so saturated
that it is difficult to find the right conference to tune in. Also,
there is a security concern. A multicasting conference among a small
group of people can be eavesdropped by people all over the world.
- Another important thing to consider is the potential drop in
actual attendees if they can "attend" the conference from
their workstation.
- I think multicast is a good tool for giving someone who doesn't have
the time/resources to participate physically in a conference to be an
active participant in some form.
- Multicast doesn't solve time zones problems ;-) Sessions should be
recorded and replayed at least 2 times during the (next) day.
- It is hard to get all the presentation
materials onto a common electronic media. Once done however,
the strengths of computer networks can come to bear, and new
ways of teaching/demonstrating/participation can evolve.
- Multicasting is very useful provided the visual presentation is
formatted for the video portion. Many of the video presentations suffered
from too small fonts or poor foreground/background color combinations.
Some of the presentations may not have been formatted appropriately
for a slide presentation, added the video distortion of the mbone,
they became unreadable at remote sites.
The video should be done via the Whiteboard or via a multicasting
form of Mosaic. Then the distortions of the text would be much less
and thus the text would be readable.
Multicasting allows people whose schedules or interests interfere with
full time attendence to avoid missing what they do need to know.
If priced correctly, it also allows a strapped department to send one or
two full-time attendees and have the rest virtually attend selected
sessions.
- Other remarks:
- I was a bit surprised on how few participant there were on the MBONE.
- Video of overheads is a very poor way to go. Getting slides onto a
whiteboard or into WWW beforehand, with (or without) a way to have remote
synchronization (as Mosaic has in Unix) would be much better. That, audio and
a still of the speaker would be much better than the present video.
- Didn't get nv 3.3 beta in time to see anything significant
- Acceptable slides in most cases. My rule of thumb is that good slides
remain useful and bad slides get worse. This also held true at your
conference.
- Incidentally, I disagree with your question. The presence of papers
in .html on-line was tremendously useful. I will be using some.
- Audio video and web site were all very useful.
- Audio is HARDER to get right than video but people's effort usually
goes into video. You guys were usually OK but I recommend more
emphasis on audio next time.
- THANK YOU VERY MUCH for your tremendously useful efforts.
- I checked in a few times, but never saw a picture on nv! The audio
when it seemed to be on was "miked" so badly as to be unusable! As
far as I could tell the broadcast was a failure!
- I think Multicasting software technology and supportive high
performance networking infrastructure will significantly impact for the
better, how conferences occur (not take "place"). My hope is that
mcast conferencing will allow more frequent and inclusive dialog among
researchers, scientists and academics. Multicasting has the advantages
of economy, by not requiring high hotel and travel costs for
participation. Also, given the nature of some sectors of the
information industry, many of the most valuable minds are heavily
burdened with responsibilities in their institutions, which makes
several days leave for conferences impractical. This group includes
academics who have teaching or advisory duties on campuses.
- I did not follow the whole event -- I was just in the process of
testing the software.
- I would prefer to go to a conference in person. But there are too many
to attend (and especially for people over here in Europe it is difficult
to be allowed to go to the interesting events which mainly take place
in America). The greatest advantage I see is that you can doe your work
and besides take some time off and listen and watch those lectures you
are most interested in.
- I was going to [ask a question remotely], but we lost a/v on the sessions
I wanted to participate in :-(
- We were seeing drop-outs typically around the 50% mark for both audio
and video, but this didn't affect the video too badly. The audio
came over quite badly, with the speakers often sounding like the
proverbial "dalek in a dustin" :-(
- Suspect there were problems with gain control on the mikes in Chicago
- I was only participating on MBONE on Thursday, I've heard from
others that the quality may have been better on other days.
- The first day (morning session) I did not receive any audio/video
signals from the conference. The second day the audio reception
was poor (20% packet loss), which made it impossible to participate
in the conference.
- As you can see, I didn't participate much. I was very interested in
participating, but found the audio and video problems too distracting.
Plus, I didn't know the schedule in advance.
- We are astounded, not by the quality or content of Internet
multicasting, but rather by the sheer wonder that it can be
done at all. Multicasting today is the Internet's equivalent
of Ham Radio.
- I have deleted the repeated forms for various sessions, since
I couldn't distinguish them. I'm sorry about this; if audio had
been of good quality and video consistent (and overheads actually
legible), I would have really put some time into the conference.
- I could not identify individual sessions, having not kept a
program. But every attempt usually resulted in intermittent
audio, absent video (or a frozen image-- "(signal lost)").
Further, before the audio went on the air, there was VERY
POOR control of volume levels. Average volume levels
seemed to vary by up to 50 db.
I hope my (indented by tab) comments are what you had in mind,
considering that I was probably on the far side of a poorly
configured mrouter. I'll be glad to hear the results.
- Its a pity that whenever I tried to access the conference there seemed
to be some technical problems. I was really hoping to see the
publishing part, but all I saw was a bit about the use of digital cash
on the WWW (I don't know what session it was; I only caught five minutes
of it before I got called away). I know how tricky multicasting
conference sessions is (I've tried to do it and we had awful problems)
but for something as important as the WWW conference it might have been
an idea to have a set of backup strategies, spare cables, etc and have
the setup tested out the day before (the later is pretty important and
was the one thing we learned from our attempt!). Retransmitting the
recorded session over the MBONE at a later date (say an uncluttered
weekend) is a good idea, as is putting it up on a media on demand
server. However, I think multicasting the WWW conference is a really
good idea and I encourage you to do it again in the future.
- Enabling participation from viewer via mbone adds
significantly to the value of a multicast conference, IMHO.
- I rated the usefulness of the video as poor mainly because my
workstation is monochrome; the dithering made it difficult to read
most of the slides that were shown. If I had color, I suspect that
the video would have been much more useful. Getting the materials
via WWW sounds like the best idea in any case.
My memories of the individual sessions are vague, mostly because the
conference was not my top priority; it was simply running in the
background most of the time (alongside Multimedia 94). Therefore,
my answers below may not be completely accurate. But in general,
when I was able to receive your transmissions the quality was
adequate to follow the presentations.
- I "watched," but was doing e-mail questions from users and answering
phone inquiries at the same time, so it was a very distracted
watching. I found the whole thing fascinating none-the-less.
- Although the technical difficulties were distractions,
the spirit of the thing was very positive. Since it was my first
mbone experience, it was more of an experiment from my perspective.
FOR ALL SESSIONS: In general, I did not lose the video and it was
watchable; the audio quality varied wildly and I lost it from time to
time.
Just like any meeting, some of the presenters had good visuals and
others poor. The poor ones looked really bad.
- It seems possible that the MBONE interfered with normal Internet
traffic to/from NLM and/or NCBI, since I experienced very bad network
delays when I was at the conference reaching my NCBI computers, but no
delays reaching a computer in New Hampshire. These effects should be
accounted for in future multicasting.
- A combination of poor microphone balance on the floor and heavy
break-up before the final question session meant that we (I) couldn't
really follow what had been asked and what answers had been proffered.
Curiously, the questions from the floor (and net) were easier to follow
than the answers on the 'stationary' mic's .... heavier auto-compression
might have helped (i.e., of the dynamic range rather then sample
rate/packet)
- You should note that I was watching these while I was working,
so I did not have my full attention on it. In general, when we
could get anything, the video was OK and the audio peaked at just about OK,
but was mostly poor to incomprehensible. Day 1 was a complete wash out.
I might have got a little muddled over the others, my memory isn't what
it never was!
I assume that you are soliciting comments about the broadcast rather then
the content of these sessions.
- Your survey's too long. I tried to listen to the broadcast because I was
testing a new version of mbone I installed and because several people from
our site attended the conference and mentioned it to me. I heard
intermittent audio bursts during the day that were mostly queries from
other sites about why nothing was being broadcast from the conference,
but never received any consistent audio broadcast and never received any
video broadcast at all. Since I was successful viewing other
broadcasts later in the day, I would conclude you had some technical
problems.
- Well, the only video I saw coming from your broadcast was a woman sitting
at a terminal not doing anything. Other than that I never received any
other content.
- I didn't receive the first day at all.
I got the impression that nobody did.
- Audio was very poor on Tuesday & Wednesday. I gave up early Wednesday.
- Audio generally has more information content than video, but there was
substantial (at times) breakup of the audio (I've found dvi format to
be good for lossy audio).
- It is a fantastic idea. I was not able to spend the time
necessary to really participate in the conference. I am very
interested in both MBONE and WWW.
The overhead slides were readable as long as the camera was held
still, the computer screen stuff was almost un-readable.
I watched the San Francisco Multi-media conference when we could
not receive the WWW conference. They seemed more able to hold
the camera still. Local feedback would be helpful, if the
camera man could see what the medium speed MBONE looked like, he
could improve his style.
Our feed is through a 1.2 MegaBit T-1 through HP Labs, this may
have effected our performance.
- The multicast from the conference was so intermittent that I never got
anything out of it. I listened to several people trying to get things
going, but gave up after receiving only occasional bursts of multicast
from the conference.
I have not had this problem with other conferences.
- A multicasting version of a Web browser (such as NCSA
Mosaic) which would allow remote participants toview the presenter's
visual materials in synchrony with the presenter" is very vague.. My views
are probably bound too tightly to the implementation of the applications
that are Web based, and the ones that are Multicast based to see a direct
connection between the two. I can see gateways that multicast a URL that
would be sent to a browser, or a special document type that would have a
browser start a Multicast application, but I don't see the application for
a Multicast browser. They imply two totally different things to me.
Perhaps you can clarify.
- The actor and the cameraman must be taught what to do in a MBone
transmission to get the best results.
- Very bad network connectivity from France during the conference.
- Sorry for the late (and inadequate) reply. Hopefully my comments
will be of some use, although I don't have time to complete your entire
questionnaire.
I received video from your conference very well, but I'm afraid that the
audio was too broken up for me to listen for very long periods. I was able
to hear clearly comments from other Mbone participants across the Atlantic,
so the problem wasn't just slow trans-Atlantic communications.
I would be VERY interested to hear if you plan to rebroadcast any of the
sessions.
- Teach the cameraman the difference between 30 fps and 1 fps.
Panning/zooming and generally moving around is BAD for the video.
PART 2: QUESTIONS ABOUT SPECIFIC SESSIONS:
Tuesday, October 18 (Conference Day 1)
Plenary Session 8:30 - 10:00 CDT (13:30 - 15:00 UTC) Great Hall
(Hardin, Peters, Berners-Lee)
[11] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[1] [0] excellent
[3] [2] acceptable
[2] [3] poor/intermittent
[7] [8] could not receive
Comments about this session: [none]
Session 1: Publishing 10:15 - 11:45 CDT (15:15 - 16:45 UTC) Gold Room
(Stuart Weibel)
[11] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[3] [2] excellent
[1] [0] acceptable
[0] [1] poor/intermittent
[8] [9] could not receive
Comments about this session: [none]
Session 2: Authoring Tools 2:15 - 3:45 CDT (19:15 - 20:45 UTC) Gold Room
(Yuri Rubinsky)
[11] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [0] excellent
[3] [1] acceptable
[0] [1] poor/intermittent
[6] [7] could not receive
Comments about this session: [none]
Session 3: Commercial Transactions on the WWW (Panel) 4:00 - 5:30 CDT
(21:00 - 22:30 UTC) Great Hall (Allan Schiffman)
[12] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [0] excellent
[3] [2] acceptable
[2] [1] poor/intermittent
[5] [6] could not receive
Comments about this session: [none]
Wednesday, 19 October (Conference Day 2)
Plenary Session 8:30 - 10:00 CDT (13:30 - 15:00 UTC) Great Hall
(Hardin, Goldstein, Chaum)
[10] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [0] excellent
[4] [6] acceptable
[7] [4] poor/intermittent
[1] [2] could not receive
Comments about this session: [none]
Session 1: Computer Supported Cooperative Work 10:15 - 11:45 CDT
(15:15 - 16:45 UTC) Plaza Room (Weymouth)
[10] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [1] excellent
[6] [4] acceptable
[6] [5] poor/intermittent
[0] [2] could not receive
Comments about this session: [none]
Session 2: K-12 Education 2:15 - 3:45 CDT (19:15 - 20:45 UTC) Plaza Room
(Bievenue)
[12] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [0] excellent
[5] [6] acceptable
[5] [3] poor/intermittent
[0] [1] could not receive
Comments about this session: [none]
Session 3: WWW Security: The Big Picture (Panel) 4:00 - 5:30 CDT
(21:00 - 22:30 UTC) Great Hall (Allan Schiffman)
[13] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[1] [0] excellent
[5] [6] acceptable
[3] [2] poor/intermittent
[0] [1] could not receive
Comments about this session: The most interesting one.
Thursday, 20 October (Developers Day)
Session 1: HTML and SGML 8:30 - 10:00 CDT (13:30 - 15:00 UTC) Gold Room
(Berners-Lee)
[15] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[1] [0] excellent
[2] [5] acceptable
[4] [1] poor/intermittent
[2] [3] could not receive
Comments about this session: [none]
Session 2: CERN-MIT-NCSA 10:15 - 11:45 CDT (15:15 - 16:45 UTC) Gold Room
(Berners-Lee, Hardin, Cailliau)
[12] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [0] excellent
[3] [5] acceptable
[5] [2] poor/intermittent
[2] [3] could not receive
Comments about this session: [none]
Session 3: Web Programming Interfaces 1:00 - 2:30 CDT (18:00 - 19:30 UTC)
Gold Room (Thompson)
[12] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[0] [0] excellent
[3] [4] acceptable
[4] [1] poor/intermittent
[3] [5] could not receive
Comments about this session: [none]
Session 4: Ask the Mosaic Developers 2:45 - 4:15 CDT (19:45 - 21:15 UTC)
Gold Room (McLaren)
[13] did not try to participate in this session
tried to participate in this session, and reception was as follows:
AUDIO VIDEO
[1] [0] excellent
[1] [6] acceptable
[6] [2] poor/intermittent
[0] [0] could not receive
Comments about this session:
- couldn't receive some of it
- This was a Q & A but 1) half of the panel's microphones didn't work
and 2) those that did often couldn't be heard on the MBONE as they
were not hooked into the transmitting workstation. I asked a
question but couldn't hear the answer. The moderator did,
however make a real effort to include the virtual attendees
and the answers I did manage to hear were extremely valuable.
Appendix 3: Images from the Multicast
The images appearing below, with a single noted exception,
were prepared by Steve Satterfield of the NCBI/NLM,
a colleague of Rodgers,
who watched the multicast on his Sun workstation.
The multicast team at the meeting was far too busy to save such images
themselves; we are grateful to Steve for sharing these.
The images are offered here at a
gamma value
of 2.6;
if they appear too light or too dark on your display,
you will have to download the images,
correct the gamma value so as to be appropriate for your monitor,
and display them locally.
An elaborate ceiling frieze in the Gold Room.
The audience during Session 1 (HTML and SGML)
on Thursday, 20 October (Developers Day).
David Raggett and Håkon Lie during the HTML/SGML session.
R. P. C. Rodgers asking a question during the HTML/SGML session,
David Raggett and Håkon Lie standing by.
R. P. C. Rodgers asking a question during the HTML/SGML session,
David Raggett and Håkon Lie standing by.
The nv window on Rodgers' Sun SPARCstation at the NLM,
showing the last image transmitted from the conference.
Appendix 4: Failure of the White House Multicast
Following find the email message Carl Malamud (Internet Multicasting Service)
sent to the remote conference mail list (rem-conf@es.net)
describing the technical problem that led to the failure of
the White House multicast on 18 October:
From rem-conf-request@es.net Thu Oct 20 17:08 EDT 1994
Date: Thu, 20 Oct 1994 14:53:38 -0400
From: Carl Malamud
To: rem-conf@es.net
Subject: White House Announcement
Org: Internet Multicasting Service
Content-Type: text
Content-Length: 734
Sigh. We were all ready to go for Vice President's announcement of the
new WWW server. All the usual problems of doing things out of White
House/EOB were all taken care of: power, a table, a machine that works,
etc... were all furnished by extremely capable staff at ARPA and NSF.
The only problem was connecting to the local net which used a DELNI.
We ran out of the DELNI into our TP hub and out to the Sun. Everything
worked fine until the last minute when the hub broke. The problem with
the White House complex is that it is *really* tough to run out, get some
more equipment, and run back in. To use the technical term, we were
hosed.
Thanks to everybody for your patience. We'll get this right one of
these days!
Carl
Appendix 5: Proposal: A Multicasting World-Wide Web Browser
Multi-Web:
A Proposal for A Simple Prototype Application
Merging Multicasting and the World-Wide Web
R. P. C. Rodgers
Lister Hill National Center for Biomedical Communications
National Library of Medicine
8600 Rockville Pike
Bethesda MD 20894 USA
19 August 1994
revised 24 August 1994
(under revision, December 1994)
Rather than further postpone sharing this report,
this section is being withheld until the current
revisions are completed.
Parent document within HyperDOC hierarchy
HyperDOC home page
NLM HyperDOC / Online Information Services / April 1994
