1. WebMUX Multiplexing Protocol(HTTP related) Nirmala Rajaram Pranathi kaliga Swapna Nagaraj Tadafumi Ido Vakula Vura

2. AGENDA HTTP HTTP-NG Suite HTTP-NG Architecture Model WebMUX - Overview WebMUX Protocol Model WebMUX Message Structure Operation Considerations Problem Scenario Conclusion

3. HTTP Core Protocol of WWW for exchanging information on the Web HTTP/1.0 opens TCP Connection for each URI retrieved and closes connection. - Cost of packets and round trip times(RTTs) - Poor performance for small HTTP requests. HTTP/1.1 persistent connections and pipelining reduce network traffic and TCP overhead but still has many deficiencies. HTTP-New Generation(HTTP-NG) is proposed to overcome deficiencies in HTTP.

4. HTTP-NG Suite Developed as part of WWW Consortium HTTP-NG Project Subdivides HTTP into three layers- Message transport Layer, Object Message Layer and Web Application layer. TCWAIPP…..Wireless Object System and Binary Wire Protocol WebMUX Protocol TCP/IP SSL --------------- TCP/IP UDP Other Message Transport Layer Object Message Layer Web Application Layer

5. WebMUX Overview Session Management Protocol Separates the underlying Transport Protocol from the upper level Application Protocol Provides service for higher layer by taking advantage of the lower level transport layer With TCP as the underlying protocol the MUX layer helps to provide multiple connection over a single TCP/IP connection. Multiple applications can co-exist in the higher level and new applications can be added easily.

6. The Protocol Model WebMUX connection is called as a session It facilitates the communication between the initiator and the responder It supports simultaneous rendering of in-line objects

7. The Protocol Model

8. WebMUX Message Structure Two types of messages: 1) Data 2) Control Usually the messages are 32-bit or 64-bit aligned SessionID : 1) 8-bits in length 2) 0 and 1 reserved for future use 3) session IDs given by initiator are even and responder are odd 4) session IDS are reused

9. Data Message Structure

10. Control Message Structure No data and padding

11. Protocol Operation New session Establishment 1) Initialize connection 2)Sends SYN message 3)Responder sends SYN/FIN/RST

12. Continued… Session release 1) FIN message 2)Terminate connection Two ways 1)Graceful release 2)Disgraceful release

13. Problem Scenario Deadlock Scenario Initiator message larger than memory size Avoidance Exchange of credit information between initiator and responder Default credit Size 16kB per session

14. Conclusion Allow multiple protocols to be multiplexed over same TCP connection Deadlock-free, by credit based flow control scheme Simple design, high-performance, low overhead Allow connections to established in both directions The transition to future web protocols can be done easily

15. Reference http://www.ifip.org/con2000/icct2000/icct003.pdf http://www.w3.org/Protocols/MUX/WD-mux-980722.html http://www.w3.org/Protocols/MUX/ http://www.w3.org/Protocols/HTTP-NG/