Communication and DASH Presented by: Gabriel Loewen and Vivens - PowerPoint PPT Presentation

Communication and DASH Presented by: Gabriel Loewen and Vivens Ndatinya

Communication ● Hypertext Transfer Protocol ● SOAP web services ● RESTful web services and JSON ● Ajax

HTTP: Hypertext Transfer Protocol ● Relatively simple client-server protocol ● HTTP is stateless ○ HTTP does not any concept of open connections and does not require a server to maintain information on its clients.

HTTP Connections ● Based on TCP ● Drawback in HTTP version 1.0 and older: ○ A Web document is constructed from a collection of different files from the same server. ○ Inefficient use of TCP connections ○ Non-persistent

Non-persistent vs Persistent Connections

HTTP 1.1 Pipelining

HTTP methods ● Head : Request to return the header of a document ● Get : Request to return a document to the client ● Put : Request to store a document ● Post : Provide data that are to be added to a document ● Delete : Request to delete a document

HTTP Messages HTTP Request Message :

HTTP Messages HTTP response message :

HTTP Message Headers: Examples Header Source Contents Accept Client The types of content the client can handle. Accept-Encoding Client The document encodings the client can handle Authorization Client A list of Client's credentials Last-Modified Server The time the returned document was last modified. Location: Server A document reference to which the client should redirect the request. Warning Both Information about the status of the data in a message

Problems in HTTP 1.1 ● Does not allow for graceful abortion of HTTP transactions without closing the TCP connection. ● Does not adequately support simultaneous rendering of inlined objects - part of most Web pages today. ● The lack of modularity makes the evolution of HTTP more difficult.

MUX: Transition to Future Web Protocols MUX is a session management protocol separating the underlying transport from the upper level application protocols. ● Multiplexing data streams on top of a reliable stream oriented transport. ● Support web private protocols with servers over the same connection as the HTTP conversation. ● Still a draft and part of the W3C HTTP-NG project

SOAP: Simple Object Access Protocol ● It has been the standard for communication with web services ● Main purpose: provide simple means for different parties to communicate ● Very little common knowledge between communicating entities ● Based on XML

SOAP Message Example

RESTful Web Services ● Current Predominant web service model ● Simpler alternative to SOAP and WSDL based Web services ● Easier-to-use resource-oriented model to expose services ● Yahoo, Google, and Facebook have deprecated or passed on SOAP and WSDL- based interfaces in favor of REST,

REST Four Basic Design Principles 1. Use HTTP methods explicitly ● RESTful Web services explicitly use HTTP methods in a way that follows the protocol as defined by RFC 2616. 2. Be stateless ● Statelessness improves Web service performance

REST Four Basic Design Principles 3 . Expose directory-like URIs ● The structure of a URI should be straightforward , predictable , and easily understood . ● Hierarchical URIs : http://www.myservice.org/discussion/topics/{topic} http://www.myservice.org/discussion/2008/12/10/{topic} 4. Transfer XML, Json or both ● Resource representation should be simple and human-readable

Json Object: Example { "firstName": "John", "lastName": "Smith", "age": 25, "address": {"streetAddress": " 21 2nd street", "city": "New York","state": "NY", "postalCode": 35405} "phoneNumber": { { "type": "home", "number": "212 555 1234"}, {"type": "home","number": "675 899 4000"} } }

RESTful services vs. SOAP services The goal of web services: simplifying data as much as possible without compromising security services. ● SOAP suffers from huge overhead of headers and heavy xml payloads. ● Restful services are preferred on PDA and mobile devices.

RESTful services vs. SOAP services ● No specialized web service client is needed to access REST web services. ● REST's Json objects seamlessly integrate with Javascript, python, C# , Ruby, and etc. ● REST web services with JSON have made web applications highly scalable .

Ajax: Asynchronous JavaScript and XML ● Send requests and retrieve data from a server asynchronously (in the background) without interfering with the display and behavior of the existing page. ● XMLHttpRequest ○ Load the server's response back directly back into the script. ○ Data might be received as Json, xml, html, ... ○ Alter the DOM of the currently active document in the browser window ● Responsive and dynamic web applications : Gmail, Google Maps, Facebook, and etc.

