Implementation and Performance Analysis of a UDP Binding for SOAP

Master Thesis Presentation Implementation and Performance Analysis of a UDP Binding for SOAP Fahad Aijaz [email_address] Supervised by: Prof. Dr. -Ing. B. Walke Dipl.-Ing. Guido Gehlen Chair of Communication Networks RWTH Aachen, Germany Wednesday, February 8, 2006

Presentation Agenda

Motivation (“Why?“)

Proposed Solution (“What?“)

Simple Object Access Protocol (SOAP) & Middleware Architecture

Mapping to OSI Reference Model

Unreliable and Reliable UDP Binding

Mobile Web Service Server Architecture

Performance Analysis

Analytical Model

Theses

Summary & Outlook

End of Presentation

1: Motivation REASON: Since HTTP and TCP are not designed for a mobile environment

The congestion control, connection establishment (3-way handshake)

and slow-start phase of TCP effect high latencies in mobile

communication networks.

 In a mobile network, the latency of a SOAP RPC call is high. REASON: If SOAP is used by the application, the remote procedure calls (RPCs) will be transmitted in the majority of cases within the slow start phase of the TCP connection.

UDP is a mandatory requirement for the multicast/broadcast communication for applications related to Web Service Discovery.

One example is UPnP home networking and mobile services.

To provide a supliment for default HTTP binding in mobile network but

with better performance.

The use of XML Web Services over standard Internet protocols and mobile communication systems is veryinefficient.

Reliable Unreliable

2: Proposed Solution  UDP Binding for SOAP should be developed which avoids the problems of TCP.

Since UDP is an unreliable protocol an additional

reliability protocol shall be implemented in the UDP SOAP

Binding.

Session management has to be specified and developed using the

SOAP specification and Web Service Addressing.

HTTP Server shall be extended with the additional functionality of UDP Server.

UDP client and server binding shall be developed.

Enable the invocation of mobile SOAP services via UDP.

3: Simple Object Access Protocol (SOAP)

The framework has been designed to be independent of any particular

programming model and other implementation specific semantics.

SOAP is intended for exchanging structured information in a decentralized, distributed environment.

SOAP uses XML technologies to define an extensible messaging

framework, which provides a message construct that can be exchanged

over a variety of underlying protocols.

Default: HTTP Our Focus: UDP

4: Web Services Based Middleware Architecture Middleware Glue (IT World) Computing (Telco World) Communication WS-Discovery, WS-Addressing, WS-Security etc. Middleware to support developers Can be bound to either session or transport layer protocols (Transport Neutral)

5: Mapping to OSI Reference Model Transport Support for Mobile and Desktop Clients Algorithm Recommendation by SOAP-over-UDP Specification Based on the unique MessageId in SOAP Messages and WS-Addressing Selective Repeat (Explicit Request) ARQ is realized by introducing additional header in UDP datagram. 3 (N) 4 (T) 5 (S) 6 (P) 7 (A) HTTP TCP IP UDP SOAP HTTP-Binding Unreliable UDP-Binding Reliable UDP-Binding SOAP Session Management SOAP Session Management ARQ

6: SOAP Message Exchange Patterns (MEP) and Service Access Points (SAP) UDP SOAP UDP-SAP Reliable Binding Unreliable Binding WS-Sec. WS-Addr. SOAP Parser Rel. One-Way SAP Rel. Req-Resp SAP Unrel. One-Way SAP Unrel. Req-Resp SAP One-Way Req-Res SOAP MEPs  Core SOAP Parser providing 4 SAPs to upper layers, by using WS-Addressing properties

6.1: Unreliable UDP (One-Way Message Exchange Pattern) SOAP receiver SOAP sender UDP-DATA request UDP-DATA indication SOAP-MESSAGE request SOAP-MESSAGE indication SOAP UDP UDP SOAP UDP datagram

Possible Use Cases

Sending multicast “probe“ messages for discovery to a control point.

Service Announcement

