From wbell@CS.Cornell.EDU Wed Oct 3 11:34:25 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f93FYPo05014 for ; Wed, 3 Oct 2001 11:34:25 -0400 (EDT) Received: from [192.168.1.103] (syr-66-24-16-64.twcny.rr.com [66.24.16.64]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA26124 for ; Wed, 3 Oct 2001 11:34:22 -0400 (EDT) Subject: 615 PAPER #24 From: Walter Bell To: egs@CS.Cornell.EDU Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14.99+cvs.2001.09.29.08.08 (Preview Release) Date: 03 Oct 2001 11:34:10 -0400 Message-Id: <1002123273.1127.3.camel@brute> Mime-Version: 1.0 24) AMRIS: A Multicast Protocol for Ad hoc Wireless Networks AMRIS is a simple multicast protocol based on increasing id numbers that's built to sit on top of an existing unicast routing protocol. AMRIS constructs a multicast tree starting with a special node called the Sid, who by definition has the lowest id in the the tree. From him downward, each node picks a larger number keeping a property that each parent has a lower id than it's children. An important note is that there are large gaps in the sequence space such that it's always possible for a node to pick an id that satisfies this decreasing id property. There are two phases to AMRIS: tree initialization, and tree maintenance. This paper only examines the situation where we have a single sender in the multicast group, who by definition is the special Sid node. The Sid broadcasts a NEW-SESSION message indicating to it's neighbors that it is going to be a sender of a new group, and nodes that are interested in joining respond via JOIN-ACK messages towards the Sid which joins every node from the Sid to each destination to the tree. Nodes pick an id that is greater than that of their parent, which defines the responsibility for reconstruction when a link is broken; nodes with higher id numbers [children] are responsible for re-connecting to the multicast tree when a link is broken. When links are broken, tree maintenance protocols are started, which first send a broadcast to all neighbors to find another node connected to the group, and then a normal join procedure proceeds. Otherwise, a node re-connects to the tree via a multi-hop broadcast storm, which is a JOIN-REQ, to which possible parent nodes respond with a JOIN-ACK, and the route is then setup via a JOIN-CONF message. This two phase commit is used to make sure that only one route gets setup between possible parents and the orphaned node. I think there's a useful insight in AMRIS in it's simplicity of these id's but I think it's too simple to be useful in a real setting as it makes little effort to construct good multicast trees-- any node who wishes to join grabs some arbitrary set of nodes and enlists them as routers in the tree even if there's a better path otherwise. This would use more network resources than would otherwise be needed. From avneesh@csl.cornell.edu Wed Oct 3 23:32:19 2001 Return-Path: Received: from capricorn.ds.csl.cornell.edu (capricorn.csl.cornell.edu [132.236.71.92]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f943WJo29721 for ; Wed, 3 Oct 2001 23:32:19 -0400 (EDT) Subject: 615 Paper 24 Date: Wed, 3 Oct 2001 23:32:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <97C142C1212ED545B0023A177F5349C4053ACC@capricorn.ds.csl.cornell.edu> Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-TNEF-Correlator: Thread-Topic: 615 Paper 24 Thread-Index: AcFMhTJpWLfcJHNDSFm525CbPNqS6A== From: "Avneesh Bhatnagar" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f943WJo29721 AMRIS: A Multicast protocol for Ad hoc Wireless networks Summary/Critique: The AMRIS protocol, provides a simplified idea of how multicast routing could be done, though there are significant issues that the paper does not address. The main approach is that a multicast tree can be constructed with a parent node (sid) which has the lowest sequence number, while the other nodes which join as children have increasing sequence numbers. There is no mention of how this sequence number is chosen, though as long as the parent has a lower sequence number than the child, this should work. The working of the protocol, assimilates a request reply sequence consisting of Join requests and acknowledgments, which are finally ended by a JOIN_CONF message if the link was broken), thus completing the second phase of the Join operation. When a node wants to initialize the tree, it sends a NEW_SESSION message. nodes wishing to join this tree send JOIN_REQs. When a link breaks, the node with the higher id is responsible for joining. The above mentioned two phase messaging is used with the node sending the messages to a potential parent. The JOIN_CONF conserves the tree property, by preventing multiple paths. If there are no potential parents, then a broadcast storm is initiated. The AMRIS protocol brings about very low computational complexity as compared to the traffic that might be generated. There is also no proof about the optimality or 'quality' of the multicast tree, since we just select the first child that responds to join the tree. From papadp@ece.cornell.edu Thu Oct 4 09:52:28 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94DqSo04349 for ; Thu, 4 Oct 2001 09:52:28 -0400 (EDT) Received: from photon (photon.ee.cornell.edu [128.84.239.166]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f94DrJR11856; Thu, 4 Oct 2001 09:53:19 -0400 Date: Thu, 4 Oct 2001 10:01:53 -0400 (EDT) From: "Panagiotis (Panos) Papadimitratos" X-Sender: papadp@photon.ee.cornell.edu To: Emin Gun Sirer cc: Panagiotis Papadimitratos Subject: 615 PAPER 24 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of: "AMRIS: A Multicast Protocol for Ad Hoc Wireless Networks," by C.W. Wu, Y.C. Tay Panagiotis Papadimtratos papadp@ee.cornell.edu The proposed multicast protocol is tree based and relies on the idea of assigning dynamically increasing identity numbers, which represent the logical height of the node and thus allow the rapid formation of the shared tree. The protocol is designed for the MANET context and targets fast adaptation to topological changes, while the tree maintenance related control overhead is limited in general to the region of the link breakage. Moreover, there is no requirement for a unicast protocol, on which AMRIS would rely. Each network node is assigned a multicast session ID (msm-ID) number and order of such ID numbers implies the way multicast data flows from the source to the receivers. Initially, a special node, Sid, the tree root and the node that has the lowest msm-ID , broadcasts a NEW_SESSION packet, which includes the Sid's msm-ID. As neighbor nodes receive the packet, they calculate their own msm-ids by maintaining the constrain/property that the chosen msm-ID is larger than the one specified in the received packet. A significant gap is left between the received and the chosen msm-ID number so that tree maintenance is facilitated. Then, nodes relay the NEW_SESSION packet, after replacing the received msm-ID with their own one and the result is that msm-IDs increase with distance from Sid. Node are also required to broadcast beacons to their neighbors, containing the msm and node IDs, membership status, registered parent and child IDs and partition ID. The beaconing mechanism provides for the link breakage detection: if beacons are not heard for a predefined interval of time, the neighbor is considered to have moved out of the transceiver radio range. Nodes join the multicast session by unicasting JOIN_REQs to a potential parent node (neighbor) with a lower msm-ID. The receiving node replies with JOIN_ACK if it is a member of the multicast group; otherwise, it relays JOIN_REQ_PASSIVE to one potential parent of its own. In case no JOIN_ACK is received, the node performs an expanding ring search (called Branch Reconstruction (BR)) until it succeeds in joining the multicast session. Finally, data forwarding is performed only by nodes that belong to the tree, with packets flowing from the parent to child or vice versa. Packets are assumed to be lost during the tree maintenance, following link breakages. In conclusion, AMRIS advantage is simplicity, no reliance to a unicast protocol, and fast reconfigurations. On the other hand, it lacks the robustness of the mesh-based multicasting mechanisms since there is no route redundancy, and the effects of mobility could severely affect the control overhead, if for example, BRs are the only means for nodes to re-join the session. Furthermore, the tree links can become bottlenecks themselves as the data rate increases, since there are unique routes for data delivery. From daehyun@csl.cornell.edu Thu Oct 4 10:03:35 2001 Return-Path: Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94E3Yo05487 for ; Thu, 4 Oct 2001 10:03:34 -0400 (EDT) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id KAA47740 for egs@cs.cornell.edu; Thu, 4 Oct 2001 10:03:29 -0400 (EDT) (envelope-from daehyun) From: Daehyun Kim Message-Id: <200110041403.KAA47740@wilkes.csl.cornell.edu> Subject: 615 PAPER 24 To: egs@CS.Cornell.EDU Date: Thu, 4 Oct 2001 10:03:29 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper proposes a multicast routing protocol for ad hoc networks called called Ad hoc Multicast Routing protocol utilizing Increasing id-numberS (AMRIS). The basic idea of AMRIS is to maintain a multicast routing tree with id number system. Each node participating in the muticast session is given a unique id called msm-id. The root node of the multicast tree is give the smallest id called Sid, and id numbers increase as they radiate from the root. The ordering between id numbers are used to direct the routing flow. Because id numbers are sparse, connection fail or new node's joining can be handled quickly and locally. The following is the two main procedures; 1. Tree Initialization: This is the mechanism where a multicast tree is constructed. The root of multicast tree broadcast a NEW SESSION messages. By this message, all nodes determines it msm-ids. A node which wants to join the multicast tree, send a JOIN-REQ message to a potential parent, which procedure traverses upward to a node which is already in the tree. Then, a JOIN-ACK message is propagated back to the initiating node. 2. Tree Maintenance: This is the mechanism where a node can join a already existing multicast tree. There are two subroutines, BR1 and BR2. BR1 is used when a potential parent nodes exist and BR2 is used otherwise. Basically, BR1 is a unicast approach, but BR2 is a broadcast. I think AMRIS is a simple algorithm, which give AMRIS low protocol overhead. The simplicity comes from the id system. By using msm-ids, the multicast tree can be managed efficiently. Especially, the sparseness between ids looks a neat idea. In my opinion, AMRIS will find the optimal path. AMRIS tries to construct the multicast tree arbitrarily, so it does not guarantee the shortest path. As they said in the conclusion section, if a clever constraints is given in AMRIS it might result in more optimal tree. In addition, it will be better to show the optimality of the tree found by AMRIS in the simulation results. From c.tavoularis@utoronto.ca Thu Oct 4 10:34:54 2001 Return-Path: Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94EYro09237 for ; Thu, 4 Oct 2001 10:34:53 -0400 (EDT) Received: from webmail1.ns.utoronto.ca ([128.100.132.24] EHLO webmail1.ns.utoronto.ca ident: IDENT-NOT-QUERIED [port 40629]) by bureau6.utcc.utoronto.ca with ESMTP id <238387-25953>; Thu, 4 Oct 2001 10:34:46 -0400 Received: by webmail1.ns.utoronto.ca id <126208-22900>; Thu, 4 Oct 2001 10:34:33 -0400 To: COM S 615 Subject: 615 PAPER 24 Message-ID: <1002206062.3bbc736eb2247@webmail1.ns.utoronto.ca> Date: Thu, 04 Oct 2001 10:34:22 -0400 (EDT) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT User-Agent: IMP/PHP IMAP webmail program 2.2.3 AMRIS (Ad hoc Multicast Routing Protocol utilizing Increasing id-numberS) allows a node to initiate a multicast session on-demand such that each node along the path has an increasing id number. These unique id numbers are used for routing and allow nodes to dynamically leave and join active sessions, as well as adapt to topological changes. AMRIS constructs a shared delivery tree rooted at an initiating node which assigns itself a multicast session member id (msm-id), Sid. During the tree- initialization phase, Sid broadcasts a NEW-SESSION message to all its neighbors indicating its msm-id, session id, and routing metrics. A node receiving the message generates its own msm-id, such that it is greater than the one received. It will store relevant information into its Neighbor-Status table temporarily (approx. 3 beacon intervals) and rebroadcast the message including its msm-id. In this manner, The NEW-SESSION message will propagate to every node in the network. Random jitter is introduced between rebroadcast to prevent broadcast storms caused by all nodes responding simultaneously. Gaps are left between neighboring msm-ids for local repairs. Nodes not interested in the multicast will still participate as forwarding nodes, known as U-Nodes. When a new session is not being propagated, nodes continue to maintain neighbor status through periodic beacons. For a node, X, to join the new session, it must choose a parent node from the set of neighboring nodes with lower msm-ids (closer to Sid). X will choose Y from this set, send it a JOIN-REQ via unicast and wait for a JOIN-ACK. If Y is not part of the delivery tree yet, it will also try to locate a parent node. This process will repeat until a JOIN-ACK is propagated back to X, forming a delivery tree. AMRIS also provides tree maintenance for nodes leaving and joining sessions. When a link breaks, the node with higher msm-id must find a way to rejoin through one of two branch reconstruction routines. In BR1, a node has a potential parent neighbor and performs the same steps as for joining a new session. In BR2, a node cannot find a potential parent node and therefore broadcasts a JOIN-REQ. The node may have more than one candidate to choose from and will have to reply to the selected parent. Simulations results show that performance worsens with greater mobility. This is mainly because soft state beacons determine connectivity and cannot keep up with fast node movement, thus resulting in packet loss. Although trivial, this paper does not specify how Sid keeps track of multicasting members. As for routing, AMRIS does not choose the optimal path in any respect, but simply favors nodes with smaller msm-ids. This algorithm could be improved by using criteria such as distance, number of hops, bandwidth, stability, or battery power when choosing parent nodes. From samar@ece.cornell.edu Thu Oct 4 10:36:16 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94EaGo09635 for ; Thu, 4 Oct 2001 10:36:16 -0400 (EDT) Received: from plato (plato.ece.cornell.edu [128.84.239.28]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f94Eb8R13078 for ; Thu, 4 Oct 2001 10:37:08 -0400 Date: Thu, 4 Oct 2001 10:38:52 -0400 (EDT) From: Prince Samar X-X-Sender: To: Subject: 615 PAPER 24 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 24) AMRIS: A Multicast Protocol for Ad hoc Wireless Networks Ad hoc Multicast Routing protocol utilizing Increasing id-numberS or AMRIS is a reactive multicast protocol for MANETs which is independent of the underlying unicast protocol. AMRIS assigns multicast session id numbers to the participating nodes which monotonically increases as they radiate away from a selected node called Sid. AMRIS constructs a shared delivery tree based on session id numbers to support multiple senders and receivers. These session-ids provide each node with an indication of their logical height in the multicast tree. A special node called Sid, which is selected (how?) from amongst the senders, starts the Initialization phase by broadcasting a NEW-SESSION message to its neighbors. Nodes which receive this message generate their own session ids, which are selected sparse to allow for tree maintenance, and rebroadcast the message. A node desiring to join the session sends a unicast JOIN-REQ to its neighbor with the smallest msm-id. If this neighbor itself is not in the delivery tree, it will try to locate a potential parent for itself in a similar fashion. If this fails, a 1-hop peek approach is used. As a last resort, a node reverts to Branch-Reconstruction (BR) process which has two sub-routines - BR1 and BR2. This paper presents a simple algorithm to construct a multicats tree in an ad hoc network using increasing session-ids. There is no indication how a Sid would be elected for a session from among the multiple senders. Also, selection of a potential parent node based on the smallest msm-id may not be the best way to do it. It may even lead to highly sub-optimal tree generation. Also, it is not clear how are the session numbers generated at each node and how is it guaranteed that they are unique. The authors mention that these msm-ids are sparse which facilitates tree maintenance, but do not describe how sparse they should be. Also, the simulation results and their hypothesis of the optimum beacon period seem too dependent on the mobility model they are using. From eyh5@ee.cornell.edu Thu Oct 4 10:36:17 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94EaHo09642 for ; Thu, 4 Oct 2001 10:36:17 -0400 (EDT) Received: from hegel (hegel.ee.cornell.edu [128.84.236.63]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f94Eb8R13082 for ; Thu, 4 Oct 2001 10:37:08 -0400 Date: Thu, 4 Oct 2001 10:36:14 -0400 (EDT) From: Edward Hua To: egs@CS.Cornell.EDU Subject: 615 Paper # 24 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AMRIS: A Multicast Protocol for Ad hoc Wireless Networks C.W.Wu, Y.C. Tay This paper proposes dynamically assigning nodes in a multicast session with unique ID numbers. The ID number provides a mobile node a logical height in the multicast tree. The value of the ID grows bigger as the node is further away from the root node. The AMRIS algorithm mainly consists of two components, the tree initialization and tree maintenance. Tree initialization first identifies a root node among a number of nodes. From the root node a NEW SESSION message is broadcast and received by neighboring nodes, who then compute their ID values with respect to the values of the nodes they receive the NEW SESSION message from. The main function of tree maintenance is to re-construct a broken link in a multicast tree when a node has moved away. In tree maintenance, the authors use two mechanisms to repair a broken branch: BR1 is used when the detached node has parent nodes (i.e., nodes whose ID values are smaller) nearby, and BR2 is used when no parent nodes are in the vicinity of the detached node. In invoking BR2, the algorithm may have to adjust its transmit power level to accommodate a distant parent node if it has found one. However, that could produce interference to the other nodes. Therefore, when implementing AMRIS, this potential shortcoming needs to be studied and addressed. In addition, the tree maintenance operation does not address the situations of how a node may dissociate itself from the multicast tree and of what would happen when the tree became partitioned. When a node requesting to join a multicast tree receives several acknowledgements from potential parent nodes, it must choose one to be attached to. Here, an improvement may be made where the node, instead of flushing all the other parent nodes, caches them for future reference when there comes a need to merge two or more multicast trees. This scenario happens when the overall network has the tendency to drift apart, potentially resulting in network partitioning. The paper fails to address the choosing of a root node, citing that it is beyond the scope of this paper. However, this is a key issue as it directly impacts the construction of a multicast tree. Also in the performance evaluation, the beacon messages are discounted from the total amount of overhead traffic. They should be included to give a more accurate picture. From gupta@CS.Cornell.EDU Thu Oct 4 10:55:46 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94Etjo11973 for ; Thu, 4 Oct 2001 10:55:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 615 PAPER 24 Date: Thu, 4 Oct 2001 10:55:45 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D430202E3E7@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 24 Thread-Index: AcFM5KI8EJmgSrXPEdW1vgCgydyP2Q== From: "Indranil Gupta" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94Etjo11973 AMRIS: a multicast protocol for ad hoc wireless networks, Wu and Tay. Reviewer: Indranil Gupta This paper proposes a protocol for dynamically managing a multicast tree with group member joins, leaves and link failures. It uses a concept of 'id-numbers' per member of the multicast tree, denoting its distance from the source. Consecutive members along a tree branch choose sequence id's that are some distance apart, so that new nodes can be accomodated in between. Personally, I do not see much intellectual contribution in the idea of maintaining the sequence numbers for each multicast member - a periodic broadcast by the sender should suffice -in fact, if the sender is mobile, this will have to be done anyway. The only possible advantage of the sequence numbers is that the 'direction' away from the source is clearly specified, and this helps to prevent loops. Unfortunately, the paper contains neither a discussion of these issues, nor any non-trivial contribution other than the sequence numbers' idea. From viran@csl.cornell.edu Thu Oct 4 11:36:29 2001 Return-Path: Received: from moore.csl.cornell.edu (moore.csl.cornell.edu [132.236.71.83]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94FaSo17255 for ; Thu, 4 Oct 2001 11:36:28 -0400 (EDT) Received: from localhost (viran@localhost) by moore.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id f94FaNS32467 for ; Thu, 4 Oct 2001 11:36:23 -0400 (EDT) (envelope-from viran@moore.csl.cornell.edu) X-Authentication-Warning: moore.csl.cornell.edu: viran owned process doing -bs Date: Thu, 4 Oct 2001 11:36:23 -0400 (EDT) From: "Virantha N. Ekanayake" To: Subject: 615 Paper 24 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AMRIS is a multicast routing protocol based on building a shared-tree for a multicast session. Each node is assigned a session-specific ID number whose value is proportional to its depth in the tree, with the initiator being at the root of the tree. An interesting detail about AMRIS is that it isn't required to be built on a unicast routing protocol. A multicast session is initiated via a broadcast; all nodes interested in joining the session send a request to potential parents in the tree (based on the ID). The new session information is kept around at a node for a certain interval, allowing neighboring nodes to decide whether to join or not. Most of the conclusions drawn in this paper were fairly obvious and general, with nothing really related to the protocol in question evaluated. In terms of future work, studies on how this protocol works during congestion and when there's high mobility (what if there aren't enough free IDs between nodes to repair links) need to be done. From ranveer@CS.Cornell.EDU Thu Oct 4 11:57:22 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94FvMo20016 for ; Thu, 4 Oct 2001 11:57:22 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 615 PAPER 24 Date: Thu, 4 Oct 2001 11:57:22 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D430203EDD3@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 24 Thread-Index: AcFM7U9fx6m83rdiEdW5awCQJ59Etw== From: "Ranveer Chandra" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94FvMo20016 AMRIS: A Multicast protocol for Ad hoc Wireless networks This paper proposes a simple idea of using increasing Id numbers to build the multicast tree. The initiator of the group has the smallest Id. Subsequently, any other node that wishes to join the multicast tree maintains the increasing Id numbers among tree nodes. The main contribution of the paper is its simplicity and reduction in computational complexity. Minimal state is also stored in the nodes, and AMRIS could also work with any underlying unicast protocol. However, AMRIS is known to fail in the case of tree merge after a network partition. There is also no documentation on how to identify a single sender if more than 1 want to join at the same time. In the simulation, what is the 'packet delivery ratio' in multicast? Besides, AMRIS does not seem to be very responsive to tree merge after a partition. The AMRIS tree is also built around the source which might lead to non-optimal trees. Personally, I feel that better multicast protocols have been proposed, and simplicity at the cost of reliability and responsiveness is not a bargain. From teifel@csl.cornell.edu Thu Oct 4 12:10:13 2001 Return-Path: Received: from disney.csl.cornell.edu (disney.csl.cornell.edu [132.236.71.87]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94GADo21407 for ; Thu, 4 Oct 2001 12:10:13 -0400 (EDT) Received: from localhost (teifel@localhost) by disney.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id f94GA8661929 for ; Thu, 4 Oct 2001 12:10:08 -0400 (EDT) (envelope-from teifel@disney.csl.cornell.edu) X-Authentication-Warning: disney.csl.cornell.edu: teifel owned process doing -bs Date: Thu, 4 Oct 2001 12:10:08 -0400 (EDT) From: "John R. Teifel" To: Subject: 615 PAPER 24 Message-ID: <20011004114204.P14118-100000@disney.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AMRIS: This paper discusses AMRIS (Ad hoc Multicast Routing protocol utilizing Increasiing id-numberS). Every node in a multicast session is dynamically assigned an id-number. The ordering of the id-numbers is used to direct the multicast communication flow. In AMRIS a shared deliver tree is used to support multiple senders and receivers with in a multicast session. The id-numbers are used dynamically leave and join multicast sessions, as well as provide a mechanism to repair routes. Their simulations show that AMRIS has high delivery ratio and low overheads, but doesn't really compare it to the performance of other multicasting protocols. From ramasv@CS.Cornell.EDU Thu Oct 4 12:41:01 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94Gf1o25023 for ; Thu, 4 Oct 2001 12:41:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: cs615 PAPER 24 Date: Thu, 4 Oct 2001 12:41:01 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7F277@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 24 Thread-Index: AcFM81n9b6a2it2ITQG4o+/ZxPViig== From: "Venu Ramasubramanian" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94Gf1o25023 AMRIS: A Multicast Protocol For Ad Hoc Wireless Networks This paper presents a tree based multicast protocol for mobile ad hoc networks. The main contribution of this paper involves using increasing session ids with large gaps to identify downstream nodes and facilitate loop free tree repair. The multicast operations such as join, prune, reapir follow the same patterns as MAODV involving join rreqs, replies and activations. The link breakage is initiated by a downstream node that performs a local join to repair the link. As any tree based multicast protocol AMRIS also suffers from frequent disconnections in the tree due to several link breakages. This decreases the reliability of AMRIS significantly. The sequence numbers are designed such that the downstream node and upstream nodes have a large gap in them to facilitate route maintanance. Such an approach is not a guaranteed approach to prevent loops as you might run out of sequence numbers. The operation of AMRIS with multiple senders is not well defined in this paper. As a marked contrast this paper provides reasonable good simulation including physical layer effects and measuring useful metrics like packet delivery ratio, average latency and control overhead. From haom@csl.cornell.edu Thu Oct 4 14:49:29 2001 Return-Path: Received: from mauchly.csl.cornell.edu (mauchly.csl.cornell.edu [132.236.71.68]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94InSo10986 for ; Thu, 4 Oct 2001 14:49:28 -0400 (EDT) Received: from localhost (haom@localhost) by mauchly.csl.cornell.edu (8.9.3/8.9.2) with ESMTP id OAA83752 for ; Thu, 4 Oct 2001 14:49:23 -0400 (EDT) (envelope-from haom@mauchly.csl.cornell.edu) X-Authentication-Warning: mauchly.csl.cornell.edu: haom owned process doing -bs Date: Thu, 4 Oct 2001 14:49:23 -0400 (EDT) From: Ming Hao To: Emin Gun Sirer Subject: 615 PAPER 24 In-Reply-To: <200110041810.f94IAG602148@hoho.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The Core-Assisted Mesh Protocol by J.J.Garcia-Luna-Aceves and Ewerton L. Madruga the contribution of this paper is that it proposes a new multicasting structure, mesh other than tree. this not only reduce the latency, but also less suffer the link failure with this multiple paths. the cores of the group is used for nodes to join the group. if route to the core is known, the join request is unicasted to it insdead od flooding it to the whole network. Multiple cores are supported. actually the core here does not have a very special role. the algorithm has good idea. but the implementation is clumsy. for example, i think the push-join and requiring the source and intermediate routers to join a group in order to send packets to the group is definitely not necessary. this ont only results in two types of member(simplex and duplex), thus making things more complicated than necessary, but also involes more message overhead. teh simulation configuration kind of go to the extreme to emphasize the mobility of nodes so that making the advantage of CAMP nore prominant than other algorithms. summary: i like the mesh idea of this paper, which i actually thought of it when reviewing first multicast paper. the idea of multiple cores is also very good. but i till think the implementation should be optimized in many places. fro example, avoiding push join every node along the path if the node only want to sends data but not join the group. -ming Ming Hao PH.D Candidate, EE mh97@cornell.edu Cornell University Office: (607) 255-0817 Ithaca, NY 14853 http://www.ee.cornell.edu/~haom/ From jcb35@cornell.edu Tue Oct 16 12:26:09 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9GGQ9o28472 for ; Tue, 16 Oct 2001 12:26:09 -0400 (EDT) Received: from localhost.localdomain (syr-66-66-30-147.twcny.rr.com [66.66.30.147]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA17285 for ; Tue, 16 Oct 2001 12:26:07 -0400 (EDT) Received: from localhost (john@localhost) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f9GGREv04390 for ; Tue, 16 Oct 2001 12:27:14 -0400 Date: Tue, 16 Oct 2001 12:27:13 -0400 (EDT) From: "John C. Bicket" To: egs@CS.Cornell.EDU Subject: 615 PAPER 24 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This paper discussed AMRIS, which is another multicast protocol for ad-hoc networks. By giving each node in a multicast session a id number that increases from a root node, amris can establish a "logical height" of particular nodes and can use this height to determine multicast routing information. When a node wishes to start a multicast session, it sends a new session message that contains an multicast session id to its neighbors. Each node that receives this message computes its own multicast session id, which is larger and not consecutive (for repair purposes) than the originator's multicast session id. To join a group, a node just has to find the nearest node that is in a tree and then pick a session id in line with its new parent. Branch reconstruction is taken care of by forcing the child node that breaks away to perform reconstruction (this is determined by which node has the highest multicast session id). They then either try to find a neighbor on the tree or broadcast a join request message. The paper then presented simulation results. The results did not seem particularly revealing, mainly because they didn't compare the results to any other routing protocols. The paper was very short, and didn't seem to discuss a lot of the particular details of the routing protocols. But the sequence number idea is an interesting one.