RESTful Web Services: Example Delicious: Bookmarking distributed web system has a simple REST API http://www.peej.co.uk/articles/restfully- delicious.html

Dynamic Adaptive Streaming over HTTP (DASH) ● Breaks multimedia streams into many chunks ● Each chunk has several alternative bitrates ● DASH mechanism automatically selects the appropriate bitrate based on network conditions ● Dynamic bitrate allows for smooth playback with minimal interruption

Dynamic Adaptive Streaming over HTTP (DASH) Goals of DASH: ● Decrease time spent buffering of media ● Increase QOS of streaming services ● Dynamic approach to bitrate selection ○ Previous solutions relied upon user bias

Dynamic Adaptive Streaming over HTTP (DASH) ● Specified by International Standards Organization ○ ISO/IEC DIS 23009-1 ● Specifications: ○ Client model ○ Data model ○ Protocols ○ and others...

Dynamic Adaptive Streaming over HTTP (DASH) Client model - Composed of two components ● Dash access engine ● Media engine Dash access engine: receives MPD (media presentation description), or metadata, and the media segment data. Segment is encoded as MPEG and synched to correct time in relation to overall stream

Dynamic Adaptive Streaming over HTTP (DASH) Dash client model diagram:

Dynamic Adaptive Streaming over HTTP (DASH) Data model: hierarchical format described by Media Presentation Description document Contains information regarding the time interval of the segment, along with the set of available bit rates, languages, captions, and subtitles.

Dynamic Adaptive Streaming over HTTP (DASH) MPD Diagram Notice the hierarchical nature of the structure.

Dynamic Adaptive Streaming over HTTP (DASH) The MPD is used to describe the location of the media segments. The player is responsible for reading the MPD using the DASH access engine and selecting the appropriate segment to retrieve. Client holds responsibility of ensuring QOS.

Dynamic Adaptive Streaming over HTTP (DASH) Client/Server protocol is used ● Specified in RFC 2616 Utilizes the HTTP GET method for transmission of data from server to client.

Evaluation of DASH Rate-Adaptation Saamer Akhshabi, Ali C. Begen, and Constantine Dovrolis. 2011. An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP. In Proceedings of the second annual ACM conference on Multimedia systems (MMSys '11). ACM.

Evaluation of DASH Rate-Adaptation ● DASH must adapt to the network conditions ● Many questions about adaptation process 1. How does an adaptive video react to changes in the bandwidth? 2. How fast can the player converge to the maximum bitrate available? 3. How does it handle competition between multiple players on the same link?

Evaluation of DASH Rate-Adaptation Three DASH players tested: ● Microsoft Smooth Streaming ● Netflix ● OSMF

How does an adaptive video react to changes in the bandwidth? Smooth Streaming: Conservative when switching bitrates under decreased bandwidth Netflix: Utilizes larger buffer, allows it to be less agressive OSMF: In infancy of development. Rate- adaption is faulty during experiment. Failed to adapt to network changes propery.

How fast can the player converge to the maximum bitrate available? Smooth Streaming: Bitrate switching is very frequent, causing convergence to be sporadic. Netflix: Priority on highest possible bitrate using largest buffer out of the three. But also changes bitrate very often, like Smooth Streaming. OSMF: Utilizes TCP, and fails to converge to appropriate bitrate due to additional complexity of TCP

How does it handle competition between multiple players on the same link? Smooth Streaming: Fails to provide fair bitrate between competing players Netflix: Suffers from same issues as Smooth Streaming OSMF: Favors one player. Tests indicate a failure or excessive buffering in one player

Dynamic Adaptive Streaming over HTTP (DASH) Overview ● DASH is a relatively new approach to streaming media ● Aim is to provide best QOS under fluctuating network conditions ● Current players suffer from problematic bitrate-switching algorithms. Some fail to be consistent in switching decisions