Internet Engineering Task Force G-S. Ahn, A. T. Campbell INTERNET-DRAFT A. Veres, L. Sun draft-ahn-swan-manet-00.txt Columbia University Expiration : August 2003 February 2003 SWAN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This draft specifies SWAN, a stateless network protocol which uses distributed control algorithms to deliver service differentiation in MANETs. SWAN uses rate control for UDP and TCP best-effort traffic, and source-based admission control for UDP real-time traffic. SWAN also uses explicit congestion control notification (ECN) to dynamically regulate admitted real-time traffic in the face of network dynamics brought on by mobility or traffic overload conditions. SWAN is designed to support real-time services over best effort MACs without the need to install and maintain costly QOS state at MANET nodes. This makes the SWAN approach to MANET QOS simple, scalable, and robust. The ns-2 simulation code is available from the web (http://comet.columbia.edu/swan/). Ahn, Campbell, Veres, Sun Expires August 2003 [Page 1] INTERNET-DRAFT SWAN February 2003 Table of Contents 1. Introduction....................................................2 2. SWAN Network Model..............................................3 3. Distributed Control Algorithms..................................5 3.1 Rate Control of Best-Effort Traffic............................5 3.2 Source-based Admission Control of Real-Time Traffic............6 3.2.1 Bandwidth Probe Message Format...............................8 3.3 ECN-based Regulation of Real-Time Traffic......................9 3.3.1 Source-Based Regulation Algorithm............................9 3.3.2 Network-Based Regulation Algorithm..........................10 3.3.3 Regulate Message Format.....................................11 4. Acknowledgement................................................11 5. References.....................................................12 6. Author's Addresses.............................................12 1. Introduction SWAN [1] operates on a best effort MAC and uses feedback-based mechanisms to support soft real-time services and service differentiation in mobile ad hoc networks. SWAN uses rate control for UDP and TCP best- effort traffic and source-based admission control for UDP real-time traffic. SWAN also uses explicit congestion notification (ECN) [5] to dynamically regulate admitted real-time traffic in the face of network dynamics such as mobility or traffic overload. Intermediate nodes do not keep per-flow state information in SWAN networks. As a result, there is no need for signaling or complex control mechanisms to update, refresh and remove per-flow state information, as is the case with "stateful" mobile ad hoc networks found in literature [2]. Changes in topology and network conditions, even node and link failure do not affect the operation of the SWAN control system. Instead of depending on depending on state information, SWAN uses feedback information from the network. A rate control mechanism uses Ahn, Campbell, Veres, Sun Expires August 2003 [Page 2] INTERNET-DRAFT SWAN February 2003 the MAC delay measurements from packet transmissions as feedback, while a source-based admission control mechanism uses rate measurements of aggregated real-time traffic as feedback. For full details and performance evaluation of SWAN, see [1]. The ns-2 source code is available from [10]. The source code from an implementation of SWAN in a wireless testbed will be available Jan 2003 from [10]. 2. SWAN Network Model The SWAN network model includes a number of mechanisms used to support real-time services and service differentiation in mobile ad hoc networks. In order to ensure that the bandwidth and delay requirements of real- time UDP traffic are met, rate control of TCP and UDP best effort traffic is performed at every mobile node in a fully distributed and decentralized manner. Rate control is designed to restrict best effort traffic yielding the necessary bandwidth required to support real-time traffic. Rate control also allows the best effort traffic to efficiently utilize the bandwidth that is not utilized by the real-time traffic at any moment. The total rate of all best effort traffic and real-time traffic transported over each local shared media channel should be maintained below a certain "threshold rate", limiting any excessive delays that might be experienced. SWAN adopts the well-known additive increase multiplicative decrease (AIMD) rate control mechanism as part of this task. A classifier and a shaper operate on the interface between the IP and MAC layers. The classifier is capable of differentiating real-time and best effort packets, forcing the shaper to process best effort packets but not real-time packets. The shaper represents a simple leaky bucket traffic shaper. The goal of the shaper is to delay best effort packets in conformance with the rate calculated by the AIMD rate controller. There is no flow or session state information maintained at intermediate nodes in support of end-to-end communications between source destination pairs. Furthermore, when a session is admitted there is no admission control decision taken at intermediate nodes. Rather, the admission control test to determine if a new session should be admitted or not is conducted solely at the source node. A key operation of the admission controller, which is based at every mobile device, is to efficiently estimate local bandwidth availability. The admission controller located at the source node probes the network between the source and destination to determine the instantaneous end-to-end bandwidth availability. Based on the results of a request/response probe the session admission controller located at source node makes a decision to admit a new real-time flow or not. Once a session is admitted as a real-time session its packets Ahn, Campbell, Veres, Sun Expires August 2003 [Page 3] INTERNET-DRAFT SWAN February 2003 are marked as RT (for real time service) otherwise they are considered as best effort packets. SWAN uses the DS (DiffServ) field [4] to identify the class of this packet as shown in figure 1. The RECOMMENDED codepoint for the best effort packets is the bit pattern '000000' and the RECOMMENDED codepoint for RT (the real-time packets) MUST be assigned. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ DSCP: Differentiated Services Codepoint ECN: Explicit Congestion Notification Figure 1: The Differentiated Services and ECN Fields in IP. A probing packet is sent at the beginning of a session or when mobility or channel load conditions force a real-time session to re- establish its end-to-end service quality. Once a session is admitted it is desirable to maintain service quality for the lifetime of the session. Because SWAN [1] takes a conservative approach when allocating bandwidth to real-time traffic, small scale violations of service quality can be tolerated without impacting application level QOS. These small-scale violations may occur because of bursty real-time sources or unpredictable traffic patterns. In a static wireless ad hoc network there is little need for further control algorithms above and beyond the rate control of best effort traffic and admission control of real-time traffic. One could even argue that under low mobility conditions this approach is sufficient for the delivery real-time performance. However, the bandwidth availability and dynamics of a wireless channel may change rapidly in the case of moderate to higher levels of mobility. Larger- scale violations may occur when real-time flows are admitted or dynamically re-routed. In the former case, multiple source nodes could simultaneously send new session probes that may traverse common intermediate nodes facilitating the admission of new sessions. This in turn could overload these common intermediate nodes. There is a need for additional SWAN mechanisms that can help resolve these issues. SWAN regulates real-time sessions when a mobile node observes violations of real-time sessions; for example, due to mobility or source-based admission. SWAN adopts a regulation mechanism based on ECN, which was originally proposed for controlling and improving TCP traffic performance in IP networks. To allow for experimentation with IPv4, two bits (i.e., ECN-Capable Transport and Congestion Experienced bits) have been set-aside in the IP header for ECN in RFC 2780 as shown in Figure 1. We propose to use ECN to Ahn, Campbell, Veres, Sun Expires August 2003 [Page 4] INTERNET-DRAFT SWAN February 2003 control and regulate UDP real-time traffic in the case of traffic violations most likely brought on by the re-routing of real-time sessions. By regulation, we mean that the ECN mechanism forces real- time flows to re-establish their real-time service. Under such conditions an existing flow would either be able to re-establish its original service quality or be dropped. We do not consider bandwidth adaptation of real-time sessions in this draft. Rather, we assume that real-time flows attempt to re-establish service at their original bandwidth levels. It should also be noted that SWAN's ECN control system also serves to regulate real-time sessions in the case of persistent congestion, or due to potential overloading associated with source-based admission control. If multiple sources read (via bandwidth probes) the state of the network at the same time they may erroneously admit more real- time sessions than an intermediate node can support. We call this condition "false admission" [1]. If false admission occurs, then the ECN control system will randomly regulate real-time flows, forcing the control system back to an operating point that is within the admission threshold of the wireless network. SWAN's design philosophy is not to add more protocol complexity or state information to resolve any perceived unfairness among real-time flows that are randomly selected for dynamic regulation. Rather, we rely on the existing SWAN distributed control algorithms to resolve such issues. 3. Distributed Control Algorithms 3.1 Rate Control of Best-Effort Traffic Each node in a mobile ad hoc network independently regulates best effort traffic. The rate controller determines the departure rate of the shaper using the AIMD rate control algorithm based on feedback from MAC. This feedback measure used by the rate controller represents the packet delay measured by the MAC layer. In our model we use existing best effort MAC technology as part of SWAN. Packet delay for the IEEE 802.11 DCF mode MAC, for example, can be measured rather simply. When a packet arrives at the MAC layer, the MAC listens to the channel and defers access to the channel according to the CSMA/CA algorithm. When the MAC gets access to the channel then RTS-CTS-DATA-ACK packets are exchanged. The reception of an ACK packet at the transmitter indicates that a packet was received successfully. The packet delay represents the time it took to send the packet between the transmitter and receiver including the total deferred time (including possible collision resolution) plus the time to fully acknowledge the packet. This is simply measured at the source node by subtracting the time that a packet is passed to the MAC layer (from the upper layer) from the time an ACK packet is received from the receiver. Ahn, Campbell, Veres, Sun Expires August 2003 [Page 5] INTERNET-DRAFT SWAN February 2003 SWAN's AIMD rate control algorithm is as follows. Every T seconds, each mobile device increases its transmission rate gradually (additive increase with increment rate of C Kbps) until the packet delays become excessive. The rate controller detects excessive delays when one or more packets have greater delays than the threshold delay D sec. As soon as the rate controller detects excessive delays, it backs off the rate (multiplicative decrease by R%). The threshold delay D is based on the real-time delay requirements of applications in wireless network, as discussed in our previous work [3]. The shaping rate is adjusted every T second. The period T should be small enough to be responsive to the dynamics of mobile ad hoc networks. If there is a large difference between the shaping rate and the actual transmission rate then a mobile device is capable of transmitting a burst without due control, hence, potentially limiting the performance of real-time traffic. To resolve this problem, the rate controller monitors the actual transmission rate. When the difference between the shaping rate and the actual rate is greater than G % of the actual rate, then the rate controller adjusts the shaping rate to be G % above the actual rate. This "gap" (i.e., G%) allows the best-effort traffic to increase its actual rate gradually. For a detailed discussions on the values of these parameters, see [1]. 3.2 Source-based Admission Control of Real-Time Traffic Using a shared wireless channel allows mobile hosts to listen to packets sent within radio transmission range. An admission controller uses this feature to measure local resource availability. At each node, the admission controller measures the rate of real-time traffic in terms of bits per second. Note that in order to smooth out small- scale traffic variations, the admission controller uses a running average (e.g., weighted moving average) of these measures. If we know the threshold rate [3] that would trigger excessive delays, then bandwidth availability in a local shared media channel is simply the difference between the threshold rate and current rate of the real-time traffic. However, it is difficult to estimate the threshold rate accurately because the threshold rate may change dynamically depending on traffic patterns. It is not desirable to admit real-time traffic up to the threshold rate for a number of reasons. First, best effort traffic would be starved of resources should the real-time traffic consume bandwidth up to such a threshold rate. Best effort traffic is rate controlled to yield the bandwidth required for real- time traffic and to keep the total traffic, both real-time and best effort, below the threshold rate. Second, there would be no flexibility to tolerate channel dynamics, as previously discussed. Ahn, Campbell, Veres, Sun Expires August 2003 [Page 6] INTERNET-DRAFT SWAN February 2003 The total rate of aggregated real-time traffic may be dynamic due to changes in traffic patterns and node mobility. Due to node mobility, for example, intermediate nodes may need to maintain real-time traffic in excess of resources set-a-side for real-time traffic. There are a number of possible ways to address this problem. SWAN admits real-time traffic up to a rate that is more conservative than the threshold rate. Therefore, the estimated available bandwidth of a local shared media channel is the difference between this conservative admission control rate and the current rate of the real- time traffic. With such a policy, we can use fixed, coarse, and statistically approximated values for the admission control rate. Even though the measure is conservative, the utilization of the network is not limited because any remaining unutilized bandwidth will be potentially absorbed by the best-effort traffic. This approach is simple and flexible and allows bandwidth sharing between real-time and best-effort traffic. The process of admitting a new session is as follows. The admission controller located at the source node sends a bandwidth probe request packet (section 3.2.1) toward the destination node to estimate the end-to-end bandwidth availability. The admission controller does not send a bandwidth probe request packet directly to the destination node. A bandwidth probe request packet MUST visit every intermediate node in the route provided by a MANET routing protocol. So the admission controller at the source node sends a bandwidth probe request packet to the next hop in the route to the destination. If the network is using an on-demand routing, the on-demand routing protocol MUST initiate a route discovery process if there's no known route to the destination when the admission controller queries for the next hop in the route to the destination. Each intermediate node between the source-destination pair receives the probing request packet, and updates the bottleneck bandwidth field if the bandwidth availability at the node is less than the current value of the field, and then passes the packet to the next hop. Therefore, if the local bandwidth availability is different for each hop along the path between the source and destination then the value of the bottleneck field at the destination node represents the bottleneck bandwidth along the path. The destination node sends a bandwidth probe reply packet (section 3.2.1) back to the source node with the bottleneck field copied from the bandwidth probe request. A bandwidth probe reply packet is sent directly to the source node. There is no need for this bandwidth probe reply packet to follow a reverse path back toward the source node. Once the source node receives the bandwidth probe reply packet it can execute the simple source-based admission control by comparing the bottleneck bandwidth and the bandwidth requirement for the new real- time session. Note that no bandwidth request is carried in the bandwidth probe, no admission control is executed at intermediate Ahn, Campbell, Veres, Sun Expires August 2003 [Page 7] INTERNET-DRAFT SWAN February 2003 nodes, nor are there any resources allocated or reserved on behalf of the source node during the lifetime of the session. Rather, the bandwidth probe instantaneously reads the state of the network path presented to it by the routing protocol and makes a local source based admission decision based on the bandwidth probe reply. What makes such a stateless approach work is that all nodes independently regulate best effort traffic and each source uses admission control for real-time sessions. When a new real-time session is admitted, the packets associated with the flow are marked as RT (real-time packets/traffic). The classifier looks at the marking, and if the packet is marked as RT, the packet will bypass the shaper mechanism, remaining unregulated. Here there is an implicit assumption that the source node regulates its real-time sessions based on its admission control decision. 3.2.1 Bandwidth Probe Message Format SWAN's source-based admission control defines two control messages called "bandwidth probe request" and "bandwidth probe reply", sent with UDP using a port number reserved for SWAN module. The bandwidth probe messages are defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | PROBE ID | Bottleneck Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0 (Bandwidth Probe Request) 1 (Bandwidth Probe Reply) PROBE ID The sequence number uniquely identifying the Bandwidth Probe in conjunction with the source and destination IP addresses of a real-time traffic session that is in the admission control process Bottleneck Bandwidth The available bandwidth (in Kbps) along the path that a probe is passing through. This field is updated at each intermediate node with the local available bandwidth of this intermediate node only if the local available bandwidth is smaller than the value in this field. Ahn, Campbell, Veres, Sun Expires August 2003 [Page 8] INTERNET-DRAFT SWAN February 2003 Source IP Address The source IP address of a real-time traffic session that is in the admission control process Destination IP Address The destination IP address of the real-time traffic session that is in the admission control process 3.3 ECN-based Regulation of Real-Time Traffic The ECN-based regulation of real-time sessions operates as follows. Each node continuously, and independently, measures the utilization of its real-time traffic to estimate the local available bandwidth, as described in Section 3.2. Each mobile node can detect violations (i.e., congestion/overload conditions) using this periodic traffic measurement. When a node detects such a violation, it starts marking the ECN bits in the IP header of the real-time packets. The destination node monitors the ECN bits and notifies the source using a regulate message. When the source node receives a regulate message, it initiates re-establishment of its real-time session based on its original bandwidth needs. To reestablish a real-time session a source node follows the same process as setting up a new session by sending a probing request toward the destination. A source node terminates the session if the estimated end-to-end bandwidth indicated in the probing response packet cannot meet its existing session needs. This is one of the reasons why we call our approach to service differentiation in mobile ad hoc networks "soft" because an admitted real-time flow may encounter both periodic violations in its bandwidth requirements and, in the worst case, may have to be "dropped" or live with degraded best effort delivery. If the nodes in a congested or overloaded condition were to mark all packets with CE (Congestion Experienced) then all sessions traversing these nodes would be forced to be re-established their real-time service at the same time. Such an approach is inefficient and would lead to erroneous behavior. For example, all sources may re-probe the network and see network resources over utilized and drop all their flows accordingly. This clearly is not the best policy. More systematic approaches may only penalize a small number of sources. To address the problem, we consider two approaches and discuss their suitability and trade-offs. 3.3.1 Source-Based Regulation Algorithm When an intermediate node experiences overload or congested conditions it marks all flows with CE. When destination nodes encounter packets with the CE bit marked they send regulate messages Ahn, Campbell, Veres, Sun Expires August 2003 [Page 9] INTERNET-DRAFT SWAN February 2003 to the appropriate source nodes to force the re-establishment of flows that have previously been successfully admitted. However, in this case the source node does not immediately initiate re- establishment upon receipt of a regulate message. Rather, it waits for a random amount of time before initiating the re-establishment procedure. Under such a regime, source regulation would be staggered thereby avoiding flash-crowd conditions, where, a number of sources simultaneously initiate regulation (i.e., re-establishment of service) at the same time and see the path overbooked and drop their real-time sessions accordingly. Under a staggered regime, the rate of the real-time traffic will gradually decrease until it reaches below the admission control rate. At that point, congested or overbooked nodes will stop marking packets. Because flows can be admitted by mistake, due to false admission, source nodes need to be capable of differentiating between regulation associated with false admission and regulation due to mobility. Nodes can do this by keeping some state information about newly admitted flows versus on-going flows. This allows a source node to take immediate corrective action in the case where it receives a regulation message for a flow that it just admitted, albeit falsely. A disadvantage of this approach is that sources that regulate earlier than other sources (i.e., wait the shortest period of time before initiating re-establishment) are more likely to find the path overbooked and be forced to drop their sessions. An advantage of this scheme, however, is that it is purely source-based. 3.3.2 Network-Based Regulation Algorithm Rather than marking all packets with CE, congested/overloaded nodes randomly select a "congestion set" of real-time sessions and only mark packets associated with this set. This can be done using a hash function without keeping any per-flow state at the intermediate nodes. A congested node marks the congested set for a period of time T seconds and then calculates a new congested set. As in the case of the previous algorithm, nodes stop marking packets "congested" when the measured rate of the real-time traffic drops below the admission control rate. Under such an approach the rate of the real-time traffic will gradually decrease until it reaches below the admission control rate. However, there is a need for intermediate routers to distinguish between flows that have been falsely admitted or not. In this case, source nodes could use an additional bit in the TOS field to indicate if a RT session is new or old (namely RT-new, RT-old). When a flow is newly admitted, packets are marked as RT-new for a period of time before being marked as RT-old. A disadvantage on this scheme is that it requires some intelligence at intermediate nodes to manage the congested sets and determine if a flow is new or old in order to correctly respond to false admission. Ahn, Campbell, Veres, Sun Expires August 2003 [Page 10] INTERNET-DRAFT SWAN February 2003 3.3.3 Regulate Message Format SWAN's dynamic regulation defines two types of control messages called regulate message, sent with UDP using a port number reserved for SWAN module. The regulate message is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Message ID | CU (Currently Unused) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 (Regulate Message with Source based Algorithm) 3 (Regulate Message with Network based Algorithm) Message ID The sequence number uniquely identifying the Regulate Message in conjunction with the source and destination IP addresses of a real-time traffic session that needs to be regulated CU (Currently Unused) A field that is currently not in use. Source IP Address The source IP address of a real-time traffic session that needs to be regulated Destination IP Address The destination IP address of a real-time traffic session that needs to be regulated 4. Acknowledgement The work is sponsored in part by the ARO Award DAAD 19-99-10287, and with support from Ericsson Research. Jaekwon Oh, Il-Jun Hwang, and Professor Mischa Schwartz for their help and comments on this draft. Ahn, Campbell, Veres, Sun Expires August 2003 [Page 11] INTERNET-DRAFT SWAN February 2003 5. References [1] G.-S. Ahn, A. T. Campbell, Andras Veres and Li-Hsiang Sun, "Supporting Service Differentiation for Real-Time and Best Effort Traffic in Stateless Wireless Ad Hoc Networks (SWAN)", IEEE Transactions on Mobile Computing, September 2002. [2] S-B. Lee, G-S. Ahn, X. Zhang and A. T. Campbell, "INSIGNIA", Internet Draft, draft-ietf-manet-insignia-00.txt, MANET Working Group Internet Draft, November 1999. [3] A. Veres, A. T. Campbell, M. Barry and L-H. Sun, "Supporting Service Differentiation in Wireless Packet Networks Using Distributed Control", IEEE Journal of Selected Areas in Communications, Vol. 19, No. 10, October 2001. [4] K. Nichols, S. Blake, F. Baker and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", Internet RFC 2474, December 1998. [5] K. Ramakrishnan, S. Floyd and D. Black, "An Addition of Explicit Congestion Notification (ECN) to IP", Internet RFC 3168, September 2001. [6] J. L. Sobrinho and A. S. Krishnakumar, "Quality-of-Service in Ad hoc Carrier Sense Multiple Access Networks", IEEE Journal on Selected Areas in Communications, Vol. 17, No. 8, August 1999. [7] P. Sinha, N. Venkitaraman, R. Sivakumar, and V. Bharghavan, "WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks", in Proc. ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom), August 1999. [8] G. Bianchi, "Performance Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks", Computer Networks, 1989. [9] D. Bansal and H. Balakrishnan, "TCP-friendly Congestion Control for Real-time Streaming Applications", Technical Report, MIT-LCS-TR-806, MIT Laboratory for Computer Science, May 2000. [10]http://comet.columbia.edu/swan/ 6. Author's Addresses Gahng-Seop Ahn, Andrew T. Campbell, Andras Veres, Li-Hsiang Sun Dept. of Electrical Engineering, Columbia University 500 W. 120th Street Rm. 1312 New York, NY 10027 Phone: 1-212-854-2498 Fax : 1-212-316-9068 Email: ahngang@comet.columbia.edu Ahn, Campbell, Veres, Sun Expires August 2003 [Page 12]