R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer," in Proceedings of IEEE INFOCOM '96, pp. 206-- 214, March 1996. 125  Home/Search   Document Details and Download   Summary   Related Articles   Check

....running on legacy (e.g. Token Ring and Ethernet) and high speed ATM LAN networks is described in [20] The AQUA system [71] has developed QoS negotiation and adaptation support for allocation of CPU and network resources. A native mode ATM transport layer has been designed and implemented in [9]. It provides support for traffic policing and shaping, but no support is provided for scheduling protocol processing and accounting for implementation overheads and constraints. A good survey of such communication architectures can be found in [15] Predictable graceful degradation has also been ....

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer," in INFOCOM, pp. 206--214, March 1996.

.... [51] An RSVP based QoS architecture supporting integrated services in TCP IP protocol stacks, running on legacy (e.g. Token Ring and Ethernet) LAN interfaces as well as high speed ATM networks, is described in [52] A native mode ATM transport layer has been designed and implemented in [53]. The design of a QoS controlled communications system for ATM networks is described in [54] However, implementation overheads and constraints are not incorporated in the resource management policies. Moreover, no performance impact of supporting QoS in communication is reported. Real time ....

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer," in Proc. IEEE INFOCOM, pp. 206--214, March 1996.

....a native mode ATM transport layer with quality of service (QOS) support is described. For scheduling between applications and the transport multi threading is used. Note to the reader: This preliminary version of the report assumes that you are familiar with the work by Ahuja, Keshav and Saran [1, 2]. Unless you know the details of this work, this report is not very meaningful. October 28, 1996. Technical Report CU CTR TR 463 96 29. Contact: Jean Francois Huard CTR Columbia University Room 801 Schapiro Research Bldg. 530 West 120th Street New York, NY 10027 Tel: 1 212 939 7155 ....

....is useful for experimenting with flow and congestion control algorithms without having the difficulties of working in kernel space. Our implementation is based on the code of transport layer of a native mode ATM protocol stack developed for the IIT, Delhi Low cost Integrated testbed (IDLInet) [1, 2]. For user space scheduling between applications and the transport, multi threading is used. This report assumes that the reader is familiar with IDLInet code, and has access to it. It emphasizes the differences and enhancements of the user space implementation compared to the original ....

[Article contains additional citation context not shown here]

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native-mode ATM transport layer (extended version)," IEEE/ACM Trans. Networking, vol. 4, pp. 502--518, Aug. 1996.

....an RSVP based QoS architecture supporting integrated services in TCP IP protocol stacks, running on legacy (e.g. Token Ring and Ethernet) LAN interfaces as well as high speed ATM networks [13] as described in Chapter 7. A native mode ATM transport layer has been designed and implemented in [3], and enhanced with QoS support for a user space implementation [75] Similar to our RSVP based QoS architecture, traffic policing and shaping is performed while copying application data into kernel buffers; the application is blocked if it is violating its traffic specification. However, our ....

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer," in Proc. IEEE INFOCOM, pp. 206--214, March 1996.

....Lannion, France RSM Department, ENST de Bretagne, BP 78, 35512 Cesson Sevign , France Dominique Bonjour dominique.bonjour cnet.francetelecom.fr Omar Elloumi Omar.Elloumi enst bretagne.fr . Corresponding author 2 would be able to take advantage of all the ATM network capabilities [AKS96], KSW95] While such applications can (and will) be written, we claim in this paper that an initial and useful set can be easily derived from existing, well proven Internet applications. The adaptation of these applications to a native ATM environment can be achieved with a modest effort. In ....

....for a software solution. First, numerous interface cards provide, for the time being, only a limited support of this feature. A second motivation is that a software realization gives more flexibility to control connection aggregation, at both the VP and VC levels. Moreover, as also explained in [AKS96], the transport layer has the advantage of being able to block the applications. Still, a hardware solution regulates better inter cell spacing while a software shaper is mostly helpful to control bursts of packets. Design of the scheduler We have designed and implemented a rate regulator based on ....

A. Ahuja, S. Keshav, H. Saran, "Design, Implementation and Performance of a Native Mode ATM Transport Layer", Proc. of IEEE Infocom '96, Mar. 1996.

....It supports both unicast and multicast connections. The transport protocol suites supported by TP are implemented as libraries linked with the applications. The protocols currently supported are qStack (see below) and kStack [17] the user space implementation of a native mode ATM protocol stack [14]. We are currently looking into the possibility of supporting RTP RTCP [15] In short, TP is a containment object that permits us to support many transport protocol suites transparently. For each device, TP monitors the QOS received by all of its established connections. It does so by polling the ....

Ahuja, R., Keshav, and S., Saran, H. "Design, Implementation and Performance of a Native Mode ATM Transport Layer." In Proc. of IEEE Infocom, San Francisco, CA, Mar. 1996. Extended version to appear in IEEE/ACM Trans. on Networking.

....ones presented in this paper. A novel RSVP based QoS architecture supporting integrated services in TCP IP protocol stacks, running on legacy (e.g. Token Ring and Ethernet) and high speed ATM LAN networks is described in [8] A native mode ATM transport layer has been designed and implemented in [22]. These architectures also provide support for traffic policing and shaping; however, no support is provided for scheduling protocol processing and incorporation of implementation overheads and constraints. Operating system support for QoS sensitive communication: Real time upcalls (RTUs) 23] ....

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer," in Proc. IEEE INFOCOM, pp. 206--214, March 1996.

