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
• f 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
• riented 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

• f 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

• f 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

• f 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

Dynamic Adaptive Streaming over HTTP (DASH)

Conclusion:

• New technology in media streaming
• More research necessary to determine best

bitrate-selection algorithm

• Many services already adopting DASH

○ Netflix, Youtube, Amazon VOD

• Platforms becoming available

○ Smooth Streaming, OSMF

Questions?