Application Layer Protocols Applications: communicating distributed - PDF document

Wireless Networks III: advanced concepts Hans-Peter Schwefel and Tatiana K. Madsen • Mm1 IP Mobility Support (HPS) • Mm2 Wireless TCP (HPS) • Mm3 Wireless applications, SIP & IMS (HPS) • Mm4 Ad-hoc Networks I (TKM) • Mm5 Ad-hoc Networks II (TKM) Note: Slide-set contains more material than covered hps@kom.auc.dk tatiana@kom.auc.dk in the lecture! http://www.kom.auc.dk/~hps http://www.kom.auc.dk/~tatiana Hans Peter Schwefel Page 1 Wireless Networks III, Fall 2005: MM3, Wireless Services Application Layer Protocols Applications: communicating distributed processes • ’end-user’ applications • network services Application Layer Protocols • highest layer of communication reference model • Define messages exchanged by applications • Provide an Application Programming Interface (API) • Use Transport Layer to exchange data Examples : UDP based TCP based DNS HTTP , FTP, telnet, Video Streaming SMTP, NNTP Multimedia Conferencing Hans Peter Schwefel Page 2 Wireless Networks III, Fall 2005: MM3, Wireless Services

Design principles & approaches • End-to-end principle – communication does not rely on functions in the network ASCII ↔ binary encoded protocols • – ASCII frequently easier to debug and implement – Examples for ASCII encoded: HTTP, SIP, SMTP • Separation of Control Messages and User Data – Separate connections (e.g. SIP) � out-of-band signalling – Special character sequences (e.g. SMTP) � in-band signalling – Content length encoding: control messages specify length of subsequent data messages Client-Server ↔ peer-to-peer • Hans Peter Schwefel Page 3 Wireless Networks III, Fall 2005: MM3, Wireless Services Client-Server Paradigm • Server (software process, not piece of hardware!) – Offers a service to clients – accepts connections / requests on a (well- known) port – runs continuously – Frequently starts up multiple processes to serve multiple clients • Client – Initiates contact to server (over an IP network) – process runs only as long as needed – can use any port Hans Peter Schwefel Page 4 Wireless Networks III, Fall 2005: MM3, Wireless Services

End User Services: Categorization Communication Entertainment • m-Gaming •Unified Messaging •Gambling •MMS • Voice over IP • Audio • Chat •Buddy list • Video • Conferencing •Presence configuration •Availability configuration Commerce •m-Banking Information •m-Shopping •Dynamic Info Svcs. •m-ticketing & reservations •Static Info Svcs. •m-advertisement Hans Peter Schwefel Page 5 Wireless Networks III, Fall 2005: MM3, Wireless Services Prediction: services in mobile NWs 350 300 Browsing & Download 250 Messaging Mbit/ 200 User/ Month 150 Real-Time Multimedia 100 Voice 50 (Minutes of Use x 9,6 kb/s) 0 2003 2004 2005 2006 2007 2008 � Within the next six years data and multimedia traffic will overrule voice � In 2008 Multimedia Communication will account for ¼ of mobile traffic Hans Peter Schwefel Page 6 Wireless Networks III, Fall 2005: MM3, Wireless Services

Content 1. Introduction • Application Layer Protocols, basic principles • Service categories 2. Hyper-Text Transfer Protocol (HTTP) • Properties and messages • Problems & Improvements in wireless settings 3. Video Streaming • Encoding and tranmission principles, buffering issues • Enhancements for wireless settings: layered coding, multiple description coding 4. Service Support Infrastructure • Session Initiation Protocol (SIP) • IP based multimedia subsystems (IMS) 5. Summary Hans Peter Schwefel Page 7 Wireless Networks III, Fall 2005: MM3, Wireless Services Hypertext Transfer Protocol (HTTP) • defined in RFCs 1768, 1945, 2616, 2617 • Client-Server Model – All communication (Requests, Response) uses TCP transport – Client: browser that requests, receives, and displays WWW objects – Server • Send objects in response to requests • Well-known port 80 (but others can be specified in URL) • Stateless protocol – self-contained requests – no state kept in server – augmented by the “cookies” concept (store state in clients) • Caching support – HTTP allows to retrieve file properties only (“HEAD” method) • Support for proxies Hans Peter Schwefel Page 8 Wireless Networks III, Fall 2005: MM3, Wireless Services

