Transport Systems

In this work we describe and evaluate an instantiation of the QoS-A [1] [2] called the multimedia enhanced transport system (METS). METS supports multi-layer coded flows in a multicast, multimedia networking environment in which client workstations have varying capabilities. In terms of services, METS offers a flexible QoS configurable API at the transport layer. In terms of mechanisms, it populates the network layer as well as the transport layer with a number of modules providing control over quality of service (QoS). The novel aspects of METS relate to the protocol, QoS maintenance and flow management planes of the QoS-A. Briefly, the protocol plane is responsible for transferring media with a taget level of QoS. The QoS maintenance plane is then responsible for the fine grained monitoring and maintenance of the protocol plane. For example, at the transport layer, the QoS maintenance plane monitors rate, loss, jitter and delay and takes remedial action when they fluctuate. Finally, the flow management plane is responsible for flow establishment (including end-to-end admission control, QoS based routing and resource reservation), QoS mapping, which translates QoS representations between layers, and coarse grained QoS management (e.g., re-negotiation of QoS). The work describes flow scheduling, flow shaping and basic flow monitoring in the QoS- A protocol plane. Flow scheduling and shaping are fundamental to the smooth pacing of media onto the network and regulation of media between end-systems. Flow monitoring also plays an important role in measuring the performance of the flow as media is delivered to the receiver. In the QoS maintenance plane, the most important functions are transport QoS management and jitter correction which works in unison with the flow monitor to smooth out network induced jitter. In the flow management plane, METS provides QoS groups which encapsulate multicast sessions in which participants with heterogeneous QoS capabilities/ requirements may participate. The flow management plane arranges for per-participant QoS negotiation and resource allocation to take place and is also responsible for informing the user of ongoing QoS performance. The other key aspect of METS described in this work is dynamic QoS adaptation. This is a flow management plane mechanism designed to exploit the layered encoding property of currently popular media formats. An example of a media format with layered encoding is MPEG [H.262,94]. MPEG structures video streams in terms of three layers: a coarse or base representation of the signal plus successive enhancement layers. In the case of MPEG1, the base layer (BL) is represented by I pictures and the enhancement layers (E1 and E2) by P and B pictures, respectively. In our dynamic QoS adaptation scheme,QoS adapters take remedial action, based on a user supplied QoS policy, to scale flows (e.g. by adding or removing enhancement layers or instantiating filters) when resource availability and/or user QoS requirements change. Scaling is a term used to refer to the dynamic manipulation of media flows by objects called filters as they pass through a communications channel. Example MPEG filters are coarse grained picture droppers and fine grained low-pass filters (which trade off bandwidth for picture resolution) .

A full version of this work appears in [4].

References

[1] Campbell, A., Coulson, G. and Hutchison, D., ``A Quality of Service Architecture,'' ACM Computer Communications Review, April 1994.

[2] Campbell, A., ``A Quality of Service Architecture,'' Ph.D Thesis, Lancaster University, England, Januray 1996.

[3] Coulson, G., Campbell, A and P. Robin, ``Design of a QoS Controlled ATM Based Communication System in Chorus,'' IEEE Journal of Selected Areas in Communications (JSAC), Special Issue on ATM LANs: Implementation and Experiences with Emerging Technology, 1995.

[4] Campbell, A. and Coulson, G., ``A QoS Adaptive Multimedia Transport System: Implementation and Experiences,'' 5th International Workshop on Protocols for High Speed Networks, Sophia Antipolis, France, November 1996

RTP: A Transport Protocol for Real-Time Applications

Henning Schulzrinne

This memo describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This RFC is the product of the Audio/Video Transport Working Group of the IETF.

A full version of this work appears in [1].

References

