From owner-manet@itd.nrl.navy.mil Thu Jun 1 14:47:34 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00120 for ; Thu, 1 Jun 2000 14:47:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA13257 for manet-outgoing; Thu, 1 Jun 2000 13:08:35 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA13252 for ; Thu, 1 Jun 2000 13:08:33 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id MAA06104 for ; Thu, 1 Jun 2000 12:08:32 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id MAA25464 for manet@itd.nrl.navy.mil; Thu, 1 Jun 2000 12:08:20 -0500 (CDT) Date: Thu, 1 Jun 2000 12:08:20 -0500 (CDT) Message-Id: <200006011708.MAA25464@sun.cs.tamu.edu> To: manet@itd.nrl.navy.mil Subject: preliminary program : workshop on ad hoc networking and computing Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk First Annual Workshop on Mobile Ad Hoc Networking & Computing (MobiHoc) ----------------------------------------------------------------------- (in conjuction with the MobiCom 2000 conference) August 11, 2000 Boston Preliminary program for the workshop is posted at http://www.cs.tamu.edu/faculty/vaidya/mobihoc/ Registration information will be made available in the near future. Note that to get the lowest airfares contracted for the event, you may want to book your air ticket sometime soon (see the travel information accessible from the above web site). We will send another announcement once a better-formatted and printer-friendly program is available on the web site. For questions about the MobiHoc workshop, please feel free to contact any of the workshop organizers. ---------------------------------------------------------------------------- Nitin H. Vaidya Associate Professor (office) 979-845-0512 Computer Science Department (FAX) 979-847-8578 Texas A&M University E-mail : vaidya@cs.tamu.edu 3112 TAMU College Station, TX 77843-3112 (Web)http://www.cs.tamu.edu/faculty/vaidya/ From owner-manet@itd.nrl.navy.mil Thu Jun 1 20:00:33 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07291 for ; Thu, 1 Jun 2000 20:00:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA20612 for manet-outgoing; Thu, 1 Jun 2000 18:19:02 -0400 (EDT) Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA20607 for ; Thu, 1 Jun 2000 18:19:01 -0400 (EDT) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with SMTP id SAA01973 for ; Thu, 1 Jun 2000 18:19:00 -0400 (EDT) Date: Thu, 1 Jun 2000 18:19:00 -0400 (EDT) From: Dmitri Deshun Perkins To: manet@itd.nrl.navy.mil Subject: flooding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Can anyone comment on the relative performance of "flooding" as a routing algorithm in ad hoc networks? Have any studies been done that discuss when(under what conditions) it might be advantageous to simply use flooding(at least for control pkts)? Please point me to any papers that discuss this topic. I briefly searched the archives and did not locate a discussion directly related to the above questions. Please excuse me if this topic has already been discussed. Feel free to point me to the correct archives. Thanks for your time, DDP From owner-manet@itd.nrl.navy.mil Thu Jun 1 20:34:39 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07791 for ; Thu, 1 Jun 2000 20:34:38 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA21365 for manet-outgoing; Thu, 1 Jun 2000 19:16:33 -0400 (EDT) Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA21352; Thu, 1 Jun 2000 19:16:22 -0400 (EDT) Message-Id: <4.2.2.20000601185018.0168ba70@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 01 Jun 2000 19:10:22 -0400 To: Dmitri Deshun Perkins , manet@itd.nrl.navy.mil From: Joe Macker Subject: Re: flooding In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 06:19 PM 6/1/00 -0400, Dmitri Deshun Perkins wrote: >Can anyone comment on the relative performance of "flooding" >as a routing algorithm in ad hoc networks? Have any studies >been done that discuss when(under what conditions) it might >be advantageous to simply use flooding(at least for control >pkts)? For what its worth to you, a flooding performance comparison was included in early simulation of ILS (ideal link state) and TORA. The intent was to qualitatively see how well flooding was doing in comparison to the other algorithms. http://tonnant.itd.nrl.navy.mil/tora/tora_sim.html As far as control packets, many algorithms do use forms of broadcast forwarding for some control packets, queries ,etc (also controlled or scoped flooding algorithms have been proposed..even for data ...(see the DSR ID) ..others?) >Please point me to any papers that discuss this topic. >I briefly searched the archives and did not locate a discussion >directly related to the above questions. Please excuse me if >this topic has already been discussed. Feel free to point me >to the correct archives. > > >Thanks for your time, >DDP From owner-manet@itd.nrl.navy.mil Fri Jun 2 06:27:51 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27045 for ; Fri, 2 Jun 2000 06:27:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA27817 for manet-outgoing; Fri, 2 Jun 2000 04:53:22 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA27812 for ; Fri, 2 Jun 2000 04:53:20 -0400 (EDT) Received: from inria.fr (ruspina.inria.fr [128.93.17.52]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e528rH907760; Fri, 2 Jun 2000 10:53:17 +0200 (MET DST) Message-ID: <393786CC.BC45BB78@inria.fr> Date: Fri, 02 Jun 2000 12:05:00 +0200 From: Anis LAOUITI Organization: INRIA X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dmitri Deshun Perkins , manet@itd.nrl.navy.mil Subject: Re: flooding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dmitri Deshun Perkins wrote: > Can anyone comment on the relative performance of "flooding" > as a routing algorithm in ad hoc networks? Have any studies > been done that discuss when(under what conditions) it might > be advantageous to simply use flooding(at least for control > pkts)? > > Please point me to any papers that discuss this topic. > I briefly searched the archives and did not locate a discussion > directly related to the above questions. Please excuse me if > this topic has already been discussed. Feel free to point me > to the correct archives. > > Thanks for your time, > DDP Hi You can take a look to this Research Report "Multipoint relaying : An efficient technique for flooding in mobile wireless networks" ftp://ftp.inria.fr/INRIA/publication/publi-ps-gz/RR/RR-3898.ps.gz This technique is used in OLSR protocol (Optimzed Link State Routing) to flood control information in the network by reducing the number of retransmissions while forwarding a broadcast packet. http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-01.txt Anis LAOUITI From owner-manet@itd.nrl.navy.mil Fri Jun 2 11:46:52 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05553 for ; Fri, 2 Jun 2000 11:46:51 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA02168 for manet-outgoing; Fri, 2 Jun 2000 09:38:49 -0400 (EDT) Received: from ftchakountio.bbn.com (FTCHAKOUNTIO.BBN.COM [128.89.35.251]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA02163 for ; Fri, 2 Jun 2000 09:38:47 -0400 (EDT) Received: from localhost (ftchakou@localhost) by ftchakountio.bbn.com (8.8.8/8.8.8) with SMTP id JAA29594; Fri, 2 Jun 2000 09:41:56 -0400 (EDT) (envelope-from ftchakou@ftchakountio.bbn.com) Date: Fri, 2 Jun 2000 09:41:56 -0400 (EDT) From: Fabrice Tchakountio Reply-To: ftchakou@bbn.com To: manet@itd.nrl.navy.mil cc: ramanath@bbn.com Subject: Path length Distribution in MANET Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi all - Can anyone point me to any papers related to a probabilistic distribution model of the path length between two nodes in Mobile Ad-Hoc Networks ? I've been unable to find any links related to that topic, so far. A positive reply will be greatly appreciated ! Thanks Fabrice.. From owner-manet@itd.nrl.navy.mil Fri Jun 2 11:46:56 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05564 for ; Fri, 2 Jun 2000 11:46:55 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA02900 for manet-outgoing; Fri, 2 Jun 2000 10:07:13 -0400 (EDT) Received: from tnint06.telogy.com (tnint06.telogy.com [209.116.120.7]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA02894 for ; Fri, 2 Jun 2000 10:07:08 -0400 (EDT) Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id ; Fri, 2 Jun 2000 10:06:54 -0400 Message-ID: <61891BA043DED21180920090273F173868C202@TNINT06> From: Alan Amis To: "'Dmitri Deshun Perkins'" , manet@itd.nrl.navy.mil Subject: RE: flooding Date: Fri, 2 Jun 2000 10:06:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Dmitri, Based on previous responses I would assume that you are considering flooding as a means to actually route the control packets. However, if you are looking at flooding to provide the underlying infrastructure for routers in ad hoc networks I can suggest you take a look at a heuristic described in "Max-Min D-Closure Formations in Wireless Ad-Hoc Networks". This paper can be found in the proceeding of INFOCOM 2000. The main juice of this paper is that leaders (or effectively routers) are determined with no node in the network more than D hops away from its leader. The very attractive part of this heuristic is that it runs in D message rounds, not a function of how many nodes are in the network. Alan Amis -----Original Message----- From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] Sent: Thursday, June 01, 2000 6:19 PM To: manet@itd.nrl.navy.mil Subject: flooding Can anyone comment on the relative performance of "flooding" as a routing algorithm in ad hoc networks? Have any studies been done that discuss when(under what conditions) it might be advantageous to simply use flooding(at least for control pkts)? Please point me to any papers that discuss this topic. I briefly searched the archives and did not locate a discussion directly related to the above questions. Please excuse me if this topic has already been discussed. Feel free to point me to the correct archives. Thanks for your time, DDP From owner-manet@itd.nrl.navy.mil Fri Jun 2 12:50:24 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07165 for ; Fri, 2 Jun 2000 12:50:24 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA04944 for manet-outgoing; Fri, 2 Jun 2000 11:11:15 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA04939 for ; Fri, 2 Jun 2000 11:11:13 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e52FB8f16907; Fri, 2 Jun 2000 17:11:08 +0200 (MET DST) Message-Id: <3.0.1.32.20000602171547.0a6b1a70@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 02 Jun 2000 17:15:47 +0200 To: ftchakou@bbn.com, manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET Cc: ramanath@bbn.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id LAA04940 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit What do you mean by path length? The length of the shortest path or the length of the route obtained by a MANET protocol? In both cases you need a model of the network geometry. Philippe A 09:41 02/06/00 -0400, Fabrice Tchakountio a écrit : >Hi all - >Can anyone point me to any papers related to a probabilistic distribution >model of the path length between two nodes in Mobile Ad-Hoc Networks ? >I've been unable to find any links related to that topic, so far. >A positive reply will be greatly appreciated ! >Thanks >Fabrice.. > > > > > > > From owner-manet@itd.nrl.navy.mil Fri Jun 2 12:50:32 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07176 for ; Fri, 2 Jun 2000 12:50:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA05008 for manet-outgoing; Fri, 2 Jun 2000 11:13:54 -0400 (EDT) Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA05001 for ; Fri, 2 Jun 2000 11:13:52 -0400 (EDT) Received: from arctic.cse.msu.edu (arctic.cse.msu.edu [35.9.20.20]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with SMTP id LAA10774; Fri, 2 Jun 2000 11:13:51 -0400 (EDT) Date: Fri, 2 Jun 2000 11:13:51 -0400 (EDT) From: Dmitri Deshun Perkins To: Alan Amis cc: manet@itd.nrl.navy.mil Subject: flooding(point of clarification) In-Reply-To: <61891BA043DED21180920090273F173868C202@TNINT06> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Alan, Thanks for the reply. I just wanted to give a point of clarification to my previous e-mail(flooding). At this point, I am just exploring the issues(routing, security, etc) of ad hoc networks as a possible dissertation topic. As I discuss the routing issues with others(namely, members of my advisory committee and students that attend weekly research meetings), the first question(based only on intuition) is always, "What's wrong with simply using flooding?" I suspect that many of you must get this question as well. Thus, I have been attempting to (quantitatively) answer this question via simulation and wanted to reference other work related to flooding in an ad hoc environment. I have read much of the info concerning routing in an ad hoc environment and was just curious to know if flooding had been considered/rejected as a possible routing solution and if so, why? Again, thanks for your comments. Thanks, Perkins On Fri, 2 Jun 2000, Alan Amis wrote: > Hi Dmitri, > > Based on previous responses I would assume that you are considering > flooding as a means to actually route the control packets. However, > if you are looking at flooding to provide the underlying infrastructure > for routers in ad hoc networks I can suggest you take a look at a > heuristic described in "Max-Min D-Closure Formations in Wireless > Ad-Hoc Networks". This paper can be found in the proceeding of > INFOCOM 2000. The main juice of this paper is that leaders (or > effectively routers) are determined with no node in the network more > than D hops away from its leader. The very attractive part of this > heuristic is that it runs in D message rounds, not a function of how > many nodes are in the network. > > Alan Amis > > -----Original Message----- > From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] > Sent: Thursday, June 01, 2000 6:19 PM > To: manet@itd.nrl.navy.mil > Subject: flooding > > > > > Can anyone comment on the relative performance of "flooding" > as a routing algorithm in ad hoc networks? Have any studies > been done that discuss when(under what conditions) it might > be advantageous to simply use flooding(at least for control > pkts)? > > Please point me to any papers that discuss this topic. > I briefly searched the archives and did not locate a discussion > directly related to the above questions. Please excuse me if > this topic has already been discussed. Feel free to point me > to the correct archives. > > > Thanks for your time, > DDP > From owner-manet@itd.nrl.navy.mil Fri Jun 2 13:45:46 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08247 for ; Fri, 2 Jun 2000 13:45:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA06645 for manet-outgoing; Fri, 2 Jun 2000 12:19:48 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA06640 for ; Fri, 2 Jun 2000 12:19:46 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e52GJVf17553; Fri, 2 Jun 2000 18:19:31 +0200 (MET DST) Message-Id: <3.0.1.32.20000602182411.0a6d8540@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 02 Jun 2000 18:24:11 +0200 To: Dmitri Deshun Perkins , Alan Amis Subject: Re: flooding(point of clarification) Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <61891BA043DED21180920090273F173868C202@TNINT06> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id MAA06641 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Clearly flooding data in the network is resource over-consuming. If your network has 100 nodes, then each data packet needs to be repeated 100 times, thus reducing your efficient bandwidth by a factor 100. Philippe PS: I also have problem on how the IP stack will support this. A 11:13 02/06/00 -0400, Dmitri Deshun Perkins a écrit : > >Hi Alan, > >Thanks for the reply. I just wanted to give a point of clarification >to my previous e-mail(flooding). At this point, I am just exploring >the issues(routing, security, etc) of ad hoc networks as a possible >dissertation topic. As I discuss the routing issues with others(namely, >members of my advisory committee and students that attend weekly research >meetings), the first question(based only on intuition) is always, >"What's wrong with simply using flooding?" I suspect that many of you >must get this question as well. > >Thus, I have been attempting to (quantitatively) answer this question via >simulation and wanted to reference other work related to flooding in an >ad hoc environment. I have read much of the info concerning routing in an >ad hoc environment and was just curious to know if flooding had been >considered/rejected as a possible routing solution and if so, why? Again, >thanks for your comments. > >Thanks, >Perkins > >On Fri, 2 Jun 2000, Alan Amis wrote: > >> Hi Dmitri, >> >> Based on previous responses I would assume that you are considering >> flooding as a means to actually route the control packets. However, >> if you are looking at flooding to provide the underlying infrastructure >> for routers in ad hoc networks I can suggest you take a look at a >> heuristic described in "Max-Min D-Closure Formations in Wireless >> Ad-Hoc Networks". This paper can be found in the proceeding of >> INFOCOM 2000. The main juice of this paper is that leaders (or >> effectively routers) are determined with no node in the network more >> than D hops away from its leader. The very attractive part of this >> heuristic is that it runs in D message rounds, not a function of how >> many nodes are in the network. >> >> Alan Amis >> >> -----Original Message----- >> From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] >> Sent: Thursday, June 01, 2000 6:19 PM >> To: manet@itd.nrl.navy.mil >> Subject: flooding >> >> >> >> >> Can anyone comment on the relative performance of "flooding" >> as a routing algorithm in ad hoc networks? Have any studies >> been done that discuss when(under what conditions) it might >> be advantageous to simply use flooding(at least for control >> pkts)? >> >> Please point me to any papers that discuss this topic. >> I briefly searched the archives and did not locate a discussion >> directly related to the above questions. Please excuse me if >> this topic has already been discussed. Feel free to point me >> to the correct archives. >> >> >> Thanks for your time, >> DDP >> > From owner-manet@itd.nrl.navy.mil Fri Jun 2 13:48:47 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08280 for ; Fri, 2 Jun 2000 13:48:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA06333 for manet-outgoing; Fri, 2 Jun 2000 12:05:38 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA06328 for ; Fri, 2 Jun 2000 12:05:30 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA08758; Fri, 2 Jun 2000 12:05:13 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA06731; Fri, 2 Jun 2000 12:04:08 -0400 (EDT) Received: from kbrayer.mitre.org (129.83.36.88) by mailhub2.mitre.org with SMTP id 3595961; Fri, 02 Jun 2000 12:05:10 EST Message-ID: <3937DF19.49076294@mitre.org> Date: Fri, 02 Jun 2000 12:21:46 -0400 From: Kenneth Brayer Reply-To: kb@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.61C-19990607M (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dmitri Deshun Perkins CC: Alan Amis , manet@itd.nrl.navy.mil Subject: Re: flooding(point of clarification) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dimitri In a fixed network with fixed topology and using shortest path routing you can calculate the traffic level that a network can carry, depending on data rates, error rates, capacities of equipment, etc. If you use flooding you send everything everywhere. That is you send many more packets than are necessary. That is you deny your customer the use of some of the networks capacity. In a MANET you are less efficient at using the network than in a fixed network because the topology is changing and you need to find the path to the packet's destination. Again if you use ONLY flooding you will minimize the total traffic handling capacity of the network. Some flooding may be necessary but it is advantageous to use as little as possible. I was among the first researchers in this area in 1976-1981 before the words MANET and Ad-Hoc were coined. If you look at my routing protocol you will see I used a little flooding at startup but then tried to make the network look as much like fixed path routing as possible. Parts of my protocol have appeared in the internet protocols and in many of the Ad-Hoc protocols under study today. A thesis using only flooding is not useful, in my opinion, as it will give a minimum capability network and is not new. You have to go back to Paul Baran's papers on Hot Potato Routing and work that followed it. I suggest you run the Science Citation Index on Paul Baran and find the papers that reference him. This should uncover papers on flooding. You might also contact Norm Abramson at U. of Hawaii. He invented the Aloha Net back in the 1970s and is probably knowledgeable on flooding papers. A list of my Ad-Hoc papers follows (sorry there are no computer copies, my work preceded on line databases): The Proc. IEEE paper is a good place to get a view of my work. Networking of HF Radio Transmission K. Brayer, IEEE MILCOM'86, Monterey, CA, October 1986 Packet Switching for Mobile Earth Stations via Low-Orbit Satellite Network K. Brayer, Proceedings of the IEEE, November 1984 Autonomous Adaptive Local Area Networking: Ring Communications via Point-to-Point Implementation K. Brayer, IEEE INFOCOM'84, San Francisco, CA, April 1984 An Adaptive Computer Communication Network Designed with Decentralized Control K. Brayer, IEEE Communications Magazine, November 1983 Adaptive Networking of Variable Topology Satellite Networks K. Brayer, Sixth International Conference on Digital Satellite Communications, Phoenix, AZ, September 1983 Routing in a "mobile" network - fact or fantasy? K. Brayer, Data Communications, August 1983 Implementation and Performance of Survivable Computer Communication with Autonomous Decentralized Control K. Brayer, IEEE Communications Magazine, July 1983 Geographically Distributed Control of a Microprocessor Communications Network K. Brayer, IEEE Communications Conference, Boston, MA, June 1983 Implementing Computer Communications with OEM Microprocessors: Survivable Network Routing System K. Brayer, IEEE Globecom'82, Miami, FL, November 1982 Implementing Computer Communications with OEM Microprocessors: Survivable Routing System Performance K. Brayer, IEEE Globecom'82, Miami, FL, November 1982 Survivable Computer Communications Routing using Decentralized Control K. Brayer, IEEE International Conference on Circuits and Computers, New York, NY, September 1982 Simulation via Implementation with Applications in Computer Communication K. Brayer, V.S. Lafleur, G.H. Simpson, 15th Simulation Symposium, Tampa, FL, March 1982 Dmitri Deshun Perkins wrote: > > Hi Alan, > > Thanks for the reply. I just wanted to give a point of clarification > to my previous e-mail(flooding). At this point, I am just exploring > the issues(routing, security, etc) of ad hoc networks as a possible > dissertation topic. As I discuss the routing issues with others(namely, > members of my advisory committee and students that attend weekly research > meetings), the first question(based only on intuition) is always, > "What's wrong with simply using flooding?" I suspect that many of you > must get this question as well. > > Thus, I have been attempting to (quantitatively) answer this question via > simulation and wanted to reference other work related to flooding in an > ad hoc environment. I have read much of the info concerning routing in an > ad hoc environment and was just curious to know if flooding had been > considered/rejected as a possible routing solution and if so, why? Again, > thanks for your comments. > > Thanks, > Perkins > > On Fri, 2 Jun 2000, Alan Amis wrote: > > > Hi Dmitri, > > > > Based on previous responses I would assume that you are considering > > flooding as a means to actually route the control packets. However, > > if you are looking at flooding to provide the underlying infrastructure > > for routers in ad hoc networks I can suggest you take a look at a > > heuristic described in "Max-Min D-Closure Formations in Wireless > > Ad-Hoc Networks". This paper can be found in the proceeding of > > INFOCOM 2000. The main juice of this paper is that leaders (or > > effectively routers) are determined with no node in the network more > > than D hops away from its leader. The very attractive part of this > > heuristic is that it runs in D message rounds, not a function of how > > many nodes are in the network. > > > > Alan Amis > > > > -----Original Message----- > > From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] > > Sent: Thursday, June 01, 2000 6:19 PM > > To: manet@itd.nrl.navy.mil > > Subject: flooding > > > > > > > > > > Can anyone comment on the relative performance of "flooding" > > as a routing algorithm in ad hoc networks? Have any studies > > been done that discuss when(under what conditions) it might > > be advantageous to simply use flooding(at least for control > > pkts)? > > > > Please point me to any papers that discuss this topic. > > I briefly searched the archives and did not locate a discussion > > directly related to the above questions. Please excuse me if > > this topic has already been discussed. Feel free to point me > > to the correct archives. > > > > > > Thanks for your time, > > DDP > > From owner-manet@itd.nrl.navy.mil Fri Jun 2 15:26:50 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11249 for ; Fri, 2 Jun 2000 15:26:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA09710 for manet-outgoing; Fri, 2 Jun 2000 14:04:32 -0400 (EDT) Received: from crystal.bbn.com (CRYSTAL.BBN.COM [128.89.1.232]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA09705 for ; Fri, 2 Jun 2000 14:04:30 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id OAA68026; Fri, 2 Jun 2000 14:14:37 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200006021814.OAA68026@crystal.bbn.com> To: jacquet@menetou.inria.fr cc: ftchakou@bbn.com, manet@itd.nrl.navy.mil, ramanath@bbn.com Subject: Re: Path length Distribution in MANET In-reply-to: Your message of "Fri, 02 Jun 2000 17:15:47 +0200." <3.0.1.32.20000602171547.0a6b1a70@menetou.inria.fr> Date: Fri, 02 Jun 2000 14:14:37 -0400 From: Ram Ramanathan Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Yes, it is model dependent. Let me rephrase Fabrice's question (Fabrice and I are working together on the problem). Given a "randomly generated" (elaborated later) network, what is the expected value of the shortest path between two nodes in the network. Somewhat equivalently, what is the prob that the length of the shortest path between two nodes is equal to K, for K = 1..D, where D = diameter of network. We are looking for answers for any of these "random genartion" models: 1) random graphs (a la Bollobas and his random graph theory, e.g., there exists a link between two nodes with fixed probability p) 2) unit disk graphs (modelling ad hoc networks) 3) manhattan street network with boundaries We would also be interesting in hearing simulation results for specific protocols, e.g., what was the average route hops in a simulation of DSR for a given number of nodes, density etc. thanks in advance, -Ram. > From: jacquet@menetou.inria.fr > Received: from bur-smtp1.bbn.com (bur-smtp1.bbn.com [199.92.105.175]) > by bur-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05503; > Fri, 2 Jun 2000 11:11:17 -0400 (EDT) > Received: by bur-smtp1.bbn.com (8.9.1/8.9.1) id LAA06243; > Fri, 2 Jun 2000 11:11:20 -0400 (EDT) > Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) > by bur-smtp1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA06232; > Fri, 2 Jun 2000 11:11:16 -0400 (EDT) > Received: from prisse (prisse.inria.fr [128.93.9.64]) > by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e52FB8f16907; > Fri, 2 Jun 2000 17:11:08 +0200 (MET DST) > Message-Id: <3.0.1.32.20000602171547.0a6b1a70@menetou.inria.fr> > X-Sender: jacquet@menetou.inria.fr > X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] > Date: Fri, 02 Jun 2000 17:15:47 +0200 > To: ftchakou@bbn.com, manet@itd.nrl.navy.mil > Subject: Re: Path length Distribution in MANET > Cc: ramanath@bbn.com > In-Reply-To: .com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by cam-mbx1.bbn.com id LAA08031 > > What do you mean by path length? The length of the shortest path or the > length of the route obtained by a MANET protocol? In both cases you need a > model of the network geometry. > > Philippe > > A 09:41 02/06/00 -0400, Fabrice Tchakountio a écrit : > >Hi all - > >Can anyone point me to any papers related to a probabilistic distribution > >model of the path length between two nodes in Mobile Ad-Hoc Networks ? > >I've been unable to find any links related to that topic, so far. > >A positive reply will be greatly appreciated ! > >Thanks > >Fabrice.. > > > > > > > > > > > > > > > From owner-manet@itd.nrl.navy.mil Fri Jun 2 15:26:54 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11260 for ; Fri, 2 Jun 2000 15:26:53 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA09860 for manet-outgoing; Fri, 2 Jun 2000 14:10:09 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA09855 for ; Fri, 2 Jun 2000 14:10:07 -0400 (EDT) Received: from brb.isi.edu (brb.isi.edu [128.9.160.181]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA15857; Fri, 2 Jun 2000 11:10:07 -0700 (PDT) Received: (from katia@localhost) by brb.isi.edu (8.9.3/8.8.6) id LAA20091; Fri, 2 Jun 2000 11:10:06 -0700 (PDT) Date: Fri, 2 Jun 2000 11:10:06 -0700 (PDT) Message-Id: <200006021810.LAA20091@brb.isi.edu> From: Katia Obraczka To: perkin27@cse.msu.edu Subject: Re: flooding Cc: manet@itd.nrl.navy.mil Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Date: Thu, 1 Jun 2000 18:19:00 -0400 (EDT) From: Dmitri Deshun Perkins MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Can anyone comment on the relative performance of "flooding" as a routing algorithm in ad hoc networks? Have any studies been done that discuss when(under what conditions) it might be advantageous to simply use flooding(at least for control pkts)? Please point me to any papers that discuss this topic. I briefly searched the archives and did not locate a discussion directly related to the above questions. Please excuse me if this topic has already been discussed. Feel free to point me to the correct archives. Thanks for your time, DDP Dmitri, We have done a comparative study of flooding in the context of multicast routing in MANETs. A paper with our preliminary results appeared in the DIALM99 workshop (soft copy available from http://www.isi.edu:80/people/katia/dialm.ps.gz). We have just written a report on more recent results we got when comparing flooding with other ad hoc multicast routing protocols. If you are interested, I can send you a pointer to that as well. There is also a study by SJ Lee et al. from UCLA comparing their multicast routing protocol ODMRP with other ad hoc multicast protocols, including flooding. If interested I can send you a pointer to that as well. Katia From owner-manet@itd.nrl.navy.mil Fri Jun 2 15:29:05 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11294 for ; Fri, 2 Jun 2000 15:29:04 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA10105 for manet-outgoing; Fri, 2 Jun 2000 14:19:26 -0400 (EDT) Received: from prima.time.saic.com (time.saic.com [205.153.241.31]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA10100 for ; Fri, 2 Jun 2000 14:19:24 -0400 (EDT) Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32]) by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id OAA27059; Fri, 2 Jun 2000 14:19:51 -0400 (EDT) Message-Id: <200006021819.OAA27059@prima.time.saic.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Ram Ramanathan cc: manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET In-Reply-To: Your message of "Fri, 02 Jun 2000 14:14:37 EDT." <200006021814.OAA68026@crystal.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Jun 2000 14:19:23 -0400 From: Ken Carlberg Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Ram, > We are looking for answers for any of these "random genartion" models: > > 1) random graphs (a la Bollobas and his random graph theory, e.g., there > exists a link between two nodes with fixed probability p) > 2) unit disk graphs (modelling ad hoc networks) > 3) manhattan street network with boundaries Have you had a chance to look at Ellen Zegura's work (GA. Tech) on modeling networks? The one paper that comes to mind is: "A Quantitative Comparison of Graph-Based Models". An attractive aspect of the work was the notion of locality with respect to connectivity. The work had sessile (non-moving networks) in mind, but perhaps it be helpful. -ken From owner-manet@itd.nrl.navy.mil Fri Jun 2 15:29:14 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11311 for ; Fri, 2 Jun 2000 15:29:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA09694 for manet-outgoing; Fri, 2 Jun 2000 14:03:20 -0400 (EDT) Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA09689 for ; Fri, 2 Jun 2000 14:03:19 -0400 (EDT) Received: from localhost (talucci@localhost) by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id LAA22703; Fri, 2 Jun 2000 11:03:15 -0700 (PDT) Date: Fri, 2 Jun 2000 11:03:15 -0700 (PDT) From: Fabrizio Talucci To: manet@itd.nrl.navy.mil cc: kb@mitre.org Subject: "Ad-Hoc" trivial question. In-Reply-To: <3937DF19.49076294@mitre.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk To All (especially first researchers), does anybody remember where this "Ad-Hoc" come from? What does it exactly mean? Anything to do with Latin? When was it coined? Who? Thanx, Fabrizio Talucci On Fri, 2 Jun 2000, Kenneth Brayer wrote: > I was among the first researchers in this area in 1976-1981 before the > words MANET and Ad-Hoc were coined. From owner-manet@itd.nrl.navy.mil Fri Jun 2 15:31:34 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11397 for ; Fri, 2 Jun 2000 15:31:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA09439 for manet-outgoing; Fri, 2 Jun 2000 13:52:15 -0400 (EDT) Received: from crystal.bbn.com (CRYSTAL.BBN.COM [128.89.1.232]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA09434 for ; Fri, 2 Jun 2000 13:52:13 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id OAA67959 for ; Fri, 2 Jun 2000 14:02:19 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200006021802.OAA67959@crystal.bbn.com> To: manet@itd.nrl.navy.mil Subject: Re: flooding(point of clarification) In-reply-to: Your message of "Fri, 02 Jun 2000 12:21:46 EDT." <3937DF19.49076294@mitre.org> Date: Fri, 02 Jun 2000 14:02:19 -0400 From: Ram Ramanathan Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I wonder if it is appropriate to dismiss flooding so. Surely, whether flooding is viable in a network or not depends on several parameters including size, radio data rate, traffic load and mobility. For instance, consider a 100 node network of 11 Mbps radios (COTS today). Suppose the only traffic were situational awareness traffic at 3 kbps per node. Assume further that channel access and header overhead etc. reduce the raw data rate of 11 Mbps by a factor of 20 (pessimistically), to yield an effective data rate per node of 550 kbps. Each node then runs comfortably at about 50% utilization. Flooding is an adequate solution. Moreover, as has been pointed out previously on this working group and several papers, if the mobility is extremely high flooding may be the *only* way to deliver data. I am not advocating flooding, or implying that one should tailor network design to low data rate traffic. I am merely pointing out that before one goes off and designs complex schemes, one should examine the viability bounds for the simplest possible solution for the problem -- and Dimitri is asking the right set of questions in this context. Indeed, questions that should have been asked (as Dimitri points out) and answered long ago, but no answers seem to be around? Further, as technology improves (e.g., the data rate), it might be worthwhile examining such brute force methods for limited scenarios. Dimitri: Some recent work that may be relevant on this topic (although perhaps not answering the question directly) Ho et al, "Flooding for Reliable Multicast in Ad hoc networks", DIAL-M Proceedings, 99 Ni et al, "The Broadcast Storm Problem...", Proc. Mobicom 99. and citations therein. Also check out NOAHnet -- this uses data flooding for wired nets. Go to your favorite search engine (I used Google.com) and search for NOAHnet. I would be interested in seeing your analysis of flooding when it is done! -Ram. > Date: Fri, 02 Jun 2000 12:21:46 -0400 > From: Kenneth Brayer > Reply-To: kb@mitre.org > Organization: The MITRE Corporation > X-Mailer: Mozilla 4.61C-19990607M (Macintosh; U; PPC) > X-Accept-Language: en > MIME-Version: 1.0 > To: Dmitri Deshun Perkins > CC: Alan Amis , manet@itd.nrl.navy.mil > Subject: Re: flooding(point of clarification) > References: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: owner-manet@itd.nrl.navy.mil > Precedence: bulk > > Dimitri > > In a fixed network with fixed topology and using shortest path routing > you can calculate the traffic level that a network can carry, depending > on data rates, error rates, capacities of equipment, etc. If you use > flooding you send everything everywhere. That is you send many more > packets than are necessary. That is you deny your customer the use of > some of the networks capacity. In a MANET you are less efficient at > using the network than in a fixed network because the topology is > changing and you need to find the path to the packet's destination. > Again if you use ONLY flooding you will minimize the total traffic > handling capacity of the network. Some flooding may be necessary but it > is advantageous to use as little as possible. > > I was among the first researchers in this area in 1976-1981 before the > words MANET and Ad-Hoc were coined. If you look at my routing protocol > you will see I used a little flooding at startup but then tried to make > the network look as much like fixed path routing as possible. Parts of > my protocol have appeared in the internet protocols and in many of the > Ad-Hoc protocols under study today. > > A thesis using only flooding is not useful, in my opinion, as it will > give a minimum capability network and is not new. You have to go back to > Paul Baran's papers on Hot Potato Routing and work that followed it. I > suggest you run the Science Citation Index on Paul Baran and find the > papers that reference him. This should uncover papers on flooding. You > might also contact Norm Abramson at U. of Hawaii. He invented the Aloha > Net back in the 1970s and is probably knowledgeable on flooding papers. > > A list of my Ad-Hoc papers follows (sorry there are no computer copies, > my work preceded on line databases): The Proc. IEEE paper is a good > place to get a view of my work. > > > Networking of HF Radio Transmission > K. Brayer, IEEE MILCOM'86, Monterey, CA, October 1986 > > > Packet Switching for Mobile Earth Stations via Low-Orbit Satellite Network > K. Brayer, Proceedings of the IEEE, November 1984 > > Autonomous Adaptive Local Area Networking: Ring Communications via > Point-to-Point Implementation > K. Brayer, IEEE INFOCOM'84, San Francisco, CA, April 1984 > > An Adaptive Computer Communication Network Designed with Decentralized Control > K. Brayer, IEEE Communications Magazine, November 1983 > > Adaptive Networking of Variable Topology Satellite Networks > K. Brayer, Sixth International Conference on Digital Satellite Communications, > Phoenix, AZ, September 1983 > > Routing in a "mobile" network - fact or fantasy? > K. Brayer, Data Communications, August 1983 > > Implementation and Performance of Survivable Computer Communication with > Autonomous Decentralized Control > K. Brayer, IEEE Communications Magazine, July 1983 > > Geographically Distributed Control of a Microprocessor Communications Network > K. Brayer, IEEE Communications Conference, Boston, MA, June 1983 > > Implementing Computer Communications with OEM Microprocessors: > Survivable Network Routing System > K. Brayer, IEEE Globecom'82, Miami, FL, November 1982 > > Implementing Computer Communications with OEM Microprocessors: > Survivable Routing System Performance > K. Brayer, IEEE Globecom'82, Miami, FL, November 1982 > > Survivable Computer Communications Routing using Decentralized Control > K. Brayer, IEEE International Conference on Circuits and Computers, > New York, NY, September 1982 > > Simulation via Implementation with Applications in Computer Communication > K. Brayer, V.S. Lafleur, G.H. Simpson, 15th Simulation Symposium, Tampa, > FL, March 1982 > > > Dmitri Deshun Perkins wrote: > > > > Hi Alan, > > > > Thanks for the reply. I just wanted to give a point of clarification > > to my previous e-mail(flooding). At this point, I am just exploring > > the issues(routing, security, etc) of ad hoc networks as a possible > > dissertation topic. As I discuss the routing issues with others(namely, > > members of my advisory committee and students that attend weekly research > > meetings), the first question(based only on intuition) is always, > > "What's wrong with simply using flooding?" I suspect that many of you > > must get this question as well. > > > > Thus, I have been attempting to (quantitatively) answer this question via > > simulation and wanted to reference other work related to flooding in an > > ad hoc environment. I have read much of the info concerning routing in an > > ad hoc environment and was just curious to know if flooding had been > > considered/rejected as a possible routing solution and if so, why? Again, > > thanks for your comments. > > > > Thanks, > > Perkins > > > > On Fri, 2 Jun 2000, Alan Amis wrote: > > > > > Hi Dmitri, > > > > > > Based on previous responses I would assume that you are considering > > > flooding as a means to actually route the control packets. However, > > > if you are looking at flooding to provide the underlying infrastructure > > > for routers in ad hoc networks I can suggest you take a look at a > > > heuristic described in "Max-Min D-Closure Formations in Wireless > > > Ad-Hoc Networks". This paper can be found in the proceeding of > > > INFOCOM 2000. The main juice of this paper is that leaders (or > > > effectively routers) are determined with no node in the network more > > > than D hops away from its leader. The very attractive part of this > > > heuristic is that it runs in D message rounds, not a function of how > > > many nodes are in the network. > > > > > > Alan Amis > > > > > > -----Original Message----- > > > From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] > > > Sent: Thursday, June 01, 2000 6:19 PM > > > To: manet@itd.nrl.navy.mil > > > Subject: flooding > > > > > > > > > > > > > > > Can anyone comment on the relative performance of "flooding" > > > as a routing algorithm in ad hoc networks? Have any studies > > > been done that discuss when(under what conditions) it might > > > be advantageous to simply use flooding(at least for control > > > pkts)? > > > > > > Please point me to any papers that discuss this topic. > > > I briefly searched the archives and did not locate a discussion > > > directly related to the above questions. Please excuse me if > > > this topic has already been discussed. Feel free to point me > > > to the correct archives. > > > > > > > > > Thanks for your time, > > > DDP > > > > From owner-manet@itd.nrl.navy.mil Fri Jun 2 15:37:56 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11469 for ; Fri, 2 Jun 2000 15:37:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA10128 for manet-outgoing; Fri, 2 Jun 2000 14:19:44 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA10123 for ; Fri, 2 Jun 2000 14:19:42 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA29764; Fri, 2 Jun 2000 14:19:41 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA26129; Fri, 2 Jun 2000 14:18:35 -0400 (EDT) Received: from kbrayer.mitre.org (129.83.36.88) by mailhub2.mitre.org with SMTP id 3597957; Fri, 02 Jun 2000 14:19:37 EST Message-ID: <3937FE9D.A9D33541@mitre.org> Date: Fri, 02 Jun 2000 14:36:17 -0400 From: Kenneth Brayer Reply-To: kb@mitre.org Organization: The MITRE Corporation X-Mailer: Mozilla 4.61C-19990607M (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ram Ramanathan CC: manet@itd.nrl.navy.mil Subject: Re: flooding(point of clarification) References: <200006021802.OAA67959@crystal.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Ram Generally some flooding is needed at some time and the more fragmented the net the more you might need. Your example is perfectly fine but is that the only traffic pattern. In general my customer wants a wide variety of traffic in a large complex net so if I can find an approach which preserves capacity for the user that is what I will do. Thus, I seek to minimize flooding, overhead messages, connectivity table distribution etc. There is a large body of literature on flooding but it is more than 30 years old and exists only in hard copy in libraries. I think the IEEE literature search engines available through most libraries will find those citations. Ken Brayer The MITRE Corporation Ram Ramanathan wrote: > > I wonder if it is appropriate to dismiss flooding so. Surely, whether flooding > is viable in a network or not depends on several parameters including size, > radio data rate, traffic load and mobility. > > For instance, consider a 100 node network of 11 Mbps radios (COTS today). > Suppose the only traffic were situational awareness traffic at 3 kbps per > node. Assume further that channel access and header overhead etc. reduce the > raw data rate of 11 Mbps by a factor of 20 (pessimistically), to yield an > effective data rate per node of 550 kbps. Each node then runs comfortably > at about 50% utilization. Flooding is an adequate solution. > > Moreover, as has been pointed out previously on this working group and several > papers, if the mobility is extremely high flooding may be the *only* way > to deliver data. > > I am not advocating flooding, or implying that one should tailor network > design to low data rate traffic. I am merely pointing out that before one > goes off and designs complex schemes, one should examine the viability > bounds for the simplest possible solution for the problem -- and Dimitri > is asking the right set of questions in this context. Indeed, questions > that should have been asked (as Dimitri points out) and answered long ago, > but no answers seem to be around? Further, as technology improves (e.g., > the data rate), it might be worthwhile examining such brute force methods > for limited scenarios. > > Dimitri: > Some recent work that may be relevant on this topic (although perhaps not > answering the question directly) > > Ho et al, "Flooding for Reliable Multicast in Ad hoc networks", DIAL-M > Proceedings, 99 > > Ni et al, "The Broadcast Storm Problem...", Proc. Mobicom 99. > > and citations therein. > > Also check out NOAHnet -- this uses data flooding for wired nets. > Go to your favorite search engine (I used Google.com) and search for NOAHnet. > > I would be interested in seeing your analysis of flooding when it is done! > > -Ram. > > > Date: Fri, 02 Jun 2000 12:21:46 -0400 > > From: Kenneth Brayer > > Reply-To: kb@mitre.org > > Organization: The MITRE Corporation > > X-Mailer: Mozilla 4.61C-19990607M (Macintosh; U; PPC) > > X-Accept-Language: en > > MIME-Version: 1.0 > > To: Dmitri Deshun Perkins > > CC: Alan Amis , manet@itd.nrl.navy.mil > > Subject: Re: flooding(point of clarification) > > References: > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > Sender: owner-manet@itd.nrl.navy.mil > > Precedence: bulk > > > > Dimitri > > > > In a fixed network with fixed topology and using shortest path routing > > you can calculate the traffic level that a network can carry, depending > > on data rates, error rates, capacities of equipment, etc. If you use > > flooding you send everything everywhere. That is you send many more > > packets than are necessary. That is you deny your customer the use of > > some of the networks capacity. In a MANET you are less efficient at > > using the network than in a fixed network because the topology is > > changing and you need to find the path to the packet's destination. > > Again if you use ONLY flooding you will minimize the total traffic > > handling capacity of the network. Some flooding may be necessary but it > > is advantageous to use as little as possible. > > > > I was among the first researchers in this area in 1976-1981 before the > > words MANET and Ad-Hoc were coined. If you look at my routing protocol > > you will see I used a little flooding at startup but then tried to make > > the network look as much like fixed path routing as possible. Parts of > > my protocol have appeared in the internet protocols and in many of the > > Ad-Hoc protocols under study today. > > > > A thesis using only flooding is not useful, in my opinion, as it will > > give a minimum capability network and is not new. You have to go back to > > Paul Baran's papers on Hot Potato Routing and work that followed it. I > > suggest you run the Science Citation Index on Paul Baran and find the > > papers that reference him. This should uncover papers on flooding. You > > might also contact Norm Abramson at U. of Hawaii. He invented the Aloha > > Net back in the 1970s and is probably knowledgeable on flooding papers. > > > > A list of my Ad-Hoc papers follows (sorry there are no computer copies, > > my work preceded on line databases): The Proc. IEEE paper is a good > > place to get a view of my work. > > > > > > Networking of HF Radio Transmission > > K. Brayer, IEEE MILCOM'86, Monterey, CA, October 1986 > > > > > > Packet Switching for Mobile Earth Stations via Low-Orbit Satellite Network > > K. Brayer, Proceedings of the IEEE, November 1984 > > > > Autonomous Adaptive Local Area Networking: Ring Communications via > > Point-to-Point Implementation > > K. Brayer, IEEE INFOCOM'84, San Francisco, CA, April 1984 > > > > An Adaptive Computer Communication Network Designed with Decentralized Control > > K. Brayer, IEEE Communications Magazine, November 1983 > > > > Adaptive Networking of Variable Topology Satellite Networks > > K. Brayer, Sixth International Conference on Digital Satellite Communications, > > Phoenix, AZ, September 1983 > > > > Routing in a "mobile" network - fact or fantasy? > > K. Brayer, Data Communications, August 1983 > > > > Implementation and Performance of Survivable Computer Communication with > > Autonomous Decentralized Control > > K. Brayer, IEEE Communications Magazine, July 1983 > > > > Geographically Distributed Control of a Microprocessor Communications Network > > K. Brayer, IEEE Communications Conference, Boston, MA, June 1983 > > > > Implementing Computer Communications with OEM Microprocessors: > > Survivable Network Routing System > > K. Brayer, IEEE Globecom'82, Miami, FL, November 1982 > > > > Implementing Computer Communications with OEM Microprocessors: > > Survivable Routing System Performance > > K. Brayer, IEEE Globecom'82, Miami, FL, November 1982 > > > > Survivable Computer Communications Routing using Decentralized Control > > K. Brayer, IEEE International Conference on Circuits and Computers, > > New York, NY, September 1982 > > > > Simulation via Implementation with Applications in Computer Communication > > K. Brayer, V.S. Lafleur, G.H. Simpson, 15th Simulation Symposium, Tampa, > > FL, March 1982 > > > > > > Dmitri Deshun Perkins wrote: > > > > > > Hi Alan, > > > > > > Thanks for the reply. I just wanted to give a point of clarification > > > to my previous e-mail(flooding). At this point, I am just exploring > > > the issues(routing, security, etc) of ad hoc networks as a possible > > > dissertation topic. As I discuss the routing issues with others(namely, > > > members of my advisory committee and students that attend weekly research > > > meetings), the first question(based only on intuition) is always, > > > "What's wrong with simply using flooding?" I suspect that many of you > > > must get this question as well. > > > > > > Thus, I have been attempting to (quantitatively) answer this question via > > > simulation and wanted to reference other work related to flooding in an > > > ad hoc environment. I have read much of the info concerning routing in an > > > ad hoc environment and was just curious to know if flooding had been > > > considered/rejected as a possible routing solution and if so, why? Again, > > > thanks for your comments. > > > > > > Thanks, > > > Perkins > > > > > > On Fri, 2 Jun 2000, Alan Amis wrote: > > > > > > > Hi Dmitri, > > > > > > > > Based on previous responses I would assume that you are considering > > > > flooding as a means to actually route the control packets. However, > > > > if you are looking at flooding to provide the underlying infrastructure > > > > for routers in ad hoc networks I can suggest you take a look at a > > > > heuristic described in "Max-Min D-Closure Formations in Wireless > > > > Ad-Hoc Networks". This paper can be found in the proceeding of > > > > INFOCOM 2000. The main juice of this paper is that leaders (or > > > > effectively routers) are determined with no node in the network more > > > > than D hops away from its leader. The very attractive part of this > > > > heuristic is that it runs in D message rounds, not a function of how > > > > many nodes are in the network. > > > > > > > > Alan Amis > > > > > > > > -----Original Message----- > > > > From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] > > > > Sent: Thursday, June 01, 2000 6:19 PM > > > > To: manet@itd.nrl.navy.mil > > > > Subject: flooding > > > > > > > > > > > > > > > > > > > > Can anyone comment on the relative performance of "flooding" > > > > as a routing algorithm in ad hoc networks? Have any studies > > > > been done that discuss when(under what conditions) it might > > > > be advantageous to simply use flooding(at least for control > > > > pkts)? > > > > > > > > Please point me to any papers that discuss this topic. > > > > I briefly searched the archives and did not locate a discussion > > > > directly related to the above questions. Please excuse me if > > > > this topic has already been discussed. Feel free to point me > > > > to the correct archives. > > > > > > > > > > > > Thanks for your time, > > > > DDP > > > > > > From owner-manet@itd.nrl.navy.mil Fri Jun 2 16:01:30 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12029 for ; Fri, 2 Jun 2000 16:01:30 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA11361 for manet-outgoing; Fri, 2 Jun 2000 14:47:18 -0400 (EDT) Received: from ftchakountio.bbn.com (FTCHAKOUNTIO.BBN.COM [128.89.35.251]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA11356 for ; Fri, 2 Jun 2000 14:47:17 -0400 (EDT) Received: from localhost (ftchakou@localhost) by ftchakountio.bbn.com (8.8.8/8.8.8) with SMTP id OAA29922; Fri, 2 Jun 2000 14:50:21 -0400 (EDT) (envelope-from ftchakou@ftchakountio.bbn.com) Date: Fri, 2 Jun 2000 14:50:21 -0400 (EDT) From: Fabrice Tchakountio Reply-To: ftchakou@bbn.com To: jacquet@menetou.inria.fr cc: manet@itd.nrl.navy.mil, ramanath@bbn.com Subject: Re: Path length Distribution in MANET In-Reply-To: <3.0.1.32.20000602171547.0a6b1a70@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Fri, 2 Jun 2000 jacquet@menetou.inria.fr wrote: > What do you mean by path length? The length of the shortest path , assuming for instance , that a version of link-state routing protocol is implemented. Thanks.. From owner-manet@itd.nrl.navy.mil Fri Jun 2 16:24:47 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12532 for ; Fri, 2 Jun 2000 16:24:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA12095 for manet-outgoing; Fri, 2 Jun 2000 15:07:47 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA12090 for ; Fri, 2 Jun 2000 15:07:46 -0400 (EDT) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 374551A040C; Fri, 2 Jun 2000 14:06:22 -0500 (CDT) Received: from localhost (basagni@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id OAA21431; Fri, 2 Jun 2000 14:07:17 -0500 (CDT) X-Authentication-Warning: apache.utdallas.edu: basagni owned process doing -bs Date: Fri, 2 Jun 2000 14:07:17 -0500 (CDT) From: Stefano Basagni To: Fabrizio Talucci Cc: manet@itd.nrl.navy.mil, kb@mitre.org Subject: Re: "Ad-Hoc" trivial question. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > To All (especially first researchers), > does anybody remember where this "Ad-Hoc" come from? Ad hoc (please, no hyphen) has been an English word for over a hundred years (and yes, it has to do with Latin). Here's what the Merriam-Webster on-line has to say: ad hoc * \AD-HAHK or AD-HOKE\ * (adjective) 1 a : concerned with a particular end or purpose b : formed or used for specific or immediate problems or needs 2 : fashioned from whatever is immediately available : improvised Example sentence: When the mayor learned that the mill, the town's main employer, was scheduled to close, he assembled an ad hoc committee to address the crisis. In Latin, "ad hoc" literally means "for this." That historical meaning is clearly reflected in contemporary English uses of "ad hoc" -- anything that is "ad hoc" can be thought of as existing "for this purpose only." For example, an "ad hoc committee" is generally authorized to look into a single matter of limited scope, not to pursue any interesting issue. "Ad hoc" can also be used as an adverb meaning "for the case at hand apart from other applications," as in "a commission created ad hoc." The adverb is the older (it has been used in English since the mid 17th century), but the adjective is no quickly improvised addition to our language; it has been part of English since at least 1879. > When was it coined? > Who? In the multi-hop mobile wireless nets community I do not know who used this name first. I remember to have heard it from Dave Johnson at one of the first mobiCom, but I am not really sure. Would love to know about its genesis. Ciao, St. -- Dr. Stefano Basagni Center for Advanced Telecommunications Systems and Services (CATSS) The University of Texas at Dallas MS EC38 Richardson, TX 75080 Tel. 972 883 2216 ~~~ Fax 972 883 6204 ~~~ E-mail: basagni@utdallas.edu From owner-manet@itd.nrl.navy.mil Fri Jun 2 21:34:19 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18310 for ; Fri, 2 Jun 2000 21:34:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA17656 for manet-outgoing; Fri, 2 Jun 2000 19:46:38 -0400 (EDT) Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA17651 for ; Fri, 2 Jun 2000 19:46:37 -0400 (EDT) Received: from localhost (talucci@localhost) by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id QAA18513; Fri, 2 Jun 2000 16:46:22 -0700 (PDT) Date: Fri, 2 Jun 2000 16:46:22 -0700 (PDT) From: Fabrizio Talucci To: Stefano Basagni cc: manet@itd.nrl.navy.mil, kb@mitre.org Subject: Re: "Ad-Hoc" trivial question. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Thanx, but, of course, by posting in this mailing list I was interested mainly in how this "ad hoc" thing relates to the multihop wireless networks and not, for instance, to the wireless cellular ones. I do have an english dictionary here and, fortunately, somehow I write and read Latin. Exactly my problem! Fabrizo Talucci On 2 Jun 2000, Stefano Basagni wrote: > > To All (especially first researchers), > > does anybody remember where this "Ad-Hoc" come from? > > Ad hoc (please, no hyphen) has been an English word for over a > hundred years (and yes, it has to do with Latin). Here's what the > Merriam-Webster on-line has to say: > > > ad hoc * \AD-HAHK or AD-HOKE\ * (adjective) > > 1 a : concerned with a particular end or purpose b : formed or used > for specific or immediate problems or needs > > 2 : fashioned from whatever is immediately available : improvised > > Example sentence: > When the mayor learned that the mill, the town's main employer, was > scheduled to close, he assembled an ad hoc committee to address the > crisis. > > In Latin, "ad hoc" literally means "for this." That historical meaning > is clearly reflected in contemporary English uses of "ad hoc" -- > anything that is "ad hoc" can be thought of as existing "for this > purpose only." For example, an "ad hoc committee" is generally > authorized to look into a single matter of limited scope, not to > pursue any interesting issue. "Ad hoc" can also be used as an adverb > meaning "for the case at hand apart from other applications," as in "a > commission created ad hoc." The adverb is the older (it has been used > in English since the mid 17th century), but the adjective is no > quickly improvised addition to our language; it has been part of > English since at least 1879. > > > > When was it coined? > > Who? > > In the multi-hop mobile wireless nets community I do not know who used > this name first. I remember to have heard it from Dave Johnson at one of > the first mobiCom, but I am not really sure. Would love to know about > its genesis. > > Ciao, St. > > > > -- > Dr. Stefano Basagni > Center for Advanced Telecommunications Systems and Services (CATSS) > The University of Texas at Dallas MS EC38 Richardson, TX 75080 > Tel. 972 883 2216 ~~~ Fax 972 883 6204 ~~~ E-mail: basagni@utdallas.edu > From owner-manet@itd.nrl.navy.mil Sat Jun 3 04:02:23 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04689 for ; Sat, 3 Jun 2000 04:02:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA21128 for manet-outgoing; Sat, 3 Jun 2000 02:11:44 -0400 (EDT) Received: from sdns.nudt.edu.cn (sdns.nudt.edu.cn [202.197.0.181]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA21123 for ; Sat, 3 Jun 2000 02:10:56 -0400 (EDT) Received: from pdl ([172.26.20.22]) by sdns.nudt.edu.cn (Netscape Messaging Server 3.6) with SMTP id AAA522F; Sat, 3 Jun 2000 15:08:58 +0900 Message-ID: <004201bfcd23$3ed8ac80$16141aac@pdl..nudt.edu.cn> From: "w.peng" To: "Dmitri Deshun Perkins" Cc: Subject: Re: flooding Date: Sat, 3 Jun 2000 14:16:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dmitri, I've done some research on the broadcast problem in mobile ad hoc networks. I've developed two approaches to reduce the broadcast redundancy and compared their performance with flooding. If you are interested in my work, you can take a look to my three papers: 1) "Efficient Broadcast in Mobile Ad Hoc Networks Using Connected Dominating Sets". This paper has been accepted for publication in ICPADS'2000. 2) "AHBP: An Efficient Broadcast Protocol for Mobile Ad Hoc Networks". accepted by Journal of Computer Science And Technology (publicated in Beijing, China). 3) "On the Reduction of Broadcast Redundancy in Mobile Ad Hoc Networks". will appear as a poster in MobiHOC'2000. Because my homepage is under construction, so write to me if you want a copy of my paper. Wei Peng Department of Computer Science, Changsha Institute of Technology, Changsha, Hunan, 410073, P.R.China Email: wpeng@nudt.edu.cn > > >Can anyone comment on the relative performance of "flooding" >as a routing algorithm in ad hoc networks? Have any studies >been done that discuss when(under what conditions) it might >be advantageous to simply use flooding(at least for control >pkts)? > >Please point me to any papers that discuss this topic. >I briefly searched the archives and did not locate a discussion >directly related to the above questions. Please excuse me if >this topic has already been discussed. Feel free to point me >to the correct archives. > > >Thanks for your time, >DDP > > From owner-manet@itd.nrl.navy.mil Sat Jun 3 08:47:49 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05963 for ; Sat, 3 Jun 2000 08:47:49 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA23063 for manet-outgoing; Sat, 3 Jun 2000 07:03:56 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA23058 for ; Sat, 3 Jun 2000 07:03:55 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12yBiY-0006Dw-00; Sat, 03 Jun 2000 12:03:50 +0100 Message-ID: <3938E616.EE1299DC@ee.surrey.ac.uk> Date: Sat, 03 Jun 2000 12:03:50 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: perkin27@cse.msu.edu, manet Subject: Re: flooding References: <61891BA043DED21180920090273F173868C202@TNINT06> <3.0.1.32.20000602182411.0a6d8540@menetou.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dimitri, you may want to have a look at our RDMAR protocol where localisation of Route Discovery as well as of Route Repair is achieved, thus reducing significantly the overhead of flooding the entire network area. See my homepage for some RDMAR papers http://www.ee.surrey.ac.uk/Personal/G.Aggelou/publications.html or the IETF MANET WG homepage for the IETF draft (http://www.ietf.org/html.charters/manet-charter.html). Regards, George N. A. Can anyone comment on the relative performance of "flooding" > >> as a routing algorithm in ad hoc networks? Have any studies > >> been done that discuss when(under what conditions) it might > >> be advantageous to simply use flooding(at least for control > >> pkts)? > >> > >> Please point me to any papers that discuss this topic. > >> I briefly searched the archives and did not locate a discussion > >> directly related to the above questions. Please excuse me if > >> this topic has already been discussed. Feel free to point me > >> to the correct archives. > >> > >> > >> Thanks for your time, > >> DDP > >> > > -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Centre for Communications Systems Research Mobile Communications Research Group University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Sat Jun 3 11:46:27 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09360 for ; Sat, 3 Jun 2000 11:46:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA24445 for manet-outgoing; Sat, 3 Jun 2000 10:08:41 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA24440 for ; Sat, 3 Jun 2000 10:08:39 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12yEbL-00075J-00; Sat, 03 Jun 2000 15:08:35 +0100 Message-ID: <39391161.22BDC25@ee.surrey.ac.uk> Date: Sat, 03 Jun 2000 15:08:33 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ram Ramanathan , manet Subject: Re: flooding(point of clarification) References: <200006021802.OAA67959@crystal.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Ram a few comments on your thoughts: > For instance, consider a 100 node network of 11 Mbps radios (COTS today). > Suppose the only traffic were situational awareness traffic at 3 kbps per > node. Assume further that channel access and header overhead etc. reduce the > raw data rate of 11 Mbps by a factor of 20 (pessimistically), to yield an > effective data rate per node of 550 kbps. Each node then runs comfortably > at about 50% utilization. Flooding is an adequate solution. 1) If, according to your assumptions, each node runs at about 50% of its nominated data rate, don't you think this is a major reason to avoid flooding then? Do you believe 50% effective utilisations is a good performanmce indication for protocol design? 2) Uncontrolled propagation of control messages implies that: a. some areas of the network topology are unecessarily disturbed. Hence, even if we accept the 50% effective utilisation for the set of nodes that must propagate this control messaging, say during a Route Discovery process, for the successful discovery of a route, then, however, this 50% is not an acceptable figure for the rest of nodes which even if they don't propagate the route discovery signalling, the discovery will be successful. For example, by localising the route discovery signalling such that only the nodes between the source and destination of the discovery are disturbed, then certainly the rest of the network nodes will enjoy much better channel utilisation rates. b. (adding to a.), in CDMA-based networks where interference levels increase as a function of the user activity (and ), the extra control messaging will increase user interference. Therefore, system capacity will be reduced. c. the probability of collisions at the channel access layer also increases. This in turn implies more retransmissions and the such.... Which in turn implies more delay on per packet forwarding. By any means, your scenario does not show any tradeoffs as what the benefits of using flooding would be _compared_ to when floding is not used. Therefore, I would say that your conclusion "Flooding is an adequate solution" is not true. Regards, George N. A. From owner-manet@itd.nrl.navy.mil Sun Jun 4 00:04:27 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16540 for ; Sun, 4 Jun 2000 00:04:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA00035 for manet-outgoing; Sat, 3 Jun 2000 22:12:55 -0400 (EDT) Received: from crystal.bbn.com (CRYSTAL.BBN.COM [128.89.1.232]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA00030 for ; Sat, 3 Jun 2000 22:12:54 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id WAA72814; Sat, 3 Jun 2000 22:22:57 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200006040222.WAA72814@crystal.bbn.com> To: "George N. Aggelou" cc: Ram Ramanathan , manet Subject: Re: flooding(point of clarification) In-reply-to: Your message of "Sat, 03 Jun 2000 15:08:33 BST." <39391161.22BDC25@ee.surrey.ac.uk> Date: Sat, 03 Jun 2000 22:22:57 -0400 From: Ram Ramanathan Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk George, Your repeated reference to "control messages" tells me you have completely misunderstood me. I was talking about flooding every DATA packet to everywhere in the network. There ARE NO control messages in a "flooding protocol". As I mentioned in my previous note, flooding is clearly not what I would want to use as my routing mechanism all the time. However, understanding in what regions of the n-dimensional space of (datarate, load, mobility, size ..) flooding works, and in what regions it breaks would be valuable -- the example was one point in such a space, to make my point (no pun:) Again, what I suggest is that data flooding might be competitive when 1) mobility is so high that no routing protocol can converge fast enough 2) when offered_load/data_rate is sufficiently low -- this could happen because load is low or as data_rate increases (as is the industry trend) It seems like you've missed the example too, so here are some inline comments. > > > > For instance, consider a 100 node network of 11 Mbps radios (COTS today). > > Suppose the only traffic were situational awareness traffic at 3 kbps per > > node. Assume further that channel access and header overhead etc. reduce the > > raw data rate of 11 Mbps by a factor of 20 (pessimistically), to yield an > > effective data rate per node of 550 kbps. Each node then runs comfortably > > at about 50% utilization. Flooding is an adequate solution. > > 1) If, according to your assumptions, each node runs at about 50% of its > nominated data rate, don't you think this is a major reason to avoid > flooding then? Do you believe 50% effective utilisations is a good > performanmce indication for protocol design? Huh? Are you saying that 50% is too much or that it is too little? If you are saying 50% is too much, i.e., people should run a link at less than this, consider that most ISPs use 50% as a conservative, safe number. If you are saying 50% is too little, you have missed this completely. I use utilization, informally, as load/capacity. In the example, the node effective capacity is 550 kbps. The load is 3kbps*100 (since every packet is sent exactly once (using sequence numbers to purge duplicates) by every node in the network) or 300 kbps. Thus, the utilization is 54.5%. If you want to run it at a higher utilization, sure, that is fine, it supports even higher traffic. For instance, at 90% utilization, it supports 5 kbps at every node. In other words, if you think I shuld be saying 90% instead of 50%, just replace 3kbps by 5kbps in the exampel. > > 2) Uncontrolled propagation of control messages implies that: > What control messages (read above)?! I'll ignore the points a,b,c since it seems like you're talking about the benefits of "constrained flooding" of routing control messages - a noble thought, but largely irrelevant to the discussion. > a. some areas of the network topology are unecessarily disturbed. > Hence, even if we accept the 50% effective utilisation for the set of > nodes that must propagate this control messaging, say during a Route > Discovery process, for the successful discovery of a route, then, > however, this 50% is not an acceptable figure for the rest of nodes > which even if they don't propagate the route discovery signalling, the > discovery will be successful. For example, by localising the route > discovery signalling such that only the nodes between the source and > destination of the discovery are disturbed, then certainly the rest of > the network nodes will enjoy much better channel utilisation rates. > > b. (adding to a.), in CDMA-based networks where interference levels > increase as a function of the user activity (and ), the extra control > messaging will increase user interference. Therefore, system capacity > will be reduced. > > c. the probability of collisions at the channel access layer also > increases. This in turn implies more retransmissions and the such.... > Which in turn implies more delay on per packet forwarding. > > > By any means, your scenario does not show any tradeoffs as what the Didn't say I was showing tradeoffs.... > benefits of using flooding would be _compared_ to when floding is not > used. > Therefore, I would say that your conclusion "Flooding is an adequate > solution" is not true. Of course it is an adequate solution for the particular scenario. Of course it is not in general. Cheers, -Ram. > > > Regards, > George N. A. > From owner-manet@itd.nrl.navy.mil Sun Jun 4 07:32:43 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06841 for ; Sun, 4 Jun 2000 07:32:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA03042 for manet-outgoing; Sun, 4 Jun 2000 05:37:27 -0400 (EDT) Received: from iti-idsc.gov.eg (mail.iti.gov.eg [163.121.12.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA03037 for ; Sun, 4 Jun 2000 05:37:16 -0400 (EDT) Received: from localhost (habanoub@localhost) by iti-idsc.gov.eg (8.9.1b+Sun/8.9.1) with ESMTP id MAA19465 for ; Sun, 4 Jun 2000 12:38:08 +0300 (EET DST) Date: Sun, 4 Jun 2000 12:38:08 +0300 (EET DST) From: SSDP143 To: mobile adhoc group Subject: Broadcast ID Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk we are a group of 3 students at ITI - Egypt, trying to get into the AODV thing , well we could figure some inconsistency regards using the Broadcast ID, and here is what we see: (draft-ietf-manet-aodv-05.txt) 1-(section 4.)the Broadcast ID definition specifies that the Broadcast Id combined with the source node's IP address, UNIQUElY identifys the particular route request, here the word PARTICULAR did not show exactly if we are talking about the a PARTICULAR DESTINATION or this PARTICULAR RREQ message., yet that's not the big problem though. 2- (section 9.2) talking about generating RREQ messages; it was stated that " The Broadcast ID field is incremented by one from the last broadcast ID used by the current node FOR THE SAME DESTINATION" which means that the source is keeping track of Broadcast IDs he sent to each destination, this make it available to have 2 RREQ with the same source IP address and Broadcast ID, yet different Destinations, this make s us understand (the previous declaration of Broadcast ID) as for PARTICULAR DESTINATION , rather than PARTICULAR RREQ.... still one more point... 3-(section 9.3)on determining if a node would forward RREQ messages, it checks if a similar message was received before or not, it makes its decision based only upon the "source IP, Broadcast ID" combination, which clearly shows that here the "source IP, and Broadcast ID" combination alone , can UNIQUELY determine a PARTICULAR RREQ message, rather than RREQ message for a particular destination. We hope we had explained what we mean in a clear way. Best regards for all, Azza Hany Morcos From owner-manet@itd.nrl.navy.mil Sun Jun 4 08:42:44 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07326 for ; Sun, 4 Jun 2000 08:42:42 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA03554 for manet-outgoing; Sun, 4 Jun 2000 06:53:12 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA03549 for ; Sun, 4 Jun 2000 06:53:10 -0400 (EDT) Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12yY1j-0005QQ-00; Sun, 04 Jun 2000 11:53:07 +0100 Message-ID: <393A3513.271EDC93@ee.surrey.ac.uk> Date: Sun, 04 Jun 2000 11:53:07 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ram Ramanathan , manet Subject: Re: flooding(point of clarification) References: <200006040222.WAA72814@crystal.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Ram, My previous comments address some problems of flooding "control signalling" in a MANET as your wording "traffic" in your first message was interpreted as "routing-related control + data traffic". Apologies for the confusion then. Best, George N.A. > Your repeated reference to "control messages" tells me you have completely > misunderstood me. I was talking about flooding every DATA packet to > everywhere in the network. > There ARE NO control messages in a "flooding protocol". As I mentioned in my previous note, flooding is clearly not what > I would want to use as my routing mechanism all the time. However, > understanding in what > regions of the n-dimensional space of (datarate, load, mobility, size ..) > flooding works, and in what regions it breaks would be valuable -- the > example was one point in such a space, to make my point (no pun:) > > Again, what I suggest is that data flooding might be competitive when > 1) mobility is so high that no routing protocol can converge fast enough > 2) when offered_load/data_rate is sufficiently low -- this could happen > because load is low or as data_rate increases (as is the industry trend) > > It seems like you've missed the example too, so here are some inline > comments. > > > > > > > > For instance, consider a 100 node network of 11 Mbps radios (COTS today). > > > Suppose the only traffic were situational awareness traffic at 3 kbps per > > > node. Assume further that channel access and header overhead etc. reduce the > > > raw data rate of 11 Mbps by a factor of 20 (pessimistically), to yield an > > > effective data rate per node of 550 kbps. Each node then runs comfortably > > > at about 50% utilization. Flooding is an adequate solution. > > > > 1) If, according to your assumptions, each node runs at about 50% of its > > nominated data rate, don't you think this is a major reason to avoid > > flooding then? Do you believe 50% effective utilisations is a good > > performanmce indication for protocol design? > > Huh? Are you saying that 50% is too much or that it is too little? > > If you are saying 50% is too much, i.e., people should run a link at less > than this, consider that most ISPs use 50% as a conservative, safe number. > > If you are saying 50% is too little, you have missed this completely. > I use utilization, informally, as load/capacity. In the example, the node > effective capacity is 550 kbps. The load is 3kbps*100 (since every packet > is sent exactly once (using sequence numbers to purge duplicates) by every > node in the network) or 300 kbps. Thus, the utilization is 54.5%. > > If you want to run it at a higher utilization, sure, that is fine, it > supports even higher traffic. For instance, at 90% utilization, it > supports 5 kbps at every node. In other words, if you think I shuld > be saying 90% instead of 50%, just replace 3kbps by 5kbps in the exampel. > > > > > 2) Uncontrolled propagation of control messages implies that: > > > > What control messages (read above)?! > > I'll ignore the points a,b,c since it seems like you're talking about > the benefits of "constrained flooding" of routing control messages - > a noble thought, but largely irrelevant to the discussion. > > > a. some areas of the network topology are unecessarily disturbed. > > Hence, even if we accept the 50% effective utilisation for the set of > > nodes that must propagate this control messaging, say during a Route > > Discovery process, for the successful discovery of a route, then, > > however, this 50% is not an acceptable figure for the rest of nodes > > which even if they don't propagate the route discovery signalling, the > > discovery will be successful. For example, by localising the route > > discovery signalling such that only the nodes between the source and > > destination of the discovery are disturbed, then certainly the rest of > > the network nodes will enjoy much better channel utilisation rates. > > > > b. (adding to a.), in CDMA-based networks where interference levels > > increase as a function of the user activity (and ), the extra control > > messaging will increase user interference. Therefore, system capacity > > will be reduced. > > > > c. the probability of collisions at the channel access layer also > > increases. This in turn implies more retransmissions and the such.... > > Which in turn implies more delay on per packet forwarding. > > > > > > By any means, your scenario does not show any tradeoffs as what the > > Didn't say I was showing tradeoffs.... > > > benefits of using flooding would be _compared_ to when floding is not > > used. > > Therefore, I would say that your conclusion "Flooding is an adequate > > solution" is not true. > > Of course it is an adequate solution for the particular scenario. Of > course it is not in general. > > Cheers, > > -Ram. > > > > > > > Regards, > > George N. A. > > -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Centre for Communications Systems Research Mobile Communications Research Group University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Sun Jun 4 11:14:38 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08197 for ; Sun, 4 Jun 2000 11:14:38 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA04580 for manet-outgoing; Sun, 4 Jun 2000 09:25:09 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA04574 for ; Sun, 4 Jun 2000 09:25:07 -0400 (EDT) Received: from photon.cs.tamu.edu (IDENT:2654@photon [128.194.134.1]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id IAA12833; Sun, 4 Jun 2000 08:25:03 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by photon.cs.tamu.edu (8.9.3/8.9.3) id IAA08460; Sun, 4 Jun 2000 08:25:09 -0500 (CDT) Date: Sun, 4 Jun 2000 08:25:09 -0500 (CDT) Message-Id: <200006041325.IAA08460@photon.cs.tamu.edu> To: ramanath@bbn.com Subject: Re: flooding(point of clarification) Cc: manet@itd.nrl.navy.mil Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Ram: >> From: Ram Ramanathan ... >> 2) when offered_load/data_rate is sufficiently low -- this could happen >> because load is low or as data_rate increases (as is the industry trend) I agree with the first part of your statement. With sufficiently low load, the cost of finding/maintaining routes could be higher than simply flooding a packet, so flooding could be more effcient. I am not so sure about the second part of your argument ... Correct me if I am mistaken, but I guess what you are saying is that if there is plenty of bandwidth available, the no harm in using it inefficiently. This may not always make sense. For instance, what is bandwidth is abundant, but energy supply isn't ? Just nitpicking -:) - nitin >> >> It seems like you've missed the example too, so here are some inline >> comments. >> >> > >> > >> > > For instance, consider a 100 node network of 11 Mbps radios (COTS today). >> > > Suppose the only traffic were situational awareness traffic at 3 kbps per >> > > node. Assume further that channel access and header overhead etc. reduce the >> > > raw data rate of 11 Mbps by a factor of 20 (pessimistically), to yield an >> > > effective data rate per node of 550 kbps. Each node then runs comfortably >> > > at about 50% utilization. Flooding is an adequate solution. >> > >> > 1) If, according to your assumptions, each node runs at about 50% of its >> > nominated data rate, don't you think this is a major reason to avoid >> > flooding then? Do you believe 50% effective utilisations is a good >> > performanmce indication for protocol design? >> >> Huh? Are you saying that 50% is too much or that it is too little? >> >> If you are saying 50% is too much, i.e., people should run a link at less >> than this, consider that most ISPs use 50% as a conservative, safe number. >> >> If you are saying 50% is too little, you have missed this completely. >> I use utilization, informally, as load/capacity. In the example, the node >> effective capacity is 550 kbps. The load is 3kbps*100 (since every packet >> is sent exactly once (using sequence numbers to purge duplicates) by every >> node in the network) or 300 kbps. Thus, the utilization is 54.5%. >> >> If you want to run it at a higher utilization, sure, that is fine, it >> supports even higher traffic. For instance, at 90% utilization, it >> supports 5 kbps at every node. In other words, if you think I shuld >> be saying 90% instead of 50%, just replace 3kbps by 5kbps in the exampel. >> >> > >> > 2) Uncontrolled propagation of control messages implies that: >> > >> >> What control messages (read above)?! >> >> I'll ignore the points a,b,c since it seems like you're talking about >> the benefits of "constrained flooding" of routing control messages - >> a noble thought, but largely irrelevant to the discussion. >> >> > a. some areas of the network topology are unecessarily disturbed. >> > Hence, even if we accept the 50% effective utilisation for the set of >> > nodes that must propagate this control messaging, say during a Route >> > Discovery process, for the successful discovery of a route, then, >> > however, this 50% is not an acceptable figure for the rest of nodes >> > which even if they don't propagate the route discovery signalling, the >> > discovery will be successful. For example, by localising the route >> > discovery signalling such that only the nodes between the source and >> > destination of the discovery are disturbed, then certainly the rest of >> > the network nodes will enjoy much better channel utilisation rates. >> > >> > b. (adding to a.), in CDMA-based networks where interference levels >> > increase as a function of the user activity (and ), the extra control >> > messaging will increase user interference. Therefore, system capacity >> > will be reduced. >> > >> > c. the probability of collisions at the channel access layer also >> > increases. This in turn implies more retransmissions and the such.... >> > Which in turn implies more delay on per packet forwarding. >> > >> > >> > By any means, your scenario does not show any tradeoffs as what the >> >> Didn't say I was showing tradeoffs.... >> >> > benefits of using flooding would be _compared_ to when floding is not >> > used. >> > Therefore, I would say that your conclusion "Flooding is an adequate >> > solution" is not true. >> >> Of course it is an adequate solution for the particular scenario. Of >> course it is not in general. >> >> Cheers, >> >> -Ram. >> >> > >> > >> > Regards, >> > George N. A. >> > >> >> From owner-manet@itd.nrl.navy.mil Sun Jun 4 15:01:56 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09404 for ; Sun, 4 Jun 2000 15:01:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA06725 for manet-outgoing; Sun, 4 Jun 2000 13:33:06 -0400 (EDT) Received: from spaceghost.fuse.net (spaceghost.fuse.net [216.68.1.121]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA06720 for ; Sun, 4 Jun 2000 13:33:04 -0400 (EDT) Received: from Default ([216.68.190.19]) by spaceghost.fuse.net (InterMail vK.4.02.00.00 201-232-116 license 55099144ff2ca28e37c1a3433615ef97) with SMTP id <20000604173347.MNEM2785.spaceghost@Default>; Sun, 4 Jun 2000 13:33:47 -0400 From: "Samir R. Das" To: "SSDP143" , "mobile adhoc group" Subject: RE: Broadcast ID Date: Sun, 4 Jun 2000 13:34:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, can uniquely identify a particular route request, assuming that the broadcast id is incremented for each route request. One alternative is to increment broadcast id on a per-destination basis and use to uniquely identify requests. Any one technique would be fine. There may be some inconsistency in the draft text in this regard. We will fix it in the next iteration. Thanks for your comments. Samir >-----Original Message----- >From: owner-manet@itd.nrl.navy.mil >[mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of SSDP143 >Sent: Sunday, June 04, 2000 5:38 AM >To: mobile adhoc group >Subject: Broadcast ID > > > >we are a group of 3 students at ITI - Egypt, trying to get into the AODV >thing , well we could figure some inconsistency regards using the >Broadcast ID, and here is what we see: >(draft-ietf-manet-aodv-05.txt) >1-(section 4.)the Broadcast ID definition specifies that the Broadcast Id >combined with the source node's IP address, UNIQUElY identifys the >particular route request, >here the word PARTICULAR did not show exactly if we are talking about the >a PARTICULAR DESTINATION or this PARTICULAR RREQ message., yet that's not >the big problem though. > >2- (section 9.2) talking about generating RREQ messages; it was stated >that " The Broadcast ID field is incremented by one from the last broadcast >ID used by the current node FOR THE SAME DESTINATION" >which means that the source is keeping track of Broadcast IDs he sent to >each destination, this make it available to have 2 RREQ with the same >source IP address and Broadcast ID, yet different Destinations, this make >s us understand (the previous declaration of Broadcast ID) as for >PARTICULAR DESTINATION , rather than PARTICULAR RREQ.... > >still one more point... >3-(section 9.3)on determining if a node would forward RREQ messages, it >checks if a similar message was received before or not, it makes its >decision based only upon the "source IP, Broadcast ID" combination, which >clearly shows that here the "source IP, and Broadcast ID" combination >alone , can UNIQUELY determine a PARTICULAR RREQ message, rather than RREQ >message for a particular destination. > >We hope we had explained what we mean in a clear way. > >Best regards for all, > >Azza >Hany >Morcos > > > > From owner-manet@itd.nrl.navy.mil Sun Jun 4 15:04:52 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09420 for ; Sun, 4 Jun 2000 15:04:52 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA06713 for manet-outgoing; Sun, 4 Jun 2000 13:30:23 -0400 (EDT) Received: from apex.ece.ucsb.edu (apex.ece.ucsb.edu [128.111.56.36]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA06708 for ; Sun, 4 Jun 2000 13:30:21 -0400 (EDT) Received: from pi.ece.ucsb.edu (pi.ece.ucsb.edu [128.111.193.170]) by apex.ece.ucsb.edu (8.9.1/8.9.1) with ESMTP id KAA19182; Sun, 4 Jun 2000 10:30:17 -0700 (PDT) Received: from pi.ece.ucsb.edu (pi.ece.ucsb.edu [128.111.193.170]) by pi.ece.ucsb.edu (8.9.1/8.9.1) with SMTP id KAA08523; Sun, 4 Jun 2000 10:30:19 -0700 (PDT) Message-Id: <200006041730.KAA08523@pi.ece.ucsb.edu> Date: Sun, 4 Jun 2000 10:30:19 -0700 (PDT) From: Elizabeth Royer Reply-To: Elizabeth Royer Subject: Re: Broadcast ID To: habanoub@iti-idsc.gov.eg Cc: manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: j0nH1owyKjLq11+L/Mt8hQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello, In regards to the Broadcast ID of AODV, each node keeps ONE Broadcast ID counter. This counter is incremented EACH time a RREQ is sent for any destination. Hence, the Source IP Address and Broadcast ID will always uniquely identify the RREQ. Your point 3 below is the way it works, not point 2. Because each node only maintains one Broadcast ID counter, there will not be two RREQs with the same Source IP Address / Broadcast ID pair for different destinations. Thanks for pointing out the ambiguous wording. Regards, Elizabeth ~> ~> we are a group of 3 students at ITI - Egypt, trying to get into the AODV ~> thing , well we could figure some inconsistency regards using the ~> Broadcast ID, and here is what we see: ~> (draft-ietf-manet-aodv-05.txt) ~> 1-(section 4.)the Broadcast ID definition specifies that the Broadcast Id ~> combined with the source node's IP address, UNIQUElY identifys the ~> particular route request, ~> here the word PARTICULAR did not show exactly if we are talking about the ~> a PARTICULAR DESTINATION or this PARTICULAR RREQ message., yet that's not ~> the big problem though. ~> ~> 2- (section 9.2) talking about generating RREQ messages; it was stated ~> that " The Broadcast ID field is incremented by one from the last broadcast ~> ID used by the current node FOR THE SAME DESTINATION" ~> which means that the source is keeping track of Broadcast IDs he sent to ~> each destination, this make it available to have 2 RREQ with the same ~> source IP address and Broadcast ID, yet different Destinations, this make ~> s us understand (the previous declaration of Broadcast ID) as for ~> PARTICULAR DESTINATION , rather than PARTICULAR RREQ.... ~> ~> still one more point... ~> 3-(section 9.3)on determining if a node would forward RREQ messages, it ~> checks if a similar message was received before or not, it makes its ~> decision based only upon the "source IP, Broadcast ID" combination, which ~> clearly shows that here the "source IP, and Broadcast ID" combination ~> alone , can UNIQUELY determine a PARTICULAR RREQ message, rather than RREQ ~> message for a particular destination. ~> ~> We hope we had explained what we mean in a clear way. ~> ~> Best regards for all, ~> ~> Azza ~> Hany ~> Morcos ~> ~> ~> ~> From owner-manet@itd.nrl.navy.mil Sun Jun 4 21:51:15 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11903 for ; Sun, 4 Jun 2000 21:51:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA09925 for manet-outgoing; Sun, 4 Jun 2000 20:30:49 -0400 (EDT) Received: from hnl.erg.sri.com (hnl.erg.sri.com [128.18.100.13]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA09920 for ; Sun, 4 Jun 2000 20:30:47 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by hnl.erg.sri.com (8.9.1/8.9.0) with ESMTP id RAA03068; Sun, 4 Jun 2000 17:30:45 -0700 (PDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.8.8+Sun/8.8.8) with ESMTP id RAA21303; Sun, 4 Jun 2000 17:30:25 -0700 (PDT) Message-Id: <200006050030.RAA21303@pit.erg.sri.com> To: Dmitri Deshun Perkins cc: manet@itd.nrl.navy.mil Subject: Re: flooding In-reply-to: Your message of "Thu, 01 Jun 2000 18:19:00 EDT." Date: Sun, 04 Jun 2000 17:30:25 -0700 From: Richard Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > Can anyone comment on the relative performance of "flooding" > as a routing algorithm in ad hoc networks? Have any studies > been done that discuss when(under what conditions) it might > be advantageous to simply use flooding(at least for control > pkts)? > > Please point me to any papers that discuss this topic. > A simulation study comparing flooding (for disseminating link-state updates) to TBRPF (Topology Broadcast based on Reverse Path Forwarding) and to some other routing protocols was presented in the following paper: R.G. Ogier, ``Efficient Routing Protocols for Packet-Radio Networks Based on Tree Sharing,'' Proc. Sixth IEEE Intl. Workshop on Mobile Multimedia Communications (MOMUC'99), November 1999. TBRPF was originally presented in the following paper, but the above paper used more accurate simulation models. B. Bellur and R. G. Ogier, ``A Reliable, Efficient Topology Broadcast Protocol for Dynamic Networks,'' Proc. IEEE INFOCOM '99, New York, March 1 999. These papers can be found at http://www.erg.sri.com/publications.html TBRPF and flooding both provide each node with the state of every link in the network (or within a cluster if hierarchical routing is used), but TBRPF does it more efficiently by sending each update along a min-hop tree rooted at the source of the update. (Thus, for example, leaves of the tree need not forward updates.) TBRPF dynamically updates these broadcast trees using the link-state information that is received along the trees. The simulation results in the MOMUC'99 paper show that TBRPF generates between 36% and 85% less update/control traffic than flooding, depending on the density of the network topology and on whether unicast or broadcast link-level transmissions are used. The MOMUC paper also presents a protocol called FTSP (Full Tree-Sharing Protocol), which is very similar to the ORA (optimal routing) version of STAR. The simulation results also show that TBRPF generates between 14% and 58% less update/control traffic than FTSP, despite the fact that FTSP provides each node with only partial topology information. (TBRPF has not yet been compared to other MANET protocols such as TORA, DSR, and AODV.) Richard Ogier From owner-manet@itd.nrl.navy.mil Mon Jun 5 06:35:53 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27714 for ; Mon, 5 Jun 2000 06:35:52 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA14003 for manet-outgoing; Mon, 5 Jun 2000 04:39:16 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA13998 for ; Mon, 5 Jun 2000 04:39:15 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e558d8T29360; Mon, 5 Jun 2000 10:39:08 +0200 (MET DST) Message-Id: <3.0.1.32.20000605104349.0a6b1c40@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 05 Jun 2000 10:43:49 +0200 To: Ram Ramanathan Subject: Re: Path length Distribution in MANET Cc: ftchakou@bbn.com, manet@itd.nrl.navy.mil In-Reply-To: <200006021814.OAA68026@crystal.bbn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id EAA13999 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit A 14:14 02/06/00 -0400, Ram Ramanathan a écrit : > >Yes, it is model dependent. Let me rephrase Fabrice's question (Fabrice and >I are working together on the problem). > Just few very simple results before you attack the "details" of the problems. > >1) random graphs (a la Bollobas and his random graph theory, e.g., there > exists a link between two nodes with fixed probability p) when the number n of node get large (with p fixed) pair of nodes are at distance 1 with probability p, and distance 2 with probability 1-p. Other distance probabilities tend to zero (exponentially fast in n). Interesting things occurs when p=O(1/n) or p=O(1/sqrt(n)). >2) unit disk graphs (modelling ad hoc networks) If the node density is increasing, the shortest path length between two nodes quickly tends to be ceil of the cartesian distance. Interesting things occurs when the unit is not the disk. >3) manhattan street network with boundaries Nothing specific wireless. the shortest path length equal to the sum of the absolute discrepancies between node coordinates. > >> > From owner-manet@itd.nrl.navy.mil Mon Jun 5 10:30:49 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03223 for ; Mon, 5 Jun 2000 10:30:48 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA17054 for manet-outgoing; Mon, 5 Jun 2000 08:40:27 -0400 (EDT) Received: from angelo.kcl.ac.uk (angelo.kcl.ac.uk [137.73.66.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA17049 for ; Mon, 5 Jun 2000 08:40:24 -0400 (EDT) Received: from somewherekovk4 (EE105.eee.kcl.ac.uk [137.73.11.105]) by angelo.kcl.ac.uk with SMTP id NAA15591 for < manet@itd.nrl.navy.mil>; Mon, 5 Jun 2000 13:40:07 +0100 (BST) Message-ID: <009601bfceeb$89792e80$690b4989@somewherekovk4> From: "Piyush Khengar" To: Date: Mon, 5 Jun 2000 13:42:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01BFCEF3.EAD8BA30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0093_01BFCEF3.EAD8BA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe manet ------=_NextPart_000_0093_01BFCEF3.EAD8BA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe = manet
------=_NextPart_000_0093_01BFCEF3.EAD8BA30-- From owner-manet@itd.nrl.navy.mil Mon Jun 5 12:15:56 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05401 for ; Mon, 5 Jun 2000 12:15:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA19593 for manet-outgoing; Mon, 5 Jun 2000 10:18:43 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA19587 for ; Mon, 5 Jun 2000 10:18:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA15582; Mon, 5 Jun 2000 07:17:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA25334; Mon, 5 Jun 2000 07:17:41 -0700 X-Virus-Scanned: Mon, 5 Jun 2000 07:17:41 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma025189; Mon, 5 Jun 00 07:17:35 -0700 Message-ID: <393BB680.9B9E3355@iprg.nokia.com> Date: Mon, 05 Jun 2000 07:17:36 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jacquet@menetou.inria.fr CC: Ram Ramanathan , ftchakou@bbn.com, manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET References: <3.0.1.32.20000605104349.0a6b1c40@menetou.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, jacquet@menetou.inria.fr wrote: > >1) random graphs (a la Bollobas and his random graph theory, e.g., there > > exists a link between two nodes with fixed probability p) > > when the number n of node get large (with p fixed) pair of nodes are at > distance 1 with probability p, and distance 2 with probability 1-p. Other > distance probabilities tend to zero (exponentially fast in n). Interesting > things occurs when p=O(1/n) or p=O(1/sqrt(n)). This seems like an impossible result, unless there is more to the problem statement. For instance, if p==0, then surely P(distance==2) == 0. If p==0.00000001, then P(distance=2) is not much larger than 0. Besides, this problem statement places no geometric constraint. The two nodes that are farthest apart are equally probable to have a link as the two nodes closest together. Is there some intuition that I can gain to make this problem statement relevant to ad hoc networks that use actual physical media? > >2) unit disk graphs (modelling ad hoc networks) > > If the node density is increasing, the shortest path length between two > nodes quickly tends to be ceil of the cartesian distance. Interesting > things occurs when the unit is not the disk. Can you be more specific? I would have expected that the results would be roughly similar. Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Mon Jun 5 13:30:42 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07049 for ; Mon, 5 Jun 2000 13:30:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA22362 for manet-outgoing; Mon, 5 Jun 2000 11:45:12 -0400 (EDT) Received: from crystal.bbn.com (CRYSTAL.BBN.COM [128.89.1.232]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA22357 for ; Mon, 5 Jun 2000 11:45:11 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id LAA76101; Mon, 5 Jun 2000 11:55:06 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200006051555.LAA76101@crystal.bbn.com> To: Nitin H Vaidya cc: ramanath@bbn.com, manet@itd.nrl.navy.mil Subject: Re: flooding(point of clarification) In-reply-to: Your message of "Sun, 04 Jun 2000 08:25:09 CDT." <200006041325.IAA08460@photon.cs.tamu.edu> Date: Mon, 05 Jun 2000 11:55:05 -0400 From: Ram Ramanathan Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > > > Ram: > > >> From: Ram Ramanathan > ... > >> 2) when offered_load/data_rate is sufficiently low -- this could happen > >> because load is low or as data_rate increases (as is the industry trend) > > I agree with the first part of your statement. > With sufficiently low load, the cost of finding/maintaining > routes could be higher than simply flooding a packet, > so flooding could be more effcient. > > I am not so sure about the second part of your > argument ... Correct me if I am mistaken, but I guess what you > are saying is that if there is plenty of bandwidth available, the > no harm in using it inefficiently. This may not always make sense. More precisely, I was saying that for a given set of requirements/constraints I'd pick the simplest solution, and that flooding may be the simplest solution in some cases, e.g, when you need only to support low load and you have high bandwidth (capacity). > For instance, what is bandwidth is abundant, but energy > supply isn't ? Yes, of course, energy may or may not be an issue. This is but one of several resource constraints (e.g. buffers may be another) that have to be met. > > Just nitpicking -:) > > - nitin -Ram. From owner-manet@itd.nrl.navy.mil Mon Jun 5 13:30:45 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07061 for ; Mon, 5 Jun 2000 13:30:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA22522 for manet-outgoing; Mon, 5 Jun 2000 11:50:10 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA22517 for ; Mon, 5 Jun 2000 11:50:08 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e55FnTT07153; Mon, 5 Jun 2000 17:49:30 +0200 (MET DST) Message-Id: <3.0.1.32.20000605175414.0a6b4e60@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 05 Jun 2000 17:54:14 +0200 To: "Charles E. Perkins" Subject: Re: Path length Distribution in MANET Cc: Ram Ramanathan , ftchakou@bbn.com, manet@itd.nrl.navy.mil In-Reply-To: <393BB680.9B9E3355@iprg.nokia.com> References: <3.0.1.32.20000605104349.0a6b1c40@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id LAA22518 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hello, Charlie, A 07:17 05/06/00 -0700, Charles E. Perkins a écrit : > >Hello, > >jacquet@menetou.inria.fr wrote: > >> >1) random graphs (a la Bollobas and his random graph theory, e.g., there >> > exists a link between two nodes with fixed probability p) >> >> when the number n of node get large (with p fixed) pair of nodes are at >> distance 1 with probability p, and distance 2 with probability 1-p. Other >> distance probabilities tend to zero (exponentially fast in n). Interesting >> things occurs when p=O(1/n) or p=O(1/sqrt(n)). > >This seems like an impossible result, unless there is more to the >problem statement. For instance, if p==0, then surely P(distance==2) == 0. >If p==0.00000001, then P(distance=2) is not much larger than 0. The formula is of the kind P(distance>2) >Besides, this problem statement places no geometric constraint. >The two nodes that are farthest apart are equally probable to >have a link as the two nodes closest together. Is there some >intuition that I can gain to make this problem statement relevant >to ad hoc networks that use actual physical media? > >> >2) unit disk graphs (modelling ad hoc networks) >> >> If the node density is increasing, the shortest path length between two >> nodes quickly tends to be ceil of the cartesian distance. Interesting >> things occurs when the unit is not the disk. > >Can you be more specific? I would have expected that the results >would be roughly similar. The ceil of the cartesian distance is the best you can get (since the number of hops is integer). cartesian distance and shortes path tends to be equivalent when the distances increase. However the distance obtained by flooding significantly differs from shortest path in this model. > > >Regards, >Charlie P. > Regards, Philippe From owner-manet@itd.nrl.navy.mil Mon Jun 5 13:33:22 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07157 for ; Mon, 5 Jun 2000 13:33:20 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA23164 for manet-outgoing; Mon, 5 Jun 2000 12:05:32 -0400 (EDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA23159 for ; Mon, 5 Jun 2000 12:05:30 -0400 (EDT) Received: from cs.duke.edu (amnesia.cs.duke.edu [152.3.137.104]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA11479 for ; Mon, 5 Jun 2000 12:05:25 -0400 (EDT) Message-ID: <393BD038.390F0C06@cs.duke.edu> Date: Mon, 05 Jun 2000 12:07:21 -0400 From: Amin Vahdat Reply-To: vahdat@cs.duke.edu Organization: Duke University X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: flooding (Epidemic Routing) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit In the context of flooding protocols in ad hoc networks, we recently conducted a study on the effectiveness of "controlled" flooding for partially connected ad hoc networks. In the paper, we outline a number of scenarios where a connected path from source to destination is potentially never available, making traditional ad hoc routing protocols inappropriate. The idea is to use epidemic algorithms and logical time vectors to exchange unseen messages among connected neighbors, and using eventual connectivity among "connected" islands to deliver messages to their destination. For the set of experiments we conducted, our algorithms show excellent delivery rates, average delivery times that scale with how "unconnected" the network is, and moderate per-node resource consumption. One direction we are pursuing is the applicability of the algorithms to multicast in ad hoc networks. The paper is available at: http://www.cs.duke.edu/~vahdat/ps/epidemic.pdf The title and abstract are included below. I would appreciate any comments on the paper. -- Amin Vahdat Assistant Professor Duke University http://www.cs.duke.edu/~vahdat Title: Epidemic Routing for Partially-Connected Ad Hoc Networks Abstract: Mobile ad hoc routing protocols allow nodes with wireless adaptors to communicate with one another without any pre-existing network infrastructure. Existing ad hoc routing protocols, while robust to rapidly changing network topology, assume the presence of a connected path from source to destination. Given power limitations, the advent of short-range wireless networks, and the wide physical conditions over which ad hoc networks must be deployed, in some scenarios it is likely that this assumption is invalid. In this work, we develop techniques to deliver messages in the case where there is never a connected path from source to destination or when a network partition exists at the time a message is originated. To this end, we introduce Epidemic Routing, where random pair-wise exchanges of messages among mobile hosts ensure eventual message delivery. The goals of Epidemic Routing are to: i) maximize message delivery rate, ii) minimize message latency, and iii) minimize the total resources consumed in message delivery. Through an implementation in the Monarch simulator, we show that Epidemic Routing achieves eventual delivery of 100% of messages with reasonable aggregate resource consumption in a number of interesting scenarios. From owner-manet@itd.nrl.navy.mil Mon Jun 5 15:32:21 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09180 for ; Mon, 5 Jun 2000 15:32:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA26484 for manet-outgoing; Mon, 5 Jun 2000 13:42:26 -0400 (EDT) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA26479 for ; Mon, 5 Jun 2000 13:42:24 -0400 (EDT) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id NAA12704; Mon, 5 Jun 2000 13:42:15 -0400 Date: Mon, 5 Jun 2000 13:42:15 -0400 From: "J. Noel Chiappa" Message-Id: <200006051742.NAA12704@ginger.lcs.mit.edu> To: manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET Cc: charliep@iprg.nokia.com, jacquet@menetou.inria.fr, jnc@ginger.lcs.mit.edu, ramanath@bbn.com Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > From: "Charles E. Perkins" >>> 1) random graphs ... e.g., there exists a link between two nodes with >>> fixed probability p) >> when the number n of node get large (with p fixed) pair of nodes are at >> distance 1 with probability p, and distance 2 with probability 1-p. >> Other distance probabilities tend to zero (exponentially fast in n). >> Interesting things occurs when p=O(1/n) or p=O(1/sqrt(n)). > This seems like an impossible result, unless there is more to the > problem statement. For instance, if p==0, then surely P(distance==2) > == 0. If p==0.00000001, then P(distance=2) is not much larger than 0. No, I think it might be correct - note the phrase "when N gets large". Even if you have a low probability of connection to any given node, if there are a very large set of nodes to chose from as an intermediate, the chance of at least one two-hop path existing is pretty good. Well, let's work it out. For a graph of N nodes, the probability of a direct connection between nodes i and j is p. Now, considering two-hop paths, there are N-2 potential intermediate nodes k (i.e. all the nodes in the graph, except i and j). For any node k, the probability of a two-hop path through that node is p^2, so the chance of a path through k not existing is 1-p^2, and the probability that there is no k which is connected to both i and j is (1-p^2)^(N-2). (And the probability that there is at least one would be 1-that, of course...) I've forgotten the math I'd need to take the limit of that as N goes to infinity, but I'll bet the answer is just plain 0 (anything less than 1 multiplied by itself enough times gets vanishingly small). So, the chance that a one-hop path does exist must be 1-0 == 1 (somewhat better than the stated 1-p, which makes no sense anyway - why would the probability go down as the probabilty of a link goes up). > Besides, this problem statement places no geometric constraint. The two > nodes that are farthest apart are equally probable to have a link as > the two nodes closest together. It's worse than that. By saying that the probabilty p of a link existing between i and j is a fixed p, regardless of N, you're saying that the degree D (i.e. number of connections) of any given node goes up at the same rate as the network grows. This is extremely unlikely, physically; much better would be a model with constant D. I don't seem to recall much work on such graphs in my graph theory books on random graphs, though (sigh). I do seem to recall a paper by Yakov on memory requirements for BGP which indicated that the average path length in a graph of degree D, as the graph grew, was O(ln(N)); and IIRC he had a cite to a paper showing that. Noel From owner-manet@itd.nrl.navy.mil Mon Jun 5 15:33:57 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09205 for ; Mon, 5 Jun 2000 15:33:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA24190 for manet-outgoing; Mon, 5 Jun 2000 12:30:24 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA24185 for ; Mon, 5 Jun 2000 12:30:22 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id LAA03177; Mon, 5 Jun 2000 11:29:59 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id LAA15255; Mon, 5 Jun 2000 11:29:42 -0500 (CDT) Date: Mon, 5 Jun 2000 11:29:42 -0500 (CDT) Message-Id: <200006051629.LAA15255@sun.cs.tamu.edu> To: ramanath@bbn.com Subject: Re: flooding(point of clarification) Cc: manet@itd.nrl.navy.mil Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> From: Ram Ramanathan >> >> > >> > >> > Ram: ... >> > I am not so sure about the second part of your >> > argument ... Correct me if I am mistaken, but I guess what you >> > are saying is that if there is plenty of bandwidth available, the >> > no harm in using it inefficiently. This may not always make sense. >> >> More precisely, I was saying that for a given set of requirements/constraints >> I'd pick the simplest solution, and that flooding may be the simplest solution >> in some cases, e.g, when you need only to support low load and you have high >> bandwidth (capacity). OK. I would agree with that. - nitin From owner-manet@itd.nrl.navy.mil Mon Jun 5 15:34:14 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09218 for ; Mon, 5 Jun 2000 15:34:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA26525 for manet-outgoing; Mon, 5 Jun 2000 13:44:27 -0400 (EDT) Received: from crystal.bbn.com (CRYSTAL.BBN.COM [128.89.1.232]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA26519 for ; Mon, 5 Jun 2000 13:44:26 -0400 (EDT) Received: from crystal.bbn.com (localhost.bbn.com [127.0.0.1]) by crystal.bbn.com (8.9.3/8.8.8) with ESMTP id NAA76826; Mon, 5 Jun 2000 13:54:12 -0400 (EDT) (envelope-from ramanath@crystal.bbn.com) Message-Id: <200006051754.NAA76826@crystal.bbn.com> To: "Charles E. Perkins" cc: jacquet@menetou.inria.fr, Ram Ramanathan , ftchakou@bbn.com, manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET In-reply-to: Your message of "Mon, 05 Jun 2000 07:17:36 PDT." <393BB680.9B9E3355@iprg.nokia.com> Date: Mon, 05 Jun 2000 13:54:12 -0400 From: Ram Ramanathan Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > Date: Mon, 05 Jun 2000 07:17:36 -0700 > From: "Charles E. Perkins" > Organization: Nokia Research Center > X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) > X-Accept-Language: en > MIME-Version: 1.0 > To: jacquet@menetou.inria.fr > CC: Ram Ramanathan , ftchakou@bbn.com, > manet@itd.nrl.navy.mil > Subject: Re: Path length Distribution in MANET > References: <3.0.1.32.20000605104349.0a6b1c40@menetou.inria.fr> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: owner-manet@itd.nrl.navy.mil > Precedence: bulk > Status: O > > > Hello, > > Besides, this problem statement places no geometric constraint. > The two nodes that are farthest apart are equally probable to > have a link as the two nodes closest together. Is there some > intuition that I can gain to make this problem statement relevant > to ad hoc networks that use actual physical media? I didn't say or mean to imply that it was a good model for ad hoc nets. I was picking the pure random graph and the unit disk graphs as the two "extremes" of a continuum in which a typical ad hoc network might lie -- I believe most ad hoc networks will have some distance dependency, but not depend *only* on distance as unit disk graphs do. Another way to look at it is using the well-known (e.g. see Rappaport's book Wireless Communication) large scale propagation model which says that the actual path loss is log-normally distributed with variance V around a mean path loss computed using some formula (e.g. k1/d^4 + k2). The log-normal distribution is to model "environmental clutter" (e.g. metal objects or other RF barriers). The more the clutter, the higher the V, and more "arbitrary" the graph starts looking. In the extreme, there is so much clutter that whether or not two nodes can communicate has nothing to do with distance, only on the presence or absence of barriers -- which may be purely random. (For practical relevance think gigabit ad hoc nets in the 24 GHz ISM band:) At the other extreme, when there is no clutter at all, the connectivity is purely distance dependent (corresponds to V=0 of log-normal distribution mentioned above). If there are expected path length results for the general model (say as a function of V), that would be great! But I think that is unlikely and so posed the question for the two extremes - which will at least be some insight. -Ram. From owner-manet@itd.nrl.navy.mil Mon Jun 5 16:19:22 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09787 for ; Mon, 5 Jun 2000 16:19:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA27809 for manet-outgoing; Mon, 5 Jun 2000 14:28:01 -0400 (EDT) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA27803 for ; Mon, 5 Jun 2000 14:28:00 -0400 (EDT) Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id OAA12784; Mon, 5 Jun 2000 14:27:50 -0400 Date: Mon, 5 Jun 2000 14:27:50 -0400 From: "J. Noel Chiappa" Message-Id: <200006051827.OAA12784@ginger.lcs.mit.edu> To: manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET Cc: charliep@iprg.nokia.com, jacquet@menetou.inria.fr, jnc@ginger.lcs.mit.edu, ramanath@bbn.com Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > From: "J. Noel Chiappa" > the chance that a one-hop path does exist must be 1-0 == 1 Minor typo - that should be "two-hop path" (i.e. one from i to k, and one from k to j). Noel From owner-manet@itd.nrl.navy.mil Mon Jun 5 16:23:39 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09838 for ; Mon, 5 Jun 2000 16:23:39 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA28781 for manet-outgoing; Mon, 5 Jun 2000 15:03:15 -0400 (EDT) Received: from icarus.lis.pitt.edu (icarus.lis.pitt.edu [136.142.116.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id PAA28772 for ; Mon, 5 Jun 2000 15:03:13 -0400 (EDT) Received: by icarus.lis.pitt.edu (SMI-8.6/1.34) id PAA12138; Mon, 5 Jun 2000 15:03:31 -0400 Date: Mon, 5 Jun 2000 15:03:30 -0400 (EDT) From: "A. Bruce McDonald" Reply-To: "A. Bruce McDonald" Subject: Re: flooding To: manet@itd.nrl.navy.mil In-Reply-To: <393BD038.390F0C06@cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I think that most people would agree that even the *best* routing algorithm will eventually break if the topology changes rapidly enough (it would be interesting to learn what the *fundamental* limitations are---if we could characterize such a thing). I would hasten to add that even the simplest of all routing algorithms, flooding, will itself break down without considerable control. This seems to be an often overlooked reality of routing under extreme conditions. Flooding reliably in the best of circumstances can be difficult. Hence, even flooding may not be as simple as we'd like it to be under these circumstances. --Bruce McDonald University of Pittsburgh From owner-manet@itd.nrl.navy.mil Mon Jun 5 17:45:32 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11010 for ; Mon, 5 Jun 2000 17:45:32 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA00540 for manet-outgoing; Mon, 5 Jun 2000 15:53:05 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA00535 for ; Mon, 5 Jun 2000 15:53:03 -0400 (EDT) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id BBC401A01E5 for ; Mon, 5 Jun 2000 14:51:32 -0500 (CDT) Received: from localhost (ravip@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id OAA09175 for ; Mon, 5 Jun 2000 14:52:23 -0500 (CDT) X-Authentication-Warning: apache.utdallas.edu: ravip owned process doing -bs Date: Mon, 5 Jun 2000 14:52:22 -0500 (CDT) From: Ravi Prakash To: manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET In-Reply-To: <3.0.1.32.20000605175414.0a6b4e60@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, We did some preliminary simulation experiments to determine the upper bounds on path lengths and path stability in mobile ad hoc networks. The idea was to have nodes move on a grid of streets, as in a fleet of taxi-cabs. The goal of these experiments was to determine the feasibility of route caching in protocols like AODV and DSR. Our experiments seem to indicate that caching may have very limited utility as paths do not stay unchanged for long. The paper containing these results is available as University of Texas at Dallas Technical Report # UTDCS-05-00 and can be downloaded from the following URL: www.utdallas.edu/~ravip/papers/persist.ps Here is a brief description of the work and a synopsis of results. I would really appreciate your comments. With best regards, ----Ravi. ========================= DESCRIPTION ================================ Two cabs (also referred to as nodes) in line of sight have a range R, and two cabs on mutually perpendicular streets have range R' (where R' < R). Then, two nodes that are within range are supposed to have a link. So, it is a minor modification of the unit-disk graph model. We ran the Bellman-Ford algorithm to determine the reachability of nodes. Also, we decided to simulate movement in a region where the bounds along the x-axis and y-axis were both significantly more than R. This ensures that the network does not appear to be a linear alignment of nodes. We noticed that when the number of nodes was small the graph was highly partitioned and there were very few paths, with a majority being one-hop. As the number of nodes increased, as expected the number of partitions decreased and the average path length increased. The paper presents the mean and the 90% confidence intervals of path length and path persistence. Path persistence was measured as the duration for which the shortest path between a pair of nodes remains unchanged, i.e., all the intermediate nodes stay in the same alignment. As expected, with increasing path length, path persistence declined rather steeply. This, in our opinion, is because in a longer path there is a higher probability that at least one node will move such that it is now out of range of at least one of its neighbors (predecessor/successor) in the path. What was most disturbing was that path persistence was very low even when nodes alternated between moving at an average speed of 35 kph for a while, and staying put for a while on reaching the destination of their trip. Please note that we considered an ideal (i.e., highly unrealistic) communication model where two nodes within range always had a link. So, in reality both path persistence and path length may be far lower than what our experiments indicate. This seems to imply that the reduction in route discovery traffic that protocols like AODV and DSR strive to achieve by caching routes may be limited. Also, we found that deploying traffic lights at street-intersections increased path persistence while significantly reducing path lengths. This is because traffic lights tend to aggregate nodes at the intersections and they tend to move almost in unison until the next light. The presence of one-way streets has very little additional impact on path persistence and path lengths. ======================================================================== Ravi Prakash (ravip@utdallas.edu) www.utdallas.edu/~ravip Department of Computer Science The University of Texas at Dallas Richardson, TX 75083-0688. Phone: (972) 883-2289, Fax: (972) 883-2349 From owner-manet@itd.nrl.navy.mil Mon Jun 5 19:00:46 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12327 for ; Mon, 5 Jun 2000 19:00:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA01527 for manet-outgoing; Mon, 5 Jun 2000 16:24:14 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA01521 for ; Mon, 5 Jun 2000 16:24:12 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id PAA12093; Mon, 5 Jun 2000 15:24:07 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id PAA16254; Mon, 5 Jun 2000 15:23:49 -0500 (CDT) Date: Mon, 5 Jun 2000 15:23:49 -0500 (CDT) Message-Id: <200006052023.PAA16254@sun.cs.tamu.edu> To: manet@itd.nrl.navy.mil, ravip@utdallas.edu Subject: Re: Path length Distribution in MANET Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> From: Ravi Prakash >> >> We did some preliminary simulation experiments to determine the upper >> bounds on path lengths and path stability in mobile ad hoc networks. The >> idea was to have nodes move on a grid of streets, as in a fleet of >> taxi-cabs. >> >> The goal of these experiments was to determine the feasibility of route >> caching in protocols like AODV and DSR. Our experiments seem to indicate >> that caching may have very limited utility as paths do not stay unchanged >> for long. I don't mean to distract folks from the interesting discussion on path lengths, but we reported a similar conclusion about the perils of caching in "dynamic" ad hoc networks, in our MobiCom 99 paper on TCP-on-MANET (the paper discusses the interaction between TCP and stale caches). Of course, caches are not a bad idea in general. As intuition would suggest, caches can be helpful in networks with slowly mobile nodes. - nitin >> The paper containing these results is available as University of Texas at >> Dallas Technical Report # UTDCS-05-00 and can be downloaded from the >> following URL: >> >> www.utdallas.edu/~ravip/papers/persist.ps >> >> Here is a brief description of the work and a synopsis of results. I would >> really appreciate your comments. >> >> With best regards, >> >> ----Ravi. >> >> ========================= DESCRIPTION ================================ >> >> Two cabs (also referred to as nodes) in line of sight have a range R, and >> two cabs on mutually perpendicular streets have range R' (where R' < >> R). Then, two nodes that are within range are supposed to have a link. So, >> it is a minor modification of the unit-disk graph model. We ran the >> Bellman-Ford algorithm to determine the reachability of nodes. >> Also, we decided to simulate movement in a region where the bounds along >> the x-axis and y-axis were both significantly more than R. This ensures >> that the network does not appear to be a linear alignment of nodes. >> >> We noticed that when the number of nodes was small the graph was highly >> partitioned and there were very few paths, with a majority being one-hop. >> As the number of nodes increased, as expected the number of partitions >> decreased and the average path length increased. The paper presents the >> mean and the 90% confidence intervals of path length and path persistence. >> >> Path persistence was measured as the duration for which the shortest path >> between a pair of nodes remains unchanged, i.e., all the intermediate >> nodes stay in the same alignment. As expected, with increasing path >> length, path persistence declined rather steeply. This, in our opinion, is >> because in a longer path there is a higher probability that at least >> one node will move such that it is now out of range of at least one of its >> neighbors (predecessor/successor) in the path. >> >> What was most disturbing was that path persistence was very low even when >> nodes alternated between moving at an average speed of 35 kph for a while, >> and staying put for a while on reaching the destination of their >> trip. Please note that we considered an ideal (i.e., highly >> unrealistic) communication model where two nodes within range always had a >> link. So, in reality both path persistence and path length may be far >> lower than what our experiments indicate. This seems to imply that the >> reduction in route discovery traffic that protocols like AODV and DSR >> strive to achieve by caching routes may be limited. >> >> Also, we found that deploying traffic lights at street-intersections >> increased path persistence while significantly reducing path lengths. This >> is because traffic lights tend to aggregate nodes at the intersections and >> they tend to move almost in unison until the next light. >> >> The presence of one-way streets has very little additional impact on path >> persistence and path lengths. >> >> ======================================================================== >> Ravi Prakash (ravip@utdallas.edu) www.utdallas.edu/~ravip >> Department of Computer Science >> The University of Texas at Dallas >> Richardson, TX 75083-0688. Phone: (972) 883-2289, Fax: (972) 883-2349 >> >> >> From owner-manet@itd.nrl.navy.mil Mon Jun 5 20:47:13 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13007 for ; Mon, 5 Jun 2000 20:47:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA04689 for manet-outgoing; Mon, 5 Jun 2000 19:07:24 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA04684 for ; Mon, 5 Jun 2000 19:07:23 -0400 (EDT) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 933141A00C5 for ; Mon, 5 Jun 2000 18:05:52 -0500 (CDT) Received: from localhost (ravip@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id SAA02584 for ; Mon, 5 Jun 2000 18:06:42 -0500 (CDT) X-Authentication-Warning: apache.utdallas.edu: ravip owned process doing -bs Date: Mon, 5 Jun 2000 18:06:42 -0500 (CDT) From: Ravi Prakash To: manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET In-Reply-To: <200006052023.PAA16254@sun.cs.tamu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Nitin Vaidya wrote on June 5: > > Of course, caches are not a bad idea in general. As intuition would > suggest, caches can be helpful in networks with slowly mobile nodes. > > - nitin > Hi Nitin, I would like to further qualify the statement by stating that caches can be helpful in networks where the *communication to mobility ratio* is high. Afterall, route caching will have little utility in a network where the interarrival time of packets exceeds the caching duration. Proactive protocols like DSDV will suffer "high overheads" and will be beaten by reactive ones like DSR and AODV when the packet interarrival time exceeds the update interval (assuming the update interval has been chosen with the mobility rate in mind). However, when a large number of packets arrive at a node for routing the cost of periodic updates is amortized over all these packets, thus reducing the overhead per packet. Thanks, ----Ravi. ======================================================================== Ravi Prakash (ravip@utdallas.edu) www.utdallas.edu/~ravip Department of Computer Science The University of Texas at Dallas Richardson, TX 75083-0688. Phone: (972) 883-2289, Fax: (972) 883-2349 From owner-manet@itd.nrl.navy.mil Tue Jun 6 13:45:37 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15519 for ; Tue, 6 Jun 2000 13:45:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA18955 for manet-outgoing; Tue, 6 Jun 2000 10:53:56 -0400 (EDT) Received: from 01mail.nomadix.com ([63.237.188.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA18948 for ; Tue, 6 Jun 2000 10:53:54 -0400 (EDT) Received: by 01MAIL with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Jun 2000 07:53:47 -0700 Message-ID: <05FF165EFE6DD311912600508B3235204586B6@01MAIL> From: Fred Delley To: "'manet@itd.nrl.navy.mil'" Subject: Unsubscibe Date: Tue, 6 Jun 2000 07:53:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCFC7.044E4786" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCFC7.044E4786 Content-Type: text/plain; charset="iso-8859-1" Please Unsubscibe ------_=_NextPart_001_01BFCFC7.044E4786 Content-Type: text/html; charset="iso-8859-1"
Please Unsubscibe
------_=_NextPart_001_01BFCFC7.044E4786-- From owner-mmnet@itd.nrl.navy.mil Tue Jun 6 14:38:10 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16654 for ; Tue, 6 Jun 2000 14:38:09 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA21147 for mmnet-outgoing; Tue, 6 Jun 2000 12:23:57 -0400 (EDT) Received: from hotmail.com (f256.law8.hotmail.com [216.33.240.131]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id MAA21142 for ; Tue, 6 Jun 2000 12:23:55 -0400 (EDT) Received: (qmail 74432 invoked by uid 0); 6 Jun 2000 16:23:54 -0000 Message-ID: <20000606162354.74431.qmail@hotmail.com> Received: from 147.188.192.41 by www.hotmail.com with HTTP; Tue, 06 Jun 2000 09:23:54 PDT X-Originating-IP: [147.188.192.41] From: "charanjit walia" To: mmnet@itd.nrl.navy.mil Subject: code Date: Tue, 06 Jun 2000 09:23:54 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Can you please give me some feedback on writing algorithms or pseudocode for LAR in ad hoc mobile networks using opnet. cheers charanjit singh ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Wed Jun 7 18:47:46 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22069 for ; Wed, 7 Jun 2000 18:47:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA24414 for manet-outgoing; Wed, 7 Jun 2000 15:55:39 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA24409 for ; Wed, 7 Jun 2000 15:55:37 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id OAA13845; Wed, 7 Jun 2000 14:55:34 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id OAA06607; Wed, 7 Jun 2000 14:55:13 -0500 (CDT) Date: Wed, 7 Jun 2000 14:55:13 -0500 (CDT) Message-Id: <200006071955.OAA06607@sun.cs.tamu.edu> To: manet@itd.nrl.navy.mil Subject: special issue CFP : mobile ad hoc networking Cc: parviz@us.ibm.com Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Call for Papers IEEE Personal Communications Magazine Special Issue on Advances in Mobile Ad Hoc Networking ------------------------------------ Motivation and Scope A mobile ad hoc network is a collection of wireless nodes that can dynamically form a network without using any pre-existing network infrastructure. Due to the potential ease of deployment, many applications have been conceived for such networks, including personal area networking, home networking, and battlefield applications. The objective of the proposed special issue is to provide the readers with an overview of the recent progress in the field of wireless ad hoc networks. Ad hoc networking is gaining importance with the increasingly widespread application of wireless technology in day-to-day civilian applications as well as military applications Scope of the proposed special issue will include various issues related to mobile ad hoc networks -- papers related to upper layers of the protocol stack, including applications are particularly encouraged. Topics of interest include, but are not limited to, the following: * Ad hoc mobile applications * Routing protocols * Energy-efficient protocols * Sensor-based Ad Hoc Networks * Quality of service issues * Security-related issues * Implementation and operational experiences Important Dates * Paper submission due date: August 15, 2000 * Accept/reject decisions by: October 30, 2000 * Revised papers due: November 30, 2000 * Publication date: February 2001 Submission Instructions Electronic paper submission is requested -- acceptable formats are MS Word, PostScript and Portable Document Format (PDF). Submissions should not exceed 24 double-spaced pages. List of references may be single-spaced. Please e-mail your submission to vaidya@cs.tamu.edu (Nitin Vaidya). In addition, please e-mail a plain-text abstract and title for your paper to parviz@us.ibm.com (Parviz Kermani). Due date for all submissions is August 15, 2000. Important: After a paper is submitted for review, the submitting author would be sent an acknowledgement, including the number assigned to the paper. If such an acknowledgement is not received within a week of submitting the paper, the authors are requested to contact the guest editors. It is anticipated that approximately 7 papers will be accepted for publication in this special issue. Guest Editors: Parviz Kermani Nitin H. Vaidya IBM T. J. Watson Research Center Computer Science Dept. 30 Saw Mill River Road 301 H.R.Bright Building Hawthorne, NY 10532 Texas A&M University U.S.A. College Station, TX 77843-3112 U.S.A. Phone: 914-784-7769 Phone: 979-845-0512 Fax: 914-784-6205 Fax: 979-847-8578 E-mail: parviz@us.ibm.com E-mail: vaidya@cs.tamu.edu From owner-manet@itd.nrl.navy.mil Thu Jun 8 10:20:34 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08276 for ; Thu, 8 Jun 2000 10:20:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA09458 for manet-outgoing; Thu, 8 Jun 2000 08:30:11 -0400 (EDT) Received: from marjan.fesb.hr (marjan.fesb.hr [161.53.166.3]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA09020; Thu, 8 Jun 2000 08:18:31 -0400 (EDT) Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id LAA01077; Thu, 8 Jun 2000 11:43:04 +0200 (MET DST) Message-ID: <03db01bfd132$0d136c90$2ba635a1@fesb.hr> From: "SoftCOM Secretary" To: "SoftCOM Mailing List" Subject: SoftCOM 2000 Deadline Extension and Feature Topic CFP Date: Thu, 8 Jun 2000 11:44:18 +0200 Organization: FESB, University of Split MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear All, Due to the number of requests for deadline extension the SoftCOM 2000 Organizing Committee has extended the paper submission deadline to June 19, 2000. We use this opportunity to remind the potential contributors that the deadline for special session "The New Millennium Telecommunications in the Alps-Adria Countries" is approaching. From the papers presented at SoftCOM 2000, a set of the most representative papers (or their integrals) will be selected for publication in the August 2001 issue of the IEEE Communications Magazine. Deadline for the Feature Topic: Complete manuscript to be received by July 15, 2000 Notification of acceptance: July 31, 2000 The Feature Topic includes, but it is not limited to: -historical background, developments, -operation statistics and experiencies, user (universities, institutes, schools) opinions, -the newest technologies and services, -development of telelearning and videoconferencing, -Web applications and information systems, -security aspects, -plans for future,toward the new millennium, -the role of universities and institutes, -the role of the national and regional operators and companies, industry and institutions, -joint projects, joint institutes and laboratories between academic and operators and companies, industry and institutions, -participation of academic institutions in education of professionals from industry and vice versa, Participation in this FT is expected from institutions which cover academic networking (such as CARNet in Croatia, Arnes in Slovenia), as well as from universities, institutes and schools as users, particularly in the Alps-Adria region. In addition, contributions from national and regional institutions, companies, operators and industry who participate in development of academic networking, promotion of education and R&D investigations are particularly welcome. More details can be found at http://www.fesb.hr/SoftCOM Thank you for your interest in SoftCOM 2000. SoftCOM 2000 Organizing Committee From owner-mmnet@itd.nrl.navy.mil Thu Jun 8 11:12:52 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09419 for ; Thu, 8 Jun 2000 11:12:52 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA09029 for mmnet-outgoing; Thu, 8 Jun 2000 08:19:00 -0400 (EDT) Received: from marjan.fesb.hr (marjan.fesb.hr [161.53.166.3]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA09020; Thu, 8 Jun 2000 08:18:31 -0400 (EDT) Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id LAA01077; Thu, 8 Jun 2000 11:43:04 +0200 (MET DST) Message-ID: <03db01bfd132$0d136c90$2ba635a1@fesb.hr> From: "SoftCOM Secretary" To: "SoftCOM Mailing List" Subject: SoftCOM 2000 Deadline Extension and Feature Topic CFP Date: Thu, 8 Jun 2000 11:44:18 +0200 Organization: FESB, University of Split MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear All, Due to the number of requests for deadline extension the SoftCOM 2000 Organizing Committee has extended the paper submission deadline to June 19, 2000. We use this opportunity to remind the potential contributors that the deadline for special session "The New Millennium Telecommunications in the Alps-Adria Countries" is approaching. From the papers presented at SoftCOM 2000, a set of the most representative papers (or their integrals) will be selected for publication in the August 2001 issue of the IEEE Communications Magazine. Deadline for the Feature Topic: Complete manuscript to be received by July 15, 2000 Notification of acceptance: July 31, 2000 The Feature Topic includes, but it is not limited to: -historical background, developments, -operation statistics and experiencies, user (universities, institutes, schools) opinions, -the newest technologies and services, -development of telelearning and videoconferencing, -Web applications and information systems, -security aspects, -plans for future,toward the new millennium, -the role of universities and institutes, -the role of the national and regional operators and companies, industry and institutions, -joint projects, joint institutes and laboratories between academic and operators and companies, industry and institutions, -participation of academic institutions in education of professionals from industry and vice versa, Participation in this FT is expected from institutions which cover academic networking (such as CARNet in Croatia, Arnes in Slovenia), as well as from universities, institutes and schools as users, particularly in the Alps-Adria region. In addition, contributions from national and regional institutions, companies, operators and industry who participate in development of academic networking, promotion of education and R&D investigations are particularly welcome. More details can be found at http://www.fesb.hr/SoftCOM Thank you for your interest in SoftCOM 2000. SoftCOM 2000 Organizing Committee From owner-manet@itd.nrl.navy.mil Thu Jun 8 16:11:46 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15715 for ; Thu, 8 Jun 2000 16:11:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA17357 for manet-outgoing; Thu, 8 Jun 2000 12:41:11 -0400 (EDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA17352 for ; Thu, 8 Jun 2000 12:41:09 -0400 (EDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DNGF4Q3B@mta5.rcsntx.swbell.net> for manet@itd.nrl.navy.mil; Thu, 8 Jun 2000 11:05:48 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:48 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: manet@itd.nrl.navy.mil Message-id: <0FVU00DFFFDM3B@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-manet@itd.nrl.navy.mil Thu Jun 8 17:55:57 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17664 for ; Thu, 8 Jun 2000 17:55:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA20984 for manet-outgoing; Thu, 8 Jun 2000 14:52:20 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA20978 for ; Thu, 8 Jun 2000 14:52:18 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id OAA08198; Thu, 8 Jun 2000 14:52:06 -0400 (EDT) Date: Thu, 8 Jun 2000 14:52:06 -0400 (EDT) From: Zygmunt Haas To: zainprov@swbell.net cc: manet@itd.nrl.navy.mil Subject: Re: Shocking LOSE 10-100lbs. DESTINY In-Reply-To: <0FVU00DFFFDM3B@mta5.rcsntx.swbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > Hello From Destiny, > > You will LOOSE 20-100 pounds easy! Hmmm, this might be REALLY useful for some routing protocols (:-) ... Sorry, just could not resist ... Zygmunt. ==-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- From owner-manet@itd.nrl.navy.mil Thu Jun 8 18:11:04 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17975 for ; Thu, 8 Jun 2000 18:11:03 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA23182 for manet-outgoing; Thu, 8 Jun 2000 16:07:25 -0400 (EDT) Received: from taurus.cs.albany.edu (taurus.cs.albany.edu [169.226.2.109]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA23177 for ; Thu, 8 Jun 2000 16:07:22 -0400 (EDT) Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id QAA19639; Thu, 8 Jun 2000 16:04:40 -0400 (EDT) From: "S.S.Ravi" Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id QAA27918; Thu, 8 Jun 2000 16:04:38 -0400 Date: Thu, 8 Jun 2000 16:04:38 -0400 Message-Id: <200006082004.QAA27918@euler.cs.albany.edu> To: dmanet@zpr.uni-koeln.de, im-net-digest@iwr.uni-heidelberg.de, itc@ieee.org, manet@itd.nrl.navy.mil, mobile-ip@standards.nortelnetworks.com, mobility@media.mit.edu, opt-net@zib.de, orcs-l@listserv.okstate.edu, podc-post@research.telcordia.com, tccc@ieee.org, theorynt@listserv.nodak.edu Subject: DIAL M Workshop -- Call for Participation Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk CALL FOR PARTICIPATION 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html SPONSORS: (a) National Science Foundation. (b) ACM SIGMOBILE (in cooperation with ACM SIGACT) (c) Basic and Applied Simulation Science Group (TSA-2) of Los Alamos National Laboratory. SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The conference program includes three invited talks and 11 contributed papers. (The schedule of talks appears below.) REGISTRATION and HOTEL INFORMATION: DIAL M Workshop registration is being conducted in conjunction with the MobiCom 2000 conference registration. Please see the Mobicom 2000 home page (http://www.argreenhouse.com/mobicom2000) for registration, conference location and hotel information. STUDENT TRAVEL GRANTS: Students attending DIAL M may apply for Student Grants to defray a part of the cost of attending the workshop. Any student may apply (presenting a paper is NOT a prerequisite). For further information, please contact the DIAL M Program Chair Professor Errol Lloyd (elloyd@udel.edu). Funding for these grants is provided by the National Science Foundation. CONFERENCE PROGRAM: 7 AM - Noon Registration 7 AM - 8 AM Continental Breakfast 8 AM Welcome by the Program Chair: Errol Lloyd (Univ. of Delaware) 8:05 AM Remarks by the Steering Committee Chair: Maurizio Bonuccelli (Univ. of Pisa) SESSION ONE 8:10 - 8:30 AM Online Algorithms for Channel Assignment Problems in Cellular Networks P. Crescenzi (Universita di Firenza); G. Gambosi and P. Penna (Universita di Roma) 8:30 - 8:50 AM Worst-case Analysis of a Dynamic Channel Assignment Strategy L. Narayanan and Y. Tang (Concordia University) 8:50 - 9:10 AM Efficient Use of Radio Spectrum in Wireless Networks with Channel Separation between Close Stations A. Bertosi (Univ. of Trento); M. C. Pinotti (National Research Council, Italy); R. Tan (Univ. of Science and Arts of Oklahoma) 9:10 - 9:30 AM Blocking Probability Estimates in a Partitioned Sector TDMA System C. Chekuri, K. Ramanan, P. Whiting and L. Zhang (Bell Laboratories) 9:30 - 9:50 AM Energy-Efficient Routing in Radio Networks K. Nagoya (Nagoya Institute of Technology); S. Olariu (Old Dominion University) 9:50 - 10:20 AM Refreshment Break an Discussion Time SESSION TWO 10:20 - 11:20 AM INVITED TALK: Data Structures for Mobile Data Leonidas Guibas (Stanford University) 11:20 - 11:40 AM Mobile Facility Location S. Bespamyatnikh (Univ. of British Columbia); B. Bhattacharya (Simon Fraser University); D. Kirkpatrick and M. Segal (Univ. of British Columbia) 11:40 - Noon A. Aggarwal, M. Kapoor, L. Ramachandran and A. Sarkar (IBM India Research Laboratory) Noon - 1:10 PM Workshop Luncheon SESSION THREE 1:10 - 2:10 PM INVITED TALK: The Post-PC Era: It's about the New Services-Enabled Internet Randy Katz (Univ. of California, Berkeley) 2:10 - 2:30 PM Dynamic Session Management for Static and Mobile Users: A Competitive On-Line Algorithmic Approach Y. Bejarno, I. Cidon (Technion - Israel Institute of Technology); J. (Seffi) Naor (Bell Laboratories) 2:30 - 2:50 PM Efficient Memoryless Protocol for Tag Identification C. Law, K. Lee and K. Y. Siu (Massachusetts Institute of Technology) 2:50 - 3:20 PM Refreshment Break and Discussion Time SESSION FOUR 3:20 - 4:20 PM INVITED TALK: Application of a Theory of Simulation to Models of Mobile Communication Systems Christopher Barrett (Los Alamos National Laboratory) 4:20 - 4:40 PM A Decision-Theoretic Approach to Resource Allocation in Wireless Multimedia Networks Z. Haas, J. Halpern, L. Li and S. Wicker (Cornell Univ.) 4:40 - 5:00 PM Leader Election Algorithms for Mobile Ad Hoc Networks N. Malpani, J. Welch and N. Vaidya (Texas A&M Univ.) PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S. S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. From owner-manet@itd.nrl.navy.mil Fri Jun 9 04:30:28 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07493 for ; Fri, 9 Jun 2000 04:30:27 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA01982 for manet-outgoing; Fri, 9 Jun 2000 02:27:39 -0400 (EDT) Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [203.197.74.142] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id CAA01977 for ; Fri, 9 Jun 2000 02:27:35 -0400 (EDT) Received: (qmail 16134 invoked from network); 9 Jun 2000 06:38:15 -0000 Received: from nalanda.ccs.iitb.ernet.in (144.16.106.1) by mailhost.iitb.ac.in with SMTP; 9 Jun 2000 06:38:15 -0000 Received: (qmail 15841 invoked by uid 2007); 9 Jun 2000 06:13:18 -0000 Date: Fri, 9 Jun 2000 11:43:17 +0530 (IST) From: Richa Jain To: manet@itd.nrl.navy.mil Subject: Visualisation for wireless/mobile networks (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi all, I need to look into the mobile features incorporated into NS, for a project I'm currently working on. Could someone help me out on the following: 1. Does NS have any other mobile extensions apart from those made by the CMU Monarch project? Are all the CMU mobile extensions incorporated in NS? Are all the mobile features of NS- vs 2.1b6 documented anywhere ie. is there a list of all the mobile features currently in NS? ( I am unable to access the Mobins2 page mentioned in the NS contributed code (Wireless) section - any ideas what it contains and how I can get thru?) 2. The CMU monarch project has a visualiser "ad-hockey" for moblie networks. Any ideas on how I can install/use it with the version of NS (2.1b6) I have (from the ns-allinone file)? Has anyone tried something like this before? Thanx in advance, Richa. From owner-manet@itd.nrl.navy.mil Fri Jun 9 13:31:58 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15837 for ; Fri, 9 Jun 2000 13:31:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA12295 for manet-outgoing; Fri, 9 Jun 2000 11:31:08 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA12290 for ; Fri, 9 Jun 2000 11:31:06 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id KAA05239 for ; Fri, 9 Jun 2000 10:31:04 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id KAA17073 for manet@itd.nrl.navy.mil; Fri, 9 Jun 2000 10:30:41 -0500 (CDT) Date: Fri, 9 Jun 2000 10:30:41 -0500 (CDT) Message-Id: <200006091530.KAA17073@sun.cs.tamu.edu> To: manet@itd.nrl.navy.mil Subject: MobiHOC: Workshop on Mobile Ad Hoc Networking & Computing Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk -------------------------------------------------------------------------- Call for Participation The First Annual Workshop on Mobile Ad Hoc Networking & Computing (MobiHOC) August 11, 2000 Boston, Massachusetts, USA (in conjunction with MobiCom 2000) Advance program, registration information, and hotel information for the MobiHOC workshop are now available at http://www.cs.tamu.edu/faculty/vaidya/mobihoc/ If you are unable to access the above web page, please send e-mail to vaidya@cs.tamu.edu -------------------------------------------------------------------------- MobiHOC 2000 Advance Program -------------------------------------------------------------------------- MobiHoc received 82 submissions, of which 13 were accepted as regular papers, and 12 as posters. The accepted papers/posters came from 13 countries. -------------------------------------------------------------------------- Keynote Leonard Kleinrock will present a keynote address on Beyond the Netherworld of Cyberspace. -------------------------------------------------------------------------- Introductions and Welcome 8:00 - 8:30 a.m. -------------------------------------------------------------------------- Session A: Routing 8:30 - 10:15 a.m. * On the Impact of Alternate Path Routing for Load Balancing in Mobile Ad-Hoc Networks Marc Pearlman, Zygmunt Haas (Cornell University), Peter Sholander (Scientific Research Corporation), and Siamak S. Tabrizi (Air Force Rome Laboratories) * LANMAR: Landmark Routing for Large Scale Wireless Ad Hoc Networks with Group Mobility Guangyu Pei, Mario Gerla, and Xiaoyan Hong (University of California, Los Angeles) * DDR-Distributed Dynamic Routing Algorithm for Mobile Ad Hoc Networks Navid Nikaein, Houda Labiod, and Christian Bonnet (Eurecom Institute) * Predicting Node Proximity in Ad-Hoc Networks: A Least Overhead Adaptive Model for Selecting Stable Routes A. Bruce McDonald and Taieb Znati (University of Pittsburgh) -------------------------------------------------------------------------- Session B: Multicasting 10:45 - 12:00 a.m. * Neighbor Supporting Ad Hoc Multicast Routing Protocol Seungjoon Lee and Chongkwon Kim (Seoul National University) * Role-Based Multicast in Highly Mobile but Sparsely Connected Ad Hoc Networks Linda Briesemeister (DaimlerChrysler Research and Technology) and Gunter Hommel (Technical University of Berlin) * Content Based Multicast (CBM) in Ad Hoc Networks Hu Zhou and Suresh Singh (Oregon State University) -------------------------------------------------------------------------- Keynote Address and Lunch 12:00 - 1:30 p.m. Keynote Speaker: Leonard Kleinrock Topic: Beyond the Netherworld of Cyberspace -------------------------------------------------------------------------- Session C: Novel Issues 1:30 - 2:45 p.m. * An Architecture for Building Self-Configurable Systems Lakshminarayanan Subramanian and Randy H. Katz (University of California, Berkeley) * MIPMANET - Mobile IP for Mobile Ad Hoc Networks Ulf Jonsson, Fredrik Alriksson, Tony Larsson, Per Johansson (Ericsson Radio Systems), and Gerald Q. Maguire Jr. (Royal Institute of Technology) * Enforcing Service Availability in Mobile Ad-Hoc WANs Levente Buttyan and Jean-Pierre Hubaux (Swiss Federal Institute of Technology, Lausanne) -------------------------------------------------------------------------- Session D: Link Layer 3:15 - 4:30 p.m. * Fair Medium Access in 802.11 based Wireless Ad-Hoc Networks Brahim Bensaou, Yu Wang, and Chi Chung Ko (National University of Singapore) * Low Power Rendezvous in Embedded Wireless Networks Terry Todd (McMaster University), Frazer Bennett (PA Consulting Group), and Alan Jones (AT&T Laboratories Cambridge) * Assignment Methods for Spatial Reuse TDMA Jimmi Gronkvist (Swedish Defence Research Establishment) -------------------------------------------------------------------------- Poster Session 4:30 - 6:00 p.m. * A Speech-Optimised Multiple Access Scheme for a Mobile Ad Hoc Network V. N. Muthiah and W. C. Wong (National University of Singapore) * On the Reduction of Broadcast Redundancy in Mobile Ad Hoc Networks Wei Peng and Xi-Cheng Lu (Changsha Institute of Technology) * Central Controller Handover Procedure for ETSI-BRAN HiperLAN/2 Ad Hoc Networks and Clustering with Quality of Service Guarantees Jorg Habetha, Andreas Hettich, Jorg Peetz (Aachen Institute of Technology), and Yonggang Du (Philips Research Laboratories) * DEAPspace -- Transient Ad-hoc Networking of Pervasive Devices Reto Hermann, Dirk Husemann, Michael Moser, Michael Nidd, Christian Rohner, and Andreas Schade (IBM Zurich Research Lab) * Securing Ad Hoc Services, a Jini View Christian Gehrmann (Ericsson Research), and Pekka Nikander (Helsinki Institute of Technology) * Dynamic Quality-of-Service for Mobile Ad Hoc Networks M. Mirhakkak, N. Schult, and D. Thomson (MITRE Corporation) * A Simulation Analysis on Reactive Route Repair Techniques for QoS Sensitive Applications in Mobile Ad Hoc Networks George Aggelou and Rahim Tafazolli (University of Surrey) * Proximity Awareness and Fast Connection Establishment in Bluetooth Theodoros Salonidis (University of Maryland), Pravin Bhagwat (IBM T. J. Watson Research Center), and Leandros Tassiulas (University of Maryland) * Utility-Based Decision-Making in Wireless Sensor Networks John Byers and Gabriel Nasser (Boston University) * A Distributed Mechanism for Topology Discovery in Ad hoc Wireless Networks using Mobile Agents Romit RoyChoudhury (Haldia Institute of Technology), Somprakash Bandyopadhyay (PricewaterhouseCoopers Ltd.), and Krishna Paul (CTS-Calcutta) * Performance Aspects of Bluetooth Scatternet Formation G. Miklos, A. Racz, Z. Turanyi, A. Valko (Ericsson Research), and P. Johansson (Ericsson Radio Systems) * Load Balancing via Relay in Next Generation Wireless Systems Chunming Qiao, Hongyi Wu, and Ozan Tonguz (University at Buffalo) -------------------------------------------------------------------------- NOTE: The program listed above is preliminary, and the session schedule is subject to change. -------------------------------------------------------------------------- From owner-manet@itd.nrl.navy.mil Fri Jun 9 14:47:25 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17153 for ; Fri, 9 Jun 2000 14:47:25 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA14174 for manet-outgoing; Fri, 9 Jun 2000 12:45:36 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA14169 for ; Fri, 9 Jun 2000 12:45:34 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id JAA22202; Fri, 9 Jun 2000 09:45:23 -0700 (PDT) Date: Fri, 9 Jun 2000 09:45:23 -0700 (PDT) From: Ya Xu To: Richa Jain cc: manet@itd.nrl.navy.mil Subject: Re: Visualisation for wireless/mobile networks (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Fri, 9 Jun 2000, Richa Jain wrote: > > > > > Hi all, > > I need to look into the mobile features incorporated into NS, for a > project I'm currently working on. Could someone help me out on the > following: > > 1. Does NS have any other mobile extensions apart from those made by the > CMU Monarch project? Are all the CMU mobile extensions incorporated in NS? > Are all the mobile features of NS- vs 2.1b6 documented anywhere ie. is > there a list of all the mobile features currently in NS? > Ns integrated cmu Monarch project and Charley' mobileIP. Ns also has its own implementation to simulate both wired and wireless network altogether. > ( I am unable to access the Mobins2 page mentioned in > the NS contributed code (Wireless) section - any ideas what it contains > and how I can get thru?) > All ns related link can be accessed by http://mash.cs.berkeley.edu You can check both ns docs and tutorial to find infomation regarding wireless network simulation > 2. The CMU monarch project has a visualiser "ad-hockey" for moblie > networks. Any ideas on how I can install/use it with the version of NS > (2.1b6) I have (from the ns-allinone file)? Has anyone tried something > like this before? > Ns does not support ad-hockey. However, Ns has its own animator called Nam to visualize both wired and wireless simulation. Some examples are included in current ns snapshot. More questions can be sent to ns mailing list for answers thanks -Ya From owner-manet@itd.nrl.navy.mil Fri Jun 9 15:03:33 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17482 for ; Fri, 9 Jun 2000 15:03:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA14645 for manet-outgoing; Fri, 9 Jun 2000 13:08:07 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA14635 for ; Fri, 9 Jun 2000 13:08:04 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.10.0/8.10.0) with SMTP id e59H80r15917; Fri, 9 Jun 2000 19:08:00 +0200 (MET DST) Message-Id: <3.0.1.32.20000609191252.0259d2b0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 09 Jun 2000 19:12:52 +0200 To: "J. Noel Chiappa" , manet@itd.nrl.navy.mil Subject: Re: Path length Distribution in MANET Cc: charliep@iprg.nokia.com, jnc@ginger.lcs.mit.edu, ramanath@bbn.com In-Reply-To: <200006051742.NAA12704@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id NAA14641 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit A 13:42 05/06/00 -0400, J. Noel Chiappa a écrit : > > > Besides, this problem statement places no geometric constraint. The two > > nodes that are farthest apart are equally probable to have a link as > > the two nodes closest together. > >It's worse than that. By saying that the probabilty p of a link existing >between i and j is a fixed p, regardless of N, you're saying that the degree >D (i.e. number of connections) of any given node goes up at the same rate as >the network grows. This is extremely unlikely, physically; much better would >be a model with constant D. The problem with such models is that it is difficult to guarrantee that the graph is connected, it may break in several isolated islands. Philippe From owner-manet@itd.nrl.navy.mil Fri Jun 9 18:06:29 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19452 for ; Fri, 9 Jun 2000 18:06:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA18453 for manet-outgoing; Fri, 9 Jun 2000 15:22:05 -0400 (EDT) Received: from babbage.ececs.uc.edu (mail.ececs.uc.edu [129.137.8.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA18448 for ; Fri, 9 Jun 2000 15:22:04 -0400 (EDT) Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA13315 for ; Fri, 9 Jun 2000 15:22:02 -0400 (EDT) From: Samir Das Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id PAA29672 for manet@itd.nrl.navy.mil; Fri, 9 Jun 2000 15:21:45 -0400 (EDT) Message-Id: <200006091921.PAA29672@wayward.ececs.uc.edu> Subject: MobiCom 2000: Call for Participation To: manet@itd.nrl.navy.mil Date: Fri, 9 Jun 2000 15:21:45 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from IBM Research (Platinum supporter), HP Laboratories (Platinum supporter), Nokia (Gold supporter) and AT&T Laboratories Cambridge (Gold supporter) CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-manet@itd.nrl.navy.mil Sun Jun 11 17:47:15 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09764 for ; Sun, 11 Jun 2000 17:47:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA12265 for manet-outgoing; Sun, 11 Jun 2000 15:51:09 -0400 (EDT) Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA12260 for ; Sun, 11 Jun 2000 15:51:07 -0400 (EDT) Received: from cse.uta.edu (IDENT:ramesh@[129.107.100.27]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id OAA06637; Sun, 11 Jun 2000 14:51:25 -0500 (CDT) Message-ID: <3943A86B.521A267@cse.uta.edu> Date: Sun, 11 Jun 2000 09:55:39 -0500 From: Ramesh Yerraballi Reply-To: ramesh@cse.uta.edu Organization: UTA Computer Science and Engineering X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: sigmobile@acm.org Subject: WoWMoM 2000: Call for Participation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, This is an invitation to participate in this year's Wokshop on Wireless Mobile Multimedia to be held in conjunction with MobiCom-2000. The technical program and registration info. are below. My apologies if you receive multiple copies of this mail Ramesh Yerraballi ----------------------------------- Dr. Ramesh Yerraballi Assistant Professor, Dept. of CSE Univ. of Texas at Arlington e-mail: ramesh@cse.uta.edu ----------------------------------- --------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM-2000 The Third ACM International Workshop on Wireless Mobile Multimedia (in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center, Boston, Massachusetts, USA  Sponsors: * ACM SigMobile * Nortel Networks * The University of California at Riverside * DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science * CReWMaN at the University of Texas at Arlington --------------------------------------------------------------------- For uptodate technical program, registration information, and hotel information for the WoWMoM workshop are now available at http://www-cse.uta.edu/crewman/conferences/wowmom-2000/ If you are unable to access the above web page, please send e-mail to ramesh@cse.uta.edu -------------------------------------------------------------------------- WoWMoM 2000 Technical Program -------------------------------------------------------------------------- Welcome Address (8:00 am - 8:30 am) -------------------------------------------------------------------------- Session I ( 8:30 am - 10:00 am) Wireless QoS: Admission and Call Control * W2F2Q: Packet Fair Queuing in Wireless Packet Networks Yung Yi, Yongho Seok, Taekyoung Kwon and Yanghee Choi Seoul National University * A Wireless Fair Scheduling Algorithm for Error'Prone Wireless Channels Peng Lin, B. Bensaou, Q. L. Ding, and K.C. Chua National University of Singapore * A Novel Distributed Call Admission Control for Wireless Mobile Multimedia Networks Youssef Iraqi , University of Montreal Raouf Boutaba, University of Waterloo, Canada * Real-time Prioritized Call Admission Control in a Base Station Scheduler Jay R. Moorma, John W. Lockwood and Sung Mo Kang University of Illinois and Washington University, St. Louis -------------------------------------------------------------------------- Coffee Break (10:00 am - 10:30 am) -------------------------------------------------------------------------- Session II (10:30 am - 12:00 noon) Wireless Mobility: Support and Performance Analysis * An Integrated Mobility and Traffic Model for Resource Allocation in Wireless Networks Hisashi Kobayashi, Shum-Zheng Yu and Brian L. Mark Princeton University and George Mason University * Mobility Modeling of Rush Hour Traffic for Location Design Area in Cellular Networks Apurva Kumer, IBM - India Research Lab. M. N. Umesh, Silicon Automation Systems, India Rajesh Jha, Lucent Technologies, NJ * Multicast Support for Mobile IP with the Hierarchical Local Registration Approach H. Omar, T. Saadawi and M. Lee The City University of New York * Performance Evaluation of ATM/AAL2 as switching technology in 3G Mobile Access Networks Oscar Mezquita Baeza, GMD Fokus GmbH Berlin, Germany Enrico Scarrone, CSELT Turin, Italy -------------------------------------------------------------------------- Lunch Break (12:00 noon - 1:30 pm) -------------------------------------------------------------------------- Session III (1:30 pm - 3:00 pm) Resource Management in Mobile Systems * Managing the Storage and Battery Resources in an Image Capture Device (Digital Camera) using Dynamic Transcoding Surendar Chandra, Carla Schlatter Ellis and Amin Vahdat Duke University * Performance Modelling of Speculative Prefetching for Compound Requests in Low Bandwidth Networks N.J. Tuah, M. Kumar and S. Venkatesh Curtin University of Technology, Australia * A Modified CDMA/PRMA Medium Access Control Protocol for Integrated Services in LEO Satellite Systems Abbas Ibrahim and Samie Tohme Ecole Nationale Superieure des Telecommunications, Paris, France * Delay Jitter Performance of Video Traffic in a Cellular Wireless ATM Network T.C. Wong, J. W. Mark and K. C. Chua National University of Singapore and University of Waterloo, Canada -------------------------------------------------------------------------- Coffee Break (3:00 pm - 3:30 pm) -------------------------------------------------------------------------- Session IV (3:30 pm - 5:00 pm) Panel -- TBD -------------------------------------------------------------------------- END OF PROGRAM From owner-manet@itd.nrl.navy.mil Mon Jun 12 13:16:29 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07185 for ; Mon, 12 Jun 2000 13:16:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA25250 for manet-outgoing; Mon, 12 Jun 2000 11:23:17 -0400 (EDT) Received: from prima.time.saic.com (time.saic.com [205.153.241.31]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA25244 for ; Mon, 12 Jun 2000 11:23:15 -0400 (EDT) Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32]) by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id LAA02424 for ; Mon, 12 Jun 2000 11:23:38 -0400 (EDT) Message-Id: <200006121523.LAA02424@prima.time.saic.com> X-Mailer: exmh version 2.0.2 2/24/98 To: manet@itd.nrl.navy.mil Subject: vendor support for Manet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jun 2000 11:22:55 -0400 From: Ken Carlberg Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, are there any vendors that are offering one of the various MANET protocols as an actual product? private responses are fine. I'm primarily curious as to how far some folks have gone beyond the research stage. cheers, -ken From owner-manet@itd.nrl.navy.mil Mon Jun 12 16:07:08 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10195 for ; Mon, 12 Jun 2000 16:07:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA00503 for manet-outgoing; Mon, 12 Jun 2000 14:03:57 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA00495 for ; Mon, 12 Jun 2000 14:03:55 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:1310@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id NAA07825 for ; Mon, 12 Jun 2000 13:03:49 -0500 (CDT) Received: from localhost (youngbae@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) with ESMTP id NAA25396 for ; Mon, 12 Jun 2000 13:03:22 -0500 (CDT) X-Authentication-Warning: sun.cs.tamu.edu: youngbae owned process doing -bs Date: Mon, 12 Jun 2000 13:03:22 -0500 (CDT) From: Youngbae - Ko X-Sender: youngbae@sun To: manet@itd.nrl.navy.mil Subject: Anycasting and Geocasting in ad hoc networks (Tech. Report) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Colleagues, We would like to announce our work on anycasting and geocasting protocols in ad hoc networks. The technical report, numbered 00-015 and titled in "Anycasting and Geocasting in Mobile Ad Hoc Networks", is available here: http://www.cs.tamu.edu/faculty/vaidya/Vaidya-mobile.html (on the list of PUBLICATIONS and TECHNICAL REPORTS) FYI, the abstract of our report is attached below. Thanks in advance for your time and we would appreciate any feedbacks (comments or suggestions) on our report. Best Regards, Young-Bae Ko < Mobile Computing & Networking Group > < Dept. of Computer Science > < Texas A&M University > Abstract ========== This technical report considers the problem of providing a geocast service, which is useful for sending messages to everyone in a specified geographical region, in mobile ad hoc networks. In the report, a novel geocasting algorithm combining unicasting and flooding is proposed for an efficient geocast packet delivery. TORA (unicast) routing protocol is first modified to be able to perform "anycasting" service. Our geocasting algorithm is then obtained using a small variation on the anycasting protocol. The proposed protocol, named "GeoTORA", also incorporates flooding, but flooding is limited to nodes within a small region. This integration of TORA and flooding can significantly reduce the overhead of geocast delivery, while maintaining reasonably high accuracy. From owner-manet@itd.nrl.navy.mil Mon Jun 12 22:10:28 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15359 for ; Mon, 12 Jun 2000 22:10:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA08632 for manet-outgoing; Mon, 12 Jun 2000 20:22:21 -0400 (EDT) Received: from krdl.org.sg (rodin.krdl.org.sg [192.122.139.27]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA08627 for ; Mon, 12 Jun 2000 20:22:18 -0400 (EDT) Received: from mailhost.krdl.org.sg (mailhost [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id IAA15848; Tue, 13 Jun 2000 08:30:38 +0800 Received: from ubiqd36 (knowd12.krdl.org.sg [192.168.136.245]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id IAA06837; Tue, 13 Jun 2000 08:21:12 +0800 (SGT) Message-Id: <200006130021.IAA06837@mailhost.krdl.org.sg> X-Sender: hlee@mailhost.krdl.org.sg X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 13 Jun 2000 08:26:20 +0800 To: Ken Carlberg , manet@itd.nrl.navy.mil From: Lee Chee-Jwai Henry Subject: Re: vendor support for Manet In-Reply-To: <200006121523.LAA02424@prima.time.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk As far as I know, there're two commercial products: - Nova Engineering's Novaroam product (www.nova-engineering.com), using the TORA protocol - Nokia's wireless router (www.rooftop.com) Regards. At 12-06-00 11:22 AM -0400, Ken Carlberg wrote: > >Hi, > >are there any vendors that are offering one of the various MANET >protocols as an actual product? private responses are fine. I'm >primarily curious as to how far some folks have gone beyond the >research stage. > >cheers, > >-ken > From owner-manet@itd.nrl.navy.mil Tue Jun 13 03:45:31 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00388 for ; Tue, 13 Jun 2000 03:45:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA13016 for manet-outgoing; Tue, 13 Jun 2000 01:59:41 -0400 (EDT) Received: from uci.agh.edu.pl (galaxy.uci.agh.edu.pl [149.156.96.9]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA13010 for ; Tue, 13 Jun 2000 01:59:33 -0400 (EDT) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id HAA18396 for ; Tue, 13 Jun 2000 07:59:12 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) for manet@itd.nrl.navy.mil id AA37250; Tue, 13 Jun 2000 07:58:15 +0200 Date: Tue, 13 Jun 2000 07:58:15 +0200 From: proms@saturn.kt.agh.edu.pl (Piotr Pacyna) Message-Id: <10006130558.AA37250@saturn.kt.agh.edu.pl> Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND To: manet@itd.nrl.navy.mil Subject: PROMS2000 - last Call for Papers Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Sir, Dear Madam, Please find enclosed the Protocols for Multimedia Systems conference CfP. We do apologise if you receive multiple copies of this. Thank you for your attention. With best regards, Piotr Pacyna OC Chair ++++++++++++++++++++++++++++++++++++++++++++++++++++++ (We do apologize, if you receive multiple copies of this CfP) Announcement and Call for Papers PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies, ZWUT a Siemens Company, http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications, eg. voice over IP; * performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks; * definition, provisioning, and supervision of QoS parameters for networked applications and services, eg. in IntServ/DiffServ networks; * multimedia traffic engineering; * applications and platforms for service management and provisioning; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due June 26, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. PROCEEDINGS 1. Each participant will receive Proceedings from the conference. 2. Two best papers will be considered for publication in the IEEE Communications Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia Systems". CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ibrahim Habib, Univ. New York Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, proms@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl From owner-manet@itd.nrl.navy.mil Tue Jun 13 13:30:16 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16133 for ; Tue, 13 Jun 2000 13:30:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA23502 for manet-outgoing; Tue, 13 Jun 2000 11:38:07 -0400 (EDT) Received: from hotmail.com (f237.law8.hotmail.com [216.33.241.237]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id LAA23497 for ; Tue, 13 Jun 2000 11:38:06 -0400 (EDT) Received: (qmail 20843 invoked by uid 0); 13 Jun 2000 15:38:01 -0000 Message-ID: <20000613153801.20842.qmail@hotmail.com> Received: from 147.188.192.41 by www.hotmail.com with HTTP; Tue, 13 Jun 2000 08:38:01 PDT X-Originating-IP: [147.188.192.41] From: "charanjit walia" To: manet@itd.nrl.navy.mil Subject: Location aided routing simulation using opnet Date: Tue, 13 Jun 2000 08:38:01 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi I am planning to do a project on the above subject using opnet. Can i get some feedback on implementation. has any one done it befor using opnet. cheers charanjit singh ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mmnet@itd.nrl.navy.mil Thu Jun 15 08:58:03 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29897 for ; Thu, 15 Jun 2000 08:58:03 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA06210 for mmnet-outgoing; Thu, 15 Jun 2000 06:57:53 -0400 (EDT) Received: from otter.mbay.net (otter.mbay.net [206.40.79.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA06000; Thu, 15 Jun 2000 06:42:37 -0400 (EDT) Received: from [206.55.224.48] (mty1-48.dip.mbay.net [206.55.224.48]) by otter.mbay.net (8.9.3/8.8.8) with ESMTP id BAA16164; Thu, 15 Jun 2000 01:06:09 -0700 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 15 Jun 2000 01:05:48 -0700 Subject: RE: IT KEEPS ON WORKING EVEN WHEN YOU TURN IT OFF! From: "Rand K. Smith" To: Top Agent6 Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3043875948_2303936_MIME_Part" Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3043875948_2303936_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FOR IMMEDIATE RELEASE: Iprocenter.com just announced it=B9s new Productivity Center for Real Estate Agents. This system definitely raises the bar to a new level. The iprocenter.com system keeps on building on-line relationships via the latest email autoresponse system, even if your computer is unplugged or you're on vacation! Web sites for real estate agents have sprung up everywhere, overnight. Costing anywhere from $200 to $2000, it=B9s not a cheap proposition considering there is no guarantee they will make you more money . . . until now. One of the top agents in the country and better known in real estate as the "Smartest Marketer" in the Industry, Rand Smith, just launched a virtual production center guaranteed to work. "Agents don=B9t have time to get re-tooled with this technology stuff. It would take them years to catch up anyway. The good news is now they=B9ll never have to. We=B9ve programmed a complete consumer driven marketing drip system into every iProcenter.com site so all any agent has to do is literally flip the switch." "When they do that, their free email service is delivered ready-to-read, an update of new leads and where every person who has visited their site is currently at in a 7 step email drip system that is second to none. Everything is already done for you from the free reports to the auto-responder consumer follow-up drip system to allowing any buyer to search for a home "unmolested." The bottom line is that this site gives prospective buyers and sellers everything they want and need, and for the agent. This system does all of the follow up automatically. It develops a relationship with every potential prospect that enters your site. We provide the consumer with valuable information that educates them every step of the way. Extensive testing indicated that the only sites homebuyers will visit are the ones who give them what they want. . . their way. It=B9s a whole new game and we intend to arm every agent who is active and licensed to sell real estate with the state-of-the-art technology that works around the clock with a simple flip-of-a-switch! Go to http://iprocenter.com right now and get 30 days free and see for yourself if this isn=B9t the latest and greatest customer service minded online assistant available anywhere. Mentor Masters Active Agent Group ****If you have received this email in error, or prefer not to receive any more invitations to such events send an email to rand@mbay.net and ask to be removed. cuff6/00import-topagent6 --MS_Mac_OE_3043875948_2303936_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: IT KEEPS ON WORKING EVEN WHEN YOU TURN IT OFF!
FOR IMMEDIATE RELEASE:

Iprocenter.com just announced it=B9s new Productivity Center
for Real Estate Agents. This system definitely raises the
bar to a new level.  The iprocenter.com system keeps on
building on-line relationships via the latest email
autoresponse system, even if your computer is unplugged or
you're on vacation!

Web sites for real estate agents have sprung up everywhere,
overnight.  Costing anywhere from $200 to $2000, it=B9s not a
cheap proposition considering there is no guarantee they
will make you more money . . . until now.

One of the top agents in the country and better known in
real estate as the "Smartest Marketer" in the Industry, Rand
Smith, just launched a virtual production center guaranteed
to work.

"Agents don=B9t have time to get re-tooled with this
technology stuff.  It would take them years to catch up
anyway.  The good news is now they=B9ll never have to.  We=B9ve
programmed a complete consumer driven marketing drip system
into every iProcenter.com site so all any agent has to do is
literally flip the switch."

"When they do that, their free email service is delivered
ready-to-read, an update of new leads and where every person
who has visited their site is currently at in a 7 step email
drip system that is second to none.  Everything is already
done for you from the free reports to the auto-responder
consumer follow-up drip system to allowing any buyer to
search for a home "unmolested."

The bottom line is that this site gives prospective buyers
and sellers everything they want and need, and for the
agent. This system does all of the follow up automatically.
It develops a relationship with every potential prospect
that enters your site.

We provide the consumer with valuable information that
educates them every step of the way.  Extensive testing
indicated that the only sites homebuyers will visit are the
ones who give them what they want. . . their way.

It=B9s a whole new game and we intend to arm every agent who
is active and licensed to sell real estate with the
state-of-the-art technology that works around the clock with
a simple flip-of-a-switch!

Go to http://iprocenter.com right now a= nd get 30 days free
and see for yourself if this isn=B9t the latest and greatest
customer service minded online assistant available anywhere.

Mentor Masters Active Agent Group

****If you have received this email in error, or prefer
not to receive any more invitations to such events send
an email to rand@mbay.net and ask to be= removed.


cuff6/00import-topagent6

--MS_Mac_OE_3043875948_2303936_MIME_Part-- From owner-manet@itd.nrl.navy.mil Thu Jun 15 09:43:51 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01784 for ; Thu, 15 Jun 2000 09:43:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA06005 for manet-outgoing; Thu, 15 Jun 2000 06:42:39 -0400 (EDT) Received: from otter.mbay.net (otter.mbay.net [206.40.79.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA06000; Thu, 15 Jun 2000 06:42:37 -0400 (EDT) Received: from [206.55.224.48] (mty1-48.dip.mbay.net [206.55.224.48]) by otter.mbay.net (8.9.3/8.8.8) with ESMTP id BAA16164; Thu, 15 Jun 2000 01:06:09 -0700 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 15 Jun 2000 01:05:48 -0700 Subject: RE: IT KEEPS ON WORKING EVEN WHEN YOU TURN IT OFF! From: "Rand K. Smith" To: Top Agent6 Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3043875948_2303936_MIME_Part" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3043875948_2303936_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FOR IMMEDIATE RELEASE: Iprocenter.com just announced it=B9s new Productivity Center for Real Estate Agents. This system definitely raises the bar to a new level. The iprocenter.com system keeps on building on-line relationships via the latest email autoresponse system, even if your computer is unplugged or you're on vacation! Web sites for real estate agents have sprung up everywhere, overnight. Costing anywhere from $200 to $2000, it=B9s not a cheap proposition considering there is no guarantee they will make you more money . . . until now. One of the top agents in the country and better known in real estate as the "Smartest Marketer" in the Industry, Rand Smith, just launched a virtual production center guaranteed to work. "Agents don=B9t have time to get re-tooled with this technology stuff. It would take them years to catch up anyway. The good news is now they=B9ll never have to. We=B9ve programmed a complete consumer driven marketing drip system into every iProcenter.com site so all any agent has to do is literally flip the switch." "When they do that, their free email service is delivered ready-to-read, an update of new leads and where every person who has visited their site is currently at in a 7 step email drip system that is second to none. Everything is already done for you from the free reports to the auto-responder consumer follow-up drip system to allowing any buyer to search for a home "unmolested." The bottom line is that this site gives prospective buyers and sellers everything they want and need, and for the agent. This system does all of the follow up automatically. It develops a relationship with every potential prospect that enters your site. We provide the consumer with valuable information that educates them every step of the way. Extensive testing indicated that the only sites homebuyers will visit are the ones who give them what they want. . . their way. It=B9s a whole new game and we intend to arm every agent who is active and licensed to sell real estate with the state-of-the-art technology that works around the clock with a simple flip-of-a-switch! Go to http://iprocenter.com right now and get 30 days free and see for yourself if this isn=B9t the latest and greatest customer service minded online assistant available anywhere. Mentor Masters Active Agent Group ****If you have received this email in error, or prefer not to receive any more invitations to such events send an email to rand@mbay.net and ask to be removed. cuff6/00import-topagent6 --MS_Mac_OE_3043875948_2303936_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: IT KEEPS ON WORKING EVEN WHEN YOU TURN IT OFF!
FOR IMMEDIATE RELEASE:

Iprocenter.com just announced it=B9s new Productivity Center
for Real Estate Agents. This system definitely raises the
bar to a new level.  The iprocenter.com system keeps on
building on-line relationships via the latest email
autoresponse system, even if your computer is unplugged or
you're on vacation!

Web sites for real estate agents have sprung up everywhere,
overnight.  Costing anywhere from $200 to $2000, it=B9s not a
cheap proposition considering there is no guarantee they
will make you more money . . . until now.

One of the top agents in the country and better known in
real estate as the "Smartest Marketer" in the Industry, Rand
Smith, just launched a virtual production center guaranteed
to work.

"Agents don=B9t have time to get re-tooled with this
technology stuff.  It would take them years to catch up
anyway.  The good news is now they=B9ll never have to.  We=B9ve
programmed a complete consumer driven marketing drip system
into every iProcenter.com site so all any agent has to do is
literally flip the switch."

"When they do that, their free email service is delivered
ready-to-read, an update of new leads and where every person
who has visited their site is currently at in a 7 step email
drip system that is second to none.  Everything is already
done for you from the free reports to the auto-responder
consumer follow-up drip system to allowing any buyer to
search for a home "unmolested."

The bottom line is that this site gives prospective buyers
and sellers everything they want and need, and for the
agent. This system does all of the follow up automatically.
It develops a relationship with every potential prospect
that enters your site.

We provide the consumer with valuable information that
educates them every step of the way.  Extensive testing
indicated that the only sites homebuyers will visit are the
ones who give them what they want. . . their way.

It=B9s a whole new game and we intend to arm every agent who
is active and licensed to sell real estate with the
state-of-the-art technology that works around the clock with
a simple flip-of-a-switch!

Go to http://iprocenter.com right now a= nd get 30 days free
and see for yourself if this isn=B9t the latest and greatest
customer service minded online assistant available anywhere.

Mentor Masters Active Agent Group

****If you have received this email in error, or prefer
not to receive any more invitations to such events send
an email to rand@mbay.net and ask to be= removed.


cuff6/00import-topagent6

--MS_Mac_OE_3043875948_2303936_MIME_Part-- From owner-manet@itd.nrl.navy.mil Sun Jun 18 14:09:58 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09326 for ; Sun, 18 Jun 2000 14:09:58 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA09213 for manet-outgoing; Sun, 18 Jun 2000 11:00:08 -0400 (EDT) Received: from iti-idsc.gov.eg (mail.iti.gov.eg [163.121.12.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA09208 for ; Sun, 18 Jun 2000 10:59:53 -0400 (EDT) Received: from localhost (habanoub@localhost) by iti-idsc.gov.eg (8.9.3+Sun/8.9.3) with ESMTP id SAA07329 for ; Sun, 18 Jun 2000 18:05:01 +0300 (EEST) Date: Sun, 18 Jun 2000 18:05:01 +0300 (EEST) From: SSDP143 To: mobile adhoc group Subject: ports Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hi is there to be a port specified for the messages used in AODV? is it assigned yet? thanks From owner-manet@itd.nrl.navy.mil Sun Jun 18 15:53:51 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09853 for ; Sun, 18 Jun 2000 15:53:51 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA10663 for manet-outgoing; Sun, 18 Jun 2000 13:49:46 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA10658 for ; Sun, 18 Jun 2000 13:49:44 -0400 (EDT) Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 133jCZ-00028l-00 for manet@itd.nrl.navy.mil; Sun, 18 Jun 2000 18:49:43 +0100 Message-ID: <394D0BB6.3B23595D@ee.surrey.ac.uk> Date: Sun, 18 Jun 2000 18:49:42 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Buffer length Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi All: For those implementing MANET protocols: What is the buffer (or queue) length you are using in your experiments? Thanks, George A. -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Centre for Communications Systems Research Mobile Communications Research Group University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Mon Jun 19 01:31:31 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18948 for ; Mon, 19 Jun 2000 01:31:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA15806 for manet-outgoing; Sun, 18 Jun 2000 23:29:31 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA15801 for ; Sun, 18 Jun 2000 23:29:29 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA27875; Sun, 18 Jun 2000 20:29:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id UAA19853; Sun, 18 Jun 2000 20:29:17 -0700 X-Virus-Scanned: Sun, 18 Jun 2000 20:29:17 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma019627; Sun, 18 Jun 00 20:29:10 -0700 Message-ID: <394D9389.601BBABC@iprg.nokia.com> Date: Sun, 18 Jun 2000 20:29:13 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: SSDP143 CC: mobile adhoc group Subject: Re: ports References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, AODV has been assigned port number 654. Regards, Charlie P. SSDP143 wrote: > > hi > is there to be a port specified for the messages used in AODV? > is it assigned yet? > thanks From owner-manet@itd.nrl.navy.mil Mon Jun 19 10:08:22 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06437 for ; Mon, 19 Jun 2000 10:08:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA21229 for manet-outgoing; Mon, 19 Jun 2000 08:07:53 -0400 (EDT) Received: from web314.mail.yahoo.com (web314.mail.yahoo.com [216.115.105.79]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id IAA21220 for ; Mon, 19 Jun 2000 08:07:51 -0400 (EDT) Message-ID: <20000619120752.15942.qmail@web314.mail.yahoo.com> Received: from [216.6.88.34] by web314.mail.yahoo.com; Mon, 19 Jun 2000 05:07:52 PDT Date: Mon, 19 Jun 2000 05:07:52 -0700 (PDT) From: sunil nikam Subject: Conference info. required To: manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, I am a researcher in the field of mobile routing. Can anyone please tell me about any upcoming conferences/symposiums/events where one can submit a paper in the area of Mobile routing ? The last date for submission should be atleast 1 week from now. Thanks, Sunil. __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ From owner-manet@itd.nrl.navy.mil Mon Jun 19 11:55:14 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11929 for ; Mon, 19 Jun 2000 11:55:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA23329 for manet-outgoing; Mon, 19 Jun 2000 09:39:48 -0400 (EDT) Received: from ftchakountio.bbn.com (FTCHAKOUNTIO.BBN.COM [128.89.35.251]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA23324 for ; Mon, 19 Jun 2000 09:39:47 -0400 (EDT) Received: from localhost (ftchakou@localhost) by ftchakountio.bbn.com (8.8.8/8.8.8) with SMTP id JAA06645; Mon, 19 Jun 2000 09:44:07 -0400 (EDT) (envelope-from ftchakou@ftchakountio.bbn.com) Date: Mon, 19 Jun 2000 09:44:07 -0400 (EDT) From: Fabrice Tchakountio Reply-To: ftchakou@bbn.com To: sunil nikam cc: manet@itd.nrl.navy.mil Subject: Re: Conference info. required In-Reply-To: <20000619120752.15942.qmail@web314.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi - You can still submit a paper for Infocom 2001. The seadline is July 5. Thanks.. On Mon, 19 Jun 2000, sunil nikam wrote: > Hi, > > I am a researcher in the field of mobile routing. > Can anyone please tell me about any upcoming > conferences/symposiums/events where one can submit a > paper in the area of Mobile routing ? > The last date for submission should be atleast 1 week > from now. > > Thanks, > Sunil. > > __________________________________________________ > Do You Yahoo!? > Send instant messages with Yahoo! Messenger. > http://im.yahoo.com/ > From owner-manet@itd.nrl.navy.mil Tue Jun 20 08:28:24 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19132 for ; Tue, 20 Jun 2000 08:28:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA16695 for manet-outgoing; Tue, 20 Jun 2000 05:55:13 -0400 (EDT) Received: from fmweb02.unimessage.net (fmweb02.unimessage.net [212.6.90.130]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA16690 for ; Tue, 20 Jun 2000 05:55:11 -0400 (EDT) Received: from fmweb02.unimessage.net (localhost [127.0.0.1]) by fmweb02.unimessage.net (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA25936 for ; Tue, 20 Jun 2000 11:55:06 +0200 Message-ID: <135040862.961494906833.JavaMail.nobody@fmweb02.unimessage.net> Date: Tue, 20 Jun 2000 11:55:06 +0200 (GMT+02:00) From: Joachim Koch To: manet@itd.nrl.navy.mil Subject: comment Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="135045589.961494906685.JavaMail.nobody@fmweb02.unimessage.net" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk --135045589.961494906685.JavaMail.nobody@fmweb02.unimessage.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Sirs and Ladies, as you can see in the attachment, I have a comment to the TORA-Routing Algorithm. It's a specification of the Optimization Routes. As I got a message from Dr. Park, he also has a further spec of this (but no time to publish). Then there will be two versions of Optimization Routes that probably could be merged easily. Yours sincerly Joachim Koch -- ________________________________________________ redseven Community - Alleine war gestern http://www.redseven.de redseven freemail - der kostenlose eMail-Service http://mail.redseven.de Join us now! --135045589.961494906685.JavaMail.nobody@fmweb02.unimessage.net Content-Type: text/plain; name=ment-tora.txt Content-Disposition: attachment; filename=ment-tora.txt Content-Transfer-Encoding: 7bit comment to AUTHOR: Joachim Koch Faculty Network-Adm. Univ. Fulda Germany 3.5. Optimizing Routes [instead of TBD.] Optimization to low communication complexity results in a minimization of the neighbour's reference_level=(tau[k],oid[k],r[k]), i.e. for each link(i,k) which is downstream and num_down>1, the downstream links(i,k) could be optimized by the lowest reference_level. If the reference_levels differ, these with r[k]=0 should be preferred. If there are still some downstream links(i,k) remaining whose neighbour's reference_levels differ, these with tau[k]=Min. should be preferred. Finally, if there are still different downstream links(i,k) with the same neighbour's reference_level are remaining, then an optimization - as known in distance-vector-routing protocols - by lowest hop-count could be supported: Then the downstream links(i,k) with the minimum of neighbour's offset=(delta[i],i) should be taken. That is, delta[i]=Min. should be preferred. In summary, the optimization is a specific algorithm to minimize the height of the neighbour HT_NEIGH[k]=(tau[i],oid[i],r[i],delta[i],i) by setting the priority P(r[i]) > P(tau[i]) > P(delta[i]), where P(oid[i]) = P(i) = 0. --135045589.961494906685.JavaMail.nobody@fmweb02.unimessage.net-- From owner-manet@itd.nrl.navy.mil Thu Jun 22 08:50:23 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03178 for ; Thu, 22 Jun 2000 08:50:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA16423 for manet-outgoing; Thu, 22 Jun 2000 06:50:28 -0400 (EDT) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA16418 for ; Thu, 22 Jun 2000 06:50:26 -0400 (EDT) Received: from oleane (dyn-1-1-180.Vin.dialup.oleane.fr [195.25.4.180]) by smtp1.cluster.oleane.net with SMTP id MAA46839 for ; Thu, 22 Jun 2000 12:50:21 +0200 (CEST) Message-ID: <057301bfdc37$dc9f4280$0401a8c0@oleane.com> From: "Peter Lewis" To: Date: Thu, 22 Jun 2000 12:51:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0570_01BFDC48.9F9102A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0570_01BFDC48.9F9102A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable test ------=_NextPart_000_0570_01BFDC48.9F9102A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
test
------=_NextPart_000_0570_01BFDC48.9F9102A0-- From owner-manet@itd.nrl.navy.mil Thu Jun 22 12:34:01 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09628 for ; Thu, 22 Jun 2000 12:34:00 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA19864 for manet-outgoing; Thu, 22 Jun 2000 09:31:24 -0400 (EDT) Received: from adrastea.novaengr.com (adrastea.novaengr.com [198.30.180.41] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA19858 for ; Thu, 22 Jun 2000 09:31:22 -0400 (EDT) Received: by adrastea.novaengr.com with Internet Mail Service (5.5.2448.0) id <1W1NRNF8>; Thu, 22 Jun 2000 09:30:35 -0400 Message-ID: <1547CB756467D2119B4100A0C9824AAD4CFD80@adrastea.novaengr.com> From: "Ray O'Connell" To: "'manet@itd.nrl.navy.mil'" Subject: Mobile AS Networks Date: Thu, 22 Jun 2000 09:30:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I am looking for research papers in the area of using a border gateway protocol to connect mobile autonomous systems together in MANET network. The BGP routers would run a MANET routing protocol or interface to a separate MANET router to provide connectivity in the wireless network. Thanks, Ray O'Connell From owner-manet@itd.nrl.navy.mil Fri Jun 23 14:14:44 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16615 for ; Fri, 23 Jun 2000 14:14:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA18906 for manet-outgoing; Fri, 23 Jun 2000 12:16:06 -0400 (EDT) Received: from fmweb02.unimessage.net (fmweb02.unimessage.net [212.6.90.130]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA18897 for ; Fri, 23 Jun 2000 12:16:03 -0400 (EDT) Received: from fmweb02.unimessage.net (localhost [127.0.0.1]) by fmweb02.unimessage.net (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA10695 for ; Fri, 23 Jun 2000 18:15:58 +0200 Message-ID: <136187077.961776958068.JavaMail.nobody@fmweb02.unimessage.net> Date: Fri, 23 Jun 2000 18:15:58 +0200 (GMT+02:00) From: Joachim Koch To: manet@itd.nrl.navy.mil Subject: comment Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit --136597113.961776690278.JavaMail.nobody@fmweb02.unimessage.net Content-Type: text/plain; charset="iso-8859-1" Now with the document embedded instead as attachment for the archive. ----- Original Message ----- Von: joachimkoch@redseven.de An: manet@itd.nrl.navy.mil Empfangen: 20.06.2000 16:00 Betreff: comment Dear Sirs and Ladies, as you can see in the attachment, I have a comment to the TORA-Routing Algorithm. It's a specification of the Optimization Routes. As I got a message from Dr. Park, he also has a further spec of this (but no time to publish). Then there will be two versions of Optimization Routes that probably could be merged easily. Yours sincerly Joachim Koch -- _ --136597113.961776690278.JavaMail.nobody@fmweb02.unimessage.net Content-Type: text/plain; name=ment-tora.txt Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=ment-tora.txt comment to AUTHOR: Joachim Koch Faculty Network-Adm. Univ. Fulda Germany 3.5. Optimizing Routes [instead of TBD.] Optimization to low communication complexity results in a minimization of the neighbour's reference_level=(tau[k],oid[k],r[k]), i.e. for each link(i,k) which is downstream and num_down>1, the downstream links(i,k) could be optimized by the lowest reference_level. If the reference_levels differ, these with r[k]=0 should be preferred. If there are still some downstream links(i,k) remaining whose neighbour's reference_levels differ, these with tau[k]=Min. should be preferred. Finally, if there are still different downstream links(i,k) with the same neighbour's reference_level are remaining, then an optimization - as known in distance-vector-routing protocols - by lowest hop-count could be supported: Then the downstream links(i,k) with the minimum of neighbour's offset=(delta[i],i) should be taken. That is, delta[i]=Min. should be preferred. In summary, the optimization is a specific algorithm to minimize the height of the neighbour HT_NEIGH[k]=(tau[i],oid[i],r[i],delta[i],i) by setting the priority P(r[i]) > P(tau[i]) > P(delta[i]), where P(oid[i]) = P(i) = 0. --136597113.961776690278.JavaMail.nobody@fmweb02.unimessage.net-- -- ________________________________________________ redseven Community - Alleine war gestern http://www.redseven.de redseven freemail - der kostenlose eMail-Service http://mail.redseven.de Join us now! -- ________________________________________________ redseven Community - Alleine war gestern http://www.redseven.de redseven freemail - der kostenlose eMail-Service http://mail.redseven.de Join us now! From owner-manet@itd.nrl.navy.mil Mon Jun 26 13:23:06 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11379 for ; Mon, 26 Jun 2000 13:23:04 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA01681 for manet-outgoing; Mon, 26 Jun 2000 11:23:42 -0400 (EDT) Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA01676 for ; Mon, 26 Jun 2000 11:23:40 -0400 (EDT) Received: from cse.uta.edu (IDENT:ramesh@[129.107.55.202]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id KAA28408; Mon, 26 Jun 2000 10:15:18 -0500 (CDT) Message-ID: <39577488.B97C6C85@cse.uta.edu> Date: Mon, 26 Jun 2000 10:19:36 -0500 From: Ramesh Yerraballi Reply-To: ramesh@cse.uta.edu Organization: UTA Computer Science and Engineering X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: MOBICOM@acm.org Subject: WoWMoM-2000: Call for Participation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit --------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM-2000 The Third ACM International Workshop on Wireless Mobile Multimedia (in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center, Boston, Massachusetts, USA --------------------------------------------------------------------- Sponsors: * ACM SigMobile Support from: * Nortel Networks * The University of California at Riverside * DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science * CReWMaN at the University of Texas at Arlington --------------------------------------------------------------------- For uptodate technical program, registration information, and hotel information for the WoWMoM workshop are now available at http://www-cse.uta.edu/crewman/conferences/wowmom-2000/ If you are unable to access the above web page, please send e-mail to ramesh@cse.uta.edu -------------------------------------------------------------------------- WoWMoM 2000 Technical Program -------------------------------------------------------------------------- Welcome Address (8:00 am - 8:30 am) -------------------------------------------------------------------------- Session I ( 8:30 am - 10:00 am) Wireless QoS: Admission and Call Control * W2F2Q: Packet Fair Queuing in Wireless Packet Networks Yung Yi, Yongho Seok, Taekyoung Kwon and Yanghee Choi Seoul National University * A Wireless Fair Scheduling Algorithm for Error'Prone Wireless Channels Peng Lin, B. Bensaou, Q. L. Ding, and K.C. Chua National University of Singapore * A Novel Distributed Call Admission Control for Wireless Mobile Multimedia Networks Youssef Iraqi , University of Montreal Raouf Boutaba, University of Waterloo, Canada * Real-time Prioritized Call Admission Control in a Base Station Scheduler Jay R. Moorma, John W. Lockwood and Sung Mo Kang University of Illinois and Washington University, St. Louis -------------------------------------------------------------------------- Coffee Break (10:00 am - 10:30 am) -------------------------------------------------------------------------- Session II (10:30 am - 12:00 noon) Wireless Mobility: Support and Performance Analysis * An Integrated Mobility and Traffic Model for Resource Allocation in Wireless Networks Hisashi Kobayashi, Shum-Zheng Yu and Brian L. Mark Princeton University and George Mason University * Mobility Modeling of Rush Hour Traffic for Location Design Area in Cellular Networks Apurva Kumer, IBM - India Research Lab. M. N. Umesh, Silicon Automation Systems, India Rajesh Jha, Lucent Technologies, NJ * Multicast Support for Mobile IP with the Hierarchical Local Registration Approach H. Omar, T. Saadawi and M. Lee The City University of New York * Performance Evaluation of ATM/AAL2 as switching technology in 3G Mobile Access Networks Oscar Mezquita Baeza, GMD Fokus GmbH Berlin, Germany Enrico Scarrone, CSELT Turin, Italy -------------------------------------------------------------------------- Lunch Break (12:00 noon - 1:30 pm) -------------------------------------------------------------------------- Session III (1:30 pm - 3:00 pm) Resource Management in Mobile Systems * Managing the Storage and Battery Resources in an Image Capture Device (Digital Camera) using Dynamic Transcoding Surendar Chandra, Carla Schlatter Ellis and Amin Vahdat Duke University * Performance Modelling of Speculative Prefetching for Compound Requests in Low Bandwidth Networks N.J. Tuah, M. Kumar and S. Venkatesh Curtin University of Technology, Australia * A Modified CDMA/PRMA Medium Access Control Protocol for Integrated Services in LEO Satellite Systems Abbas Ibrahim and Samie Tohme Ecole Nationale Superieure des Telecommunications, Paris, France * Delay Jitter Performance of Video Traffic in a Cellular Wireless ATM Network T.C. Wong, J. W. Mark and K. C. Chua National University of Singapore and University of Waterloo, Canada -------------------------------------------------------------------------- Coffee Break (3:00 pm - 3:30 pm) -------------------------------------------------------------------------- Session IV (3:30 pm - 5:00 pm) Topic: Can Mobile Internet Be All Pervasive? Moderator: Kalyan Basu, Director, Nortel Networks Panelists: TBD -------------------------------------------------------------------------- END OF PROGRAM From owner-manet@itd.nrl.navy.mil Mon Jun 26 13:38:08 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11716 for ; Mon, 26 Jun 2000 13:38:06 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA02992 for manet-outgoing; Mon, 26 Jun 2000 12:04:51 -0400 (EDT) Received: from uci.agh.edu.pl (galaxy.uci.agh.edu.pl [149.156.96.9]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA02987 for ; Mon, 26 Jun 2000 12:04:45 -0400 (EDT) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id SAA07420 for ; Mon, 26 Jun 2000 18:04:22 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) for manet@itd.nrl.navy.mil id AA26648; Mon, 26 Jun 2000 18:03:15 +0200 Date: Mon, 26 Jun 2000 18:03:15 +0200 From: proms@saturn.kt.agh.edu.pl (Piotr Pacyna) Message-Id: <10006261603.AA26648@saturn.kt.agh.edu.pl> Organization: University of Mining and Metallurgy Address: Mickiewicza 30, 30-059 Krakow, POLAND To: manet@itd.nrl.navy.mil Subject: PROMS2000, deadline extended Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Sirs, Due to numerous requests for deadline extension we will keep accepting papers until 7th July 2000. Piotr Pacyna OC Chair ++++++++++++++++++++++++++++++++++++++++++++++++++++++ (We do apologize, if you receive multiple copies of this CfP) PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 DEADLINE EXTENDED Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies, ZWUT a Siemens Company, http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications, eg. voice over IP; * performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks; * definition, provisioning, and supervision of QoS parameters for networked applications and services, eg. in IntServ/DiffServ networks; * multimedia traffic engineering; * applications and platforms for service management and provisioning; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due July 7, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. PROCEEDINGS 1. Each participant will receive Proceedings from the conference. 2. Two best papers will be considered for publication in the IEEE Communications Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia Systems". CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ibrahim Habib, Univ. New York Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, proms@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl From owner-manet@itd.nrl.navy.mil Tue Jun 27 10:53:35 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14310 for ; Tue, 27 Jun 2000 10:53:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA23426 for manet-outgoing; Tue, 27 Jun 2000 08:49:08 -0400 (EDT) Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id IAA23420 for ; Tue, 27 Jun 2000 08:49:06 -0400 (EDT) Received: (qmail 11337 invoked by uid 11205); 27 Jun 2000 12:48:52 -0000 From: Laurent Viennot MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14680.41651.904705.246567@cupidon.inria.fr> Date: Tue, 27 Jun 2000 14:48:51 +0200 (CEST) To: manet@itd.nrl.navy.mil Subject: Overhead analysis X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: Laurent.Viennot@inria.fr Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear MANet members, After the discussions on the mailing, we have been thinking quite a lot with Philippe on overhead. We have developed some analysis about the relation between routing performance (overhead) and networks parameters (size, mobility, traffic). Our aim is to identify the scenarios which favor such and such MANet protocols. We consider a mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). We have identified two classes of protocols which more or less fit the reactive and proactive boundary: 1. the flooding protocols (AODV/DSR, TORA) 2. the hello protocols (DSDV,OLSR) The performance are quantified by the quantity of overhead generated by each protocols. We have identified two source of overheads: A. the control overheads B. the route overheads Our main findings are the following: -Both classes have O(N^2) control overheads which is no surprising from graph theory point of view. Flooding algorithm and hello algorithm have different factors in front of N^2 which actually depends on traffic, geometry, mobility. One can find scenarios in favor of flooding and other scenarios in favor of hello. -Flooding protocols may not provide optimal routes (in term of hop number) the average deviation between optimal routes can be significant (a factor of 33% in dense 1D networks, more in 2D and 3D). The overhead generated by the extra transmission of data may be important since it is proportional to data traffic. A research report detailing these results is available: http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) Comments are welcome, Laurent From owner-manet@itd.nrl.navy.mil Wed Jun 28 10:23:11 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23983 for ; Wed, 28 Jun 2000 10:23:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA17402 for manet-outgoing; Wed, 28 Jun 2000 07:20:38 -0400 (EDT) Received: from iti-idsc.gov.eg (mail.iti.gov.eg [163.121.12.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA17397 for ; Wed, 28 Jun 2000 07:20:34 -0400 (EDT) Received: from localhost (habanoub@localhost) by iti-idsc.gov.eg (8.9.3+Sun/8.9.3) with ESMTP id OAA04141 for ; Wed, 28 Jun 2000 14:25:56 +0300 (EEST) Date: Wed, 28 Jun 2000 14:25:56 +0300 (EEST) From: SSDP143 To: mobile adhoc group Subject: checking time Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear all, We are a goroup of students at the Information Technology Institute Egypt we are currently implementing the AODV deamon for linux, We have a question :When do the Deamon checks for the valid routs that it has in the routing table ; does it have a to check the routing table periodically to validate each route or just checks the routing table when there are requests for routes from other programs Best regards Azza Morcos Hany From owner-manet@itd.nrl.navy.mil Wed Jun 28 13:32:25 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28548 for ; Wed, 28 Jun 2000 13:32:25 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA23742 for manet-outgoing; Wed, 28 Jun 2000 11:38:34 -0400 (EDT) Received: from giascl01.vsnl.net.in (giascl01.vsnl.net.in [202.54.9.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA23737 for ; Wed, 28 Jun 2000 11:38:29 -0400 (EDT) Received: from impactjucal2 (ppp113-108.pppcal.vsnl.net.in [203.197.113.108]) by giascl01.vsnl.net.in (8.9.0/8.9.0) with SMTP id VAA15266; Wed, 28 Jun 2000 21:09:54 +0500 (GMT+0500) From: "Samir R. Das" To: "SSDP143" , "mobile adhoc group" Subject: RE: checking time Date: Wed, 28 Jun 2000 11:40:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, AODV is an on-demand protocol. Routing table is checked for valid routes only when there is a data packet (from an application, or from another node) that needs to be routed to a remote node in the ad hoc network. Samir >-----Original Message----- >From: owner-manet@itd.nrl.navy.mil >[mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of SSDP143 >Sent: Wednesday, June 28, 2000 7:26 AM >To: mobile adhoc group >Subject: checking time > > >Dear all, > We are a goroup of students at the Information Technology >Institute Egypt we are currently implementing the AODV deamon for linux, >We have a question :When do the Deamon checks for the valid routs that it >has in the routing table ; does it have a to check the routing table >periodically to validate each route or just checks the routing table when >there are requests for routes from other programs > Best regards > > Azza > >Morcos > >Hany > > From owner-manet@itd.nrl.navy.mil Wed Jun 28 23:23:29 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09687 for ; Wed, 28 Jun 2000 23:23:29 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA07633 for manet-outgoing; Wed, 28 Jun 2000 21:49:38 -0400 (EDT) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id VAA07628 for ; Wed, 28 Jun 2000 21:49:37 -0400 (EDT) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e5T1nL308694 for ; Wed, 28 Jun 2000 21:49:21 -0400 (EDT) Message-Id: <200006290149.e5T1nL308694@breeze.research.telcordia.com> To: manet@itd.nrl.navy.mil Subject: Mobicom 2000 Date: Wed, 28 Jun 2000 21:49:20 -0400 From: Ashutosh Dutta Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Please ignore duplicate mailings. Thanks Ashutosh ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from IBM Research (Platinum supporter), HP Laboratories (Platinum supporter), Nokia (Gold supporter), AT&T Laboratories Cambridge (Gold supporter), 3COM (Gold Supporter) and Xerox Parc (Gold Supporter) CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-manet@itd.nrl.navy.mil Thu Jun 29 11:10:40 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10304 for ; Thu, 29 Jun 2000 11:10:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA15661 for manet-outgoing; Thu, 29 Jun 2000 09:11:21 -0400 (EDT) Received: from emily.cs.bham.ac.uk (emily.cs.bham.ac.uk [147.188.192.10]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA15656 for ; Thu, 29 Jun 2000 09:11:19 -0400 (EDT) Received: from dipsy.cs.bham.ac.uk by emily.cs.bham.ac.uk (Exim 3.11 #1) with esmtp id 137e5E-0007JU-00 for manet@itd.nrl.navy.mil; Thu, 29 Jun 2000 14:10:20 +0100 Message-ID: <395B49BA.59B953DB@cs.bham.ac.uk> Date: Thu, 29 Jun 2000 14:06:02 +0100 From: Charanjit S Ahluwalia Organization: School of Computer Science, The University of Birmingham, U.K. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Opnet Simulation of mobile ad hoc networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This is charanjit from university of birmingham in u.k.. For my final year Msc project I am doing A simulation of location aided routing on Opnet... It seems you have already implemented mobile routing in Opnet. Can you please share some information on this , Can i get more literature etc on the obove subject.. Please let me know if you have some information for me.. Cheers Charanjit Singh From owner-manet@itd.nrl.navy.mil Thu Jun 29 15:53:21 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18868 for ; Thu, 29 Jun 2000 15:53:20 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA22114 for manet-outgoing; Thu, 29 Jun 2000 13:47:37 -0400 (EDT) Received: from swarm.cs.wustl.edu (swarm.cs.wustl.edu [128.252.165.116]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA22109 for ; Thu, 29 Jun 2000 13:47:35 -0400 (EDT) Received: (from roman@localhost) by swarm.cs.wustl.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA20524 for manet@itd.nrl.navy.mil; Thu, 29 Jun 2000 12:46:23 -0500 (BLT) Date: Thu, 29 Jun 2000 12:46:23 -0500 (BLT) From: roman@swarm.cs.wustl.edu (Catalin Roman) Message-Id: <200006291746.MAA20524@swarm.cs.wustl.edu> To: manet@itd.nrl.navy.mil Subject: COORDINATION 2000 (Call for PartciParticipation) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk ||||||| CALL FOR PARTICIPATION ||||||||||||||||||||||||||||| COORDINATION 2000 Fourth International Conference on Coordination Models and Languages Limassol, Cyprus 11-13 September 2000 http://www-gloc.di.fct.unl.pt/coord00/ Early registration deadline: 15 July 2000 ||||||| CALL FOR PARTICIPATION ||||||||||||||||||||||||||||| On behalf of the organizing committee we would like to extend to you a warm invitation to join us this September for an exciting program and wonderful intellectual debates in the unique setting provided by Cyprus, a beautiful mythical island whose wonders are best revealed in the early days of fall. Because Cyprus is a popular vacation spot, early registration is advised. As in the past, this year's program brings together a broad range of themes associated with the development of coordination models and languages, their theoretical underpinning, and pragmatic implications. Topics receiving extended coverage include tuple space languages and their application, coordination styles and policies, migration and reconfiguration, agent systems, software architectures, dependability, etc. The single track program punctuated by ample opportunities for socializing and critical evaluation of the field allows the participants to evaluate trends, to examine a broad range of issues, and to engage each other in spirited discussions that, as previous conferences have shown, actually reshaped research agendas and led to novel developments. Antonio Porto and Catalin Roman From owner-manet@itd.nrl.navy.mil Fri Jun 30 09:54:56 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17574 for ; Fri, 30 Jun 2000 09:54:55 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA07820 for manet-outgoing; Fri, 30 Jun 2000 07:47:45 -0400 (EDT) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA07807 for ; Fri, 30 Jun 2000 07:47:42 -0400 (EDT) Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by ee.cornell.edu (8.9.3/8.9.1) with ESMTP id HAA15169; Fri, 30 Jun 2000 07:47:36 -0400 (EDT) Date: Fri, 30 Jun 2000 07:47:45 -0400 (EDT) From: Zygmunt Haas To: Laurent Viennot cc: manet@itd.nrl.navy.mil Subject: Re: Overhead analysis In-Reply-To: <14680.41651.904705.246567@cupidon.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Laurent, There is another "class" of protocols, the hybrid class, which is a mix of proactive-reactive behavior. Examples of such protocols include the Zone Routing Protocol (ZRP) and the Fisheye protocol. As you have stated, pure proactive/reactive protocols may not present "optimal" performance for a specific network operational conditions (mobility and traffic). The bigest advantage of the hybrid class is that it can adapt itself to the network operational conditions. More specifically, by dynamically adjusting the ratio of the proactive vs. reactive behavior, the amount of overhead control traffic can be *drastically* reduced. In the Zone Routing Protocol, this is achieved through the use of a single parameter - the Zone Radius, which is updated based on continual measurement of the mobility (the rate of creation/destruction of links with a node's neighbors) and the amout of traffic a node sees. (More on updating of the zone radius could be found in our paper in JSAC / August 1999.) I guess, what I am trying to say is that the hybrid class of protocols is the answer to the conclusions of your study - that in order to "cover" a broad range of MANET topologies (size of networks) and operational conditions, a *hybrid* strategy should be used. Zygmunt. ==--==-=== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas tel: +1-607-255-3454 Wireless Networks Laboratory School of Electrical Engineering fax: +1-607-255-9072 Cornell University 323 Frank Rhodes Hall e-mail: haas@ee.cornell.edu Ithaca, NY 14853 U.S.A http://www.ee.cornell.edu/~haas/wnl.html ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Tue, 27 Jun 2000, Laurent Viennot wrote: > > Dear MANet members, > > After the discussions on the mailing, we have been thinking quite a > lot with Philippe on overhead. We have developed some analysis about > the relation between routing performance (overhead) and networks > parameters (size, mobility, traffic). Our aim is to identify the > scenarios which favor such and such MANet protocols. We consider a > mobile ad-hoc network with N nodes (N assumed large, say N>50 nodes). > > We have identified two classes of protocols which more or less fit > the reactive and proactive boundary: > > 1. the flooding protocols (AODV/DSR, TORA) > 2. the hello protocols (DSDV,OLSR) > > The performance are quantified by the quantity of overhead generated > by each protocols. We have identified two source of overheads: > > A. the control overheads > B. the route overheads > > Our main findings are the following: > > -Both classes have O(N^2) control overheads which is no surprising > from graph theory point of view. Flooding algorithm and hello > algorithm have different factors in front of N^2 which actually > depends on traffic, geometry, mobility. One can find scenarios in > favor of flooding and other scenarios in favor of hello. > > -Flooding protocols may not provide optimal routes (in term of hop > number) the average deviation between optimal routes can be > significant (a factor of 33% in dense 1D networks, more in 2D and > 3D). The overhead generated by the extra transmission of data may be > important since it is proportional to data traffic. > > > A research report detailing these results is available: > http://menetou.inria.fr/~viennot/postscripts/overhead.ps.gz (166 Kb) > > > Comments are welcome, > > > Laurent > From owner-manet@itd.nrl.navy.mil Fri Jun 30 15:18:02 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24682 for ; Fri, 30 Jun 2000 15:18:01 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA15095 for manet-outgoing; Fri, 30 Jun 2000 13:00:26 -0400 (EDT) Received: from crane.prod.itd.earthlink.net (crane.prod.itd.earthlink.net [207.217.120.44]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA15083 for ; Fri, 30 Jun 2000 13:00:19 -0400 (EDT) Received: from qual-pro.com (pool0730.cvx29-bradley.dialup.earthlink.net [209.179.136.220]) by crane.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id JAA21649 for ; Fri, 30 Jun 2000 09:56:44 -0700 (PDT) Received: from yokneam (yokneam.qual-pro.com [192.168.1.3]) by qual-pro.com (8.8.5/8.8.5) with SMTP id LAA11622 for ; Fri, 30 Jun 2000 11:00:06 -0700 Received: by localhost with Microsoft MAPI; Fri, 30 Jun 2000 09:57:14 -0700 Message-ID: <01BFE279.912674C0.dshane@qual-pro.com> From: Darrell Shane Reply-To: "dshane@qual-pro.com" To: "manet@itd.nrl.navy.mil" Subject: Patents, IETF proposals and papers Date: Fri, 30 Jun 2000 09:57:13 -0700 Organization: Qual-Pro Corporation X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Are authors / inventors of routing protocols patenting their ideas? What are the implications with regard to a subsequent IETF proposal, and conference or journal publications? What are the drawbacks? Thanks, Darrell Shane From owner-manet@itd.nrl.navy.mil Fri Jun 30 17:12:45 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26618 for ; Fri, 30 Jun 2000 17:12:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA18686 for manet-outgoing; Fri, 30 Jun 2000 15:09:06 -0400 (EDT) Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA18681 for ; Fri, 30 Jun 2000 15:09:04 -0400 (EDT) Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id OAA29260; Fri, 30 Jun 2000 14:09:00 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id OAA01726; Fri, 30 Jun 2000 14:08:08 -0500 (CDT) Date: Fri, 30 Jun 2000 14:08:08 -0500 (CDT) Message-Id: <200006301908.OAA01726@sun.cs.tamu.edu> To: dshane@qual-pro.com, manet@itd.nrl.navy.mil Subject: Re: Patents, IETF proposals and papers Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk >> From owner-manet@itd.nrl.navy.mil Fri Jun 30 12:43:40 2000 >> From: Darrell Shane >> To: "manet@itd.nrl.navy.mil" >> Subject: Patents, IETF proposals and papers >> >> Hello, >> >> Are authors / inventors of routing protocols patenting their ideas? >> What are the implications with regard to a subsequent IETF proposal, >> and conference or journal publications? What are the drawbacks? I don't know the answer to your question, but on a related topic, you might be interested in looking at Phil Karn's page on the patenting issue ... it makes for an interesting reading, even if you happen to disagree with him: http://people.qualcomm.com/karn/patents/patents.html I hope IETF would not knowingly standardize something for which some idiot plans to make people pay-for-use. I presume IETF might standardized something for which XYZ has a patent, but only if that XYZ agrees to waive the patent rights. - nitin >> >> Thanks, >> Darrell Shane >> From owner-manet@itd.nrl.navy.mil Fri Jun 30 17:30:16 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26930 for ; Fri, 30 Jun 2000 17:30:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA19576 for manet-outgoing; Fri, 30 Jun 2000 15:43:16 -0400 (EDT) Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA19571; Fri, 30 Jun 2000 15:43:12 -0400 (EDT) Message-Id: <4.2.2.20000630152407.0200b100@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 30 Jun 2000 15:39:22 -0400 To: "dshane@qual-pro.com" , "manet@itd.nrl.navy.mil" From: Joe Macker Subject: Re: Patents, IETF proposals and papers In-Reply-To: <01BFE279.912674C0.dshane@qual-pro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Please see RFC 2026 on the Internet Standards Process. This should help explain to people who do not know some of guidelines in how the IETF handles Intellectual Property Rights issues. Also see http://www.ietf.org/ipr.html for some example patent statements that may relate to IETF work. This is a subject/policy more general than the manet WG and is not an appropriate thread for this mailing list. Check the IETF/IESG for more questions/info on such matters. -Joe At 09:57 AM 6/30/00 -0700, Darrell Shane wrote: >Hello, > >Are authors / inventors of routing protocols patenting their ideas? >What are the implications with regard to a subsequent IETF proposal, >and conference or journal publications? What are the drawbacks? > >Thanks, >Darrell Shane From owner-manet@itd.nrl.navy.mil Fri Jun 30 18:18:08 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27674 for ; Fri, 30 Jun 2000 18:18:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA20445 for manet-outgoing; Fri, 30 Jun 2000 16:22:42 -0400 (EDT) Received: from papa.casa.com ([213.0.67.204]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA20440 for ; Fri, 30 Jun 2000 16:22:39 -0400 (EDT) Received: from ieee.org (localhost [127.0.0.1]) by papa.casa.com (8.9.3/8.9.3) with ESMTP id WAA03527; Fri, 30 Jun 2000 22:22:07 GMT Message-ID: <395D1D8F.1D0E958A@ieee.org> Date: Fri, 30 Jun 2000 22:22:07 +0000 From: Miguel Sanchez Reply-To: misan@disca.upv.es X-Mailer: Mozilla 4.72 [es] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Nitin H Vaidya , "manet@itd.nrl.navy.mil" Subject: Re: Patents, IETF proposals and papers References: <200006301908.OAA01726@sun.cs.tamu.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Phil's proposed controversy (criticism) about the IP laws and rights is right on target. I do not know if some routing algorithms are (or are being) patented, but I detected some controversy some months ago about the RFC 2026 section 10 about IP rights. It seems that not all group members (or algorithms authors) share the same view regarding to follow the cited reference framework. Most if not all the IETF work is available to the public (for free). I think it should be this way while things are community-reviewed (i.e: I do not think it is fair to get some help from other people but to retain IP by means of patenting the invention now improved). Maybe you will be surprised to know that IP protection swings a lot from country to country. To my reduced knowledge, USA laws cover a wider range of things that can be patented. So maybe certain claims can only be granted is some countries (i.e: algorithms). Regards, Miguel Sanchez Nitin H Vaidya escribió: > >> From owner-manet@itd.nrl.navy.mil Fri Jun 30 12:43:40 2000 > >> From: Darrell Shane > >> To: "manet@itd.nrl.navy.mil" > >> Subject: Patents, IETF proposals and papers > >> > >> Hello, > >> > >> Are authors / inventors of routing protocols patenting their ideas? > >> What are the implications with regard to a subsequent IETF proposal, > >> and conference or journal publications? What are the drawbacks? > > I don't know the answer to your question, but on a related > topic, you might be interested in looking at Phil Karn's > page on the patenting issue ... it makes for an interesting > reading, even if you happen to disagree with him: > > http://people.qualcomm.com/karn/patents/patents.html > > I hope IETF would not knowingly standardize something for > which some idiot plans to make people pay-for-use. I presume > IETF might standardized something for which XYZ has a patent, > but only if that XYZ agrees to waive the patent rights. > > - nitin > > >> > >> Thanks, > >> Darrell Shane > >>