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

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


Thanks, Ivan - that does make the situation clearer.  We're obviously not 
alone in wondering where this web services road is taking us ... ;-)

-randy

At 10:27 AM 5/5/2004, Ivan R. Judson wrote:

>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
> > > >
> > > >
> > > >
> >
> >
> >
> >






More information about the ag-tech mailing list