"Howard C. Berkowitz" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> You are touching on another subject, like MPLS control vs.
> forwarding, that the marketdroids tend to get confused. Multimedia
> does not require multicast, even though they often get lumped
> together. You are describing a a multicast applications that have
> the extra QoS requirements of multimedia, just as there are
> multimedia applications (e.g., VoIP) that have no multicast
> requirement. There are major multicast applications, such as
> financial information distribution, that have no multimedia aspects.
I've picked up the Cisco Press MPLS book, but haven't gotten a chance to
read through it yet...... But it sounds like MPLS is something I'd be very
interested in understanding.
I agree that there is a need to keep in mind that not all multicast
applications need QoS, and not all multimedia applications are multicast. I
would think, though, that if there is a digital version of our current
broadcast television system, it would be implemented via multicast (using
QoS for delivery). Although people talk alot of "video on demand", IMHO,
high quality digital video on demand at a consumer level is a long way off.
Partly because of the equipment and hardware needed to support large amounts
of VOD (i.e. servers, storage, etc) and partly due to bandwidth needs. For
VOD, each viewer will require the full bandwidth for the video, as well as
QoS to make sure it's delivered properly. At that point we're looking at
millions of separate video streams all requiring "priority" meaning the core
of the internet and even most ISPs will have to have the sheer bandwidth to
pipe all of that video realtime. At least if NBC, FOX, etc were to use
multicast to deliver the content, the back-end hardware requirements and
bandwidth requirements between the broadcaster and viewer and significantly
lower. We could even point to DSS as a precursor to this new "digital
broadcasting". They, in a sense, perform multicasting by sending a single
signal to the sat. and then multiple people receive all of the channels.
Also, the Pay-Per-View system, although "close" to video on demand is being
achieved by showing the same movie at staggered times, etc..... you see
where I'm going with that....
> In the example you cite, I would hope that the egress device at the
> bar is a router with enough intelligence to recognize that more than
> one host TV wants to join the multicast group (i.e., via IGMP). The
> router would then send out a multicast or broadcast frame for the
> group, and, with 100 Mbps or faster, I suspect the synchronization
> problem would be lost in the noise. Remember that you, as a human,
> are going to be at different distances from the various TV sets, and
> the sound from each is going to reach you at a significantly
> different time -- the speed of sound in air is far slower than the
> speed of electrons or photons on a cable. Indeed, you may experience
> different propagation times through the air and the lower tones that
> conduct through the floor.
Yeah...... that's what we were assuming is that the engress router would
know all of the clients in the group. Also that, perhaps using CGMP, the
router would hand off the multicast data to a switch that doles it out to
the clients. I understand your point about the TVs being different
distances from the listener, etc, but I still wonder that if the clients
employ some buffering technique, that a small hiccup in the stream could
cause the clients to become enough out a sync that, if someone were
positioned between two the of clients, they would get a noticable echo from
the delay. Of course, if the clients didn't utilize a buffer (played the
stream "live" from the switch), then yeah, the clients shouldn't even be out
of sync really. Aren't buffers almost always employed with multimedia
applications like this to avoid disruptions due to delays introduced
somewhere else during transit to the destination? Like a jitter butter or
something? That's where I'm thinking the sync problem would rear it's ugly
head.....
I would love to setup a test "bar" and try this stuff out! =)
Mike W.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=9705&t=9655
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
