SERVICE-ORIENTED PROTOCOL INTERFACES AND DYNAMIC INTERMEDIATION OF COMMUNICATION SERVICES Dirk Henrici University of Kaiserslautern, Germany
[email protected]
Abstract Nowadays, in the Internet almost solely UDP and TCP are being used as transport protocols. The reason is not that these are better than other protocols but that they became the “common denominator” of Internet communication due to historical evolution. In this paper, a service-oriented interface between applications and transport protocols is proposed and the multitude of looming possibilities is presented. As a service-oriented interface abstracts completely from lower protocols, the use of alternative protocols and further the dynamic intermediation of communication services becomes possible transparently to applications. Since today’s structures of Internet communication and the socket interface have grown over years and are thereby increasingly taken for granted, this paper will present an alternative approach applying contemporary design criteria.
Key Words communication systems, communication protocols, system architecture, communication software, services
1. Current situation The internet protocol (IP, see [1]) being published as RFC for the first time in 1980 has become omnipresent and displaced other layer three protocols like Novell’s IPX even in local networks almost completely. The transport protocols UDP (User Datagram Protocol, see [2]) und TCP (Transmission Control Protocol, see [3], [4]) that rely on IP achieved a similar monopoly. The main reason is that applications must agree upon the protocols used to be able to communicate with each other. Since the time of commencement of the Internet, UDP and TCP acted as this common denominator. Thus, the choices of an application programmer are in practice limited to exactly these two transport protocols: UDP as connection-less protocol that doesn’t ensure that
Bernd Reuther University of Kaiserslautern, Germany
[email protected]
data reach the receiver but in exchange is the fasted way to deliver data. And in contrast, TCP, working connection-oriented and offering additional functionality like flow control and ensuring that send data reach their destination. In short: UDP corresponds to “fast”, and TCP corresponds to “reliable”. An application programmer must always ponder what is more important for the given application. These alternatives, UDP versus TCP, are reflected directly in the socket interface using whom applications access transport protocols: Using Berkeley/BSD Sockets [5] as well as using the derivated Winsock-Library in Microsoft Windows [6] upon creation of a socket it can be chosen between „SOCK_DGRAM” that practically corresponds to UDP and „SOCK_STREAM” that practically corresponds to TCP. According to the choice, different functions are used in the following. Like “accept” these are not always available for both protocols. Using “setsockopt” general options and protocol-specific options as well can be stated. Though it is possible to access other protocols using the sockets interface, this is used comparatively seldom since only UDP and TCP can be assumed available at the communication peer. We find structures persisting for approximately 25 years that established as standard. Although in more than 50 RFCs improvements for TCP were proposed and partly implemented (e.g. improved heuristics like congestion avoidance, [7]) and new options introduced (like “selective acknowledgments“, [8]), high value had to be set on compatibility so that only extension could take place instead of renewal according to state of the art research. The socket interface was extended as well, most notably according to support IPv6-addresses, but for compatibility reasons never changed elementary which would be required for future communication demands [9]. Thus, nowadays an application accesses the transport protocols UDP and TCP directly, often using the socket interface. This static binding between applications and these two transport protocols is characteristically for the current situation.
2. Assessment of current situation The situation described in the last section has evolved over years and one got used to it accordingly. Nevertheless, it should be questioned critically. Starting points are on the one hand the protocols themselves with their inherent functionalities and deficiencies in functionality and on the other hand the interfaces to the protocols. Subsequently the possibility to use alternative protocols to UDP and TCP is addressed.
2.1 Protocols The main deficiencies of IP are the address fields that are too small for future demand. Aside, the large number of header fields of which some are never or seldom used and their party unfavorable alignment (e.g. 13 bit fragmentation offset) can be mentioned. In the development of IPv6 [10] the experience with IP was made use of: The address space was increased from 32 to 128 bit, the header was simplified, fields for implementing differentiated and integrated services were inserted, and flexible extension employing option headers was rendered possible. Advantages and disadvantages of both IP-protocol versions being stateless are not discussed here. UDP is a lean protocol that extends IP only by port numbers and a checksum. Thus, the amount of data that can be carried in a single datagram is limited to a maximum of 64KB minus all headers whereby not all implementations need to support datagrams of this size. If its size exceeds the maximum transfer unit (MTU) a datagram has to be fragmented by IP. The loss of a single fragment causes the loss of the complete datagram. In contrast, TCP is much more powerful and much more sophisticated, so that it cannot be discussed in a few words. XTP (Xpress Transport Protocol) is an example for a protocol that aims to offer a better and more flexible solution than TCP. Thus, in the motivation of its specification [11] TCP is eyed at critically.
2.2 Protocol functionalities Due to the fact that the basic functionality of UDP and TCP is given which often does not satisfy the requirements of an application, this basic functionality must often be extended by additionally needed mechanisms. Frequently, when using UDP, a mechanism is needed for segmenting which splits up large packets into smaller ones. Often a “reliable UDP” is required, i.e. a protocol that ensures that packets reach their destination but avoiding the complexity of TCP (like handshake and flow control). In [12], RDP is defined for this purpose, but it is implemented in hardly any operation system. Thus, in
Stevens [5] an example for an own implementation making UDP reliable is described. For many applications, one of the drawbacks of TCP is that it works stream-oriented. Delimitation between individual messages is not possible but is needed by many applications and thus has to be implemented by the applications themselves. Often required extensions like the described ones have to be implemented by each application needing them. The complexity and fault liability of an application increase thereby in an unwanted way. But re-use is generally aimed at in order to lower fault liability and to increase extensibility and maintainability [13].
2.3 Protocol-specific interfaces The socket interface is often referred to as protocol independent (see e.g. [6], [14]). This is correct only in that way that it offers an interface to protocols, which is very general and accordingly universally applicable for almost arbitrary transport protocols. That way, the adaptation to the new address space of IPv6 was possible by inserting a new address family named AF_INET6 [15]. But equating the flexibility of the socket interface with protocol independency is not correct, since one actually comes directly into contact with the protocols: As soon as functionalities of protocols which go beyond basic functions are to be accessed, programming becomes protocol specific even with the socket interface. For instance, “TCP_NODELAY” is passed to “setsockopt” to disable Nagle’s Algorithm [16]. This has the consequence that protocols and applications are closely interlocked, which contradicts today's modularity and decoupling principles and limits flexibility. Thus, partly substantial changes in the applications are required, if they are to use other protocols. Further, the rollout of new protocol versions is only possible as long as full compatibility to existing versions is maintained.
2.4 Use of “alternative” protocols As addressing scheme IP addresses became generally accepted in the Internet, alternatives like the NSAP address space of ATM have comparatively small relevance. Thus, on the network layer IP is established. Its successor IPv6 will annihilate annoying restrictions. Consequently, it can be assumed that IPv6 one day will become generally accepted as network layer protocol broadly and will perhaps attain a monopolistic position since network components will implement the processing in hardware in order to obtain highest throughput; therefore, for
protocols with comparable functionality broad support will hardly be present. On the transport layer with SCTP (Stream Control Transmission Protocol, [17]) or the already mentioned XTP, for instance, protocols are available, which would be a serious competition for TCP in many fields of application. But several obstacles get in the way of using alternative protocols: Alternative protocols are not available on every host, but can only be used if they are available with both communication partners. Otherwise, due to their general availability UDP or TCP must be employed. Since, as described above, the interface to different protocols is not uniform, an application must implement adaptation layers, via which it can address protocols uniformly. In addition, functionality must be implemented to examine whether the communication peer is reachable using alternative protocols, before the latter can be employed. Thus, both communication peers not only must have the same protocols installed but as well must check whether usability of the latter is limited on the communication path - for example by firewalls. Thus, for each application much effort is inevitable, which is worth the benefit only in few cases. Probably for this reason, UDP and TCP attained their current relevance, which they will keep under current general conditions, although for some applications protocols with higher performance or on specific requirements of the application better tailored protocols exist. Also, the interlocking of UDP and TCP with applications can be regarded as a reason for the small market penetration of ATM within the range of terminals. The higher costs cannot be made responsible for this alone, because solutions like CIF (Cells-in-frames), FUNI, or ViAA [18] were available, that made leading ATM from the edge-device or gateway, respectively, across Ethernet to the terminals possible. It is more meaningful that the communication layer of applications had to be altered in order to use features like the quality-of-service characteristics of ATM. This work was worth the effort only for few applications. Thus, the additional cost and expenditure for ATM compared with Ethernet and TCP/IP was seldom justified.
3. Suggested solution
In the first step, a protocol-independent method for adjustment of protocol parameters is proposed. In a second step, the addressing of protocols using a serviceoriented interface is described, which in a third step finally enables dynamic protocol selection transparently to applications.
3.1 Protocol-independent setting of protocol parameters As mentioned above, upon use of the socket interface options are indicated protocol-specifically. An example for this is the option “TCP_NODELAY”, which switches off Nagle’s Algorithm. In order to be able to use such optimizations in the concrete application scenario reasonably, the programmer must have exact knowledge of the protocols being used. Besides, usage of such options makes employment of other protocols, for which no comparable or differently designated but similar options exist, more difficult. In addition, possibly not all options are available in each implementation of a protocol, which complicates portability of applications, for example between Windows and UNIX, when protocol options are used. Way out of this dilemma is abstraction: Instead of indicating concrete protocol parameters, the aim to be achieved by setting protocol parameters is described. Thus, an application should describe the way in which protocols are to yield their services abstractly instead of specifying concrete options [20]. The following points are suggested as goals. They describe the factors on which emphasis shall be put when a protocol fulfills its services: low delay for real-time applications with special requirements according to delay (VoIP, video conferences) high throughput for applications handling a large amount of data (file transfer, backups) low resource utilization for applications focusing on low utilization of the available resources (email)
In the above section disadvantages of the existing structures were addressed. In the following a solution is suggested to overcome many of the existing deficiencies.
fast connection establishment for request/response-application and time-critical transactions (DNS, online auction bids)
Interlocking between applications and underlying protocols should be loosened. Therefore, a protocol independent interface is needed, which hides protocolspecific parameters and the way of realization of functionalities in protocols from the applications [9, 19].
low cost Use of a cheap communication path (e.g. Internet instead of dial-in) (email, file-sharing)
This listing shall be regarded as an example and may be changed and extended. Apart from such simple qualitative data, it is conceivable to assess the individual goals or to complement them with quantitative data like special quality-of-service requirements. According to the goals specified by the application, the parameters of the protocols being used can finally be obtained. For example, with a demand for low delay “TCP_NODELAY” would be set in TCP and data would be segmented into several small instead of few large IP segments in order to take advantage of the pipeline effect. Contrary to this, the “TCP_NODELAY” flag will be removed, when low resource utilization is demanded. If individual demanded goals conflict, the associated protocol parameters should be set to default values or set on the basis of administrative guidelines. Using the described proceeding, the setting of protocol parameters lies no longer in the area of responsibility of the applications but is accomplished by a separate adaptation layer. This has the advantage that the application programmer doesn’t need knowledge of protocols any more and that the mapping between the specified goals and protocol parameters can be made in an optimal way for all applications on system level. Peculiarities like special possibilities and restrictions of the operating system and the actual protocol implementation can be taken into account as well.
protocols (each of which implementations), see figure 1.
can
have
several
Thus, it is not relevant for an application whether a transport protocol works connection-oriented or connection-less. But exactly the question which of these two protocol groups to use is the first one to decide when using the socket interface. From an application point of view the communication layer must only fulfill its service requirements, for instance reliable transmission of data. How the underlying mechanisms work to meet the requirements posed is not relevant for an application at all. Thereby, an application describes which services are required imperatively to perform its task. For instance, loss-free transmission and the kind of data to be transmitted (e.g. stream vs. messages). Additionally, there should be a way to define optional services (e.g. in many cases privacy of data) that should be yield if possible but are not required for an application to work. According to the description of services, suitable transport protocols can be selected by a broker. This means that an application is no longer bound to specific protocols at time of development but that the binding and setting of options takes place dynamically at run-time. Host Config. retrieving
3.2 Service-oriented interface to the transport layer
Set of available SP User Req.
For further decoupling applications and communication protocols, a general, service-oriented interface between application and transport layer appears to be reasonable. This interface can not only be used to access UDP and TCP but also other protocols lying on top of them or additional protocols like XTP. Note that such a new interface can be set aside the existing socket interface and thus doesn’t break existing applications. Service
filtering & ranking
Network Config. Application
Ordered list of appropriate SP Network-Services
confining
Service-Provider (SP) Best usable SP
Figure 2: selection process implements
Protocol implements
Software
Figure 1: interrelation of terms Employing a service-oriented interface, an application only describes the services and service properties it needs from the communication layer, and does not access individual protocols directly any more. This is sufficient because applications are not dependent on usage of certain protocols; they only demand supply of a certain service [21]. This service can be yield by different
Figure 2 illustrates the process of selecting an appropriate service provider (SP). A SP denotes a stack of protocols, which provides the communication service as a whole. The configuration of the host determines the set of available SP. In dependence of requirements from different modules, all improper SP are filtered out and the remaining ones will be ranked depending on their suitability. Finally, practical limitations will determine which SP of the (theoretically) most suitable ones will be used (practically). For example, if a hostname cannot be mapped to the required address type or if a connection setup fails a less optimal but still appropriate SP will be selected.
All kinds of protocol dependent addressing should be replaced by names. For instance, if the hostname of a communication peer is used instead of its IP-address one can abstract from protocols at OSI layer three: Whether IPv4 or IPv6 or even ATM is employed is thus completely transparent to the application. Further advantages are described in [22].
3.3 Dynamic protocol selection A truly protocol-independent interface like the one suggested above which decouples applications completely from protocols, offers a multitude of new possibilities. Not only standard protocols such as UDP and TCP can be accessed via them, it also becomes possible to use arbitrary protocols and even proprietary protocols if available (see figure 3). This also simplifies the migration to newer protocol versions, since it is possible to support multiple versions of a single protocol. applications service-oriented interface
socket interface (as usual)
broker selecting service provider adaptation layer UDP
TCP
IPv4
SCTP
XTP
IPv6
RDP
...
service provider
...
data link / physical (ISO/OSI-layer 1/2)
Figure 3: proposed architecture If “alternative” protocols shall be used it is necessary to check whether the protocol to use is available at the communication peer and whether it can be used on the communication path. In contrast to today's practice where each application must perform such an examination by itself in order to use alternative protocols, this can be done by the communication layer for the complete system now. The availability of such a preferably standardized method, which makes the use of alternative protocols possible without any effort of the applications, would open the way for new protocols or protocols specialized for special areas of application and would allow their employment in a large scale. New protocol versions could be employed transparently for applications and could be used in parallel to the old versions for arbitrary transition periods. Additionally, applications could access powerful functionality without having to implement these by themselves. This lowers the fault liability and increases robustness and flexibility.
4. Further fields of application Apart from the use of transport protocols on top of IP as service provider, such as UDP, TCP, XTP, and SCTP, it would also be conceivable to use protocols on top of the latter and to regard the resulting protocol stack as a new service provider. For instance, in [23] “BEEP” is defined. It implements often needed functionalities like framing, compression, and encryption available modularly on top of a protocol like TCP. The interface to the applications must be flexible enough to handle such requirements. One could even imagine some kind of “protocol plug-ins“ – new protocols that can be installed as simply as audio codecs or video codecs today, offering additional functionality or performing better than already installed ones. Besides the possibility to use alternative protocols without any effort for an application, the abstract scheme of description of protocol services offers new potentialities to affect protocol parameters by means of administrative policies. If an application requires “strong encryption” this could be performed today according to administrative policy by algorithm A with a key length of x and in the future by algorithm B with a key length of y without having to change the application in any way.
5. Summary This paper shall motivate to discuss the current structures of Internet communication. It has been clarified that close interlocking between applications and the two transport protocols UDP and TCP as it is given today is neither upto-date nor necessary. It was therefore suggested that an application describes the services needed from the communication layer and the way of the desired realization of these services comparatively abstractly. The decoupling between applications and protocols carried out thereby offers new possibilities and a by far larger flexibility compared to the situation today. A service-oriented and with that truly protocol independent interface between application and communication services provides a dynamic binding between application and service providers in contrast to today’s protocol selection at the time of development of an application. This allows the usage of new protocol versions and new protocols as being intended in the ISO/OSI-reference-model [21]. Besides the two standard protocols UDP and TCP, a new multitude of protocols can be employed transparently to the applications. Additionally, detailed knowledge of network protocols is no longer required for the application programmer and often needed functionality can be provided below the applications modularly which accommodates the principles of modularization and separation-of-concern.
Some of the possibilities that likewise become possible with the decoupling of applications and communication layer were outlined, for example application independent administrative policies. This should adumbrate the potentials a practical implementation would offer.
6. References [1] Postel, J. (ed.): RFC 791 - Internet Protocol DARPA Internet Program Protocol Specification; USC / Information Sciences Institute, 1981 [2] Postel, J.: RFC 768 - User Datagram Protocol DARPA Internet Program Protocol Specification; USC / Information Sciences Institute, 1980 [3] Postel, J. (ed.): RFC 793 - Transmission Control Protocol, DARPA Internet Program Protocol Specification; USC / Information Sciences Institute, 1981 [4] Stevens, W. R.: TCP/IP Illustrated, Volume 1 - The Protocols Addison Wesley, 1994 [5] Stevens, W. R.: Unix Network Programming, Volume 1 - Networking APIs Prentice-Hall, 1998 [6] Microsoft Platform SDK, Windows Sockets 2; MSDN, 2002 [7] Allman, M. et al. : RFC 2581 – TCP Congestion Control The Internet Society, 1999 [8] Mathis, M. et al.: RFC 2018 - TCP Selective Acknowledgment Options Pittsburgh Supercomputing Center, 1996 [9] Zitterbart, M. et al.: A Model for Flexible HighPerformance Communication Subsystems IEEE Journal on Selected Areas in Communication, Vol. 11, No. 4, pp. 507-518, 1993 [10] Deering, S.; Hinden, R.: RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification Network Working Group, 1998 [11] Strayer, T., ed.: Xpress Transport Protocol Specification, Revision 4.0b XTP Forum Inc., 1998 [12] Velten, D. et al.: RFC 908 - Reliable Data Protocol BBN Communications Corporation, 1984 [13] Special research project “Development of large systems with generic methods” reuse of softwareproducts; http://www.sfb501.uni-kl.de [14] The Open Group: Specification Network Services (XNS) Issue 5, X/Open Document Number C523, 1997 [15] Gilligan, R. et al.: RFC 2553 - Basic Socket Interface Extensions for IPv6 The Internet Society, 1999 [16] Nagle, J.: RFC 896 - Congestion Control in IP/TCP Internetworks Ford Aerospace and Communications Corporation, 1984 [17] Stewart, R. et al.: RFC 2960 - Stream Control Transmission Protocol The Internet Society, 2000 [18] Müller, P. et al.: ViAA – a virtual ATM API for arbitrary layer 2 access networks Computer Communications 23, pp. 1019-1026, 2000 [19] Müller, P. et al.: Using Transport Services instead of specific Transport Protocols Internal Report University of Kaiserslautern 304/00, 2000 [20] Henrici, D.: A Universal Scheme for the Classification of Network Services AG Integrated
Communication Systems, University of Kaiserslautern, 2002 [21] ISO/IEC 7498-1, ITU-Rec. X.200: Information Processing Systems – OSI Reference Model – The Basic Model International Organization for Standardization; 1994 [22] Carpenter, B.; Rekhter, Y.: RFC 1900 - Renumbering Needs Work Network Working Group, 1996 [23] Rose, M.: RFC 3080 - The Blocks Extensible Exchange Protocol Core The Internet Society, 2001
