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 inter- server 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

ISP netcasting

Linked individual sites

Co-operation agreements

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 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 - RFC Multicasting - RFC 1112 (scit web site) rtsp - RFC 2326 from 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