HTTP Requests • ASCII encoded methods to retrieve (and send) files – GET, HEAD, POST, PUT, OPTIONS, DELETE, TRACE, CONNECT • headers to transport additional information e.g. Capability selection ( client lists e.g. supported character sets, server selects one) Hans Peter Schwefel Page 9 Wireless Networks III, Fall 2005: MM3, Wireless Services HTTP Request Message: General Format • Uniform resource locator (URL) for addressing – “http://” hostname [ “:”port ] [ abs_path [ “?”query ] ] – relative URL: without the “http:// hostname” [“:”port] part • Byte-range requests – allow completion of interrupted transfers Hans Peter Schwefel Page 10 Wireless Networks III, Fall 2005: MM3, Wireless Services

HTTP Response • Content description – Markup language HTML (Hypertext markup language, RFCs 1866, 1867, 1942 ) describes structured contents – MIME notation to inform receiver about file types • in addition, receivers judge file types from file name endings Hans Peter Schwefel Page 11 Wireless Networks III, Fall 2005: MM3, Wireless Services HTTP State Information • HTTP is a “stateless” protocol – server does not maintain any request related information beyond request completion • “Cookies” can be used to store request related information in browser (RFC 2109) – “Set-cookie:” header � set cookie in browser – “Cookie:” header � browser sends cookie along with request – Cookie contains • name, value • optional: comment, domain, max. age, path, security info, version number Hans Peter Schwefel Page 12 Wireless Networks III, Fall 2005: MM3, Wireless Services

HTTP Caching and Proxies • Caching – store file locally (e.g. in client) – use local copy when same file is requested again � reduce network traffic – ageing mechanism • retrieve again only if local copy is “old” – conditional requests HTTP Server • retrieve again only if file has changed • e.g. “If-Modified-Since: Sun, 03 Jun 2001 16:12:25 GMT” Internet • server can respond with “304 Not Modified” – browser can force revalidation of page • Proxy Support – Split end-2-end client-server connection – used for performance & security reasons Proxy Proxy e.g. corporate – often combined with caching (performance) network – explicitly supported in HTTP/1.1 Hans Peter Schwefel Page 13 Wireless Networks III, Fall 2005: MM3, Wireless Services HTTP in wireless settings • Wireless links tend to show special properties, in particular – Large delays – Low throughput • Mobility can make network-internal caches and pre-fetching difficult • Wireless devices pose restrictions – User interfaces: Small screens, limited keyboards � Potential problems of HTTP transmissions -- performance / efficient use of resources -- presentation of content on mobile devices Typical transfer sizes of HTTP: – HTTP request: 100-350 byte – responses avg. <10 kbyte, header 160 byte, GIF 4.1kByte, JPEG 12.8 kbyte, HTML 5.6 kbyte – but also many large files that cannot be ignored Hans Peter Schwefel Page 14 Wireless Networks III, Fall 2005: MM3, Wireless Services

HTTP in wireless settings: Problems (cntd.) big and redundant protocol headers (readable for humans (ASCII), all state • needs to be transferred in headers) • uncompressed content transfer uses one TCP connection for each request-response pair (HTTP1.0) • – huge overhead per request (3-way-handshake) compared with the content, e.g., of a GET request – slow-start problematic • DNS lookup by client causes additional traffic & delay • Caching – quite often disabled by information providers to be able to create user profiles, usage statistics etc. – mobility can decrease network cache hit-ratios (if hand-overs to different caching devices occur) – security problems (how to use SSL/TLS together with proxy-caches?) – frequent use customized pages, dynamically generated on request via CGI, ASP, ... Hans Peter Schwefel Page 15 Wireless Networks III, Fall 2005: MM3, Wireless Services HTTP Performance Improvements Persistent Connections • Problem: Frequently retrieval of several, small embedded objects � overhead for establishment and termination of many TCP connections • Solution: More than one item transferred in one connection – HTTP/1.0: requested by “Connection: Keep-alive” header – default in HTTP/1.1 • requires specification of content length (“Content-Length” header) • for ‘dynamic’ pages: length is not known before transmission – server notifies the client • sends “Connection: close” header instead of “Content-Length” – closes the connection after transmission (see p. 4-8) Pipelining (HTTP/1.1) – send multiple GET requests (without waiting for response in between) – increase TCP efficiency for transfers of small elements – Potentially problems with servers closing connections Hans Peter Schwefel Page 16 Wireless Networks III, Fall 2005: MM3, Wireless Services