FW: The return of the report
Ivan R. Judson
judson at mcs.anl.gov
Tue Sep 17 13:47:27 CDT 2002
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.research-councils.ac.uk/
<http://www.research-councils.ac.uk/%A0>
http://www.escience-grid.org.uk
http://umbriel.dcs.gla.ac.uk/NeSC/general/
<http://umbriel.dcs.gla.ac.uk/NeSC/general/%A0%A0%A0>
-----Original Message-----
From: Philippe Galvez [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/aa0fbd34/attachment.htm>
More information about the ag-dev
mailing list