[AG-TECH] 'Bridge' for venue services, etc.?

Randy Groves randy.groves at boeing.com
Wed May 5 09:20:14 CDT 2004


The message may not have been as clear as I would have liked (an aside - 
what is the contraction for 'I would have'? I'd've?  I'dve?) - written in 
pieces amidst many other things going on.  And yes, I think that the 
appropriate interpretation is not bridge but proxy.  There are really two 
separate concerns.  The multicast issue will be with us as long as the 
commodity Internet doesn't supply this as a matter of course.  So making 
sure, as much as possible, that the aspects of the AG that are truly 
multicast (and I'm showing my ignorance here, but I'm assuming that this is 
mainly the audio and video, right?) can be used over some sort of 
unicast/multicast bridge.

The other issue is the addition of services.  With our security conscious 
world, and especially behind corporate firewalls, there is a definite 
problem with additional ports.  And there is even a growing concern with 
the overloading of port 80, and the possiblility of problems with web 
services.  In one document, I think the AGEP about firewalls, there is a 
statement that the venue client need not accept incoming packets on the 
8000/2/4/6 ports, but there will be a loss of some of the collaborative 
richness.  I guess my concern is that there not be a proliferation of ports 
that fit into this category.  I haven't even started the process of 
discussing breaching our official corporate firewall to allow AG sessions 
between external and internal sites.  I will have a significant problem 
convincing the powers that be that the 8000/2/4/6 regime is acceptable, let 
alone the fact that we will also have to bridge.  (If this becomes an 
acceptable tool, then it is feasible that Boeing might create its own 
external bridge).

That is why the idea of a proxy for the potentially many ports.

Hope that clears up my previous note.

-randy

At 06:31 AM 5/5/2004, Ivan R. Judson wrote:

>There are multiple facets needed to answer your question; let me try to
>catch as many as I can. First let me try to break apart what you're asking
>about to see if I can capture it correctly. You're mentioning multicast and
>firewalls, and concerned about users who need to work around issues related
>to them. Additionally the use of 'Bridge' in your subject line is not a like
>we've ever used the word before, it's really a proxy, right?
>
>If these assumptions are correct, I can answer your questions pretty easily.
>
>--Ivan
>
> > -----Original Message-----
> > From: owner-ag-tech at mcs.anl.gov
> > [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Randy Groves
> > Sent: Wednesday, May 05, 2004 8:25 AM
> > To: ag-tech at mcs.anl.gov
> > Subject: [AG-TECH] 'Bridge' for venue services, etc.?
> >
> > I'm looking into the future here, and wondering how many of
> > the new services that might be coming down the pike are going
> > to fit into the
> > 8000,2,4,6 port scheme of the Venue Server/Client as it is
> > presently designed.  I know that on the top end of all this,
> > the fact that some of the participants are
> > multicast-challenged will mean that they just lose out on
> > some of the newest features.  If the participants are
> > multicast-challenged and firewall-challenged (behind a
> > restrictive firewall, with a long process to go through
> > before changes can be made, long security justifications for
> > just opening up any port in the first place, etc.), I see
> > them potentially falling further and further behind.
> >
> > What is the priority, when design decisions are made, as to
> > what emphasis is placed on making sure that these situations
> > are dealt with?
> >
> > Is there a possibility of a venue service proxy in the future?
> >
> > -randy
> >
> >
> >






More information about the ag-tech mailing list