// Sorry, if it's not for nanog forum, I can drop it's address from this
I know this thread is effectively dead, but I'm just catching up and enjoyed
the discussion very much. It's NANOG so it isn't surprising there was little
discussion of the edge of the networks.
No one mentioned critical other functions for multicast and QoS: data
distribution and interactive services. The growth in broadband is putting
new services (and telephone is the simpliest) on the edge of the network.
Data distribution is a model starburst is working on. I think the demand for
it will grow exponentially.
As the broadband world grows there are real oportunities for interactive
content placed near the edge of the network. This can not be centrally
placed because of latency requirements for interactivity. The architecture
requires 1000s of servers with pratically identical data on them. It's much
like a proxy pre-fetching data. The problems is there is lots of it
(100-500G). Multi-cast on public or private net is the logical way to do get
the data there.
You areright about multimedia, but I am not sure about multicast.
Russions are saying - if you see the banner _elebhant_ on the cell with
the monkey in the zoo - don't believe to trhe banner.
Just there. Multicasting is the beautiful idea, nice banner. But look on
the real world. There is MULTIMEDIA ALREADY - I can get CNN TV, I can get
different music, I can look on the shattle lanch in real time - withouth
multicasting. There is already EXISTING MULTIMEDIA in the network -
RealVideo and StreamVideo/on/demand.
Not I have a question. No doubt, if 1000 customers ask RV stream from the
CNN, the network fail down (or exactly server refuse to do it). This mean
_this data have to be REPLICATED on the FLY_.
There is a few different ways to do such replication. One way is
MULTICASTING. It was developed for the LAN networks (because there is not
other way to replicate data over the ethernet) and it's the only way to
get multicast in the LAN if you need strong replication. But in real
life, LAN network are not bottlechecks for this multimedia - if all
RELCOM's employees ask RV CNN at once, our LAN networks can hold this
traffic withouth big problems (128Kbit * 100 = 12,8Mbit - less than 1
The other way is CACHING. Caching on the fly or caching with the short
time to live.
There is two differences between this ways. Multicasting need another
routing scheme, another address scheme, it's really ONE ANOTHER network.
Caching need... no changes for the customer, just catch request on the
fly (as WWW CACHE ENGINE by CISCO do for the WWW requests) and CACHE data
on the fly).
Now compare. One scheme need one another set of aggreements, one another
set of configurations, etc etc... It's the only way for the DENSE
MULTIMEDIA (if you need TV for the 1000 customers at one LAN at once, for
example). Another way need one more protocol (such as WWW-CACHE-CONTROL
protocol by CISCO, sorry I don't remember RFC number for it) but for some
MultiMedia requests (RealVideo and StreamVideo are enougph for now), no
aggreements, no additional configurations schemas, no changes for the
customers and/or service providers. Guess what's better.
And in real live, we have not multicast in the Internet. We have some
SHOWS, but use RVplayer or other _request and send_ systems filled up by
the information and music. And if someone propose effective cache engine
for this streams - he'll be winner, not multicasting.
Of course, no one prevent this cache engine from doing multicasting
What's about QoS - first, you need something simple oer the whole
Internet. Then you can speak about RSVP and so on - if don't WDM kill it
for this future time.