SATP A TRANSPORT PROTOCOL FOR ATM-INTRANETS

Transcription

1 A TRANSPORT PROTOCOL FOR ATM-INTRANETS Axel Böger, Martina Zitterbart Institute of Operating Systems and Computer Networks Technical University of Braunschweig, Germany fboeger j zitg@ibr.cs.tu-bs.de Joachim Sokol Siemens AG ZT IK 2, D Munich, Germany joachim.sokol@mchp.siemens.de Abstract This paper proposes a new transport protocol, namely (Simple ATM Transport Protocol), designed for ATM based Intranets. It is adapted to the specific characteristics of ATM and can be used transparently from any application as an alternative to, which is known to not suit well over ATM. Transparent means that the use of does not require any modification and recompilation of applications, which can benefit from the better performance of in case of ATM-based Intranets. Beside the implementation and integration of the protocol, some perfromance results are presented. Keywords: /IP over ATM, ATM based Intranet, Support, System Integration 1. Introduction The reliable transport protocol is one of the central protocols within the Internet world. In conjunction with IP it can be used over different networks, including ATM. However, over ATM is not the optimal protocol composition with respect to throughput and bandwidth utilization [3]. Therefore our research effort proposes a new protocol, namely, that avoids these limitations and can be used transparently in ATM-based Intranets. Transparent means that the use of does not require any modification and recompilation of applications, which can benefit from the better performance of. For this purpose a method for the transparent integration into UNIX systems has been developed thus provoding a seamless solution for both protocol stacks, see Figure 1. The co-existence of with results a communication pattern that is used for reliable intranet communication and for reliable Internet communication. The access method to is realized with the wellknown Socket API [16] with slight modification, thus offering in principle the same service as. itself resides directly on top of AAL5/ATM, see Figure 1. The paper is organized as follows. Section 2 provides an overview of performance impacts of in case of ATM, thus describing the motivation for novel approaches like. Section 3 presents the specification of in detail and Section 4 shows how this novel protocol is transparently Socket CLIP AAL5/ATM ATM Network Socket CLIP AAL5/ATM Figure 1. integration in the protocol stack. integrated in Linux. Section 5 presents performance results on selected scenarios using and. It demonstrates the benefits of in ATM based Intranet communication. Finally the study concludes with a summary on all mentioned aspects and some multicast considerations. 2. Performance impacts of over ATM Many studies show that is not well-suited for the use over ATM networks [13, 15, 5] resp. high speed networks. That particularly concerns throughput efficiency. Basic reasons for performance reduction are: window size: The maximum window size of 64 Kbyte limits the throughput due to the bandwidth-delay product and can lead to a low path utilization. A solution herefore is to implement the Window Scale option [7]. Packet size: The packet size for inter-subnet communication is restricted to 512 byte, resulting in increasing processing costs, protocol overhead and bandwidth utilisation (for 512 data bytes about 24% or 636 byte cell tax). Larger segments are possible with Path MTU Discovery [12]. Congestion control: Packet loss, caused by cell loss in an ATM switch, occur in particular with ATM-UBR (best effort) connections. Packet loss is interpreted by as consequence of a congestion. This assumption is only useful in wide area networks, not necessarily in Intranets. The slow start and congestion avoidance 1

