Download Streaming infrastructure

CP3397
Network Design and Security
Lecture 10
Streaming Multimedia and
Internet Broadcasting
Internet broadcasting and TV
Terrestrial and satellite TV



broadcasts to large audiences
has “economy of scale”
provides popular programmes and events
Internet broadcasting (IB)



allows small events to be broadcast
can reach small but global audience
provides low-cost, user-level broadcasting
What is out there?
Internet broadcasts (Audio and
Audio/Video) are now common practice
Some are



well-designed
easily accessible
widely available
Others are difficult to access and
view/hear
Access to IB
In general all users can access IB
shared links cause capacity shortfall
variable capacity broadcast
lowest quality at 28.8 kbps



small picture
low frame rate
low bandwidth audio
Home-based users need special attention
The home-based user
low bandwidth connection
shared links between Internet service
providers (ISPs) limit bandwidth
IB allows home user to be active in
“production” - not solely consume!
Quality of Service (QoS) is dependent
on the provider - there are few user
options
Software
Many now available



CuSeeMe/WhitePine Video conferencing
Real Networks - RealPlayer and G2
Microsoft Netshow/Netmeeting
Either


two way communication (conferencing)
one-way communication (broadcasting)
Servers
Broadcasting is generally done with
servers
Servers (Reflectors in CUSeeMe) allow


a number of users to connect to a single
source
links to other servers to reach
 larger audience
 geographically-dispersed audience
Infrastructure issues
Configuration of servers and interserver links determines QoS for
individuals
Home-based users can choose server
but a local server usually performs best
For broadcasting to be an important
tool the infrastructure needs careful
design.
Example events
Concert broadcast



Wolverhampton and Aberystwyth Universities joint
venture (concert in Machynlleth, Wales)
used CUSeeMe with reflectors in
UK (3), France, US(2), and Australia
OECD Seminar - Turku, Finland


broadcast by EUNet
linked servers in various EU countries
Infrastructure models
Various models
Each has its own application area
Choice depends upon




QoS required
Audience
Network operator participation
other factors
Single server
User
User
Server
User
User
User
ISP netcasting
Event
User
ISP domain
Server
Server
Server
Server
Users
Users
Users
Users
Linked individual sites
Event
User
Domain A
Server
Server
Domain B
Server
Server
Domain C
Users
Users
Users
Co-operation agreements
Domain A
Server
Permanent links
Server
Server
Domain B
Server
Domain C
Working practices
Event-dependent


Video/Audio need to be useable
and should account for
 small picture size
 limited bandwidth
 typical user terminal
New technical solutions may be needed
Higher bandwidth networks will help
Protocols
Current protocols are mainly not
optimised for use in broadcast
environments
Use of multicasting can help
Reservation protocols will improve QoS
Home-based users (in particular) are
reliant on many outside factors to
provide good QoS.
Real Systems
rtsp or http




rtsp - real time streaming protocol (RFC 2326)
works over TCP or UDP (and could use RTP)
uses URL rtsp://host.domain/dir/file as in http
rtsp and request channel separate



(out-of band control)
port 554 is standard
Uses Real’s Surestream encoding
Surestream (RealPlayer G2)
Embeds a number of bit-rate versions in
an encoding
Rates from 28.8 kbps up to corporate
LAN capacities
Switches rate based on network
congestion/capability

i.e. Adaptive/dynamic streaming of data
Multicasting
Depends on multicast routers (see
RFC 1112)
Routers maintain multicast groups and deliver
messages to individual hosts
Cuts down on duplication of messages except
for low-use wide-spread connections
Multicasting is useful if audience is grouped
Reservation protocol - RSVP
RSVP (RFC 2205)
Uses control messages to reserve capacity along a TCP
connection
Works with TCP/IP - IPv4 and v6
RSVP provides transparent operation through routers that do
not support it.
RSVP makes resource reservations for both unicast and manyto-many multicast applications,
 adapting dynamically to changing group membership as well
as to changing routes
RSVP is receiver-oriented,
 i.e., the receiver of a data flow initiates and maintains the
resource reservation used for that flow.
RSVP characteristics summary
RSVP is simplex, i.e., it makes reservations for
unidirectional data flows.
RSVP maintains "soft" state in routers and hosts,
providing graceful support for dynamic membership
changes and automatic adaptation to routing
changes.
RSVP is not a routing protocol but depends upon
present and future routing protocols.
RSVP transports and maintains traffic control and
policy control parameters that are opaque to RSVP.
RSVP provides several reservation models or "styles"
to fit a variety of applications.
Future use
Higher bandwidth will help but




it will be more expensive
not available to all
inter-ISP links are also factors in QoS
infrastructure and configuration is still
relevant
Wider use will use available bandwidth

so broadcasts need planning
References
RSVP - RFC2205
http://www.scit.wlv.ac.uk/rfc/
Multicasting - RFC 1112
(scit web site)
rtsp - RFC 2326 from http://www.ietf.org/rfc/rfc2326.txt
Sloane A. (1998) “Internet broadcasting
infrastructures for home-based users”
Proceedings of HCC5, Geneva.

available from module web site
Summary
Different models of broadcast infrastructure
have been proposed with different application
areas
Home-based users rely on ISPs to provide
QoS
New developments may not be the solution
Providers should develop infrastructures to
support broadcasts to (and from) homes