Re: Is anyone actually USING IP QoS?
Oleg Tabarovsky <olg@amt.ru> wrote:
Current state of IP multicast technology development looks more and more similar to ATM stuff, both in development speed and complexity. The same end ? :-)
Yep. Simply people try to patch fundamental problems with hacks. That never worked, but then, that fact never discouraged from trying. Particularly when there's a significant population of marks who believe everything written in the trade rags.
Proper inter-domain multicast implementation will make state volume manageable.
Handwaving. How is it going to make it manageable, exactly?
In any case, L3 mcasting seems to be pretty much dead. Replicating canned content is better done with caches, and conferencing requiries real MCUs which do things like speaker selection and noise suppression.
What about broadcasting ? Caches will not help.
They particularly help in case of broadcasting, because content reuse rate is high. You can think of multicasting as of caching where each cache has zero retention time. (Caches do not have to delay delivery until the entire file/stream is loaded).
And, IMHO, any real life conferencing can pretty well live without multicast at all.
Yep. I would say it is hard to implement a useful multiparty conferencing _with_ multicasting. (Yes, i'm fed up with H.323, H.225, H.245, Q.931, RTP, G.711, G.729, CSTA, TAPI, Megaco/MGCP, and the rest of the crap). --vadim
Proper inter-domain multicast implementation will make state volume manageable.
Handwaving. How is it going to make it manageable, exactly? Just again, there is EXISTING technology, and EXISTING multimedia. I (and our customers) can get a lot of real-radio and real-video from the different sources over the world; I can see movies, CNN reports, listen to audio books, etc etc... No one of this technologies don't use Multicast in real life.
rate is high. You can think of multicasting as of caching where each cache has zero retention time.
(Caches do not have to delay delivery until the entire file/stream is loaded). Yes. For example, I ask CNN-LIVE-KING realvideo report. I get it
This meand for me (as ISP) two choices: (1) try to use existing technology and decrease traffic by unicast caching and replications - well, it can be done _step by step_, it can be done by the opaque way (just as WWW caching from the CISCO, but much more effective because there is less multimedia sources and they provide more traffic every one). The other choice is _to build yet another network - multicast network_. Note - there is nothing except switching caches common with the unicast routing and management. May be someone ask this service in future, may be not. Anyone ask RV and StreamVideo service todays. Guess, what 99% ISP prefere? On the other hand, bandwidths increases every day. I need Multicast service if I provide xDSL for the home apartments over the small city and try to replace TV by computer. May be it's our future, I do not know at all. directly, but system can cache this stream on the nearest cache server. If you ask the same report 5 minutes later, you'll get it directly from the cache. Just as WWW is cached, with the one exception - in case of LIVE stream, caching == replication. What's about LAN networks... Hmm, we have 100Mbit networks here today. We'll have 1000Mbit networks in the near future. 1 TV stream get (let's imagine) up to 128, 256, 512Kbit bandwidth. I need 1000 receivers to use 1 (one) Gigabit uplink. Today, I do not need multicasting in my LAN's - if 10 or 20 customers (I mean intranet, not Internet) ask the same live stream, they'll get it withouth the problems. Through, it the server could send packets with the _list_ of recipients, it shoudl be better. For the comparation, compare with E-MAIL. This service did not built special address space for the multicast delivering - it use multiple address records in teh message itself. Very easy and very effective.
And, IMHO, any real life conferencing can pretty well live without multicast at all.
Yep. I would say it is hard to implement a useful multiparty conferencing _with_ multicasting. (Yes, i'm fed up with H.323, H.225, H.245, Q.931, RTP, G.711, G.729, CSTA, TAPI, Megaco/MGCP, and the rest of the crap).
--vadim
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (2)
-
Alex P. Rudnev -
Vadim Antonov