I tried to send this to you last week but last night I discovered it never
went out. I think it was cockpit trouble but I'd have sworn I sent it.
We are trying to create the network experiment. To do that we need some
fairly detailed information on what is going to be sent over the network
and what format, tools, protocals and techniques are going to be used.
Excerpting from your e-mail to me last month (4/20):
>Application bandwidth requirements:
>-----------------------------------
>-) Remote steering of simulations running on high-performance
> computers, in particular on the NASA/ESS testbeds
** >-) Remote interactive analysis and visualization of simulation
> data, including Virtual Reality applications
>-) Data movement and high-performance I/O
>-) Remote collaborations and video conferencing
** >-) Remote PowerWall application
>
**Are the "Remote interactive analysis and visualization..." and the
"Remote PowerWall" applications the same? If not what are the
differences? What kind of traffic will transit the network in each case?
What fromat will the data take in each case. What end location equipment
and software will be needed to view (or transmit) the data?
(Note: If viewing equipmet/software combo is different from transmitting,
please indentify for each). Will these applicaitons interact with each
other in some way or are they independent? What protocals will they be
using? (The Web site on PowerWall indicates it needs two rather powerfull
computer to run it with a HiPPPC network in between. Will there be a site
with a PowerWall where the computers that run it are located remotly?
>
>The most demanding applications are networked VR and the remote
>PowerWall.
>
>Without hardware supported image compression and decompression, the
>Remote PowerWall application demands at deast 32 MByte/sec (256 Mbs)
>sustained network bandwidth. This would require OC12 connectivity, the
>infrastructure for which is not currently in place.
>
>Since all sites are currently connected at OC3 capability, we
>propose to experiment with PowerWall hardware image compression and
>decompression to the sites included in this proposal initially,
>if OC3 is a possibility. We have already demonstrated sustained
>50-90 Mbs use of the vBNS for networked applications such as this.
On the Remote PowerWall (I may be repeating myself here) what will the
formats be before and after the compression? Will the encoder at the host
site be a saperate piece of equipment or is it a card in the computers
running the PowerWall? Does the receiving have to have a hardware decoder
or could it view a degraded image using software decoding or no decoding?
What will do the encoding and decoding? (Product name). If all of us
agreed to trial reliable multicast as opposed to unreliable, (new issue I
know) would it be possable to insert the required headers and trailers into
the bit stream during the compression / decompression process or would they
have to simply be added around the outside of every packet being
transmitted? (I.e. is the compression / expansion process a sealed "black
box" affair or is it an open archectecture that we could "play" with
[hopefully without breaking]).
The writer of this (I couldn't find the reference to who originated this)
mentions having done this on vBNS. Who in vBNS would know what was done,
when it was done, how it was done, and what type of data was transmitted?
If I were to contact him/her how would I refer to the project so that they
would know what I was talking about.
These questions should have been sent to you last week. I'm sorry for the
delay. If you could start on this right away I would greatly appreciate it?
Thank You for all your help
Shelly
************************************************************
Shelly Deixler
Senior Engineer - NREN Applications
NASA Ames Research Center
Mail Stop 233-10
Moffett Field, CA 94035-1000
USA
mailto:mdeixler@mail.arc.nasa.gov
http://www.nren.nasa.gov
650-604-1329 (voice)
650-604-3080 (fax)
************************************************************