Multicast status

[Tom Coffin]

Tony,
I also saw your joking comments on the mud in reference to the last
paragraph...
I find some of your comments unprofessional, unconstructive, and way out of
line.
Especially being labelled as a rouge site and your dismissal of my
inteligence 
in being able to comprehend the insurmountable technical difficulties of
enabling 
a multicast bridge.

re ACCESS agnode:
I have supported this project 100+%, sacrificed in ways you could not imagine,
and have developed the ACCESS AG node as the high-end producer of content for 
the Access Grid project. My feelings are very hurt by your unsolicited
condemnation
of me and my work to this ag-tech list. I do not believe I deserve it. 
If you have problems with me on a personal or professional level, please
address 
them to me directly.

re bridges as a backup:
From, a production perspective (one which should be addressed because the
production values up to this point have been weak at best). I was simply
stating that
bridge technologies should always be kept in hand as a possible backup
solution.

re my interest in multicast bridges:
I have no interest in creating a bridge at ACCESS for the Access Grid
project. 
I am however, interested in their technology (irregardless of your low
opinion 
of my capabilities to understand them) and again ask:
Where can I learn more information on setting up a multicast bridge?

______________________________________________
At 10:20 AM 2/9/00 -0600, Tony Rimovsky wrote:
   >Tom, please don't pursue your own bridge.  I am fairly certain that you
will
   >run into insurmountable technical difficulty getting one to work, and I
   >can't devote the resources to helping you do troubleshoot.  Setting up a
   >bridge at access-dc will increase my group's workload and be in direct
   >contradiction to what the access-grid developers are trying to accomplish.
   >There is also a good possibility that the current pipe to access-dc
couldn't
   >handle the load..
   >
   >Currently, the bridge is not simply a backup.  It discourages some of the
   >core goals of the access-grid model by allowing remote sites to be lazy
   >about dealing with multicast.  After a year of using the access-grid,
there
   >are still active sites no closer to native multicast because, in part
   >because the bridge exists.  Furthermore, the bridge confuses
   >troubleshooting, further complicating the multicast picture when something
   >does go wrong.
   >
   >There is no reason for this community to allow something as significant
as a
   >Chautauqua happen again without having put the advance effort in to make
   >sure that key sites are enabled.  Smaller impromptu events are taking a
risk
   >in relying on access-grid technology at this stage.  All it takes is
one key
   >person to be unavailable for things to break down (and that is true
even if
   >you don't use multicast.)
   >
   >Bill has outlined alternative solutions which encourage the proper
   >direction.  He has offered to help sites. I extend the same offer.
   >Particularly with the NSF, it is significant that we we get proper
multicast
   >working, either natively or using specific hardware at the remote sites.
   >
   >And, in point of fact, not every major event has required using the
bridge.
   >The recent Illinois Governor's visit is a positive example, and I
believe I
   >heard Larry describe it as the best access-grid demo yet.  As time passes,
   >the technology has improved.  Troubleshooting multicast problems is almost
   >routine now, with the bigest delays being caused by unavailable staff, not
   >mysterious technology failures.
   >
   >Final point: if the community decides that a backup mechanism is necessary
   >as a backup, then ANL should organize the implimentation, _not_ a rouge
site
   >that decides they know better.  Make your case to ANL people and the
rest of
   >the community.  If people generally think you are making sense about
   >backups, then I am sure a bridge of some sort will remain.  (They may even
   >decided it should be hosted at ACCESS!)  An open invitation was part of
the
   >propsal sent to the list on 1/27 and there hadn't been any negative
feedback
   >(other than some concern about increased $$) in response until now.  The
   >point about backups probably needs to be discussed.  Bob/Bill/Lisa, do you
   >have anything in mind with respect to a safety net?
   >
   >
   >
   >On Wed, 09 Feb 2000, Tom Coffin wrote:
   >
   >>  
   >> True, the mission of the Access Grid is to exist in a multicast 
   >> environment.  
   >> However, for large scale production events like a Chautauqua 'bridges'  
   >> should still be in place and accessible as 'backup'. (for example every 
   >> large event [sc99, chautauquas] to date has required ACCESS to switch  
   >> to 
   >> a bridge to be seen or heard. We employ telephone backups why not 
   >> network backups? 
   >> 
   >> regarding cise-nsf.gov, they currently do not have multicast enabled. 
   >> I believe they want a permanent presence on the Access Grid project.  
   >> I will touch base with the folks at NSF to see what's going on with 
   >> their becoming multicast enabled. 
   >> 
   >> Where can I learn more information on setting up a multicast bridge? 
   >> 
   >> ____________________________________________ 
   >> At 09:21 AM 2/9/00 -0600, Robert Olson wrote:  
   >> >>>> 
   >> 
   >> > In the effort to rid ourselves of multicast bridges, I thought it'd 
   >> > be good to get an update on status from folks. The following groups 
   >> > are in the bridge configs: 
   >> > 
   >> > VA Linux        Corporate folks, no working multicast 
   >> > Utah            I seem to remember you guys having working 
   >> > multicast 
   >> > Boston          Did you get your one-way multicast fixed? 
   >> > UNM             This is a work in progress, right? 
   >> > MPHCC           Also a work in progress if I recall correctly 
   >> > Kentucky        Also a work in progress if I recall correctly 
   >> > cise-nsf.gov    Tom -- this was a one-time thing, right? 
   >> > EVL/UIC As I recall, this requires a longer-term fix. Status? 
   >> > UIUC CS dept    onetime for Dan Reed I think. Anyone know status  
   >> >                 of multicast there? 
   >> > Nestor's lab    Bill, I think this is working multicast now, right? 
   >> > microsocopy.com Nestor's home. hm. 
   >> > msu.ru  Onetime demo, I think 
   >> > 
   >> > thanks, 
   >> > --bob  
   >> > 
   >> <<<< 
   >> 
   >> 
   >> 
   >> 
   >> 
   >> 
   >> ___________________________________________________________ 
   >> Tom Coffin .......................... tcoffin at ncsa.uiuc.edu 
   >> 
   >
   >-- 
   >
+-------------------------------------------------------------------------+
   > | Tony Rimovsky, Manager -- Network Development    Phone: +1 217
244-4728 |
   > | National Center for Supercomputing Applications  FAX:   +1 217
244-1987 |
   > | 605 E Springfield, Champaign IL, 61820           tony at ncsa.uiuc.edu
   |
   >
+-------------------------------------------------------------------------+
   >
   >


___________________________________________________________
Tom Coffin .......................... tcoffin at ncsa.uiuc.edu