INTERNET DRAFT Mukundan Venkataraman 19 May 2004 Infosys Technologies Ltd. Puneet Gupta Infosys Technologies Ltd. Stack Aware Architectures for Mobile Ad hoc Networks draft-venkataraman-stack-00.txt Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026. Distribution of this memo is unlimited. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Any operating protocol functions on the basis of a communication stack. While a layered approach towards a comprehensive stack development amends itself very well to division of labour and abstraction of problems, care must be taken to ensure that layers are so designed that they leverage benefits of using one another. In other words, layers should be so designed such that they are highly optimised for usage with one another. An essential feature of pervasive computing will be Mobile Ad hoc NETworks (MANETs). The two primary constraints to system design in MANETs are bandwidth and energy. We bring out the essential properties of layers in any general stack which make it highly efficient and practicable. We call this a “stack aware” architecture. We go on to exemplify this with the case of “helper nodes” in a MANET topology, and discuss the potential benefits of having them as a necessary ingredient for routing. We also bring out their significance in every layer of the integrated stack, using the OSI layers as a reference model. Venkataraman Expires 19 November 2004 [Page i] Internet Draft Stack 19 May 2004 Contents Status of This Memo i Abstract i 1. Introduction 2 2. The concept of “Helper Nodes” 2 3. The Emerging MANET Stack 3 4. Motivation for a Stack Aware Architecture 4 4.1 Application Layer . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Transport Protocols . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Routing Framework . . . . . . . . . . . . . . . . . . . . . . . 5 4.4 Energy Efficiency . . . . . . . . . . . . . . . . . . . . . . . 6 4.5 Medium Access . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Outline for a Stack Aware Architecture with Helper Nodes 7 5.1 Routing Framework . . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Energy Efficiency . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Medium Access . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Transmission Policies . . . . . . . . . . . . . . . . . . . . . 9 5.5 Application Packages . . . . . . . . . . . . . . . . . . . . . 10 6. How vital are “Hello Packets”? 11 7. Summary 11 Acknowledgements 12 References 13 Authors Addresses 14 Venkataraman Expires 19 November 2004 [Page 1] Internet Draft Stack 19 May 2004 1. Introduction A pervasive computing environment is envisioned to create a system that is ubiquitously embedded in the environment, completely connected, effortlessly portable, and constantly available. This will be an environment where there will be a collaboration of humans, wireline and wireless technologies. An essential feature of pervasive computing will be mobile ad hoc networks, or MANETs. Both wireline and wireless networks are infrastructured, whereas an ad hoc network is basically infrastructure-less, meaning, networks are created and brought down as devices come in proximities and move away. Thus MANETs are highly mobile, wireless and infrastructure-less. Thereby these essential qualities of MANETs pave way for the distinctive aspect of ubiquity in pervasive computing. MANETs present a highly dynamic scenario with spatial independence where the topology is changing and unpredictable, because hosts in these topologies are mainly nomadic. This is what basically constitutes the current notion of a MANET. Primary design constraints in MANETs are bandwidth and energy. Coupled with changing topologies, these bring about an acute set of problems. There are many questions which arise about the working of MANETs: “What is the right sort of applications that can exploit these networks?”, “How can one achieve efficient routing?”, “How do we make the most efficient use of bandwidth and energy?” etc. But perhaps the most important question is: “What constitutes as an effective stack for MANETs?” To answer the last and perhaps the most important question, we propose the use of “helper nodes” in the MANET topology. We formally define helper nodes to be either a subset of hosts in the topology or specialized devices that can be conveniently introduced in the topology. In this document, we analyze the major components of a stack using helper nodes in the following order: routing, energy efficiency, medium access, transmission policies, applications packages and finally topology layout choices. 2. The concept of “Helper Nodes” As the name suggests, these are a part of the communication topology whose primary function is to aid communication. The term “aid”, however, could be slightly misleading. Many design trends have used the notion of partitioning the topology as hosts (communication end users) and a subset of other hosts that take additional responsibilities. A few examples in this regard would be Span [Chen01], PRP [Mukundan04], Snake [Chatzigiannakis01], Runner [Chatzigiannakis02] etc. Venkataraman Expires 19 November 2004 [Page 2] Internet Draft Stack 19 May 2004 A formal definition of MANET in reference [Corson99] describes it to be a topology consisting of mobile platforms, which could be wireless communicating devices (hosts) or routers with multiple hosts per router. Such devices are small and can be conveniently mounted on top of vehicles, airplanes, ships and even on people or other small devices. These devices come with wireless transmitters and receivers using antennas that could be omni-directional or highly point-to-point. This would formally define as to what a helper node might physically be. Helper nodes in a MANET topology may come from two sources: internal and external. We say the helper node is internal if we are to elect a subset of the communicating hosts as helper nodes. Note that on election, we should still provide them with the freedom to continue communication. Hence internal helper nodes are identified as hosts in a topology that function both as a communicating end user as well as carry some additional responsibilities. A helper node is “external” if we are to deploy specialized devices that can communicate and whose sole function in the topology is to aid the communication system. Note that external helper nodes would probably not originate any data packets of their own. This document analyses the difference that a Helper Node like concept can bring about to stack development for MANETs. 3. The Emerging MANET stack The understood goal of any network design forum is interconnection of all participating nodes such that there is at least one path from any source to destination (In fact, the term “network” traditionally refers to a state of devices such that this is possible). Once this is established, one then focuses on aspects like optimization, correctness, efficiency and extensibility. Before looking into possible directions, we first present a brief refresher of what the present scenario is like. Our perception of networks is largely influenced by the Internet. It is a highly scalable architecture, and more importantly allows for seamless inclusion of newer underlying architectures and applications. One particular pattern very evident from all solutions proposed over time for MANETs has been the divergence of the underlying mechanism from that akin to the Internet. For example, routing in the Internet is achieved primarily using Distance Vector (DV) algorithm. The very first routing protocol for MANETs was Destination Sequence Distance Vector Routing (DSDV) [Bhagwat94], an attempt to extend DV for these new scenarios. The strategy was proactive and had too many drawbacks. Dynamic Source Routing (DSR) [Johnson94] is a reactive strategy and uses source routing while Ad hoc On demand Distance Vector (AODV) [Perkins99] is also reactive but uses destination sequence numbers (much like DSDV) to keep consistent routing tables (in a way, a combination of DSDV and DSR). Venkataraman Expires 19 November 2004 [Page 3] Internet Draft Stack 19 May 2004 A proactive strategy suits the Internet, because the intermediate nodes (routers) are static and reliable. Energy is not really a menacing issue, since nodes are usually connected to eternal power supplies, and neither is bandwidth (at least nothing comparable to what MANETs have at present). Computed routes tend to remain so for a long period of time. This is not the case with MANETs. Energy and bandwidth are the driving factors here. A proactive strategy does not fit since trying to pre- emptively compute routes only means a large taxation of energy, bandwidth and memory, and all this to compute a route, which will be obsoleted because of node mobility. This is why DSR and AODV naturally score over since they are “reactive” strategies An emerging stack is as depicted below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP / UDP (Transport) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSDV/DSR/AODV/PRP (Routing Framework) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Span/GAF (Energy Efficiency Modules) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP (Addressing) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IEEE 802.11 (Medium Access) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Physical Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The diagram shows modifications of the Internet stack (which primarily consists of Application, TCP, IP, Ethernet and Physical). Note the inclusion of modules for routing, energy efficiency and Medium Access. All these layers emerged since these issues demanded attention, and they were not previously required as far as the Internet architecture was concerned. 4. Motivation for a Stack Aware Architecture We define a ”stack aware” architecture to be an approach to stack design such that each layer is aware of what other layers do and the functionalities in a particular layer are highly optimized for usage with other layers. We, however, do not delve too deeply with the physical layer aspects. Venkataraman Expires 19 November 2004 [Page 4] Internet Draft Stack 19 May 2004 There are several shortcomings with the emerging stack and they do not qualify as being “stack aware”. This is largely because assumptions and optimisations made at a layer are not necessarily compatible with the best module at some other layer. We systematically study the problems at various layers: 4.1 Application Layer This field lacks applications that can exploit MANETs to the fullest extent (it is shown that localized traffic patterns perform much better in MANETs), while MANETs cannot meet the requirements of several applications. For example, emerging applications like real time streams demand tight delivery bounds while a path between source and destination cannot be guaranteed every-time. This is because the path discovery process is purely function of node mobility and availability of intermediate hops. These applications also require more appropriate congestion control, since they cannot take the huge variations in sending rates which a TCP like policy presents. Real Time Streams are important because it is understood that the most convenient way for humans to interact with devices is by gestures, voice etc., which form an important set of highly localized, real time streams package. 4.2 Transport Protocols TCP is the dominant protocol in use in the Internet. Envisioning a pervasive computing environment, it is necessary that MANETs integrate nicely into the Internet. On the other hand, TCP performs very poorly over these networks. This is largely because TCP is connection oriented and is highly optimised for use over wired networks where bit error rates are low and packet drops are primarily due to congestion. A path in MANET is made and broken dynamically (even when a session is in progress) as intermediate nodes come and go. The bit error rate for the wireless physical medium is high and packets are lost frequently for reasons other than congestion. TCP will react to all packet losses assuming congestion to be the reason, and to make matters worse, it enters serial timeouts and stalls for minutes without sending any packets. The primary reason for its poor behaviour is disconnected/make-and break topologies and the load it offers to the networks because it is a reliable protocol. TCP-SACK performs a little better though (the ACKs prove expensive on energy and bandwidth). 4.3 Routing Framework Routing in these networks is quiet a challenge, not because routes cannot be computed, but because computed routes tend to be ephemeral. Venkataraman Expires 19 November 2004 [Page 5] Internet Draft Stack 19 May 2004 It is not wise to compute a route to every destination precisely because of this (proactive strategies), nor is it very wise to use a large number of control messages since it badly taxes energy and bandwidth. The algorithm itself should be lightweight since with routes going obsolete, the process is likely to be revoked often. It is hence necessary to achieve three things here, one: is to try making a connected graph of the given topology since this quality is highly sought for in the upper layers; two: make the design choices in this layer which are aware of system constraints (namely bandwidth/energy), or in other words, make sure that the framework uses minimum of control messages, is fast, efficient and extensible; and three: topology maintenance and control is important, since it is desirable to incorporate application specific congestion control on the higher (or lower) layers. 4.4 Energy Efficiency It is a known fact that mobile devices in the “idle” state (when they are not actively sending/receiving messages) consume energy which is comparable to what they do when actively sending/receiving messages. It is imperative to put as many idle nodes to the “sleep” mode (in which the aforesaid does not happen) without bringing about degradation in the way the network operates. This basically forms the crux of any energy efficiency technique. Known popular energy efficient techniques (like Span, GAF etc.) are “protocol independent modules”, or in other words, supposed to be compatible with any protocol operating above them. This is not a very realistic assumption. For example, though Span does very well to increase network lifetime, it is not very compatible for usage with DSR or AODV. This is because Span requires a Hello Packet every second, while a key benefit of reactive strategies (DSR, AODV etc.) over proactive frameworks is the reduced number of control messages. Use of Span underneath these modules translates to poor performance for the “stack” as a whole. In general, it may not be possible for independent modules to work efficiently for any protocol above it. One can either design modules that are highly optimised for one particular protocol or one has to infuse energy efficiency into the routing protocol itself (i.e. decide the role of sleeping/awake states which also keeps protocol performance optimal). 4.5 Medium Access The practical capacity of ad hoc networks is quiet low, and this is largely because of interference and the behaviour of the IEEE 802.11 Medium Access protocol (henceforth abbreviated “802.11”. Also, we necessarily talk of the 802.11 Distributed Coordination Function or DCF version). As the density of nodes increases, so does interference. Conventional nodes can transmit/receive packets Venkataraman Expires 19 November 2004 [Page 6] Internet Draft Stack 19 May 2004 for a range of 250 meters, but can cause interference over a range of 550 meter radius. The 802.11 operates with a request-reply dialogue (the Request-To-Send or RTS, and Clear-To-Send or CTS). When two nodes are communicating, two nodes in their neighborhood wanting to communicate will try the RTS-CTS dialogue. Because of interference, these packets are garbled. The 802.11 will exponentially back-off perceiving a busy medium. The situation gets worse if this happens repeatedly, since the back-off period increases multiplicatively. The goal here is hence is to take care of the fact that an increase in the density of nodes leads to degradation in throughput as interference increases. An implicit goal of any MAC protocol in general is to minimize collisions, raise goodput and prove stable. A MAC for MANETs additionally has to be aware of sleeping/idle nodes and remedies for a high degree of interference, especially the blocking of control/request packets by data packets. From the preceding discussion, following observations are noteworthy: Connected topologies, a balanced routing approach, energy efficiency and a higher capacity for these class of networks in general. While these would constitute the requirements at individual layers, the approach also lacks a “glue” factor that can bind the individual modules to a harmonious stack. While it is possible to introduce the best in class modules for the requirements stated above, care must be taken to ensure that they are interoperable. We see an example of such an approach with “Helper Nodes” in the topology in the next section. 5. Outline of a Stack Aware Architecture with Helper Nodes Helper nodes in a MANET topology bring about a remarkable change both in the performance aspect as well as in the perspective of solution design for MANETs. In this section, we enumerate the design choices available with their inclusion in mind. We do not follow the OSI model strictly (i.e. application to physical layer), but rather discuss the stack in the following order: routing, energy efficiency, medium access, transmission policies, and choices for application layer design. One important thing to bear in ones mind in the following enumeration is that as we use the term “helper node” in different layers for discussion, we necessarily refer to the same physical device which performs these functionalities for different layers. 5.1 Routing Framework Helper nodes can greatly aid packet routing and topology maintenance, and in fact this very property forms the nucleus of stack design integration. Known techniques that use helper nodes for routing (called “support nodes” in their respective designs) are Snake, Runner and the PRP protocol. Snake uses a subset of the deployed hosts and makes them move in a snake-like fashion Venkataraman Expires 19 November 2004 [Page 7] Internet Draft Stack 19 May 2004 (a common master is elected, and all other support nodes follow the path of this master, as it makes random sweeps of the topology).The Runner was a betterment over this design, and it gave independence to all the support nodes to randomly move about in the topology. PRP, on the other hand, restricts support nodes to predefined zones. The design too is highly extensible since the only control packet used is the “Hello Packet” sent periodically. PRP guarantees connected topologies at all times, is considerably robust (does very well to keep the topology connected in failing conditions), uses minimal control messages, has a minimal mean delay for packet transmission, minimal initial network setup time and amends very well to usage of other layers beneath and above it. The basic design principle here is that of helper nodes with mutual exclusion and collective exhaustion of the given topology. The protocol works with a simple neighbor management strategy, where all the nodes engage in a simple neighbor discovery procedure only. When a host wants to send a packet, it checks its neighbor list to see if the destination is within one hop. If it is so, the packet is delivered. Otherwise, the packet is duplicated and sent to all the support nodes in its neighborhood (hosts always find a support node in their neighborhood largely because the size of a support nodes zone are calculated with the transmission range of the node in mind. For example, if the transmission range is 250 meters, the zone size is 125*125 square meters. This means that a support node in a zone is a neighbor to all the hosts within it, and since the zones collectively cover the entire topology, in effect, every part of the topology has a support node in it. Also, since a support node is in direct communication range with other support nodes adjacent to it, and this is true for all the support nodes taken pairwise, the support nodes actually end up forming an internally connected “core mesh”. The present description of PRP uses external nodes (i.e. specialized devices that can be given eternal power supply). Note that routes computed do not easily go obsolete, and hosts use a very lightweight algorithm when wanting to send a packet. 5.2 Energy Efficiency This arena has been approached to provide solutions that are independent of underlying routing techniques. Hence, they fail to optimise performance for any one particular routing framework. Known techniques that use a Helper Node like concept are Span (which calls it coordinator nodes) and Geographical Adaptive Fidelity or GAF. Span is not very compatible with AODV or DSR largely because the key benefit of lesser control messages of these reactive strategies is taken away as Span requires a Hello Packet every second, while AODV and DSR are the most popular protocols today. GAF does show some compatibility with AODV and DSR though, but these routing frameworks lack the desirable property of connecting topologies. Venkataraman Expires 19 November 2004 [Page 8] Internet Draft Stack 19 May 2004 An interesting observation at this layer is that of the significance of internal and external helper nodes. Internal helper nodes necessarily come from a part of the deployed hosts. There are obvious limitations to network lifetime when doing this (Span uses internal helper nodes by our definitions). This is because all the nodes in the topology are battery powered. On the other hand, external helper nodes can be given eternal power supply. This makes a big difference, since an external helper node need not be replaced in time (there is no power drain for them, so they don’t need to be replaced as Span or GAF presently do). Note that PRP leverages the use of Span and GAF over it (since it too requires only a Hello Packet, and functionalities can be potentially piggybacked). 5.3 Medium Access A popular or rather a standard protocol here is the IEEE 802.11 protocol, with a 802.11’s Power Saving Mode (PSM), which uses ATIM windows. The 802.11 standard cripples the capacity of ad hoc networks in general, largely because the RTS/CTS packets experience interference with normal data packets already in transit. The situation worsens because of 802.11’s exponential backoff mechanism. One way to counter this problem is to split the available bandwidth into two portions: a large bulk towards transmission of normal data packets and a much smaller portion towards transmission of control packets (RTS/CTS). This effectively separates data and control traffic into different regions of the bandwidth, though with a small sacrifice in the available bandwidth. Helper nodes in the topology can further add to the benefits by actively participating in resource allocation. The RTS/CTS dialogue can be modified such that nodes send a Hello Packet every second stating their intent to transmit to the helper node in that zone as well. Note that this is sent in the control channel, and hence experiences no interference with normal data transmission. These intent-packets can be either sent to the helper node in that zone (a more centralized design choice) or to peers straightaway (more distributed). The basic difference here is a point-to-point or broadcast transmission. Nodes may additionally include information like the number of slots that they will actively want to transmit (there may be an upper bound on the number of slots one can reserve to improve mean delay and prevent starvation). Note that this piece of information leads to better scheduling. 5.4 Transmission Policies It is clear that one has to integrate TCP over MANETs at some point of time, largely to be interoperable with the present Internet base. One primary reason for TCP’s failure here is that TCP is highly optimised for wired networks, and was never Venkataraman Expires 19 November 2004 [Page 9] Internet Draft Stack 19 May 2004 designed with ad hoc networks (or basically over wireless links) in mind. While support nodes may not do much about high bit error rates in wireless channels, use of protocols like PRP underneath which does very well to maintain connected topologies greatly benefits protocols like TCP. As far as higher bit error rates are concerned and TCP’s misassumption that all packet losses are indeed due to congestion, we envisage a lightweight layer beneath TCP, which might make it more “intelligent” and aware of the multihop wireless links. 5.5 Application Packages Performance degrades as the number of hops that a packet traverses increases, and each hop taxes energy and bandwidth while increasing the chances of interference. It is hence clear that the traffic should be as localized as possible. In other words, the stress is on “neighboring” services rather that blatant service discovery. Pervasive computing environments will be a collaboration of humans, devices and their wireless interconnects. It will be natural to use attributes like gait, speech or gestures for bridging the gap between man and machine. The envisaged application layer is hence a “smart” blend of local traffic with an intensive stress on real time streaming applications. While a PRP like framework (or in general the MANET framework) amends itself well to localized traffic, there is little thought about the requirements of these streaming applications. To address this, one has to consider two aspects: one is the tight delivery bounds that these applications demand; two, these applications cannot take huge variations in the sending rate and hence demand appropriate congestion control; three, the topology should amend itself to the use of these application specific congestion control. Use of a framework like PRP naturally means connected topologies and topology maintenance. Hence, the first aspect is taken care of. These applications do require congestion control more specific to their needs (a note may also be made on underlying architectures that are conducive to the real time streams congestion cause like the Congestion Manager [Balakrishnan03]). Efforts have been made to provide TCP-Friendly congestion control algorithms for these applications (like Binomial Algorithms [Bansal01], DAIMD [Mukundan02] etc.). The third aspect is the degree to which a MANET topology yields itself to the use of more application specific congestion control. A PRP like topology (assuming external helper nodes) amends itself very well to this. Another arena gaining in popularity is “resource discovery”. In contrast to resource discovery in hard wired networks, developers are more keen to come up with mechanisms that do not rely on fixed IP addresses to discover service/resource. Envisioning a highly mobile and dynamic scenario, trend is shifting slowly towards letting a self collaborative ad hoc network tell the end user as to where he can procure his resource (rather than make requests to Venkataraman Expires 19 November 2004 [Page 10] Internet Draft Stack 19 May 2004 common registry servers). An immediate implication here is that this allows users to specify application specific metrics (like a “least loaded” printer). A very good example is the Intentional Naming System (INS) [Adjie-Winoto99]. This system allows users to query and resources to advertise their properties. INS also revolves around a “helper node” concept, where particular nodes are designated as Intentional Name Resolvers (INR). An INR takes up a user query and returns him the result (may be with multiple choices. In the words of the authors, this depends upon unicast, multicast or an anycast). 6. How vital are “Hello Packets”? To scale to a large number of users, information dissemination has to be kept as localized as possible. This means an intense neighbor management system, where nodes are aware of what surrounds them. This information has to be fresh, since nodes are mobile and the scenario dynamic. The only way this can be achieved as of now is for nodes to explicitly inform their neighbors, and do so periodically. We will call any such packet used for a purpose such as this as a “Hello Packet”. Almost all the layers we discussed requires some local information, be it routing, energy efficiency, resource discovery etc. Hello Packets, in some form or another, will certainly be required at some layer in the stack. Note that emanating periodically, to an extent, also makes the design a little bent toward being proactive. On the other hand, a purely reactive approach where nodes do nothing until a session is initiated will not work very well since there is hardly any co-opration among entities (for example, a particular service requires to advertise its presence. If it never does so, it is practically absent from the network). The only way to approach this in a purely reactive fashion would be that an end user issues a query, and nodes around it respond, and if they are unable to satisfy the demands, they originate a similar query and so on until it is found (a form of control flooding). Doing this on each and every instance could prove time consuming. It is also possible for some applications to generate too many “request” packets. Note that while a “request” is sent out into the network and resolution is underway, incoming packets from the higher layers at the end node are buffered. If resolution takes a little long or if packets are generated very fast, the packets are prematurely dropped. Moreover, going by a “helper node” philosophy, advertising presence is rather vital. 7. Summary That which remains of importance is to what degree have we answered the question posed at the beginning of the document: What really constitutes an effective stack for pervasive computing? The contribution of this document is the new perspective offered to stack development in general with the aid of helper nodes. From Section 5, it is clear that use of the helper nodes achieves a key result: that of completely connected topologies (in effect, achieving the real definition of a “network”) and the associated accolades that this property alone brings in to the rest of the layers. Pervasive computing is synonymous to computing anywhere and anytime. While MANETs in part hold the keys to answering the “anywhere” aspect, Venkataraman Expires 19 November 2004 [Page 11] Internet Draft Stack 19 May 2004 little thought has been given to the completing the picture. Helper nodes achieve this task. The crux of our contribution is the following: there has to be a set of nodes in the topology which perform functions beyond normal communication alone, since it is impossible to achieve the desired results with a set of hosts wanting to communicate and offer total mobility. As discussed earlier, these helper nodes could be either internal or external. It is rather straightforward to use external nodes in planned scenarios, like conferences, classrooms and campuses. Internal helper nodes, on the other hand, are the answer to truly ad hoc situations when one is confronted with unforeseen circumstances of wanting to communicate in an ad hoc fashion. The inability of the existing approaches is very evident from the discussion of the emerging stack without helper nodes in the topology. With helper nodes in the topology and the contribution of completely connected topologies offered by the routing layer, the stack design can potentially achieve the following: (i) leverage energy efficiency and/or infuse these modules into the routing layer itself, (ii) amend themselves well to designing newer application layer packages that maximize the benefits of the layers beneath them, (iii) the design yields well to use of application specific congestion control and better load balancing, (iv) increase the capacity of these networks by using smarter medium access policies with the presence of helper nodes in the topology and also lead to better scheduling, (v) use specific and limited control messages to save on bandwidth, (vi) prove lightweight on memory (no bulky routing tables) and computation (lightweight algorithms that do not tax processing, given the fact that they may be revoked often) and (vii) work nicely with TCP since connected topologies ensure a smooth operation. Acknowledgements We would like to thank Dr. R. Bhakthavathsalam (Supercomputer Education and Research Centre, Indian Institute of Science, Bangalore) for his comments and suggestions. Venkataraman Expires 19 November 2004 [Page 12] Internet Draft Stack 19 May 2004 References: [Chen02] Benjie Chen, Kyle Jamieson, Hari Balakrishnan and Robert Morris, “Span: an Energy-Efficient Coordination Algorithm for Topology Maintenance in Ad Hoc Wireless Networks” ACM Wireless Networks Journal, Volume 8, Number 5, September, 2002. [Mukundan04] Mukundan Venkataraman and R. Bhakthavathsalam, “Proximate Runner Protocol for Mobile Ad hoc Wireless Networks”, WMC Conference on Computer Networks and Distributed Systems (CNDS’04), San Diego, California, Jan 2004. [Chatzigiannakis03] I. Chatzigiannakis, S. Nikoletseas and P. Spirakis, “Distributed Communication and Control Algorithms for Ad-hoc Mobile Networks”, in the Journal of Parallel and Distributed Computing (JPDC) Journal, Special Issue on Mobile Ad-hoc Networking and Computing, 63 (2003) 58-74. [Corson99] S. Corson and J. Macker, “Mobile Ad Hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations”, Internet Engineering Task Force (IETF), RFC 2501, Jan 1999. [Perkins94] C. E. Perkins and P. Bhagwat, "Highly dynamic Destination Sequenced Distance Vector routing", Proc. ACM SIGCOMM, 24(4), Oct 1994. [Broch98] J. Broch, D. B. Brosnan and D. A. Maltz, ”The Dynamic Source Routing protocol for mobile ad-hoc wireless networks”, Internet Engineering Task Force (IETF), draft-ietf-manet-dsr-01.txt (Work in Progress). Dec 1998. [Perkins03] C. E. Perkins, E. M. Royer and S. Das, “Ad hoc On-Demand Distance Vector (AODV) Routing”, Internet Engineering Task Force (IETF), RFC 3561, July 2003. [Balakrishnan01] H. Balakrishnan and S. Seshan, “ The Congestion Manager”, Internet Engineering Task Force (IETF), RFC 3124, June 2001. [Bansal01] D. Bansal and H. Balakrishnan, “ Binomial Congestion Control Algorithms”, Proc. IEEE Infocom, April 2001. [Mukundan02] Mukundan Venkataraman, “On a TCP-Friendly Linear Congestion Control Algorithm for Real Time Streaming Applications”, Proc. IEEE 11th Annual Symposium on System on a Chip, Bangalore, India, Nov 2002. [Xu01] Ya Xu, John Heidemann and Deborah Estrin, “Geography-informed Energy Conservation for Ad Hoc Routing”, Proc ACM/IEEE International Conference on Mobile Computing and Networking, Rome, Italy, July 2001. [Adjie-Winoto99] William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, and Jeremy Lilley, “Design and implementation of an Intentional Naming System” Operating Systems Review, 34(5). Dec 1999 Venkataraman Expires 19 November 2004 [Page 13] Internet Draft Stack 19 May 2004 Authors Addresses: ------------------ Questions/Comments regarding this document may be forwarded to: Mukundan Venkataraman Software Engineering and Technology Labs B19, Infosys Technologies Ltd. Electronics City Hosur Road, Bangalore Karnataka 560 100, INDIA Email: mukundan_v@infosys.com Fax: +91 (80) 8520740 Puneet Gupta Software Engineering and Technology Labs B19, Infosys Technologies Ltd. Electronics City Hosur Road, Bangalore Karnataka 560 100, INDIA Email: puneet_gupta@infosys.com Phone: +91 (80) 51173944 Fax: +91 (80) 8520740 Venkataraman Expires 19 November 2004 [Page 14]