Internet DRAFT - draft-ahn-swan-manet

draft-ahn-swan-manet



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]