....enhancements for a sockets based communication subsystem, the protocol suite adopted does not conform to IETF standards for integrated services. Moreover, they do not provide support for network interfaces with widely differing capabilities. The native mode ATM transport layer described in [21] also performs traffic policing and shaping while copying application data into kernel buffers. However, our design is applicable to general TCP IP protocol stacks, including legacy LAN and ATM interfaces, participating in an integrated services Internet. Furthermore, the decision to shape traffic ....

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer", in Proc. IEEE INFOCOM, pp. 206--214, March 1996.

....enhancements for a sockets based communication subsystem, the protocol suite adopted does not conform to IETF standards for integrated services. Moreover, they do not provide support for network interfaces with widely differing capabilities. The native mode ATM transport layer described in [30] also performs traffic policing and shaping while copying application data into kernel buffers. However, our design is applicable to general TCP IP protocol stacks, including legacy LAN and ATM interfaces, participating in an integrated services Internet. Furthermore, the decision to shape traffic ....

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer", in Proc. IEEE INFOCOM, pp. 206--214, March 1996.

....better environment to test retransmission strategies in isolation. This separation is likely to become more common for transport layers layered over ABR service in ATM networks, where the flow control is explicitly managed at the ATM level, and the error control is relegated to the transport level [1]. 0 08186 7780 5 97 10.00 1997 IEEE 0 0.02 0.04 0.06 0 0.2 0.4 0.6 0.8 1 Goodput One way Packet Loss Rate (a) Upper: W EC = 12 , 6W RT Lower: W EC = 3W RT Mean burst = 1 B = 1.0 W RT 0 0.02 0.04 0.06 0 0.2 0.4 0.6 0.8 1 Goodput One way Packet Loss Rate (b) Upper: W EC = ....

R. Ahuja, S. Keshav, and H. Saran, "Design, Implementation, and Performance of a Native-Mode ATM Transport Layer," Proc. IEEE INFOCOM '96, March 1996, pp. 206-214.

....over ABR service in ATM networks, where the flow control is explicitly managed at the ATM level, and the error control is relegated to the transport level. Thus, our results are directly applicable to ATM transport layers, and have already been implemented in a prototype native ATM transport layer [AHUJ96]. January 26, 11 In the simulations, the offered load is 100 ; the source attempts to send continuously at the speed of the bottleneck link. The one way loss rate varies from 0 to 5 . The mean loss burst size is 1 packet or 5 packets, geometrically distributed. The router buffer size B = 1 ....

R. Ahuja, S. Keshav, and H. Saran, "Design, Implementation, and Performance of a Native-Mode ATM Transport Layer," To appear, Proc. IEEE INFOCOM '96, (March 1996).

....not depend on IP and Figure 11 shows a native ATM protocol stack. The orc driver does protocol demultiplexing using the virtual circuit identifier when receiving from the network. Application programs can communicate using virtual circuits directly via a slight modification to the socket library [AHU96]. 5.5. Lessons The Xunet router has been in service since April 1993. The simple architectural model that we used for IP over ATM service, in which routers attached to the ATM network are part of a single logical IP subnet, was independently developed in the IETF and is now quite widely ....

R. Ahuja, S. Keshav and H. Saran, "Design, Implementation, and Performance of a Nativemode ATM Transport Protocol," Proc. IEEE INFOCOM'96, March 1996, pp. 206-214.

....not only provide QoS sensitive operating systems, but also make per connection QoS available to applications. Unlike IP over ATM, where the IP layer hides and fritters away ATM level QoS, we have designed and built a Native mode ATM protocol stack that makes ATM level QoS visible to applications [7, 1]. The stack includes not only a transport layer that adds reliability and flow control to AAL5, but also signaling and operating system support for connection management, handling abnormal termination, and end system resource management. We refer the reader to reference [1] for further details on ....

....to applications [7, 1] The stack includes not only a transport layer that adds reliability and flow control to AAL5, but also signaling and operating system support for connection management, handling abnormal termination, and end system resource management. We refer the reader to reference [1] for further details on our stack, and to reference [2] for a survey of related work in the area of next generation transport layer protocols. This paper describes our experiences in porting the native mode ATM stack to the FreeBSD operating system and its performance on that platform. The first ....

[Article contains additional citation context not shown here]

R. Ahuja, S. Keshav, and H. Saran, "Design, Implementation, and Performance of a Native-Mode ATM Transport Layer," Proc. INFOCOM '96, March 1996.

No context found.

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode ATM transport layer," in Proceedings of IEEE INFOCOM '96, pp. 206-- 214, March 1996. 125

No context found.

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode atm transport layer," Proceedings of IEEE INFOCOM '96, pp. 206--214, March 1996.

No context found.

R. Ahuja, S. Keshav, and H. Saran, "Design, implementation, and performance of a native mode atm transport layer," Proceedings of IEEE INFOCOM '96, pp. 206--214, March 1996.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC