| That reference doesn't say much about it, unfortunately.
I'd suggest you read this article:
"Desktop Meeting", Larry Palmer, Ricky Palmer, LAN Magazine,
Nov. 1991, Pg. 111.
"Video Teleconferencing brings sights and sounds to the desktop
as FDDI's ample network bandwidth supports a new kind of meeting."
Also, here's a note about FDDI-II I sent to some people a while back.
(the article it refers to is the one I mentioned above.)
paul
------------
I'd be happy to participate in this discussion, certainly.
Paul Callahan (along with the Palmer brothers and Jim Marsh) is finishing
up a trade press article on multimedia, which explains at some length
why FDDI is adequate (and indeed better) for that job than FDDI-2.
That article should certainly help answer the question.
We haven't come out to pound on FDDI-2 since that sort of action doesn't
normally get you anywhere and is likely to create an unfavorable impression.
On the other hand, I've certainly given my views on the technical aspects
of the issue whenever the opportunity came up. In a nutshell, they are:
1. FDDI-2 is incompatible with FDDI when in hybrid mode. (It is supposed to
be compatible in basic mode, but that doesn't mean much -- in basic mode
it acts like FDDI and provides exactly the same features as FDDI.)
2. The FDDI-2 standard is nowhere near done. SMT-2 hasn't even started yet;
it's at the same point where FDDI was 4-5 years ago.
3. 100 Mbit/s is too slow for uncompressed video. This means you must use
compression (such as JPEG, MPEG, or Px64) on your video data. Even if
uncompressed video would fit, it makes a great deal more sense to compress
anyway, since that gives you far less data to handle.
4. Compressed video does NOT come in a steady stream (unlike raw video).
The amount of data fluctuates as a function of picture complexity and
(except for JPEG) the amount of motion.
5. The one difference in service provided between FDDI-2 and FDDI is that
FDDI-2 adds "isochronous" service. This provides a fixed-bandwidth "pipe"
between stations. The bandwidth is reserved -- set aside -- and, if not
used, CANNOT be used by anyone else.
If you run compressed video through such a pipe, you have to make the
allocation large enough to deal with the peak demand. Given the
variability of compressed video, this means the average utilitization of
the pipe will be perhaps 20 to 40%. The rest is wasted.
6. The optimal data transmission service for this sort of traffic is PACKET
service, where other stations can make use of whatever bandwidth is left
over. In most cases, ordinary asynchronous service is perfectly adequate.
If you want to run your FDDI at extremely high loads (more accurately, at
significant overloads) without impact on the multimedia datastream, you
would use synchronous service instead. Both are available on the current
FDDI standard (FDDI-2 adds nothing here).
7. We've developed multimedia prototype implementations (these don't even
use compression yet, although they make up for that by using fairly
small pictures). These use ordinary FDDI and indeed run over standard
higher layer protocols (TCP/IP and UDP/IP). Note that there is no way
at all to run FDDI-2 isochronous channels and use currently defined higher
layer protocols -- the two just don't go together at all.
I guess that was a big nutshell... (a coconut, perhaps?)
paul
|
| FDDI-II is useful for things like encapsulating T1 carriers for voice.
But there are easier ways to run T1 carrier. Voice and some other
things need isochronous bandwidth, but it's not clear why you'd choose
FDDI-II as a way to provide it. What FDDI-II does, DQDB (802.6)
probably will do better; its isochronous service isn't done yet either,
but it has more interested parties. DQDB runs at more speeds too (it's
PMD-independent).
|