<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2719.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=235474014-17092002><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=235474014-17092002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=235474014-17092002><FONT face=Arial color=#0000ff
size=2>Mike</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
owner-ag-dev@mcs.anl.gov [mailto:owner-ag-dev@mcs.anl.gov] <B>On Behalf Of
</B>Rick Stevens<BR><B>Sent:</B> Tuesday, September 17, 2002 8:34
AM<BR><B>To:</B> judson@mcs.anl.gov; ag-dev@mcs.anl.gov<BR><B>Subject:</B> Re:
FW: The return of the report<BR><BR></FONT></DIV>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.<BR><BR>At 06:34
AM 9/17/2002 -0500, Ivan R. Judson wrote:<BR>
<BLOCKQUOTE class=cite cite="" type="cite"><BR><FONT face=arial
color=#0000ff size=2>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.</FONT><BR> <BR><FONT face=arial color=#0000ff
size=2>--Ivan</FONT><BR> <BR> <BR>
<DL><FONT face=tahoma size=2>
<DD>-----Original Message-----
<DD>From:</B> Michael Daw [<A href="mailto:mike.daw@man.ac.uk"
eudora="autourl">mailto:mike.daw@man.ac.uk</A>]
<DD>Sent:</B> Tuesday, September 17, 2002 3:24 AM
<DD>To:</B> 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
<DD>Cc:</B> galvez@hep.caltech.edu
<DD>Subject:</B> The return of the report<BR><BR></FONT><FONT face=arial
color=#0000ff size=2>
<DD>Dear team,</FONT>
<DD><FONT face=arial color=#0000ff size=2>
<DD>It's not over yet!</FONT>
<DD><FONT face=arial color=#0000ff size=2>
<DD>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".) </FONT>
<DD><FONT face=arial color=#0000ff size=2>
<DD>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.</FONT>
<DD><FONT face=arial color=#0000ff size=2>
<DD>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.</FONT>
<DD><FONT face=arial color=#0000ff size=2>
<DD>Please tell me if you can think of better ways forward, or have
questions or comments on anything related (or unrelated, for that
matter).</FONT>
<DD><FONT face=arial color=#0000ff size=2>
<DD>--Mike</FONT>
<DD>
<DD><FONT face=tahoma size=2>
<DD> -----Original Message-----
<DD>From:</B> Tony Hey [<A href="mailto:Tony.Hey@epsrc.ac.uk"
eudora="autourl">mailto:Tony.Hey@epsrc.ac.uk</A>]
<DD>Sent:</B> 16 September 2002 13:44
<DD>To:</B> 'mike.daw@man.ac.uk'
<DD>Cc:</B> Tony Hey; Ray Browne (Ray.Browne@dti.gsi.gov.uk); James
Fleming; Anne Trefethen
<DD>Subject:</B> FW: FW: Background Document for JCSR<BR><BR></FONT>
<DD>Mike <BR><BR><FONT size=2>
<DD>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 ...</FONT><FONT size=2>
<DD>Best wishes</FONT> <BR><BR><FONT size=2>
<DD>Tony</FONT> <BR><BR><FONT size=2>
<DD>Professor Tony Hey</FONT> <FONT size=2>
<DD>Director e-Science Core Programme</FONT> <FONT size=2>
<DD>Engineering and Physical Sciences Research Council (EPSRC)</FONT>
<FONT size=2>
<DD>Polaris House</FONT> <FONT size=2>
<DD>North Star Avenue</FONT> <FONT size=2>
<DD>SWINDON</FONT> <FONT size=2>
<DD>Wiltshire SN2 1ET</FONT> <FONT size=2>
<DD>ENGLAND</FONT> <FONT size=2>
<DD>Tel: +44(0)1793 444022 Fax: +44(0)1793 444505</FONT> <FONT
size=2>
<DD><A href="http://www.epsrc.ac.uk">http://www.epsrc.ac.uk</A>
</FONT><FONT size=2>
<DD><A href="http://www.research-councils.ac.uk/%A0"
eudora="autourl">http://www.research-councils.ac.uk/ </A></FONT><FONT
size=2>
<DD><A
href="http://www.escience-grid.org.uk">http://www.escience-grid.org.uk</A>
</FONT><FONT size=2>
<DD><A href="http://umbriel.dcs.gla.ac.uk/NeSC/general/%A0%A0%A0"
eudora="autourl">http://umbriel.dcs.gla.ac.uk/NeSC/general/
</A></FONT><FONT size=2>
<DD>-----Original Message-----</FONT> <FONT size=2>
<DD>From: Philippe Galvez [<A
href="mailto:galvez@hep.caltech.edu">mailto:galvez@hep.caltech.edu</A>]
</FONT><FONT size=2>
<DD>Sent: 15 September 2002 21:48</FONT> <FONT size=2>
<DD>To: Harvey Newman</FONT> <FONT size=2>
<DD>Cc: Tony Hey; Philippe Galvez; Alan J. Flavell</FONT> <FONT size=2>
<DD>Subject: Re: FW: Background Document for JCSR</FONT> <BR><BR><FONT
size=2>
<DD>Dear Tony,</FONT> <BR><BR><FONT size=2>
<DD>Harvey and I went over the document and made additional comments. I
hope</FONT> <FONT size=2>
<DD>you will find it useful and constructive. feel to contact us for
more</FONT> <FONT size=2>
<DD>detail. I will be glad to discuss any topics that you will find</FONT>
<FONT size=2>
<DD>appropriated.</FONT> <BR><BR><FONT size=2>
<DD> Regards,</FONT> <FONT
size=2>
<DD> Philipps</FONT>
<BR><BR><FONT size=2>
<DD>cc: Harvey Newman, Alan Flavell</FONT> <BR><BR><FONT size=2>
<DD>------------------------------------</FONT> <BR><BR><FONT size=2>
<DD> o My first comment concerns the list of
contributors. I see on the</FONT> <FONT size=2>
<DD>list Ivan Judson (from ANL/AG, AG's architect) and Jim Miller
from</FONT> <FONT size=2>
<DD>InSORS. In this regard, I am a bit surprised that the people
preparing</FONT> <FONT size=2>
<DD>the report didn't contact us directly if they wanted a
balanced</FONT> <FONT size=2>
<DD>evaluation, while avoiding technical errors and misconceptions.</FONT>
<FONT size=2>
<DD>Hopefully, Alan Flavell contributed to the VRVS parts as he is
one</FONT> <FONT size=2>
<DD>person who understands for the most part what VRVS is.</FONT>
<BR><BR><FONT size=2>
<DD> o The executive Summary is good.</FONT>
<BR><BR><FONT size=2>
<DD> Comments by Section follow:</FONT> <BR><BR><FONT
size=2>
<DD> o 2.1: Technically speaking, I don't understand the
planned usage of</FONT> <FONT size=2>
<DD>openMCU to enable interoperability between H.323 and AG. First of
all,</FONT> <FONT size=2>
<DD>VRVS has done it -- completely. Second, it is definitely not the
right</FONT> <FONT size=2>
<DD>technical solution. I already informed the AG guys about it but
looks</FONT> <FONT size=2>
<DD>like they want to insist on using it without first understanding
the</FONT> <FONT size=2>
<DD>openMCU architecture and its limitations..</FONT> <BR><BR><FONT
size=2>
<DD> o 2.4: The interoperability between AG and VRVS is
already done. The</FONT> <FONT size=2>
<DD>further deployment of AG/VRVS in UK and other countries could be
done</FONT> <FONT size=2>
<DD>easily, as well as full support for more AG virtual venues.</FONT>
<FONT size=2>
<DD>Something that people didn't get is that the current AG/VRVS
Gateway</FONT> <FONT size=2>
<DD>has never been in the "Funded Tasks development list". We simply did
it:</FONT> <FONT size=2>
<DD>because there was a need, and because our architecture was
flexible</FONT> <FONT size=2>
<DD>enough so that we were able to do it with minimal resources. This
is</FONT> <FONT size=2>
<DD>just one of several examples where people do not quite realize
the</FONT> <FONT size=2>
<DD>potential of our realtime software infrastructure, and conversely
assume</FONT> <FONT size=2>
<DD>limitations in the VRVS system that don't exist.</FONT> <FONT size=2>
<DD>In this case if people think that VRVS/AG gateway improvements
are</FONT> <FONT size=2>
<DD>needed right now, then we could do it in return for a moderate amount
of</FONT> <FONT size=2>
<DD>funding -- to improve the gateway GUI, to deploy it, and to provide
a</FONT> <FONT size=2>
<DD>bit of support. The funding is only needed because we would have to
push</FONT> <FONT size=2>
<DD>other tasks on our long in-progress development list; or (better)
we</FONT> <FONT size=2>
<DD>would take on another engineer to keep all of our milestones
(including</FONT> <FONT size=2>
<DD>the VRVS/AG ones) on schedule.</FONT> <BR><BR><FONT size=2>
<DD> o 2.4: I don't understand "It is not possible for an
Access Grid to</FONT> <FONT size=2>
<DD>participate in a VRVS session". This is not true. And the
solutions</FONT> <FONT size=2>
<DD>proposed do not take in account the current technique used in
the</FONT> <FONT size=2>
<DD>gateway.</FONT> <FONT size=2>
<DD>It would be better to ask us is there is a presumed problem: (a)
to</FONT> <FONT size=2>
<DD>find out if it is already done, (b) to allow us to propose
solutions,</FONT> <FONT size=2>
<DD>which in the great majority of cases will be quite straightforward
for</FONT> <FONT size=2>
<DD>us.</FONT> <BR><BR><FONT size=2>
<DD> o 3.4, H.323/H.320: These are Not broadcast
quality as mentioned</FONT> <FONT size=2>
<DD>here. CIF (352 X 288) is half the resolution of broadcasts. In</FONT>
<FONT size=2>
<DD>continuous presence (4 videos on a screen) one has QCIF for each
video</FONT> <FONT size=2>
<DD>which is 4 times less resolution per video than
broadcast.</FONT> <BR><BR><FONT size=2>
<DD> o 3.7 AG: A solution purely multicast based is
surely not "the only</FONT> <FONT size=2>
<DD>fully scalable solution for large-scale collaboration" as it is</FONT>
<FONT size=2>
<DD>mentioned in the report. It has been demonstrated since the
early</FONT> <FONT size=2>
<DD>1990's that the opposite is true. In contrast, it has been
recognized</FONT> <FONT size=2>
<DD>(e.g. at high performance network meetings organized by DOE this
Summer)</FONT> <FONT size=2>
<DD>that using unicast tunnels where needed to interconnect
mulitcast</FONT> <FONT size=2>
<DD>domains is demonstrably scalable. This is why VRVS has
spread to 60+</FONT> <FONT size=2>
<DD>countries, and precisely why VRVS is architected the way it
is.</FONT> <FONT size=2>
<DD> The claim that pure multicast is scalable in this section
is in</FONT> <FONT size=2>
<DD>contradiction with the following sentence, that mentions that it
will</FONT> <FONT size=2>
<DD>take few years for having all UK academic LANs with
multicast</FONT> <FONT size=2>
<DD>capability. We must point out that multicast at network level,
with</FONT> <FONT size=2>
<DD>large TTL is now considered dead by leading experts such as
Linda</FONT> <FONT size=2>
<DD>Winkler and Matt Matthis. VRVS's unicast tunnels
inter-connecting</FONT> <FONT size=2>
<DD>multicast domains has been recognized as the "obvious"
globally</FONT> <FONT size=2>
<DD>scalable solution; in contrast to what is said in this
report.</FONT> <BR><BR><FONT size=2>
<DD> o 3.7 H323: Here it is not mentioned that H.323
devices are very</FONT> <FONT size=2>
<DD>sensitive to packet loss. The adaptive/predictive protocols used
by</FONT> <FONT size=2>
<DD>H.323, while bringing higher interactivity and quality per unit</FONT>
<FONT size=2>
<DD>bandwidth, also are more sensitive to persistent "artifacts" on
the</FONT> <FONT size=2>
<DD>screen. Especially if packet loss is above a few tenths of one
percent.</FONT> <BR><BR><FONT size=2>
<DD> o 3.9 AG: An ACL list do not provide a secure
way to operate.</FONT> <FONT size=2>
<DD>Multicast is definitely not the best technique for providing
security</FONT> <FONT size=2>
<DD>since almost anyone on the network can sniff the packets. In
this</FONT> <FONT size=2>
<DD>particular case, the only solution is encryption from the
applications</FONT> <FONT size=2>
<DD>and today this could be done via the Mbone tools (Vic/Rat). This
is not</FONT> <FONT size=2>
<DD>particular to the AG, but only related to the Mbone tools. In
addition,</FONT> <FONT size=2>
<DD>the encryption provided in the Mbone tools is very basic,
and anyone</FONT> <FONT size=2>
<DD>enough competence will be able to decrypt it.</FONT> <BR><BR><FONT
size=2>
<DD> o 3.13: I don't understand what is meant by "The AG
configuration</FONT> <FONT size=2>
<DD>applied at the e-Sciences Centers makes them unsuitable for
VRVS</FONT> <FONT size=2>
<DD>conferences". Are the AG nodes there different from all the other
AG</FONT> <FONT size=2>
<DD>nodes elsewhere; if so, in which ways ?</FONT> <BR><BR><FONT size=2>
<DD> o 5.2: I am surprised by the cost for the AG.
Platinum 30,000 LS</FONT> <FONT size=2>
<DD>(UK), One could equip a whole site with desktop cameras !.</FONT>
<BR><BR><FONT size=2>
<DD> o 8.1: Again, we see an incorrect comparison
of VRVS (a realtime</FONT> <FONT size=2>
<DD>software infrastructure integrated with many clients) with the</FONT>
<FONT size=2>
<DD>application tools themselves: Netmeeting, QT, CUSeeMe,...etc..
Once</FONT> <FONT size=2>
<DD>again this is a failure to understand that VRVS is not a client</FONT>
<FONT size=2>
<DD>application, but rather provide the infrastructure upon which
many</FONT> <FONT size=2>
<DD>client applications can run, and interoperate. It is like
comparing</FONT> <FONT size=2>
<DD>Cisco routers and the Cisco IOS software, with FTP or
Telnet.</FONT> <BR><BR><FONT size=2>
<DD>-----------------------------------------------------------</FONT>
<BR><BR><BR><BR><BR><BR>
<DD>**********************************************************************
<DD>Internet communications are not secure and therefore EPSRC
<DD>does not accept legal responsibility for the contents of this
<DD>message. Any views or opinions presented are solely those
<DD>of the author and do not necessarily represent those of EPSRC
<DD>unless otherwise specifically stated.<BR><BR>
<DD>All EPSRC staff can be contacted using Email addresses
<DD>with the following format: 'firstname'.'lastname'@epsrc.ac.uk
<DD>**********************************************************************
</DD></DL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>