2 mechanisms thereupon reduce the throughput drastically without any necessity. Retransmission: The detection of packet loss at the sender side is realized with timers. The coarse granularity of the timer resolution (in many implementations a -sender reacts only after 1.5 seconds) limits throughput performance. Different approaches [12, 7, 11, 8, 9] solving only parts of the described problems by increasing window and packet sizes as well as by optimizing the retransmission mechanism. An integrated solution which is also capable to make use of the ATM features is available with, which is described in the next chapter. 3. Specification Table 1 summarizes the capabilities of. Note that with no changes are necessary in the network. The minimal requirements therefore are end-systems with ATM/AAL5 interfaces and Classical IP over ATM (RFC 2225 [10]), which is necessary for IP to ATM address translation. De-multiplexing of on the receiver side of the ATM layer occurs with an appropriate indication in the BHLI (Broadband Higher Layer Information) field of the UNI signalling. This allows the co-existence of with /IP at the ATM network interface. uses SVC s with UBR service type for data transmission, since ABR is not available in most of todays systems. The use of SVC s leads to an additional ATM signalling delay. To reduce this delay, SVC s are cached for re-use. A SVC is d after a constant but configurable time-out value, similar to the mechanism in RFC is designed for use in a local ATM intranet. For this purpose no congestion control and round trip time measurement are necessary. In a local network, observations has shown, that congestion is very rare and the delay is short (< 5ms) and nearly constant. timers, therefore, are configured with constant values. Timers are needed for connection setup and to indicate loss of acknowledgements. There are no timers for retransmission of discarded data segments, which will be explicitly signalled by negative acknowledgements. A timer is used to indicate loss of negative acknowledgements at the client side. In the actual version, only endsystems in the same subnet can be connected. This is caused by the IP to ATM address resolution, which is done by Classical IP. Classical IP only supports address resolution in a logical IP subnet (LIS). This can be improved by using the NBMA Address Resolution Protocol (NARP) [6], which allows address resolution between multiple logically independent IP subnets. When an application establishs a connection, the following conditions (in this order) must be fulfilled for usage of : function ATM connection setup ATM SVC s, use of BHLI for endpoint identification connection setup implicit, bypasses IP layer connection client or server initiated ATM connection delayed, similar to Classical IP Data transportation bidirectional, uses ATM/AAL5 directly, no LLC/SNAP encapsulation Packet structure different packets for data and control messages, no piggyback Data checksums not implemented, provided by AAL5 Packet loss indication, error control simple detection and handling by sequence number comparison, ATM guarantees correct packet order Acknowledgement scheme positive cumulative and negative explicit acknowledgements Flow control sliding window, rate control Segmentation and reassembly Round trip time measurement maximum packet size is 8 Kbyte, real packet size is application dependant, no nagle algorithm, no silly window avoidance not implemented, fixed timer values Table 1. characteristics 1 The calling system must have an ATM interface card. 2 Both systems must be in the same logical subnet (LIS) and the ATM interface must belong to this subnet. 3 The ATM address of the called system must be resolved (with ATMARP) or a cached SVC to the system already exists. 4 When no SVC exists, the SVC setup with specific BHLI information field must be successful. 5 signalling on the established SVC for implicit connection setup. To prevent packet bursts, rate control with token bucket is implemented. In an ATM switch mainly traffic bursts can lead to cell loss [13]. On the other hand, when the connection starts, has no slow start phase. The traffic throughput is only limited by a fixed amount. The size of send and receive buffers is set to 64 Kbytes. This is adequate to obtain bandwidth utilization: The ping-command estimates an average round trip time of 0.5ms in our testbed (one ATM switch). With a size of 64 Kbyte the buffers are larger than the link capacity (netto bandwidth=140 Mbit/s): 64Kbyte 140M bit=s 0:5ms State Transition Diagram Meaning of the States: FINISH no real state, virtual start- and endpoint for the diagram