6.2: Unreliable UDP (Request-Respose Message Exchange Pattern) SOAP receiver (server) SOAP sender (client) UDP-DATA request UDP-DATA indication SOAP-MESSAGE request SOAP-MESSAGE indication SOAP UDP UDP SOAP UDP datagram SOAP-MESSAGE response UDP-DATA request UDP-DATA indication SOAP-MESSAGE confirm UDP datagram Message correlation

Possible Use Cases

Event Transmission (e.g. State changes)

Context Information Exchange (eg. Status, mood, location)

Realtime Information Retrieval (e.g. Positioning data)

6.3: Reliable UDP (One-Way Message Exchange Pattern) Roles are swapped for request-response MEP 1 k N j i X 1 2 2 i j k N j Segment Buffer

Possible Use Cases

P2P Instant Messaging Services

Transportation Sector (e.g. Airlines, trains, buses)

Courier Services (e.g. Address changes)

As an alternative to HTTP

Only one ACK/NACK is transmitted

7: Selective Repeat ARQ (Explicit Request)  Selective Repeat attempts to retransmit only those packets that are actually lost. Required due to packet size constraint.  Explicit NACK is sent for only lost packets.  Packet assembly is done at the receiver when all packets are received and buffered in correct sequence.  Segmentation is done by the sender in adjustable sized chunks of bytes. Seq. No. Flag S, C, E UUID UDP Headers SOAP Data Current Time [msec], IP-Addr. In HEX , Object hash code , Random Number

8: Mobile Web Service Server Architecture Server UI decoupled from the business logic. Common for both listeners.

9: Performance Analysis (Measurements) 9.1: RTT: Reliable UDP Vs HTTP Including HTTP/TCP Processing Overhead Major Selective Repeat latencies are discarded, since not comparable to low-level TCP ARQ Java performance, memory and bytecode loading time overhead exists Mean RTT of the Reliable UDP ≈ 20-25% of RTT of the HTTP (On laptop)

9.2: RTT: Unreliable UDP Vs Reliable UDP Extra time for NACK processing, additional headers ... No re-transmission in this case

9.3: Processing: Reliable UDP Vs HTTP

Request Handling

Duplicate Detection

XML Parsing

Response SOAP Headers

UUID Generation

10: Analytical Model of Selective Repeat ARQ over UDP P lost : Probability for loss of datagram n D : Number of datagrams to be send T D : Transmission time of a datagram T timeout : Timeout T NACK : Transmission time for NACK n lost : Number of lost datagrams n x : Number of datagrams except last one excluding the last one CASE: No datagram loss CASE: Last datagram lost CASE: n lost datagrams lost Mean Transmission Latency of sending SOAP over reliable UDP using selective-repeat ARQ

10.1: Comparison With HTTP Model Used Model Used Without Loss Probability With Loss Probability Model Used Model Used HTTP UDP Analytically the UDP performance ≈ 25% of the TCP Analytically the UDP performance ≈ 17% of the TCP

11: Theses  Web Service invocation over reliable UDP can be used as a substitute to the default SOAP/HTTP binding in mobile communication environment for better performance.  The reliable UDP with selective-repeat ARQ (explicit request) as a reliability mechanism is approximately 20-25% faster than the HTTP on average.  Unreliable UDP binding enables the sending of multicast probe messages in ad-hoc environments to consume and announce Mobile Web Services hosted by and to its peers respectively.  The analytical model can be used to calculate the mean transmission latency of the SOAP messages over UDP in mobile communication environment.  The analytical model has been validated against the measurements.

12: Summary & Outlook

Flow control shall be realized to avoid receiver overloading and network congestion.

Analytical model can be extended further for handling the cases of multiple retransmissions.

SOAP message compression at the Server can be integrated for smaller message sizes. J2ME compression libraries can be used.

In general, message encryption using WS-Security specification can be integrated within the middleware architecture to ensure secure message transmission. This has already been realized at ComNets.

Realization of reliable and unreliable UDP SOAP-Binding that conforms to the SOAP-over- UDP specification and in addition, enhances the recommendation.