LEarn from Video Extensive Real Atm Gigabit Experiment
|LEVERAGE News No 4, July 1998|
|Welcome | Co-ordinator | Technophile | Pedagogical | Keynote conference address | Conference report | Acronym key|
Native ATM Services
David Fernández, a principal lecturer in the telematics department at the Universidad Politécnica de Madrid, describes recent experiments using Native ATM Services carried out by the LEVERAGE team
Along with the popularisation of ATM networks in recent years has come the debate about how applications should access the promising new services offered by this new technology. On the one hand, the Internet community proposes treating ATM networks like any other network technology: defining how an IP datagram (the basic unit of information) travels along an ATM network, in the same way as it had done for other network technologies like Ethernet, FDDI, DQDB, etc. That is why they name this approach 'CLassical IP over ATM' (CLIP).
On the other hand, other technical communities propose writing specific applications that directly access ATM network services, eliminating the use of IP.
From a theoretical point of view, each approach has its advantages and drawbacks. The main advantage of the native ATM approach is the direct access to Quality of Service (QoS) ATM capabilities. Using native ATM, multimedia applications will be able to demand the resources (bandwidth, delay, etc) they require from the network to guarantee the quality and the stability needed for multimedia realtime applications like videoconferencing or video retrieval. This functionality will also be possible in Internet with the use of resource reservation protocols like RSVP, however, it is not yet widely available.
The main advantage of the CLIP approach comes from its internetworking nature. An IP-based application is able to run over a wide variety of network technologies, not only over ATM networks. Internetworking has clearly been one of the main keys to the success of Internet. Native ATM makes sense if we foresee a future with a widely deployed ATM network reaching offices and homes (as the telephone network does at present).
Moreover, the use of native ATM should improve the performance and behaviour of applications inside our computers due to the lower number of protocols involved. Parameters like CPU usage should be lower due to the lighter nature of an ATM protocol stack.
However, as well as the theory, practical factors such as stability, efficiency and implementation quality of protocol stacks have to be taken into account when developing real applications. Some a priori advantages of one approach can be hidden by immature implementations.
With all these ideas in mind, we began to experiment inside the LEVERAGE project with native ATM services and implementations. Our main goal was to assess its usability for real applications, like the ones used so far in LEVERAGE user trials, and compare the behaviour of CLIP and native ATM stacks in a real scenario.
The methodology we followed consisted in developing dual-stack applications able to run over both CLIP and native ATM. We wrote a performance testing application and also modified the videoconference application. We reduced to the minimum the differences between versions, trying to isolate the different behaviours due to the protocol stacks being used. Fortunately, the use of the new Winsock 2.0 programming interface made this task a lot easier.
The main conclusion derived from the tests was the immaturity of the native ATM stacks used. Not only the native ATM testing scenario was unstable and difficult to configure, but also, from the performance point of view, the a priori advantages of native ATM were not significant in practice.
Finally, details of all the experiments carried out, the results and the conclusions we reached can be found in the deliverable DWP462: Report on Experiments using ATM Services available on the LEVERAGE WWW site.
|About LEVERAGE | Conferences | Deliverables | Partners | Press Archive | Related Projects|
LEVERAGE home page
Last updated 1st June 1999