FW: The return of the report

[Bob Olson]

I'm going to start out with detailed replies to the comments; we can see
about integrating with (or using as input for)  a revision of the
document.

>     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. 

That's what the contributors section says..

>     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.. 

I think the possibly unstated requirement here is that the current VRVS
infrastructure is quite monolithic, requiring manual intervention to set
up new venue/VRVS bindings. It is also a closed-source system - I don't
know if open sources is a requirement for the UK folks. It may be the case
that for this work, a UK-specific VRVS/AG bridge might be all that is
required, and the OpenMCU work we're interested is too
computer-science-researchy. 

>     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. 

Again, perhaps the document needs to address exactly what is meant by AG
to VRVS interoperability. It is the case that when VRVS is using the mbone
tools, not H323, that the interop works fine. 

I just fired up vrvs in the lobby; it shows each individual video stream
as a seperate user - this is another interoperability difference - yes,
the streams show up, but they mean something a little different in the
AG. I also find that it is forwarding all the streams. 

>    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. 

I think perhaps what this section is addressing is the breakage of
video-follows-voice when the video is not emanating from the same host as
the audio.

 > 
>     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. 

hm. I believe the statement is nearly true as written; proprietary systems
*can* utilize broadcast quality feeds. I'm reading the polycom docs on
their VS4000, that has a 60-fields per sec product that appears to
essentially double the vertical resolution by supporting interlacing
properly.

H263 itself goes up to 16CIF, 1408x1152, though I don't know if any of the
commercial h323 systems support it. 

>     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. 

Very valid points ... (seeing as MCS internal multicast is broken
currently on the main network here, problem as yet unknown; we lost NCSA
traffic due to an Abilene router upgrade that missed a bit of
configuration, etc ..)

Perhaps the discussion needs to address the need of the network to handle
the high datarates associated with large collaborative sessions. I think
VRVS is able to get away with what it does because it does bandwidth
limiting on the traffic, at least from the AG gateway 

>     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. 

He missed the sentence that says the media data are encrypted. I also
don't buy this assertion about the basic encryption that anyone with
enough competence can decrypt it. Even with the default DES, it'd probably
take a fairly sustained effort to decrypt. With the AES encryption it'd be
much more difficult; however, we need to do the analysis to find holes in
the system other than the actual encryption (machine exploits, algorithms
for key determination and distribution, social engineering, etc).

>     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 ? 

I suspect this is the spearate audio/video machine issue.

>     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 !. 

Heh. Then you'd have 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. 

Yup, good point. VRVS can be thought of as a global application-level
multicast transport network.

--bob