Conference 7.286::fddi

FDDI is the obvious answer.  It's far easier to install than broadband,
and far more efficient than MAP.

Given the number of stations you mentioned, FDDI will very easily meet the
realtime latency requirement you gave.  (At the default TTRT of 8 ms, and
with 20 stations, the worst-case transmit delay will be 160 ms.)  No special
software is required for this.

I don't understand what you mean by the "dedicated links" for voice and video.
It may well be possible to carry one or both over the FDDI, though I'd have
to see more detail to tell.

By the way, I assume there's a typo: you mentioned 512 MEGAbits/second
realtime data.  That can't possibly fit through either FDDI or broadband.
If you meant 512 KILObits/second, no problem.

	paul

    Working with Soumetty , we appreciate any input . 
    
    411.1 - you mentionned the possibility to transport audio & video
    traffic on FDDI :
    
    	- FDDI 1 defines synchronous data transfert , but how can a DEC
    	  computer use this feature to transfert video bitmap at a rate of 
    	  25 pictures/s ? It seems that some of the FDDI concepts are not
    	  yet implemented in our FDDI boards . Am I wrong ? One is likely 
    	  to wait until FDDI 2 standard is defined .
    
    	
    	- more generally , assuming you use an optic fiber link ( not 
    	  necessarily a FDDI one ) and send numeric values for video bitmaps
    	  , what kind of specific equipment do you need to connect at the
    	  other end a common analog TV set ? Does such a demodulator exist
    	  or is even current on the market ? 
    
    
    thanks . 
                                                                     

    There is an error on the throughput required in 411.0:
    The real estimations are:
    	_ 5 megabits per sec. realtime data maximum,
    	_ 20 megabits per sec. average for  non realtime data.
    	  instantaneous transfer rate may be higher of course.

                 <<< MOUSE::USER$:[NOTES$LIBRARY]FDDI.NOTE;1 >>>
                        -< FDDI - the Next Generation >-
================================================================================
Note 412.0                MORE EXPLICIT DETAILS NEEDED                No replies
TOOIS1::MIRGHANE                                     32 lines   9-DEC-1991 14:14
--------------------------------------------------------------------------------
repl to .1                                 
    
    Thanks very much Paul for your helping.
    
>>> FDDI is the obvious answer.  It's far easier to install than broadband,
>>> and far more efficient than MAP.

Could you be much more explicit here and give us the pro and cons of each 
    solution in order to see why fddi should be easier to install and more
    efficient.

 
>>> Given the number of stations you mentioned, FDDI will very easily meet the
>>> realtime latency requirement you gave.  (At the default TTRT of 8 ms, and
>>> with 20 stations, the worst-case transmit delay will be 160 ms.)  No special
>>> software is required for this.

    How can we justify the maximum of 160 millisecondes (I suppose this is what we
    get at the MAC level)? This number seems to come from 20*8 ms.
    What about Token loss management? 
    Is there a document that specifies how to calculate 
    worst case delay taking into account parameters such as TTRT and taking into 
    account the loss of the token and other non steady states 
    that may happen on the ring?
    
>>> By the way, I assume there's a typo: you mentioned 512 MEGAbits/second
>>> realtime data.  That can't possibly fit through either FDDI or broadband.
>>> If you meant 512 KILObits/second, no problem.
	right and I apologize see notes 411.3
    
    

    re:.2
       By using the newly announced DECvideo and DECaudio boards along with
    your standard FDDI board you can transmit both voide and video along
    with standard data. I've attached the DECspin Program announcement. You
    might want to check out the multimedia announcement from late Oct. for
    more details. I'm sure Paul will be able to provide you with the
    technical details of how this is possible without waiting for FDDI-II.
    
    Debbie
    

Unorderable Product Announcement: DECspin -- Digital's Sound/Picture 
Information Network Application Offering

CONTACT

Diane LaPointe, DTN 223-1327, MLO
Jack Toto, DTN 223-5871, MLO

Engineering Contact:  John Morse, DTN 223-5801, MLO

HIGHLIGHTS

o  Will allow desktop video teleconferencing using standard network 
   protocols between two or more workstations

o  Will provide for the creation and network transmission of audio and video 
   messages analogous close circuit broadcast, or phone answering machine

PRODUCT DESCRIPTION

DECspin, a layered ULTRIX software product, will be Digital's first 
application of multimedia technology that allows for the creation and 
transmission of video and audio data using standard network protocols.

Between now and January 1, 1992, DECspin will be demonstrated at the 
following events:  UNIXPO, COMDEX, DECUS, UNIFORUM and Super Computer '91.

BENEFITS

o  Full motion, true-color (24-bit) and greyscale (8-bit black & white)     
   -- Will provide for a range of picture quality through software 
   compression, picture size and variable frame rates

o  Selectable compression/decompression of video data -- Will allow for the 
   support of a wide variety of networks

o  Voice grade live audio sequences -- Will combine video and audio to do 
   integrated desktop teleconferencing

o  Transparent network transmission of live synchronized video/audio over 
   Internet and DECnet -- Will use multiple standard network protocols

o  Ability to create video/audio messages -- Will provide an answering 
   machine-like user interface.

o  Pull down menu and icon interface -- Easy to learn international user 
   interface

SPECIFICATIONS

Minimum Hardware and Software Required

o  RISC/TURBOchannel platform
o  24 - 32 MB of memory,
o  500 MB - 1 GB of local disk storage
o  DECmedia hardware (DECvideo/DECaudio)
o  Network device (FDDI is recommended)
o  Off-the-shelf video camera, handset or microphone

                            FOR INTERNAL USE ONLY
o  XMedia Tools Runtime License and ULTRIX/UWS

                            FOR INTERNAL USE ONLY
    

    Depending  upon the specifics, FDDI (1) might do the trick.  But I'd
    like to sound a word of warning:  The "marketplace" is beginning to
    look very, very hard at an alternative technology, ATM.
    
    ATM (Asynchronous Transfer Mode) is the CCITT-standard format for cell
    switching (sometimes called "fast packet", but not the same as
    "FastPacket(tm)").  It runs at different speeds (up to 620 Mbps per
    terminal defined), and supports isochronous as well as asynchronous
    connections.  It's connection-oriented and basically a physical layer
    technology; it doesnt' provide a MAC service by itself.  And it'll be
    available in public long distance networks (read:  AT&T, MCI, WilTel)
    within a year.  So it'll potentially provide "seamless" LAN/WAN
    integration (albeit bypassing your local Bell for now).
    
    Whether or not it'll be cost-competitive remains to be seen, but it
    could be.  It poses a serious threat to FDDI, especially because it's
    designed for multimedia.
    
    Digital's not ignoring it.  The Autonet II project in SRC is likely to
    support ATM.  Compared to analog-broadband, it's the way of the future
    instead of the way of the past.  I'm not trying to knock FDDI (which is
    technically a lot more robust than ATM by an order of magnitude), but
    be forewarned that there is a lot of ATM activity heating up.  (Note
    that a certain American Telephone equipment company is poised to
    release an ATM switch very soon.)
       fred