FW: The return of the report

[Rick Stevens]

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/a2a03f7b/attachment.htm>