[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments (Proposed Standard) RFC 1889, Internet Engineering Task Force, Jan. 1996.

RTP Profile for Audio and Video Conferences with Minimal Control

This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This RFC is the product of the Audio/Video Transport Working Group of the IETF. A full version of this work appears in [1].

References

[1] H. Schulzrinne, "RTP profile for audio and video conferences with minimal control," Request for Comments (Proposed Standard) RFC 1890, Internet Engineering Task Force, Jan. 1996.

Dynamic QOS Control of Multimedia Applications based on RTP

We describe a mechanism for dynamic adjustment of the bandwidth requirements of multimedia applications. The sending application uses RTP receiver reports to compute packet loss. Based on this metric the congestion state seen by the receivers is determined and the bandwidth is adjusted by a linear regulator with dead zone. The suggested mechanism has been implemented and controls the bandwidth of the vic video conferencing system. We ran several experiments on the Internet and on our local ATM network in order to tune and evaluate the algorithm. The results indicate that the mechanism can be applied to both environments. Since an ATM network has a different loss characteristic than the Internet different controller parameters must be set. A full version of this work appears in [1]. References

[1] Ingo Busse, Bernd Deffner, and Henning Schulzrinne, "Dynamic QoS control of multimedia applications based on RTP," Computer Communications, Jan. 1996.

Binary Congestion Notification in TCP

We propose to enhance TCP's congestion control mechanisms using binary congestion notification (BCN). With this scheme congestion is not simply indicated by packet losses as is currently the case. Instead, switches inform the sources about their congestion state by setting a congestion bit in the data packets. Unlike other studies, our approach maintains the basic elements of TCP's congestion control mechanisms and at the same time tries to adapt TCP's response to BCN based on the source behavior proposed for sources using ATM's available bit service (ABR). Through different simulation models we compare the throughput achieved with TCP using BCN (BCN-TCP) and 4.3BSD Tahoe-TCP and Reno-TCP. Also, the effects of integrating TCP with BCN-TCP are investigated. The effects of running TCP over ABR are studied with the help of a simple simulation model. Here, the benefits of using BCN-TCP in avoiding multiple packet losses are demonstrated and explained. Finally, fairness issues when mixing long and short distance traffic are considered. Our simulations suggest that BCN-TCP has a worse fairness performance towards long distance traffic than Tahoe- and Reno-TCP. We investigate the reason for this and suggest different approaches for overcoming this problem.

A full version of this work appears in [1].

References

[1] Dorgham Sisalem and Henning Schulzrinne, "Binary congestion notification in TCP," in Conference Record of the International Conference on Communications (ICC), (Dallas, Texas), IEEE, June 1996.

Congestion control in TCP: Performance of Binary Congestion Notification Enhanced TCP Compared to Reno and Tahoe TCP

In previous work, we proposed to enhance TCP's congestion control mechanisms using binary congestion notification (BCN). With this combined scheme called BCN-TCP, congestion is indicated both by packet loss and by having switches inform sources about their congestion state by setting a congestion bit. Unlike other studies, our approach maintains the basic elements of TCP's congestion control mechanisms and models the response of TCP to the congestion bit to that of the ATM available bit rate service (ABR). We compared the performance of BCN-TCP to the versions currently implemented in hosts (Tahoe and Reno TCP). However, BCN-TCP only offered significant performance improvements if part of the path contained ATM ABR services. In this paper, we present further results on the performance of BCN-TCP when used in heterogeneous environments, i.e., Internet paths where only some end systems support BCN-TCP. We also consider the fairness between long and short-haul connections and discover that BCN-TCP treats long-haul connections worse than Tahoe and Reno TCP. We investigate the cause of this unfairness and suggest possible remedies.

A full version of this work appears in [1].

References

[1] Dorgham Sisalem and Henning Schulzrinne, "Congestion control in TCP: Performance of binary congestion notification enhanced TCP compared to Reno and Tahoe TCP," in International Conference on Network Protocols (ICNP), (Columbus, Ohio), pp. 268-275, Oct. 1996.

Switch Mechanisms for the ABR Service

While lots of effort is done on behalf of the ATM Forum and the ITU standardisation bodies in specifying the user network interface (UNI) for ATM's available bit rate (ABR) service the specification of the switch mechanisms will be left to the manufacturers. In this study some of the algorithms proposed for dynamically distributing the available bandwidth at the switches such as EPRCA, CAPC, the OSU scheme and a modified version of the MIT proposal are compared. In our investigations we will concentrate mainly on the fairness behaviour of the schemes, their complexity and their warm up periods. The work presented here is a description of our preliminary results. At this stage, we have mainly considered the fairness behaviour of the different schemes using a single test scenario.

A full version of this work appears in [1].

References

[1] Dorgham Sisalem and Henning Schulzrinne, "Switch mechanisms for the ABR service: A comparison study," in Telecommunication Distribution Parallelism (TDP'96), (La Londes Les Maures, France), Institut National des Telecommunications, Evry, June 1996.