FW: The return of the report
Rick Stevens
stevens at mcs.anl.gov
Tue Sep 17 13:55:36 CDT 2002
yes..
At 01:47 PM 9/17/2002 -0500, Ivan R. Judson wrote:
>
>It would be immediately helpful to generate a table that compares vrvs to
>ag 1.0, 2.0, mbone tools, and H323.
>
>--Ivan
>-----Original Message-----
>From: Michael E. Papka [mailto:papka at mcs.anl.gov]
>Sent: Tuesday, September 17, 2002 9:49 AM
>To: 'Rick Stevens'; judson at mcs.anl.gov; ag-dev at mcs.anl.gov
>Cc: Michael E. Papka
>Subject: RE: FW: The return of the report
>
>I completely agree with Rick and would like to see us get a good response
>together, I request that Bob, Terry, Tom, and myself take a look at the
>report and see where we can help out with facts to plug in to the
>response. Ivan is a bit overloaded right now and collective group can
>probably touch on a lot issues to strengthen the AG side of things. We
>want to do this because if Tony encourages the report made more widely
>available this would be a good resource for us, not to mention we want to
>help Mike's case for AGs in the UK. Mike is suppose to contact Ivan with a
>timeline but I would prefer to see us getting stuff together ASAP.
>
>Mike
>-----Original Message-----
>From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov] On Behalf
>Of Rick Stevens
>Sent: Tuesday, September 17, 2002 8:34 AM
>To: judson at mcs.anl.gov; ag-dev at mcs.anl.gov
>Subject: Re: FW: The return of the report
>
>I think it is important that we address the VRVS claims up
>front. Address the encryption stuff. AES is not breakable the way they
>claim. I think the point needs to be made on the quality and usability
>differences of the audio and video. I'd like to see this addressed very
>seriously. VRVS and AG are very different in their goals. We should not
>try to argue that VRVS is bad, but just that desktop configurations have
>limitations (severe limitations in my mind for group oriented
>activities). Get the technical details right. In these kinds of reports
>is better to go overboard in spelling out what they other guys have done
>right and then focus on what is different. Be articulate and a bit verbose.
>
>At 06:34 AM 9/17/2002 -0500, Ivan R. Judson wrote:
>>Here's the feedback. I'll be working on this in the background, but input
>>is encouraged. Clearly there is a disconnect and we have to get our
>>story straight so we can answer these questions. The nuts and bolts of
>>the issues have to support our claims, or we're wasting our and Tony's time.
>>
>>--Ivan
>>
>>
>>-----Original Message-----
>>From: Michael Daw [mailto:mike.daw at man.ac.uk]
>>Sent: Tuesday, September 17, 2002 3:24 AM
>>To: Sue Rogers; Stewart Macneill; Stephen Booth; Richard Ansorge; Paul
>>Jeffreys; Mike Giles; Mark Hayes; Mark Cavanagh; Malcolm Atkinson; Liz
>>Carver; Kate Caldwell; John Gordon; John Brooke; Jeremy Sharp; Ivan R.
>>Judson; Henry Hughes; David Salmon; David Hutchison; David De Roure;
>>David Boyd; Chris Osland; Brian Gilmore; Alan J. Flavell; Peter Clarke
>>Cc: galvez at hep.caltech.edu
>>Subject: The return of the report
>>
>>Dear team,
>>It's not over yet!
>>Below is Tony's second e-mail on the subject of the report forwarding a
>>response from the VRVS team at Caltech. (Just so you know, his first
>>e-mail said "I liked your report very much and hope we can take something
>>forward from your recommendations".)
>>So - Tony wants the report revised in light of these comments. While
>>we're at it, we should also incorporate some concerns expressed by a
>>couple of other people. Then the report can be disseminated widely, as
>>Tony says.
>>What I suggest is that those of you who are interested in helping with
>>the re-draft let me know. I'll then co-ordinate some kind of meeting to
>>discuss how to take this forward. I'd like to keep the current
>>contributors on this distribution list so that they can comment on
>>revisions and remain on the contributor list. I've cc-ed Phillippe too so
>>that he - or someone at Caltech - can be a full member of the re-draft team.
>>Please tell me if you can think of better ways forward, or have questions
>>or comments on anything related (or unrelated, for that matter).
>>--Mike
>> -----Original Message-----
>>From: Tony Hey [mailto:Tony.Hey at epsrc.ac.uk]
>>Sent: 16 September 2002 13:44
>>To: 'mike.daw at man.ac.uk'
>>Cc: Tony Hey; Ray Browne (Ray.Browne at dti.gsi.gov.uk); James Fleming; Anne
>>Trefethen
>>Subject: FW: FW: Background Document for JCSR
>>Mike
>>
>>Thanks for your note - I am forwarding some comments from the VRVS team
>>at Caltech which seem to me to have some merit! And this answers my
>>strategy as to publication - I would like your team to consider these
>>comments and produce any revisions (if necessary - but I will require an
>>answer from you to their points!) to your paper. Then we would like it
>>circulated widely. There is also every possibility that JCSR will be
>>willing to fund some of your recommendations ...
>>Best wishes
>>
>>Tony
>>
>>Professor Tony Hey
>>Director e-Science Core Programme
>>Engineering and Physical Sciences Research Council (EPSRC)
>>Polaris House
>>North Star Avenue
>>SWINDON
>>Wiltshire SN2 1ET
>>ENGLAND
>>Tel: +44(0)1793 444022 Fax: +44(0)1793 444505
>><http://www.epsrc.ac.uk>http://www.epsrc.ac.uk
>>http://www.research-councils.ac.uk/
>><http://www.escience-grid.org.uk>http://www.escience-grid.org.uk
>>http://umbriel.dcs.gla.ac.uk/NeSC/general/
>>-----Original Message-----
>>From: Philippe Galvez
>>[<mailto:galvez at hep.caltech.edu>mailto:galvez at hep.caltech.edu]
>>Sent: 15 September 2002 21:48
>>To: Harvey Newman
>>Cc: Tony Hey; Philippe Galvez; Alan J. Flavell
>>Subject: Re: FW: Background Document for JCSR
>>
>>Dear Tony,
>>
>>Harvey and I went over the document and made additional comments. I hope
>>you will find it useful and constructive. feel to contact us for more
>>detail. I will be glad to discuss any topics that you will find
>>appropriated.
>>
>> Regards,
>> Philipps
>>
>>cc: Harvey Newman, Alan Flavell
>>
>>------------------------------------
>>
>> o My first comment concerns the list of contributors. I see on the
>>list Ivan Judson (from ANL/AG, AG's architect) and Jim Miller from
>>InSORS. In this regard, I am a bit surprised that the people preparing
>>the report didn't contact us directly if they wanted a balanced
>>evaluation, while avoiding technical errors and misconceptions.
>>Hopefully, Alan Flavell contributed to the VRVS parts as he is one
>>person who understands for the most part what VRVS is.
>>
>> o The executive Summary is good.
>>
>> Comments by Section follow:
>>
>> o 2.1: Technically speaking, I don't understand the planned usage of
>>openMCU to enable interoperability between H.323 and AG. First of all,
>>VRVS has done it -- completely. Second, it is definitely not the right
>>technical solution. I already informed the AG guys about it but looks
>>like they want to insist on using it without first understanding the
>>openMCU architecture and its limitations..
>>
>> o 2.4: The interoperability between AG and VRVS is already done. The
>>further deployment of AG/VRVS in UK and other countries could be done
>>easily, as well as full support for more AG virtual venues.
>>Something that people didn't get is that the current AG/VRVS Gateway
>>has never been in the "Funded Tasks development list". We simply did it:
>>because there was a need, and because our architecture was flexible
>>enough so that we were able to do it with minimal resources. This is
>>just one of several examples where people do not quite realize the
>>potential of our realtime software infrastructure, and conversely assume
>>limitations in the VRVS system that don't exist.
>>In this case if people think that VRVS/AG gateway improvements are
>>needed right now, then we could do it in return for a moderate amount of
>>funding -- to improve the gateway GUI, to deploy it, and to provide a
>>bit of support. The funding is only needed because we would have to push
>>other tasks on our long in-progress development list; or (better) we
>>would take on another engineer to keep all of our milestones (including
>>the VRVS/AG ones) on schedule.
>> o 2.4: I don't understand "It is not possible for an Access Grid to
>>participate in a VRVS session". This is not true. And the solutions
>>proposed do not take in account the current technique used in the
>>gateway.
>>It would be better to ask us is there is a presumed problem: (a) to
>>find out if it is already done, (b) to allow us to propose solutions,
>>which in the great majority of cases will be quite straightforward for
>>us.
>>
>> o 3.4, H.323/H.320: These are Not broadcast quality as mentioned
>>here. CIF (352 X 288) is half the resolution of broadcasts. In
>>continuous presence (4 videos on a screen) one has QCIF for each video
>>which is 4 times less resolution per video than broadcast.
>>
>> o 3.7 AG: A solution purely multicast based is surely not "the only
>>fully scalable solution for large-scale collaboration" as it is
>>mentioned in the report. It has been demonstrated since the early
>>1990's that the opposite is true. In contrast, it has been recognized
>>(e.g. at high performance network meetings organized by DOE this Summer)
>>that using unicast tunnels where needed to interconnect mulitcast
>>domains is demonstrably scalable. This is why VRVS has spread to 60+
>>countries, and precisely why VRVS is architected the way it is.
>> The claim that pure multicast is scalable in this section is in
>>contradiction with the following sentence, that mentions that it will
>>take few years for having all UK academic LANs with multicast
>>capability. We must point out that multicast at network level, with
>>large TTL is now considered dead by leading experts such as Linda
>>Winkler and Matt Matthis. VRVS's unicast tunnels inter-connecting
>>multicast domains has been recognized as the "obvious" globally
>>scalable solution; in contrast to what is said in this report.
>>
>> o 3.7 H323: Here it is not mentioned that H.323 devices are very
>>sensitive to packet loss. The adaptive/predictive protocols used by
>>H.323, while bringing higher interactivity and quality per unit
>>bandwidth, also are more sensitive to persistent "artifacts" on the
>>screen. Especially if packet loss is above a few tenths of one percent.
>>
>> o 3.9 AG: An ACL list do not provide a secure way to operate.
>>Multicast is definitely not the best technique for providing security
>>since almost anyone on the network can sniff the packets. In this
>>particular case, the only solution is encryption from the applications
>>and today this could be done via the Mbone tools (Vic/Rat). This is not
>>particular to the AG, but only related to the Mbone tools. In addition,
>>the encryption provided in the Mbone tools is very basic, and anyone
>>enough competence will be able to decrypt it.
>>
>> o 3.13: I don't understand what is meant by "The AG configuration
>>applied at the e-Sciences Centers makes them unsuitable for VRVS
>>conferences". Are the AG nodes there different from all the other AG
>>nodes elsewhere; if so, in which ways ?
>>
>> o 5.2: I am surprised by the cost for the AG. Platinum 30,000 LS
>>(UK), One could equip a whole site with desktop cameras !.
>> o 8.1: Again, we see an incorrect comparison of VRVS (a realtime
>>software infrastructure integrated with many clients) with the
>>application tools themselves: Netmeeting, QT, CUSeeMe,...etc.. Once
>>again this is a failure to understand that VRVS is not a client
>>application, but rather provide the infrastructure upon which many
>>client applications can run, and interoperate. It is like comparing
>>Cisco routers and the Cisco IOS software, with FTP or Telnet.
>>
>>-----------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>**********************************************************************
>>Internet communications are not secure and therefore EPSRC
>>does not accept legal responsibility for the contents of this
>>message. Any views or opinions presented are solely those
>>of the author and do not necessarily represent those of EPSRC
>>unless otherwise specifically stated.
>>
>>All EPSRC staff can be contacted using Email addresses
>>with the following format: 'firstname'.'lastname'@epsrc.ac.uk
>>**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20020917/ce96bad2/attachment.htm>
More information about the ag-dev
mailing list