3 LISTENING WORKING CLOSE_WAIT passive open recv CONNECT (send CON_CONFIRM) recv SHUTDOWN (send ACK) send DATA (recv CON_CONFIRM) FINISH (recv CON_CONFIRM) (send SHUTDOWN) active open (send CONNECT) ESTABLISHING CLOSING send DATA EST_WORK Figure 2. State transitions or Timeout (send SHUTDOWN) recv ACK recv SHUTDOWN LISTENING passive open, protocol is ready to accept an incoming connection ESTABLISHING active open, connection setup to the destination EST WORK implied through implicit connection setup, data packets are sent and connection setup is not confirmed WORKING connection setup confirmed, dada transmission in both directions CLOSE WAIT passive, wait for application CLOSING active, send message, if necessary wait for acknowledgements messages: CONNECT connection setup CON CONFIRM positive or negativ acknowledgement of connection setup DATA data segment ACK positive or negative data acknowledgement SHUTDOWN connection or connection confirmation 3.2. for Transactions To stress the differences of and the typical communication of a transaction (e.g. HTTP [2]) is used to illustrate the protocol operation. A transaction is a client request followed by a server reply on the same connection. The time line diagram for a client-server transaction with is shown in figure 3. The application calls are placed at the left and right sides in figure 3. The time flow is in logical order and the client request and server reply are both smaller than the maximum packet size. With the transaction duration time for an application is shorter as with, because of implicit connection setup ( has a 3-way handshake). Another advantage is at connection shutdown. After closing a connection, this connection remains in the TIME WAIT state, which (implementation dependant) lasts seconds. In this time, the connection is blocked for a new connection setup. This functionality is not needed for. Through the connection oriented nature of ATM, packets can not be reordered and arbitrary delayed by the network. In comparison with T/ ( for Transactions, [4]) there are no advantages of under same conditions. T/ is an experimental extension to and required changes at the application layer. So T/ can not transparently substitute, as it is possible with. client function connect write read CONNECT DATA CON_CONFIRM ACK SHUTDOWN network ACK DATA SHUTDOWN server function listen accept read write Figure 3. Client-server transaction with 4. Protocol Integration A prototype implementation of has been developed and integrated in the Linux-Kernel. The implementation is based on kernel version and the ATM-on-Linux distribution version 0.31 [1]. is integrated in the part of the Linux protocol stack [14]. As depicted in figure 4, is partly connected to the above INET (Internet) Sockets. This is mainly for application data transfer. For connection setup and shutdown, has an interface to the s. When a suitable communication partner exists (see section 3), will be indirectly activated from the interface. After a successfull connection setup, will be disabled for this connection. If the connection setup has failed, control is returned to. A slight modification of a few lines of code in the sources at the entry points is necessary for switching to the protocol. Within this scheme, application calls to are handled as described in figure 5. At the initiating client side the call is first handled by, which tries to establish a connection. If fails, the connection is handled by connect. On success the connection is served by until

4 1 0 CLIP/ATMARP ATM BSD-Socket INET-Socket UDP IP Ethernet ARP Figure 4. integration into the Linux- Kernel. termination. After closing a cleanup is done in the block. At the receiving server side, the handling is more complex. The server is in the listening state and waits to accept an incoming connection. Both protocols wait concurrently for a connection setup message. If a setup message arrives, e.g., for, a new server for this connection will be created with the specific protocol. connect read/write send/recv Client connect connection setup listen connect send/recv data transport accept send/recv Server listen listen accept accept send/recv read/write Figure 5. Processing of calls in the enhanced protocol stack. Kernel 1. connect Interface Kernel/User-Space ATMARP Daemon ATM Socket Figure 6. Communication between application, kernel and daemon. This proceeding is not specific to the protocol. It can be generalized to support other transport protocols which offer the same functionality for applications as. Problems can occur when applications use specific features, e.g., urgent mode or setting of packet and buffer sizes. To simplify the kernel implementation of, time uncritical sequences are relocated in a daemon process. The management of related ATM connections is placed in this process. This affects ATM connection setup and time delayed ATM connection teardown. Figure 6 shows the communication flow between processes in case of a connection setup. The ATMARP request is also handled by a daemon process. The and the ATMARP daemon communicating indirectly through the kernel with each other. Communication between kernel and daemon processes enforces an additional delay in the endsystems, especially at connection setup. Measurements in our testbed indicate a delay in the endsystems between 8-10 ms. This time period is of particular interest for small application data sizes, e.g., as described in section 3.2. For small data sizes this is an important factor, compared to the time duration for the data transmission. In a full kernel implementation of these additional delay could be reduced to a very small amount. 5. Performance Measurement was performed in the configuration depicted in Figure 7. PC, 120 MHz Pentium, Efficient Networks ATM Adapter ATM-Switch Cisco LS1010 ATM Link 155 Mbps Figure 7. Measurement scenario. and performance is compared based on throughput measurements. For every measurement point 8 Mbyte data have been transmitted. Figure 8 shows the throughput in dependence of the application data buffer size. The size of the buffer was increased from 128 byte to 12 Kbyte in 128 byte steps. With data buffer sizes above 12 Kbyte no relevant throughput changes can be observed. reaches a maximum throughput of 106 Mbit/s compared to a throughput of 64 Mbit/s. The upper curve in figure 8 (native ATM) represents the practical maximum transmission rate between both endsystems. The illustration shows two measurements, with activated an deactivated Nagle algorithm. The Nagle algorithm collects small data segments and sents them in a single segment. The Nagle algorithm is not implemented in, which explains the low throughput for small segment sizes. The inspection of without Nagel algorithm is quite relevant, because it will be deactivated by many interactive applications (e.g., web browser or X-Window). Thus, a comparison between and without Nagle algorithm seems to be more likely to show the throughput gain of in opposite to. An interesting observation in figure 8 is the discontinuation of the curve at 8 Kbyte. This is conditioned by the

