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 practiceSome are well-designed easily accessible widely available

Others are difficult to access and view/hear

Access to IBIn general all users can access IBshared links cause capacity shortfallvariable capacity broadcastlowest 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 connectionshared links between Internet service providers (ISPs) limit bandwidthIB 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 serversServers (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 inter-server links determines QoS for individualsHome-based users can choose server but a local server usually performs bestFor broadcasting to be an important tool the infrastructure needs careful design.

Example eventsConcert 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 modelsEach has its own application areaChoice depends upon QoS required Audience Network operator participation other factors

Single server

Server

User

User

User

User

User

ISP netcasting

Server

Users

Users

Users Users

User

Server Server

Server

Event

ISP domain

Linked individual sites

Server

Users

Users Users

User

Server Server

Server

Event

Domain A

Domain B Domain C

Co-operation agreements

Server

Server Server

ServerDomain A

Domain B

Domain C

Permanent links

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 neededHigher bandwidth networks will help

Protocols

Current protocols are mainly not optimised for use in broadcast environmentsUse of multicasting can helpReservation protocols will improve QoSHome-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 encodingRates 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 hostsCuts down on duplication of messages except for low-use wide-spread connectionsMulticasting is useful if audience is grouped

Reservation protocol - RSVP

RSVP (RFC 2205)Uses control messages to reserve capacity along a TCP connectionWorks with TCP/IP - IPv4 and v6RSVP provides transparent operation through routers that do not support it.RSVP makes resource reservations for both unicast and many-to-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

SummaryDifferent models of broadcast infrastructure have been proposed with different application areasHome-based users rely on ISPs to provide QoSNew developments may not be the solutionProviders should develop infrastructures to support broadcasts to (and from) homes