For the past several years, Parvati has been setting up technically complex demonstrations for the Visible Human Project® (VHP) using one server at the University of Wisconsin, one at Stanford, and one at the National Library of Medicine (NLM) in DC. While she has had many successes with videoconferencing and data streaming demonstrations, she often runs into such difficulties as these:

CASE 1: When a major demonstration of the VHP was scheduled at the NLM auditorium; she and her team arrived 2 days before the event, set up the projection system, and tested all the clients and connections to ensure there would be no problems. The presentation was to begin at 9:30 a.m. but, at 9:05, the network connection, without which they could not run the demonstration, disappeared! Because the auditorium was full for this event, Parvati went ahead with preparations for her presentation, not knowing for more than 20 minutes if she could demonstrate the VHP, as planned.

As it turned out, a network engineer across campus saw that a DHCP server had been started that he hadn't heard was authorized - the network folks working with the conference were aware and helping, but this particular individual wasn't on the team and, therefore, wasn't in the information loop - so he walked in at 8:45 a.m., saw what he thought was an unauthorized server running, and pulled the plug. Fortunately, the network team working on the demonstration found the problem quickly and the demonstration went on, as scheduled. It took 20 minutes to track down what had happened and fix it - Parvati was 5 minutes from beginning her talk by this time, still not knowing if she could run her demonstration before she got word that the network was functioning again.

CASE 2: For a demonstration at Hewlett Packard in Palo Alto, CA, Parvati and her team arrived two days early, set up the projection system, and tested all the clients and connections to ensure there would be no problems. This time, they lost the connection 5 minutes before the demonstration. When the connection disappeared, Parvati had already begun her presentation, so it was obvious to the audience that there were technical problems. In this case, the cause of the lost connection was that someone was installing a patch at that exact moment. Parvati was 10 minutes into her talk before the patch was completed and she could continue with the demonstration.

CASE 3: When conducting a demonstration in India, Parvati was using a Polycom at each end. The latency between the two sites was enormous; the Polycom turns itself off when it doesn't see a packet coming in. This is a major issue for videoconferencing over long distances - as Parvati says, "the latency kills you." This problem proved insoluble but, because of the preparatory work her team had done, they identified the problem in mere minutes. She thought the Internet2 community could develop guidelines for Polycom equipment (i.e., larger buffers or latency-acceptances) for use with non-high-speed Internet connections. Polycom has recently endorsed using the H.323 Beacon as a troubleshooting device; for more information about this tool, see http://e2epi.internet2.edu/Beacon/overview.html (overview) or http://www.itecohio.org/beacon/ (technical documentation and source code).

Recommendations
Parvati learned that unexpected problems occur to the best laid paths. To minimize the number of problems encountered and make solution of them quicker and easier, she has an experienced setup team. In these reported cases, the preparatory work ensured a clean path; this is crucial to the success of her demonstrations, especially when something goes wrong at the last minute. Because her team has already identified the path:

• They were familiar with the places where problems might arise,
• They were in touch with network personnel on site and at connected locations, and, thus,
• They eliminated the two foremost problems faced by end-users: finding someone who can help and convincing them that the problem is real and within their domain.

• Be alerted about demonstrations on their network,
• Understand what can affect the demonstrations, and
• Check with the network administrator who is supporting the demonstration before making any changes, however slight, that could affect the network during the demonstration period.