In message
<4(_dot_)3(_dot_)2(_dot_)7(_dot_)2(_dot_)20001020083401(_dot_)03581aa0(_at_)127(_dot_)0(_dot_)0(_dot_)1>,
Harald Alvestrand typ
ed:
MBONE tunnels to connect, and a widely available (Linux?) client that would
connect to that server, and behave like a multicast router?
"start this program on a spare PC, and you too can watch the IETF multicast".
we have reflectors - what we don't have is what we talked about ever
since 1989, which is remote control of a reflector....cu-seeme has
some stuff, but we never generalized it ....
actually , the reason for not allowing auto-setup of a reflector is
the EXACT same reason ISPs dont allow IGMP at the edge is you get to
get unexpected traffic patterns on your net - normally, a sender can
only send at the rate their access link providers to someone who can
receive at simial rate (basically TCP...) a multicast can send at a
rate 1 receiver can handle, but other receivers joing the multicast
can cause traffic to clobber downstream links so we've been working
for ages to try to devise
i) adaptive audio/video schemes in avt
ii) tools that tell receivers that they might as well leave a session
in the mmusic wg (e.g. RTP monitoring )
iii) rmt wg protocols that do TCP like congestion control
(e.g. rlc and pgmcc schemes)
etc etc and more flexible models for multicast access (igmpv3)
and routing (ssm etc) to permit ISPs to manage traffic in as similar ways
as they are used to for unicast as possible...
reflectors don't sidestep any of these problems - like NATs and other
intermediaries, appplication level stuff merely introduces another
layer to manage - soem reflectors do transcode data - these seem
useful - some folks have designed application level multicast boxes
that also do things like access control, content and delivery based
billing, and also use IP multicast where available - all reasonable,
of course, and all part of the Content Distribution Net evolution....
I've been frustrated by the need to modify core routers to support
multicast properly, and the resulting reluctance of the ISPs to deploy it.
Perhaps it's time to interpret this as damage, and route around it....?
most core/tier-1 ISPs have multicast within the core...they just don't
have general access to it yet......the reasons are partly given above
its gonna change slowly...
actually, a servlet thing for a webcast/multicast/proxy (e.g. on
apache) would be v. cool....maybe we could even support gatewaysing to
netmeeting:-)
cheers
jon