... etc.)1.1
the IEC 958 standard specifies the digital interface as carrying up to 20 bits per channel, at 32KHz, 44.1KHz or 48KHz
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... allocations.3.1
In the next version of IP, IP version 6, the address space is 16 bytes (or octets) in size, and the address space for multicast has been allocated as starting with 8 ``1'' bits. Interworking between IPv4 and IPv6 multicast address sessions is relatively straightforward compared with unicast addresses, since they are already dynamic entities, so that there are already ways for hosts and routers to interact to establish receiver membership locations.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... interface3.2
there may be some interaction with firewalls here, and this is discussed in chapter 10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... network3.3
even when this is not really the case, such as with a hub-switched ethernet, it maintains the illusion of such
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... 33.4
currently being discussed, but not yet implemented in late 1997.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... tree3.5
strictly speaking it's a reverse shortest path tree - typically the routers don't have enough information to build a true forward shortest path tree
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... based.3.6
Yes, we know telemetry could be real timeish....but we are trying to illustrate major differences clearly for now.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... reflector)3.7
CU-SeeMe is a popular MAC and PC based Internet video conferencing package that currently does not directly use IP multicast.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... 3.6Khz).4.1
This also has the effect of eliminating aliases, which are harmonic, or higher frequencies which appear at the same inter vales as the actual frequencies that we want to have in our digital signal, but more frequently.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... 140Mbps.4.2
To be more precise, the CCIR 601 standard defines a raw 4:3 rate of the full digitized TV signal as 270Mbps, including the non-visible lines, the time for interframe synch and so on. Without all this redundant information, the pure PAL and NTSC visible components can be coded uncompressed at 143 and 177 Mbps respectively.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... MIPs4.3
MIPs: million instructions per second - a common measure of CPU performance - too simple for subtle work, but good enough for back of the envelope estimates.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... recovery.5.1
There are exceptional circumstances where automatic repeat request protocols may be useful for multimedia, for instance on local area networks where the delay incurred may be tolerable. However, these are usually networks that have relatively low error rates, and FEC ma be more acceptable here too. The main specialist area where ARQ might really be needed might just be wireless LANs.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... based.5.2
Yes i know telemetry could be real timeish....but we are just trying to illustrate major differences clearly for now.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... coupled7.1
We define a tightly coupled system as one which attempts to ensure consistency at all sites. By contrast a more loosely coupled system tolerates inconsistencies, though it should attempt to resolve them in time. A very loosely coupled system will not even know the full list of conference members.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... applications7.2
Actually IVS does support audio, but has also been widely used as a pure video codec with vat as the audio tool.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... multicast7.3
or broadcast, but that is outside the scope of this document, as it does not usually provide a reverse path from receiver to sender
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... applications7.4
actually many shared workspace tools will not scale anyway, but we shall concern ourselves here with those that will
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... shift7.5
For once, we believe the use of the word paradigm is justified here, in its normal sense of ``pattern''.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... load8.1
load, in terms of messages on any particular link, state or processing power
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... scale8.2
we would like components to scale O(1). At the very worst, no component should scale worse than O(n), and even O(n) is not acceptable in some circumstances.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... available.8.3
This may in fact be a feature of the way that the application is structured in any case. For example, if the application state is the same as the effect of the sequence of messages (as is the case with a whiteboard), then it may be possible to cast a repair in terms of application state - i.e. to reconstruct a message that has the same effect as the missing one.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... networks8.4
and is it really worth video conferencing with your next door neighbour?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... will8.5
this limits the amount of storage necessary for receivers participating in a possible repair. It is derived from the fact that there are many kinds of ways to send descriptions of object locations, velocity, trajectory. Some are coded so that loss of a single message makes it hard to recover, whilst others are largely simply lists of deltas, and recovery may be reasonably easy, whilst others are explicit coordinates, and only the latest message is relevant.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... fields9.1
The use of text based protocols is still controversial. The proponents claim it provides easier design, the assumption of Least Common Denominator, the ability to use powerful tokenising tools, debugging capabilities and to easily extend via self describing fields, against slightly more complex specifications and a less efficient protocol
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... servers9.2
One of the key designers also works at Netscape...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... participant10.1
Since the voice characteristics which make voices unique are removed in compressing speech, it becomes easier to produce good copies of someone else's speech - how many times have you been mistaken for someone else on the 3 KHz telephone?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... networks10.2
Ponder the irony that the US DoD funded the design of the very open Internet...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... requests.10.3
Of course, it is a lot easier to design a scalable key distribution protocol in a symmetric capacity network such as the current day Internet, than in an asymmetric system such as the current day cable TV net, or proposed IP on ADSL and Cable Modem networks!
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... Fields.10.4
knowing what a Galois Field represents another convenient barrier to breaking such systems:-)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... tunnels.10.5
recent work is addressing this problem.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Jon CROWCROFT
1998-12-03