FW: Comments on the report by Alan, Harvey & Phillippe

[Ivan R. Judson]

More content on the report. Please comment soon so we can respond with a
reasonable strategy, early to offer time for questions with the folks
over there.

--Ivan

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 

> -----Original Message-----
> From: Michael Daw [mailto:mike.daw at man.ac.uk] 
> Sent: Friday, September 20, 2002 7:42 AM
> To: Sue Rogers; Stephen Booth; Phillippe Galvez; Peter 
> Clarke; Kate Caldwell; John Brooke; Ivan R. Judson; Henry 
> Hughes; Alan J. Flavell; Harvey Newman
> Subject: Comments on the report by Alan, Harvey & Phillippe
> 
> 
> Ivan Judson just e-mailed me saying he hadn't seen comments 
> on the report, so I'm including them here just so everyone's 
> got them and we all start from the same baseline. I hope that 
> Alan, Harvey and Phillippe don't mind me doing this.
> 
> Below are the relevant contents of 3 e-mails:
> * From Harvey to Tony (7th Sep)
> * From Phillippe to Tony (16th Sep)
> * From Alan to Phillippe (17th Sep)
> 
> I'm attaching the final version of the report too, just for 
> completeness.
> 
> --Mike
> 
> E-mail from Harvey to Tony (7th Sep)
> ------------------------------------
> My first impressions:
> 
> I think much of the report is well reasoned.
> However it does not quite recognize VRVS as
> a realtime infrastructure which can and has adapted
> to a number of realtime video and audio technologies,
> and continues to be the subject of very rapid
> development, keeping pace with emerging technologies.
> In this vein, VRVS version 3 is in beta, with major 
> improvements, and will be out in a month.
> 
> As the report says, VRVS runs in H.323 or Mbone
> modes, but also has a multi-windowing facility that
> allows one to view many sessions at once. It also
> supports MPEG2 multipoint, which is well suited
> for boardroom or other high quality use. We are
> going to implement MPEG4 as well in the near future.
> In a more general sense, we adapt VRVS to any such
> technology that has benefits. If an HDTV codec appears
> at reasonable cost (just a matter of time) we will 
> immediately go after integrating those.
> 
> As it is more than a videoconferencing technology,
> it includes a number of ways to collaborate in addition
> to audio/video:
> 
>  o Desktop sharing using VNC fom AT&T:
>      in broadcast or full-shared-control mode,
>      for application sharing, some interesting
>      forms of presentation control and demonstrations,
>      etc.
>  o Chat window with the ability to "pop" URLs
>      on all participants' screens
>  o Adaptability to other applications as needed.
>  o As a software infrastructure we are able to, and
>     have repaired the errors or omissions in implementing
>     the standards by the major vendors. We therefore
>    create interoperability where it didn't exist before.
>    Polycom is the leading example where work on the
>    part of Philippe Galvez, our chief developer, has
>    been successfully applied.
> 
> Interfacing to Access Grid should be straightforward,
> but I don't know if there is any intention to do that
> from the Access Grid side. The only limitations of the
> VRVS side of the VRVS/AG interface that is already
> implemented are those of your laptop or PC and/or
> projector.
> 
> The administrative interface for management and control
> is not mentioned, and that is much of the power of the
> system (a few people support many thousands of users).
> Of course only partners, rather than users, ever see this 
> interface and are able to evaluate its potential for further 
> development.
> 
> In anticipation of further input and feedback, I would
> like to summarize by saying that the report is most useful,
> and we would very much welcome a collaboration where
> we would learn how best to configure the working
> environments to meet the needs of the e-Science program,
> and to develop the system further where needed, for better 
> service to the research community.
> 
> As you may know our
> team is small and growing, and we are encountering an 
> increasing number of situations where we are forming 
> partnerships with small national efforts to deploy and/or 
> further develop VRVS. We would particularly welcome such an 
> effort and/or partnership in the UK associated with the 
> e-Science program, which would represent the first major 
> example of its kind, and have a unique synergy with our 
> efforts on both sides targeted at collaboratice environments 
> for "Grid Enabled Data Analysis".
> 
> Best regards
> Harvey
> 
> E-mail from Phillippe to Tony (16th Sep)
> ----------------------------------------
> 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.
> 
> E-mail from Alan to Phillippe (17th Sep)
> ----------------------------------------
> 
> Philippe,
> 
> Mike Daw has asked that he should co-ordinate the issues 
> which you bring up in your mail, and this mail is _not_ meant 
> to replace that. However, as the person most closely 
> associated with the VRVS in the authoring team, I do feel 
> that I owe you some kind of explanation, so here goes.
> 
> First of all, it was no secret from Mike that I was unhappy 
> with the structure of the chapters as they had been 
> pre-planned, but it appears that this structure was not open 
> to discussion.  I was asked to concentrate on VRVS in a 
> studio situation (which I did to the best of my ability) but 
> I was not the author of the Interworking chapter which was 
> where, I would say, the particular interests of our own (HEP) 
> user community lie. I was also interested to note at the 
> recent PPNCG[1] the views of the astronomers on the issue 
> (and Mike will have heard from Pete Clarke about that).
> 
> Then I found quite a lot of misconceptions about the VRVS 
> amongst the author team as a whole.  I did my best to 
> clarify; however, I can see that this wasn't completely effective.
> 
> Finally, some technical points which had been identified in 
> discussion appear to have landed up in the report in rather 
> vague terms which then are capable of misinterpretation.
> 
> Now to those specific points on which I think I can usefully comment:
> 
> 
> On Sun, 15 Sep 2002, Philippe Galvez wrote:
> 
> >     o 2.1: Technically speaking, I don't understand the 
> planned usage 
> > of openMCU to enable interoperability between H.323 and AG.
> 
> As far as I understood the motivation here, it was to achieve 
> transcoding between different audio codecs.  At the moment, 
> it's not possible for an H.323 user on a limited-bandwidth 
> connection to participate, as the AG uses a high-bandwidth 
> audio channel.  It may have been a mistake to include only 
> one technical solution, implying perhaps that it was the only 
> one when in fact it was not.  See also the following item...
> 
> > First of all, VRVS has done it -- completely.
> 
> How would transcoding be achieved, please?  We were aware 
> that this is possible with a number of software packages, but 
> were under the impression that the VRVS as currently operated 
> wanted to use G711u only.
> 
> >     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.
> 
> I think it was clear to us that the technical solution was 
> already very close, but it would still need roll-out of the 
> gateway(s), and identifying and resolving issues which arise 
> (how _does_ the VRVS cope with the fact that audio and video 
> are at different IPs on an AG station? I was under the 
> impression that in vic/rat mode the software pre-supposed 
> that web browser, vic and rat were all running at the same IP 
> address?).
> 
> > Something that people didn't get is that  the current 
> AG/VRVS Gateway 
> > has never been in the "Funded Tasks development list".
> 
> But I think that was the motivation of recommending that the 
> UK community provide some effort to roll out whatever 
> resources we need to support this.
> 
> > This is just one of several examples where people do not 
> quite realize 
> > the potential of our realtime software infrastructure,
> 
> I won't contest that point...
> 
> > and conversely assume
> > limitations in the VRVS system that don't exist.
> 
> Except that we were familiar with the currently-available web 
> interface.  We also had your group's future proposals, but 
> also wanted to recommend that we put up the necessary 
> resources for the developments that we wanted.
> 
> > 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.
> 
> I'm not at all sure what is your point of disagreement here, sorry.
> 
> >    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.
> 
> I can't deny that, as worded, the statement is in error. 
> "Impractical" or "inconvenient" (with the currently-available 
> web interface) might have described the situation better.  Or 
> was there a solution of which we were unaware?
> 
> > And the solutions proposed do not take in account the current 
> > technique used in the gateway.
> 
> I believe the statement was referring to an AG station 
> _participating in_ the VRVS, like any other VRVS station, 
> rather than via any kind of gateway.  As I say, the practical 
> problem is that when the vic or rat button is pressed on the 
> web page, it tries to start the applications on the node (IP 
> address) where the web browser is running.
> 
> > 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.
> 
> This is one of a handful of places where I had been 
> uncomfortable with the fact that the report seemed to be 
> proposing one specific technical solution, whereas it should 
> better have identified the problem, mentioned that a 
> technical solution seemed entirely practical, and recommended 
> further study.  (Including, of course, asking the relevant 
> people such as yourself!).
> 
> [snip...]
> 
> >     o 3.7 H323: Here it is not mentioned that H.323 devices 
> are very 
> > sensitive to packet loss.
> 
> This point is made explicit in 7.7, but indeed doesn't seem 
> to appear in quite those terms in 3.7 (which speaks vaguely 
> of "bandwidth issues" and mentions "call dropouts", but 
> doesn't directly mention the impairment of ongoing sessions 
> when packets are lost)
> 
> [snip...]
> 
> >     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".
> 
> This again, I believe, was referring to the fact that video 
> happens on one node at one IP address, while audio happens on 
> a different node at a different IP address.
> 
> >     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..
> 
> I see your point, but I think it's only fair for the users to 
> regard the VRVS as a complete offering, including the 
> characteristics and limitations of whatever the current 
> offering might be - even though, as you say, the 
> infrastructure is adaptable enough to accommodate other modes 
> of use according to demand and available development effort.
> 
> > Once again this is a failure to understand that VRVS is not 
> a client 
> > application,
> 
> Of course, the client applications *with which the users are 
> familiar* are substantially the same for AG as for the 
> vic/rat mode of VRVS, with just local adaptations, so it's 
> hard to understand why they would be so different, indeed.
> 
> > but rather provide the infrastructure upon which  many
> > client applications can run, and interoperate.
> 
> Point taken, but again I think it's not unfair to also see it 
> from the user's point of view, as a complete package which 
> they use from a well-known web page and with an H.323 client 
> -or- a vic/rat station (or whatever other features the web 
> page offers them).
> 
> I think the proposals in the report, even if in some cases 
> they were expressed awkwardly, were aimed at development and 
> roll-out of a package which the users could point and click 
> for their respective purposes.  If you already have the 
> development ready, then so much the better, but we would 
> surely expect our community (here I mean the UK eScience 
> community) to provide their fair share of resources towards 
> achieving that, no?
> 
> best regards
> 
> 
> [1] the networking co-ordination group of the PPARC community 
> (now covers HEP and Astronomy users in the UK).  Pete Clarke 
> is the chair.
> 
> 
> -----------------------oOo-----------------------
> Michael Daw
> Computer Services for Academic Research (CSAR)
> 
> Manchester Computing, Kilburn Building,
> University of Manchester, Manchester M13 9PL, UK
> 
> Tel: +44 (0)161 275 7026
> Fax: +44 (0)161 275 6800
> Email: michael.daw at man.ac.uk
> 
http://www.csar.cfs.ac.uk/staff/daw/
-----------------------OoO-----------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VCReport_FINAL.doc
Type: application/msword
Size: 360448 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20020920/1baa608a/attachment.doc>