5 Throughput (MBit/s) data buffer size (KByte) ATM (nonagle) Figure 8. Throughput of and in dependence of the application data buffer size. maximum segment size of 8 Kbyte. data segments will be split into two segments for transmission and thus, the management overhead increases. This discontinuation can also be viewed at multiples of 8 Kbyte. Important for the estimation of the transmission rates of and are segment sizes under 1 Kbyte, since most application data segments are in this range. Figure 9 shows the range between 16 bytes and 1 Kbyte. shows a remarkable throughput gain compared to without Nagle algorithm. Throughput (Mbit/s) application data buffer size (kbyte) (no Nagle) Figure 9. Throughput of and under 1 Kbyte. Measurements show a duration for an ATM SVC connection setup between ms. This is an additional delay at connection setup time and will be avoided when a connection to the same endsystem has been d a short time (5 min.) before. 6. Summary In this article, a lightweight transport protocol adapted to ATM networks was introduced. The protocol design of pays attention to avoid some of the disadvantages of over ATM. Additional simplifications in the protocol functionality are achieved through the restriction on a local ATM intranet scenario. Measurements of the implementation have shown that a transport protocol adapted to ATM can get a remarkable higher throughput as. In our testbed the throughput was increased with of about 60%. In the actual version, the complete functionality is not available, namely the urgent mode. This makes useless for some application, e.g., rlogin or telnet, which uses this mode to send out-of-band data. These applications can be identified by their fixed port numbers and handled by. Another point is the simplified segmentation of application buffers, without Nagle algorithm. This decreases the efficiency of but on the other hand, many interactive applications deactivate the Nagle algorithm to avoid possible delays in the protocol stack. The integration of in the protocol stack is completely transparent for applications. offers the same transport service as and uses the same interface as. The described method for adding a novel transport protocol is not specific to. It can be extended to other protocols, e.g. transport protocols for wireless (lowspeed) links. The protocol implementation was succesfully tested with a variety of common applications, for example ftp, HTML(HTTP) and the X-Window system. References [1] W. Almesberger. ATM on Linux. May [2] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer Protocol HTTP/1.0. Internet RFC 1945, May [3] A. Böger and M. Zitterbart. over ATM performance. Siemens Technical Report, September [4] R. Braden. T/ Extensions for Transactions. Internet RFC 1644, July [5] C. Fang, H. Chen, and J. Hutchins. A Simulation Study of Performance in ATM Networks. GLOBECOM 94, November [6] J. Heinanen and R. Govindan. NBMA Address Resolution Protocol (NARP). Internet RFC 1735, Dezember [7] V. Jacobsen, R. Braden, and D. Borman. Extensions for High Performance. Internet RFC 1323, May [8] S. Kalyanaraman, R. Jain, S. Fahmy, R. Goyal, F. Lu, and S. Srinidhi. Performance of /IP over ABR Service on ATM Networks. Globecom 96, November [9] H. T. Kung and R. Morris. Impact of ATM switching and flow control on performance: Measurements on an experimental switch. GLOBECOM 95, November [10] M. Laubach and J. Halpern. Classical IP and ARP over ATM. Internet RFC 2225, April [11] M. Mathis, J. Madhavi, S. Floyd, and A. Romanov. Selective Acknowledgement Options. Internet RFC 2018, October [12] J. Mogul and S. Deering. Path MTU Discovery. Internet RFC 1191, November [13] A. Romanow and S. Floyd. Dynamics of Traffic over ATM Networks. IEEE JSAC, vol. 13 no. 4, May [14] A. Rubini. Linux Device Drivers. O Reilly, [15] S.Keung and S. Kai-Yeung. Degradation in Performance under Cell Loss. ATM Forum , April [16] W. R. Stevens. Unix Network Programming Volume 1. Prentice Hall, 1998.