[AG-TECH] Multicast Debugging Information

[Ed Ritenour]

Bill

What we have done here to assist with those requirements is purchase laptops for
the operators to be used to quickly determine AG related problems. The laptops are
setup with the desktop version of AG. By joining a meeting we can quickly
determine whether a problem (audio or video) appears related to the local system,
network or somewhere out in the cloud. The laptop can remain connected while
network troubleshooting occurs in the background allowing the operators to
continue to deal with meeting requirements. We simply infor the network group via
email or a quick phone call. Our internal mailer includes the local and wide area
network staff who primarily deal with the multicast issues. Its a bit of a waste
of a laptop at times but with the reliability of multicast as it is today makes it
well worth while most of the time.

Ed


Bill Nickless wrote:

> Thank you Ed,
>
> I agree completely that the first and foremost priority is to make the
> meeting work for the attendees.  You're absolutely right.
>
> However, if the network doesn't work properly for a meeting, that fact
> needs to be communicated to the network people so that it can be fixed.
>
> And it's still true that the network people need to know all of the things
> I mentioned below: source/group IP addresses and a receiver that's not working.
>
> The beacon can fill that requirement--but the node operators still have to
> be sure the beacon client is running, and then tell the network people
> about problems they run across.
>
> At 01:25 PM 2/20/2003 -0800, Ed Ritenour wrote:
> >Bill
> >
> > From an operations point of view I agree with the first three items, but our
> >goal is to make the meeting a success. We have found that our users don't
> >necessarily care if the video is down as long as they can still participate in
> >the meeting. To do that they need need audio and slides. We have found from
> >past experience that it is unlikely a network problem will be resolved during
> >the testing process anyway and waiting up to the last minute to attempt
> >bridging or calling into an audio bridge makes it difficult to have successful
> >start.  By moving forward early on there is still time to finish up the power
> >point slides and any other in room issues. The client is still happy and
> >if the
> >network comes up during the meeting that is all for the better. I realize this
> >makes it more difficult for troubleshooting so we should provide as much
> >inforamtin then ensure the clients needs are met.
> >
> >Ed
>
> ===
> Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at mcs.anl.gov

--
Ed Ritenour                                                         Phone:
510-486-5754
Data Communications/ Facilities                          Pager: 510-539-1069
Network & Telecommunications Department         Fax: 510-486-7000
             Lawrence Berkeley National Laboratory
             One Cyclotron Road, Berkeley, CA. 94720
                         MS 50E-101