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

[Ivan R. Judson]

Hey Randy,

I'll address this as two separate points, first multicast and second the
services issue.

With respect to multicast, we're planning on building a pretty simple set of
services that should alleviate this problem two ways; the current bridge
model will remain as a "service provider" model so that institutions with
large bandwidth and computer resources can offer services to those less
fortunate. However, to enable the more down to earth use we want to see,
we'll also be building a set of peer-to-peer services that can provide
dynamic multicast bridging. This will still be constrained by the firewall
solution, discussed next.

The firewall issue has various parts, first, we're continuing to minimize
the number of open connections required to run a full venue client --
perhaps in the future we'll have some sort of connection concentrator and
it'll only be one hole in/out to do the client -- that's not in the near
term, that's a dream/vision :-). On the server side, we'll continue to
reduce the number of holes needed to run services, however, quite honestly
this isn't a top priority for various reasons. First, the feedback we've
received is "as long as we know _what_ we need, we can put holes in",
second, sites providing services are used to this problem, and finally, the
ratio of service providers to users favors us fixing the client situation
first. That being said, someone writing a AG enabled proxy for folks who
don't have holes in place for the two holes that I can think of for the
venue client would be great, I'd love it if someone did that.

The proliferation of services and firewalls and general web services
problems are just that general web services problems. We'll have to wait and
see what the effect is and adapt to the best solution for the users. I don't
see us steering oasis, ibm, or microsoft in terms of what we want. We'll be
responsible to our user community and continue to try and insulate the users
from changes in the underlying infrastructure, while given them more and
more functionality.

I hope that helps, 

--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 9:20 AM
> To: ag-tech at mcs.anl.gov
> Subject: RE: [AG-TECH] 'Bridge' for venue services, etc.?
> 
> 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
> > >
> > >
> > >
> 
> 
> 
>