From owner-manet@itd.nrl.navy.mil Sun Oct 1 07:31: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 SMTP id HAA08105 for ; Sun, 1 Oct 2000 07:31:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA10180 for manet-outgoing; Sun, 1 Oct 2000 04:27:54 -0400 (EDT) Received: from fw.hbwhptt.net.cn. ([202.103.0.161]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id EAA10175 for ; Sun, 1 Oct 2000 04:27:50 -0400 (EDT) From: cabnewstv2@rocketmail.com Received: from 202.103.0.161 by fw.hbwhptt.net.cn. (SMI-8.6/SMI-SVR4) id IAA20757; Sun, 1 Oct 2000 08:12:39 -0800 Received: from cabnewstv2@rocketmail.com by cabnewstv2@rocketmail.com (8.8.5/8.6.5) with SMTP id GAA00722 for ; Sat, 30 Sep 2000 23:04:26 -0600 (EST) Date: Sat, 30 Sep 00 23:04:26 EST To: cabnewstv2@rocketmai.com Subject: CABLE TV Message-ID: <> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV DE-SCRAMBLER. IF YOU HAVE NO INTEREST IN THIS INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- LEGAL CABLE TV DE-SCRAMBLER Want to watch Sporting Events?--Movies?--Pay-Per-View?? You can assemble from electronic store parts for about $12.00. We Send You: E-Z To follow Assembly Instructions. E-Z To read Original Drawings. Electronic parts lists. PLUS SOMETHING NEW YOU MUST HAVE! Something you can't do without. THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY Warning: You should not build a TV Descrambler without reading this report first. Frequently Asked Questions--CABLE TV DESCRAMBLER Q: Will the descrambler work on Fiber, TCI, Jarrod A: The answer is YES. Q: Do I need a converter box? A: This plan works with or without a converter box. Specific instructions are included in the plans for each! Q: Can the cable company detect that I have the descrambler? A: No, the signal descrambles right at the box and does not move back through the line! Q: Do I have to alter my existing cable system, television or VCR? A: The answer is no! Q: Does this work with my remote control? A: The answer is yes. The descrambler is manually controlled--but very easy to use! Q: Can you email me the plans? A: No the program comes with an easy to follow picture guide. Q: Does this work everywhere across the country? A: Yes, every where in the USA plus England, Brazil, Canada and other countries! Q: Is this deal guaranteed? A: Yes, if you are unhappy for any reason we will refund your money. ORDER INFORMATION ACT WITHIN THE NEXT 7 DAYS AND RECEIVE TWO FREE BONUS!! THE CABLE MANUAL! This manual contains hard to find information your cable company does not want you to know. Also receive The RADAR JAMMER PLANS! Never get another speeding ticket. Build you own radar jammer, this unit will jam police radar so they can't get a reading on your vechicle. Radar jammers are legal in 48 states. It is simple to build. The FREE BONUSES ALONE ARE WORTH ACTING NOW! THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED, SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE ACT NOW AND SAVE!! SIMPLY SEND $12.95, THAT'S ONLY $12.95 BUT YOU MUST ORDER WITHIN 7 DAYS FOR THIS SPECIAL PRICE!!! SEND $12.95 CHECK OR, MONEY ORDER, OR CREDIT CARD INFORMATION TO: QUALITY RESOURCES 5399 EAST HWY C30-A #242 SEAGROVE BEACH, FL 32459 FOR CREDIT CARD ORDERS FILL OUT THIS FORM AND MAIL IN, ATTENTION QUALITY RESOURCES, here is my credit card information for the amount of $12.95 for the cable descrambler kit. ACCOUNT NUMBER____________________________________ EXP. DATE____________________ NAME_____________________________________________ BILLING ADDRESS__________________________________________ CITY/STATE/ZIP_____________________________________ HOME PHONE__________________________________ THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY! This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E mail. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of new millennium! If you would like to be removed cartor12@dcemail.com From owner-manet@itd.nrl.navy.mil Mon Oct 2 18:50: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 SMTP id SAA15327 for ; Mon, 2 Oct 2000 18:50:49 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA20206 for manet-outgoing; Mon, 2 Oct 2000 16:52:57 -0400 (EDT) Received: from hotmail.com (f140.law9.hotmail.com [64.4.9.140]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA20198 for ; Mon, 2 Oct 2000 16:52:55 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Oct 2000 13:52:17 -0700 Received: from 134.74.60.103 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 02 Oct 2000 20:52:17 GMT X-Originating-IP: [134.74.60.103] From: "Yong Liu" To: manet@itd.nrl.navy.mil Cc: yliu09@yahoo.com Subject: Bluetooth address. Date: Mon, 02 Oct 2000 16:52:17 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Oct 2000 20:52:17.0817 (UTC) FILETIME=[A6A78090:01C02CB2] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, everyone: When I read the Specification of the Bluetooth System, I'm a little comfused about the address of Bluetooth device. Although every bluetooth device has a BD_ADDR address, the access code of bluetooth packet only contains the information of LAP field of the BD_ADDR address.So I wonder if LAP field of the BD_ADDR is enough to identify different Bluetooth devices, or if LAP is unique to every bluetooth device, or can two bluetooth devices have the same LAP address? Can anyone help me make this clear? Thanks, Yong _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-manet@itd.nrl.navy.mil Tue Oct 3 05:41: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 SMTP id FAA04878 for ; Tue, 3 Oct 2000 05:41:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA28899 for manet-outgoing; Tue, 3 Oct 2000 02:59:23 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA28894 for ; Tue, 3 Oct 2000 02:59:20 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e936wcZ13017 for ; Tue, 3 Oct 2000 08:58:38 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Oct 03 08:58:37 2000 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Tue, 3 Oct 2000 08:58:37 +0200 Message-ID: From: =?ISO-8859-1?Q?Johan_S=F6rensen_=28ECS=29?= To: "'Yong Liu'" , manet@itd.nrl.navy.mil Cc: yliu09@yahoo.com Subject: RE: Bluetooth address. Date: Tue, 3 Oct 2000 08:58:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id CAA28895 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id CAA28899 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA04878 Yong, Since the LAP is only a part of the whole unique BD_ADDR, the LAP is not unique in itself. The access code in the beginning of every packet is not there to uniquely identify anything in itself. A device expecting a packet correlates against the access code to find the beginning of the next packet within the piconet. Then the header checksum calculation also makes some use of the BD_ADDR of the master to verify the piconet identity. Regards, Johan Sörensen. -----Original Message----- From: Yong Liu [mailto:yliu09@hotmail.com] Sent: den 2 oktober 2000 22:52 To: manet@itd.nrl.navy.mil Cc: yliu09@yahoo.com Subject: Bluetooth address. Hi, everyone: When I read the Specification of the Bluetooth System, I'm a little comfused about the address of Bluetooth device. Although every bluetooth device has a BD_ADDR address, the access code of bluetooth packet only contains the information of LAP field of the BD_ADDR address.So I wonder if LAP field of the BD_ADDR is enough to identify different Bluetooth devices, or if LAP is unique to every bluetooth device, or can two bluetooth devices have the same LAP address? Can anyone help me make this clear? Thanks, Yong From owner-manet@itd.nrl.navy.mil Tue Oct 3 07:37: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 SMTP id HAA06414 for ; Tue, 3 Oct 2000 07:37:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA00059 for manet-outgoing; Tue, 3 Oct 2000 04:34:57 -0400 (EDT) Received: from notes-gate.yamato.ibm.com (notes-gate.yamato.ibm.co.jp [203.141.89.19]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA00051 for ; Tue, 3 Oct 2000 04:34:54 -0400 (EDT) Received: from d22mta13.yamato.ibm.com (d22mta13.yamato.ibm.com [9.68.246.84]) by notes-gate.yamato.ibm.com (8.9.3/3.7W/NG3.6) with SMTP id RAA66424; Tue, 3 Oct 2000 17:34:34 +0900 Received: by d22mta13.yamato.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 4925696D.002F39EF ; Tue, 3 Oct 2000 17:35:50 +0900 X-Lotus-FromDomain: IBMJP@INTERNET From: "Tohru Aihara" To: manet@itd.nrl.navy.mil cc: "Yong Liu" Message-ID: <4925696D.002F3834.00@d22mta13.yamato.ibm.com> Date: Tue, 3 Oct 2000 17:34:04 +0900 Subject: Re: Bluetooth address. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Yong, You are right. Packets in a piconet are identified with the access code derived from the 24-bit LAP of the master. However, the FH of the piconet is derived from the master's lower 28-bit BD_ADDR and the master's 28-bit system clock in the connection state. I think an LAP with a specific FH is usually enough to identify the piconet nearby, although some Bluetooth devices can have the same LAP addresses, There can still theoretically be identical piconets if the masters have the same lower 28-bit of Bluetooth address and if the system clocks are synchronized. Can you really imagine the situation? Best regards, Toru Aihara IBM Research, Tokyo Research Laboratory From: "Yong Liu" on 2000/10/03 05:52 To: manet@itd.nrl.navy.mil cc: yliu09@yahoo.com (bcc: Tohru Aihara/Japan/IBM) Subject: Bluetooth address. Hi, everyone: When I read the Specification of the Bluetooth System, I'm a little comfused about the address of Bluetooth device. Although every bluetooth device has a BD_ADDR address, the access code of bluetooth packet only contains the information of LAP field of the BD_ADDR address.So I wonder if LAP field of the BD_ADDR is enough to identify different Bluetooth devices, or if LAP is unique to every bluetooth device, or can two bluetooth devices have the same LAP address? Can anyone help me make this clear? Thanks, Yong _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-manet@itd.nrl.navy.mil Tue Oct 3 23:54: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 SMTP id XAA28879 for ; Tue, 3 Oct 2000 23:54:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA29511 for manet-outgoing; Tue, 3 Oct 2000 21:58:49 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id VAA29506 for ; Tue, 3 Oct 2000 21:58:45 -0400 (EDT) From: markk@sg.ibm.com Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id LAA198672; Wed, 4 Oct 2000 11:47:04 +1000 Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f03n05e.au.ibm.com (8.8.8m3/NCO v4.93) with SMTP id MAA49964; Wed, 4 Oct 2000 12:57:51 +1100 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA25696E.000AC764 ; Wed, 4 Oct 2000 12:57:44 +1100 X-Lotus-FromDomain: IBMSG@IBMAU To: "Tohru Aihara" cc: manet@itd.nrl.navy.mil, "Yong Liu" Message-ID: Date: Wed, 4 Oct 2000 09:57:19 +0800 Subject: Re: Bluetooth address. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Aihara and Yong, The access code (which uses LAP) is not the only thing used when receiving a packet. The packet header is also used in deciding whether a packet belongs to the correct piconet. The HEC in the header uses master's UAP (page 53 of baseband spec). The combination of UAP and LAP should make every piconet unique. Best Regards, Mar Kheng Kok IBM Emerging Technology Centre "Tohru Aihara" on 10/03/2000 04:34:04 PM Please respond to "Tohru Aihara" To: manet@itd.nrl.navy.mil cc: "Yong Liu" (bcc: Kheng Kok Mar/Singapore/IBM) Subject: Re: Bluetooth address. Hi Yong, You are right. Packets in a piconet are identified with the access code derived from the 24-bit LAP of the master. However, the FH of the piconet is derived from the master's lower 28-bit BD_ADDR and the master's 28-bit system clock in the connection state. I think an LAP with a specific FH is usually enough to identify the piconet nearby, although some Bluetooth devices can have the same LAP addresses, There can still theoretically be identical piconets if the masters have the same lower 28-bit of Bluetooth address and if the system clocks are synchronized. Can you really imagine the situation? Best regards, Toru Aihara IBM Research, Tokyo Research Laboratory From: "Yong Liu" on 2000/10/03 05:52 To: manet@itd.nrl.navy.mil cc: yliu09@yahoo.com (bcc: Tohru Aihara/Japan/IBM) Subject: Bluetooth address. Hi, everyone: When I read the Specification of the Bluetooth System, I'm a little comfused about the address of Bluetooth device. Although every bluetooth device has a BD_ADDR address, the access code of bluetooth packet only contains the information of LAP field of the BD_ADDR address.So I wonder if LAP field of the BD_ADDR is enough to identify different Bluetooth devices, or if LAP is unique to every bluetooth device, or can two bluetooth devices have the same LAP address? Can anyone help me make this clear? Thanks, Yong _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-manet@itd.nrl.navy.mil Wed Oct 4 12:37: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 SMTP id MAA25581 for ; Wed, 4 Oct 2000 12:37:20 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA13276 for manet-outgoing; Wed, 4 Oct 2000 10:09:59 -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 KAA13271 for ; Wed, 4 Oct 2000 10:09:56 -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.16 #1) id 13gpEO-0004Vy-00 for manet@itd.nrl.navy.mil; Wed, 04 Oct 2000 15:09:12 +0100 Message-ID: <39DB3A06.F8F6A6A2@ee.surrey.ac.uk> Date: Wed, 04 Oct 2000 15:09:10 +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: MANET MAC schemes 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, We have developped a MAC protocol for MANETs and have completed the evaluation and comparison with IEEE 802.11. As we thought of comparing the scheme with some of the already proposed MANET MAC schemes, such as MACA-BI, MACA/PR, MACAW... , I thought of asking whether anyone of you know whether the source code of any of these schemes is publicly available on the net so that we could directly perform comparisons with them. Any response will be highly appreciated. Regards, George A. -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Thu Oct 5 08:02: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 SMTP id IAA26933 for ; Thu, 5 Oct 2000 08:02:09 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA11054 for manet-outgoing; Thu, 5 Oct 2000 06:11:46 -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 GAA11049 for ; Thu, 5 Oct 2000 06:11:42 -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 MAA09584 for ; Thu, 5 Oct 2000 12:10:55 +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 AA28891; Thu, 5 Oct 2000 12:10:17 +0200 Date: Thu, 5 Oct 2000 12:10:17 +0200 From: proms@saturn.kt.agh.edu.pl (Piotr Pacyna) Message-Id: <10010051010.AA28891@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: Call for Participation Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We do apologize, if you receive multiple copies of this e-mail --------------------------------------------------------------------- PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 CALL FOR PARTICIPATION Cracow, Poland, October 22-25, 2000 http://PROMS2000.kt.agh.edu.pl/ PRELIMINARY CONFERENCE PROGRAMME Monday, 23 October 2000 08:30-09:50 Registration 09:50-10:00 Opening 10:00-11:30 Tutorial Stefan Arbanowski, Sven van den Meyer, Technical University Berlin, Germany Flexible media and content adaptation for Communication Systems 11:50-13:20 Tutorial Johan Zuidweg, Tecsidel S.A., Spain Software architectures for Next Generation Networks 14:50-16:10 Session 1A - Multimedia Protocols SIGTRAN: Signaling Transport A Relative Differentiated Service Model for Adaptive Traffic Decreasing Transfer Delay Through Partial Reliability Issues about Advance Reservation for Real-Time Traffic 14:50-16:10 Session 1B: IP-Based Services Virtual Broadcast - A novel service based on IP Multicast Scalable Resource Management Architecture for VoIP Unicast Extensions to IP Multicast 16:30-18:00 Tutorial Stanislaw Jedrus, Polish Academy of Science, Poland Practical introduction to multimedia traffic characterization and modelling techniques Tuesday, 24 October 2000 9:00-10:30 Tutorial Oliver Verscheure, IBM T.J. Watson Laboratory Scalable Multi-Windowed DTV Experience 11:50-13:00 Session 2A: QoS Management A Reflective Component-Based Middleware with Quality of Service Management QoS measurements and comparative analysis of performance parameters on ISPs Quality of Service for TCP/IP Traffic: An Overview Flexible and Extensible QoS-Management for Adaptive Middleware An Integrated Toolset for the Design of Protocols with QoS Requirements (ProtCAD/RT) Adaptability in multimedia transmissions using layering multicast and QoS guarantees 11:50-13:00 Session 2B: Video Streaming Performance Streaming Multimedia Data with Adaptive QoS Characteristics Transmission of MPEG Video over Networks with Closed-Loop Rate-Based Flow Control Buffering at Internet Caches for Improving QoS of Streaming Media Solid State Disks in Multimedia Systems with Deterministic QoS Quality Control Experiences in on Demand Video Transmission Video Placement on a Networked Disk Subsystem for Clustered Video-on-Demand Servers 14:50-16:10 Session 3A: QoS Provisioning A Framework for on-Demand QoS Bearers over Fixed and Mobile Internet Access Protocol or Header Indication - Methods to Request Quality of Service for IP-Apps Inter-domain QoS provision for Internet-wide multicast traffic SR-QoS System for Multimedia Communication in Mobile Ad Hoc Networks 14:50-16:10 Session 3B: Media Streaming Architectures An Architecture for Streaming Control in Distributed Multimedia Systems Video on Demand Using HTTP DiVA: QoS-aware streaming of multimedia content over the Internet Reliable and Flexible Video Codec Structure Implemented on a RISC Processor 20:00 Banquet Wednesday, 25 October 2000 8:30-10:00 Tutorial Peter Psenak, Cisco Systems, Belgium MPLS Traffic Engineering 10:30-11:50 Session 4A: Service Access Copyright Protection Protocols for Multimedia Distribution Based on Trusted Hardware Broadband Network Set-Top Box System Virtual Collaborative Environment with Next Generation Multimedia Systems Design and Implementation of the Electronic Programme Guides for the MPEG2-Based DVB 10:30-11:50 Session 4B: Traffic Engineering Analysis of the Adaptive Rate Control for Point to Multipoint Connections in ATM Nets Modeling and Performance Evaluation of an HFC Network Operator Deficit Round Robin Alternated: A New Scheduling The Performance of Multiplexing Voice and Circuit Switched Data in UMTS over IP Network 11:50-13:00 Session 5A - Poster: Networking Issues Group Signature Schemes Based on the Difficulty of Computation of Approximate E-th Root Internet Card, a smart card for internet Influence of Intervals and Packet Length in Test Sequences - Limits of Testing Enhanced Distributed recording of Mbone sessions Mobility in ATM Networks - QoS Support in Handover Protocols 11:50-13:00 Session 5B - Poster: Media Retrieval Methods for Content Based Radiological Images Searching Integration of a Voice Recognition-Based Indexing with Multimedia Applications Towards a High Level Interface for Content Based Retrieval and Querying Selfsimilarity of an MPEG-2 Video Stream Generated by DVD Applications 14:50-16:10 Session 6A: Service Access The Problem of End-to-end Security for Proxy-based Systems IGMPv3 Extensions for Providing IP Multicast Authentication Services: An Example of DoS Multicast Attacks Avoidance Monitoring Extensions for Component-Based Distributed Software 14:50-16:10 Session 6B: Traffic Engineering Effects of Red Dynamics on TCP-Friendliness of Rate-Based Control Protocol Multimedia Signals over IP by Using Polyphase Down Sampling Multiple Description SDL Based Performance Analysis of Audio over ST2+ Fine Grained Rate Control at Network Edge Nodes ------------------------------------------------------ see http://PROMS2000.kt.agh.edu.pl/ Thank you. ------------------------------------------------------ From owner-manet@itd.nrl.navy.mil Thu Oct 5 18:38: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 SMTP id SAA08103 for ; Thu, 5 Oct 2000 18:38:53 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA29046 for manet-outgoing; Thu, 5 Oct 2000 14:51:38 -0400 (EDT) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA29041 for ; Thu, 5 Oct 2000 14:51:36 -0400 (EDT) From: emailplan44@bigfoot.com Received: from mail.earthlink.net (1Cust231.tnt3.panama-city.fl.da.uu.net [63.15.220.231]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id LAA02363; Thu, 5 Oct 2000 11:48:32 -0700 (PDT) Received: from emailplan44@bigfoot.com by emailplan44@bigfoot.com (8.8.5/8.6.5) with SMTP id GAA01547 for ; Thu, 05 Oct 2000 12:42:01 -0600 (EST) Date: Thu, 05 Oct 00 12:42:01 EST To: emailplan44@bigfoot.com Subject: INCREASE SALES make money at home Message-ID: <> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk HELLO: THIS IS AN ADVERTISEMENT FOR 50 MILLION E-MAIL ADDRESSES ON CD-ROM. IF YOU HAVE NO INTEREST IN THIS INFORMATION, PLEASE CLICK DELETE. THANK YOU. Dear Consumer, Increase your business sales! How?? By targeting millions of buyers via e-mail !! We are offering over 50 million FRESH, DELIVERABLE, e-mail addresses on CD-ROM. The cd-rom includes targeted addresses, such as business opportuinty seekers, sports buffs, mlm, impulsive buyers and investors. The cd-rom also includes general internet, United States, United kingdom, mixed domains, International, Canadian, earthlink, aol, compuserve, misc and much more. The list's are divided into groups and are compressed. This will allow you to use the names right off the cd. ORDER IN THE NEXT 7 DAYS AND RECEIVE AN ADDITIONAL CD-ROM WITH MILLIONS OF DELIVERABLE E-MAIL ADDRESSES, AND THE BULK MASS MAILER BULKING SOFTWARE FREE!! THE TWO BONUSES ALONE ARE WORTH ACTING NOW! The bonus cd-rom contains such address as general internet, msn, aol, compuserve, delphi and much more! The bonus bulk software is designed to get the mail out fast! THE BONUSES ALONE ARE WORTH HUNDRED'S!! ACT NOW AND RECEIVE ALL THIS FOR AN ALL TIME UNBELIEVEABLE LOW, LOW PRICE OF $39.95 THAT'S RIGHT ONLY $39.95 BUT YOU MUST ORDER NOW! ORDER INFORMATION: SIMPLY SEND $39.95, CHECK, OR MONEY ORDER, US FUNDS, PAYABLE TO: R. GOODWIN CREDIT CARD ORDERS, FILL OUT FORM BELOW. SHIP TO: MARKETING AND MORE PO BOX 1862, SANTA ROSA BEACH, FL 32459 (cut and send form below) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - Print Name: ________________________________________ Address: ________________________________________ City/State/Zip: ______________________________________ CreditCard number: ____________________________________ Exp. Date: ________________________ *Signature required for credit card orders__________________________ ($39.95 e-name cd & 2bonuses) Thank you for your order! If we have reached you in error, and you would like to be removed carla7@dcemail.com From owner-manet@itd.nrl.navy.mil Thu Oct 5 21:22: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 SMTP id VAA09673 for ; Thu, 5 Oct 2000 21:22:48 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA05900 for manet-outgoing; Thu, 5 Oct 2000 18:51:05 -0400 (EDT) Received: from hikari.mkg.sfc.keio.ac.jp (hikari.mkg.sfc.keio.ac.jp [133.27.186.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA05895 for ; Thu, 5 Oct 2000 18:51:02 -0400 (EDT) Received: (from tobe@localhost) by hikari.mkg.sfc.keio.ac.jp (8.9.3/3.7W-mkg) id HAA34385; Fri, 6 Oct 2000 07:50:17 +0900 (JST) Date: Fri, 6 Oct 2000 07:50:17 +0900 (JST) Message-Id: <200010052250.HAA34385@hikari.mkg.sfc.keio.ac.jp> From: Yoshito Tobe To: manet@itd.nrl.navy.mil Subject: CFP: IWSAWC Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk --------------------------------------------------------------- International Workshop on Smart Appliances and Wearable Computing (IWSAWC) 2001 Scottsdale, AZ, USA April 16, 2001 In conjunction with the 21st International Conference on Distributed Computing Systems (ICDCS-21) --------------------------------------------------------------- CALL FOR PAPERS Over last several years, we have seen the rapid evolution in smart appliances and devices, PDAs, and wearable computers. In addition, collaborative computing technologies based on these devices enables a wealth of new prospective applications. This workshop offers the opportunity for in-depth exploration of selected topics and for the presenting the most recent research and development findings in these rapidly changing fields. Technical papers on smart devices and wearable computing are solicited for oral presentation at IWSAWC 2001. Papers reporting new developments in computing with smart devices such as PDAs, wearable computers, and cellular phones, including but not limited to those listed below, are invited. - Home Networks and Wearable Networks - Portable Devices and Smart Sensors - Wearable Computers and PDAs - Software Architecture for Home/Smart Appliances - Handheld CSCW - Wireless-phone Computing - Location-dependent Computing - Context-aware Computing - Pervasive Computing Submission: Submitted technical papers should not be longer than 3000 English words. The cover page must include title, author(s), address, and keywords. Submit a PDF or PS file of the paper to paper@mkg.sfc.keio.ac.jp. Important Dates: Paper Submission Due .............. November 1, 2000 Notification of Acceptance .......... December 20, 2000 Camera-Ready Due .............. January 20, 2001 URL: http://www.mkg.sfc.keio.ac.jp/IWSAWC/IWSAWC.html Questions: iwsawc@mkg.sfc.keio.ac.jp Program Chair: Hideyuki Tokuda, Keio University, Japan Program Commitee Members: Hans-W. Gellersen, University of Karlsruhe, Germany David B. Johnson, Rice University, USA Raj Rajkumar, Carnegie Mellon University, USA Stephen Pink, University of Arizona, USA Takahiko Kamae, Laboratories of Image Information Science and Technology, Japan Hirotaka Nakano, NTT DoCoMo, Japan Takashi Kamitake, Toshiba, Japan Nobuhiko Nishio, Keio University, Japan Yoshito Tobe, Keio University, Japan From owner-manet@itd.nrl.navy.mil Fri Oct 6 12:27: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 SMTP id MAA07692 for ; Fri, 6 Oct 2000 12:27:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA20553 for manet-outgoing; Fri, 6 Oct 2000 10:03:36 -0400 (EDT) Received: from mailserver.tridsys.com (news.tridsys.com [207.86.66.211]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA20548 for ; Fri, 6 Oct 2000 10:03:34 -0400 (EDT) Received: from tridsys.com (tridsys.com [207.86.66.202]) by mailserver.tridsys.com (NTMail 6.00.0011/NY2276.00.00796d4c) with ESMTP id hhauaaaa for manet@itd.nrl.navy.mil; Fri, 6 Oct 2000 10:05:22 -0400 Reply-To: From: "Frank Shi" To: Date: Fri, 6 Oct 2000 10:06:22 -0400 Message-ID: <000101c02f9e$9b4da870$6901a8c0@frank.tridsys.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, All, Could any of you offer some pointers to the information about "DNS for Ad hoc networks"?. It would be greatly appreciated if you would offer your own opinion on this. My manager asked me to investigate the development for that regard, but I somehow feel the saying of " "DNS for Ad hoc network" itself be an issue to justify. Thank you all, Frank _______________________________ FRANK SHI Trident Systems Inc. Phone:(703) -267-6743 Fax:(703) -273-6608 Email:frank@tridsys.com From owner-manet@itd.nrl.navy.mil Sun Oct 8 22:03: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 SMTP id WAA13979 for ; Sun, 8 Oct 2000 22:03:27 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA02786 for manet-outgoing; Sun, 8 Oct 2000 19:34:01 -0400 (EDT) Received: from www.sinet.net.cn ([202.103.190.3]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA02781 for ; Sun, 8 Oct 2000 19:33:59 -0400 (EDT) From: rsb@docsj.de Received: from pavilion ([204.31.170.62]) by www.sinet.net.cn (8.8.8+Sun/8.8.8) with SMTP id XAA08451; Sun, 8 Oct 2000 23:28:49 GMT Date: Sun, 8 Oct 2000 23:28:49 GMT Message-Id: <200010082328.XAA08451@www.sinet.net.cn> To: rsb@docsj.de Subject: At last, HERBAL V the all natural alternative! Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-manet@itd.nrl.navy.mil Mon Oct 9 00:52: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 SMTP id AAA16153 for ; Mon, 9 Oct 2000 00:52:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA04809 for manet-outgoing; Sun, 8 Oct 2000 23:04:53 -0400 (EDT) Received: from tropical.co.cr ([63.160.71.196]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA04803 for ; Sun, 8 Oct 2000 23:04:48 -0400 (EDT) From: 63426672@yahoo.com Received: from tropical.co.cr [63.178.136.109] by tropical.co.cr (SMTPD32-6.00 EVAL) id A55D3800EC; Tue, 03 Oct 2000 20:26:37 -0600 Received: from tv@yahoo.com by info@excite.com (8.8.5/8.6.5) with SMTP id GAA09654 for ; Wed, 04 Oct 2000 09:31:00 -0600 (EST) Date: Wed, 04 Oct 00 09:31:00 EST To: cable@yahoo.com Subject: cable services Message-ID: <> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > > NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV > > DE-SCRAMBLER. IF YOU HAVE NO INTEREST IN THIS > > INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- > > > > LEGAL CABLE TV DE-SCRAMBLER > > Want to watch Sporting Events?--Movies?--Pay-Per-View?? > > You can assemble from electronic store parts for about $12.00. > > We Send You: > > E-Z To follow Assembly Instructions. > > E-Z To read Original Drawings. > > Electronic parts lists. > > PLUS SOMETHING NEW YOU MUST HAVE! > > Something you can't do without. > > THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY > > Warning: You should not build a TV Descrambler without > > reading this report first. > > Frequently Asked Questions--CABLE TV DESCRAMBLER > > Q: Will the descrambler work on Fiber, TCI, Jarrod > > A: The answer is YES. > > Q: Do I need a converter box? > > A: This plan works with or without a converter box. > > Specific instructions are included in the plans for each! > > Q: Can the cable company detect that I have the descrambler? > > A: No, the signal descrambles right at the box and does > > not move back through the line! > > Q: Do I have to alter my existing cable system, > > television or VCR? > > A: The answer is no! > > Q: Does this work with my remote control? > > A: The answer is yes. The descrambler is > > manually controlled--but very easy to use! > > Q: Can you email me the plans? > > A: No the program comes with an easy to follow picture guide. > > Q: Does this work everywhere across the country? > > A: Yes, every where in the USA plus England, > > Brazil, Canada and other countries! > > Q: Is this deal guaranteed? > > A: Yes, if you are unhappy for any reason we will refund your money. > > Q: When I order, when will I get my stuff? > > A: We mail out all orders within 48 hours of receiving them. > > ORDER INFORMATION > > ACT WITHIN THE NEXT 14 DAYS AND RECEIVE TWO FREE BONUS!! > > THE CABLE MANUAL! This manual contains hard to find information your > > cable company does not want you to know. Also receive The RADAR > > JAMMER PLANS! Never get another speeding ticket. Build you own > > radar jammer, this unit will jam police radar so they can't get a reading > on > > your vechicle. Radar jammers are legal in 48 states. It is simple to > build. > > The FREE BONUSES ALONE ARE WORTH ACTING NOW! > > THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY > > MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED, > > SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP > > THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE > > ONLY FREE CABLE TV TO GAIN! ACT NOW! SIMPLY SEND > > $14.00 CHECK OR, MONEY ORDER. > > INFORMATION TO: > > > > NET SERVICES > > PO BOX 42013 > > URBANDALE, IA 50322 > > > > > > > > THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY! > > This mailing is done by an independent marketing co. > > We apologize if this message has reached you in error. > > Save the Planet, Save the Trees! Advertise > > via E mail. No wasted paper! Delete with > > one simple keystroke! Less refuse in our Dumps! > > This is the new way of new millenium! > > If you would like to be removed move233@dcemail.com > > > From owner-manet@itd.nrl.navy.mil Tue Oct 10 21:17:17 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 SMTP id VAA16465 for ; Tue, 10 Oct 2000 21:17:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA19543 for manet-outgoing; Tue, 10 Oct 2000 19:05:57 -0400 (EDT) Received: from gate.cs.rochester.edu (gate.cs.rochester.edu [192.5.53.207]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA19538 for ; Tue, 10 Oct 2000 19:05:55 -0400 (EDT) From: murphy@cs.rochester.edu Received: from crow.cs.rochester.edu (crow.cs.rochester.edu [192.5.53.157]) by gate.cs.rochester.edu (8.8.8+Sun/T--) with ESMTP id TAA16991 for ; Tue, 10 Oct 2000 19:04:51 -0400 (EDT) Received: (from murphy@localhost) by crow.cs.rochester.edu (8.9.1b+Sun/Q++) id TAA09029 for manet@itd.nrl.navy.mil; Tue, 10 Oct 2000 19:04:49 -0400 (EDT) Date: Tue, 10 Oct 2000 19:04:49 -0400 (EDT) Message-Id: <200010102304.TAA09029@crow.cs.rochester.edu> To: manet@itd.nrl.navy.mil Subject: ASE Special Issue on Software Engineering for Mobility (Call for Papers) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Kluwer Journal of Automated Software Engineering Special Issue on Software Engineering for Mobility http://www.cs.rochester.edu/u/murphy/ase.html Call for papers --------------- The integration between computing and communication represents one of the most important technological developments of the last decade, a phenomenon marked by significant economic and social changes centered mostly on the Internet. The goal of this special issue is to examine the next major wave of technological changes in the computing environment, the integration of computing, communication, and mobility. In its broadest sense, mobility involves the migration of computing components through some logical or physical space. Physical components provide the platform for applications designed to cope with changes in physical location and connectivity to both wired and wireless networks. Physical components can assume a large diversity of forms including sensors, personal digital assistants, laptops, and large computing platforms residing on vehicles including cars, ships, or airplanes. Movement may happen across geographical regions or in the confines of a single building. Applications executing on such platforms may act in isolation, may coordinate with components in close proximity, or may access resources on a fixed network. Mobile components can also come in the shape of logical units such as code fragments or active programs. The latter carry both code and execution state among fixed and mobile hosts, exploiting locality of resources and computation. A feature typical of all mobile environments is the need to adapt to a constantly changing context that is affected by variability of network characteristics, changes in the availability of resources, and heterogeneity among participating platforms. For these and other reasons, mobility is associated with increases in the complexity of the software development process. New software engineering techniques are needed to address the challenges posed by the development of software for physical and logical mobile environments. This special issue is intended to highlight new research that advances the understanding of critical issues in mobility and proposes viable solutions for the software engineering of systems that involve mobility in all its forms. Submissions are not restricted in any way. Topics of special interest include middleware tailored to mobility, tools to aid in the design of mobile systems, models that capture fundamental properties of mobility and enable formal reasoning about mobile systems, coordination techniques which address adaptability and security, and algorithms that solve fundamental problems in mobility. Submission guidelines --------------------- Authors are invited to submit an electronic version of their contribution in PostScript or PDF to murphy@cs.rochester.edu, using ASE2001 in the subject line. Submissions must be received by January 5, 2001. Manuscripts must be in English, single-spaced, 12 point font size, and 15 pages maximum. In addition to the electronic version of the paper, the email submission should include a text-only version of the title, author(s) name and affiliation, abstract, and the name and address (both postal and electronic) for the contact author. Papers submitted for consideration by the special issue must represent original unpublished work. No version of the paper may be submitted concurrently to any other journal or conference. Any manuscript failing to meet this condition will be rejected outright. Important dates ---------------- Publication of the special issue is expected in 2001. January 5, 2001 Submission Deadline March 23, 2001 First round review notification May 18, 2001 Re-submission revised papers July 13, 2001 Second round review notification September 7, 2001 Submission of final revisions Editors of the special issue ----------------------------- Gruia-Catalin Roman Amy L. Murphy Department of Computer Science Department of Computer Science Washington University University of Rochester Campus Box 1045 P.O. Box 270226 Saint Louis, MO 63130 USA Rochester, NY 14627 USA roman@cs.wustl.edu murphy@cs.rochester.edu Kluwer Journal of Automated Software Engineering -------------------------------------------------- http://www.wkap.nl/journalhome.htm/0928-8910 This Journal is an archival, peer-reviewed journal publishing research, tutorial papers, survey and accounts of significant industrial experience in the foundations, techniques, tools and applications of automated software engineering technology. This includes the study of techniques for constructing, understanding, adapting, and modeling software artifacts and processes. Both automatic systems and collaborative systems are within the scope of the journal, as are computational models of human software engineering activities. Knowledge representations and artificial intelligence techniques applicable to automated software engineering are of interest, as are formal techniques that support or provide theoretical foundations. From owner-manet@itd.nrl.navy.mil Thu Oct 12 00:54:07 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 SMTP id AAA29919 for ; Thu, 12 Oct 2000 00:54:00 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA27897 for manet-outgoing; Wed, 11 Oct 2000 23:23:41 -0400 (EDT) Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA27892 for ; Wed, 11 Oct 2000 23:23:39 -0400 (EDT) Received: from mail1.dh.trw.com ([127.0.0.1]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with SMTP id AAA30B2 for ; Wed, 11 Oct 2000 20:22:29 -0700 Received: from mailhub1.trw.com ([129.193.4.4]) by mail1.dh.trw.com (Netscape Messaging Server 3.6) with ESMTP id AAA6220 for ; Tue, 10 Oct 2000 18:03:49 -0700 Received: from navieg1.trw.com by mailhub1.trw.com for Ron.Orr@trw.com; Tue, 10 Oct 2000 17:18:46 -0700 Received: from mail-relay1.trw.com ([192.45.100.21]) by navieg1 (NAVIEG 2.1 bld 63) with SMTP id M2000101017200408527 for ; Tue, 10 Oct 2000 17:20:04 -0700 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by mail-relay1.trw.com (8.8.8/8.8.8) with ESMTP id RAA00921 for ; Tue, 10 Oct 2000 17:18:45 -0700 (PDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA19543 for manet-outgoing; Tue, 10 Oct 2000 19:05:57 -0400 (EDT) Received: from gate.cs.rochester.edu (gate.cs.rochester.edu [192.5.53.207]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA19538 for ; Tue, 10 Oct 2000 19:05:55 -0400 (EDT) Received: from crow.cs.rochester.edu (crow.cs.rochester.edu [192.5.53.157]) by gate.cs.rochester.edu (8.8.8+Sun/T--) with ESMTP id TAA16991 for ; Tue, 10 Oct 2000 19:04:51 -0400 (EDT) Received: (from murphy@localhost) by crow.cs.rochester.edu (8.9.1b+Sun/Q++) id TAA09029 for manet@itd.nrl.navy.mil; Tue, 10 Oct 2000 19:04:49 -0400 (EDT) From: murphy@cs.rochester.edu Date: Tue, 10 Oct 2000 19:04:49 -0400 (EDT) Message-Id: <200010102304.TAA09029@crow.cs.rochester.edu> To: manet@itd.nrl.navy.mil Subject: ASE Special Issue on Software Engineering for Mobility (Call for Papers) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Kluwer Journal of Automated Software Engineering Special Issue on Software Engineering for Mobility http://www.cs.rochester.edu/u/murphy/ase.html Call for papers --------------- The integration between computing and communication represents one of the most important technological developments of the last decade, a phenomenon marked by significant economic and social changes centered mostly on the Internet. The goal of this special issue is to examine the next major wave of technological changes in the computing environment, the integration of computing, communication, and mobility. In its broadest sense, mobility involves the migration of computing components through some logical or physical space. Physical components provide the platform for applications designed to cope with changes in physical location and connectivity to both wired and wireless networks. Physical components can assume a large diversity of forms including sensors, personal digital assistants, laptops, and large computing platforms residing on vehicles including cars, ships, or airplanes. Movement may happen across geographical regions or in the confines of a single building. Applications executing on such platforms may act in isolation, may coordinate with components in close proximity, or may access resources on a fixed network. Mobile components can also come in the shape of logical units such as code fragments or active programs. The latter carry both code and execution state among fixed and mobile hosts, exploiting locality of resources and computation. A feature typical of all mobile environments is the need to adapt to a constantly changing context that is affected by variability of network characteristics, changes in the availability of resources, and heterogeneity among participating platforms. For these and other reasons, mobility is associated with increases in the complexity of the software development process. New software engineering techniques are needed to address the challenges posed by the development of software for physical and logical mobile environments. This special issue is intended to highlight new research that advances the understanding of critical issues in mobility and proposes viable solutions for the software engineering of systems that involve mobility in all its forms. Submissions are not restricted in any way. Topics of special interest include middleware tailored to mobility, tools to aid in the design of mobile systems, models that capture fundamental properties of mobility and enable formal reasoning about mobile systems, coordination techniques which address adaptability and security, and algorithms that solve fundamental problems in mobility. Submission guidelines --------------------- Authors are invited to submit an electronic version of their contribution in PostScript or PDF to murphy@cs.rochester.edu, using ASE2001 in the subject line. Submissions must be received by January 5, 2001. Manuscripts must be in English, single-spaced, 12 point font size, and 15 pages maximum. In addition to the electronic version of the paper, the email submission should include a text-only version of the title, author(s) name and affiliation, abstract, and the name and address (both postal and electronic) for the contact author. Papers submitted for consideration by the special issue must represent original unpublished work. No version of the paper may be submitted concurrently to any other journal or conference. Any manuscript failing to meet this condition will be rejected outright. Important dates ---------------- Publication of the special issue is expected in 2001. January 5, 2001 Submission Deadline March 23, 2001 First round review notification May 18, 2001 Re-submission revised papers July 13, 2001 Second round review notification September 7, 2001 Submission of final revisions Editors of the special issue ----------------------------- Gruia-Catalin Roman Amy L. Murphy Department of Computer Science Department of Computer Science Washington University University of Rochester Campus Box 1045 P.O. Box 270226 Saint Louis, MO 63130 USA Rochester, NY 14627 USA roman@cs.wustl.edu murphy@cs.rochester.edu Kluwer Journal of Automated Software Engineering -------------------------------------------------- http://www.wkap.nl/journalhome.htm/0928-8910 This Journal is an archival, peer-reviewed journal publishing research, tutorial papers, survey and accounts of significant industrial experience in the foundations, techniques, tools and applications of automated software engineering technology. This includes the study of techniques for constructing, understanding, adapting, and modeling software artifacts and processes. Both automatic systems and collaborative systems are within the scope of the journal, as are computational models of human software engineering activities. Knowledge representations and artificial intelligence techniques applicable to automated software engineering are of interest, as are formal techniques that support or provide theoretical foundations. From owner-manet@itd.nrl.navy.mil Thu Oct 12 16:30: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 SMTP id QAA05343 for ; Thu, 12 Oct 2000 16:30:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA18667 for manet-outgoing; Thu, 12 Oct 2000 13:58:51 -0400 (EDT) Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA18662 for ; Thu, 12 Oct 2000 13:58:49 -0400 (EDT) From: 00914698@yahoo.com Received: from mail.earthlink.net (1Cust57.tnt2.des-moines.ia.da.uu.net [63.11.130.57]) by gull.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id KAA28705; Thu, 12 Oct 2000 10:56:18 -0700 (PDT) Received: from spyguide22@yahoo.com by cathy127@excite.com (8.8.5/8.6.5) with SMTP id GAA02774 for ; Thu, 12 Oct 2000 23:11:36 -0600 (EST) Date: Thu, 12 Oct 00 23:11:36 EST To: mikeh727@yahoo.com Subject: The Net Detective. Learn how to snoop on Anyone! Message-ID: <> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk READY TO KNOW? > > CONFIDENTIAL > > The SOFTWARE They Want BANNED In all 50 STATES. > Why? Because these secrets were never intended to reach your eyes... > Get the facts on anyone! > > Locate Missing Persons, find Lost Relatives, obtain Addresses > and Phone Numbers of old school friends, even Skip Trace Dead > Beat Spouses. This is not a Private Investigator, but a > sophisticated SOFTWARE program DESIGNED to automatically > CRACK YOUR CASE with links to thousands of Public Record databases. > > Find out SECRETS about your relatives, friends, enemies, > and everyone else! -- even your spouse! With the New, > INTERNET SPY AND YOU! > > It's absolutely astounding! Here's what you can learn: > > License plate number! > Get anyone's name and address with just a license plate number! > (Find that girl you met in traffic!) > > Driving record! > Get anyone's driving record > > Social security number! > Trace anyone by social security number! > > Address! > Get anyone's address with just a name! > > Unlisted phone numbers! > Get anyone's phone number with just a name-even unlisted numbers! > > Locate! > Long lost friends, relatives, a past lover who broke your heart! > > E-mail! > Send anonymous e-mail completely untraceable! > > Dirty secrets! > Discover dirty secrets your in-laws don't want you to know! > > Investigate anyone! > Use the sources that private investigators use (all on the Internet) > secretly! > > Ex-spouse! > Learn how to get information on an ex-spouse that will help you > win in court! (Dig up old skeletons) > > Criminal search-Backround check! > Find out about your daughters boyfriend! > (or her husband) > > Find out! > If you are being investigated! > > Neighbors! > Learn all about your mysterious neighbors! Find out what they > have to hide! > > People you work with! > Be astonished by what you'll learn about people you work with! > > Education verification! > Did he really graduate college? Find out! > > Internet Spy and You > Software will help you discover ANYTHING about anyone, with > clickable hyperlinks and no typing in Internet addresses! Just > insert the floppy disk and Go! > > You will be shocked and amazed by the secrets that can be > discovered about absolutely everyone! Find out the secrets > they don't want you to know! About others, about yourself! > > It's INCREDIBLE what you can find out using Internet Spy and You > and the Internet! You'll be riveted to your computer screen! > Get the software they're trying to ban! Before it's too late! > > LIMITED TIME OFFER: ORDER TODAY! > > Only $24.95 > > > We will RUSH YOU our Internet Spy and You software so you can > begin discovering all the secrets you ever wanted to know! > > You can know EVERYTHING about ANYONE with our Internet Spy and > You Software. Works with all browsers and all versions of AOL! > > ORDER TODAY: SEND ONLY $24.95 US CASH, CHECK, OR MONEY ORDER > (you may also send one of your own address labels > for accuracy if you have one.) > > ATTENTION ORDERS OUTSIDE THE US: You must ad $5 for shipping. > > > *Foreign money orders must be payable on a US BANK AND IN US FUNDS! > NO EXCEPTIONS! > > > > > DON'T WAIT TO GET STARTED... it's as easy as 1. 2. 3. > > > STEP 1 - Print the order form text below > > STEP 2 - Type or print your order information into the order form section > > STEP 3 - Mail order form and payment to the address below > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>Mail the portion below<<<<<<<<<<<<<<<<<<<< > > Send to: > > Consumer Resources > > PO BOX 283 > > Johnston, IA 50131 > > > U.S.A > > > > > > >>>>>>>>>>>>>>>>>>>>> Mail-in Order Form <<<<<<<<<<<<<<<<<<<<<<<< > > > > > Name: ______________________________ > > > Address: _____________________________ > > > City/State/Zip __________________________________________ > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>> end of form <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > DISCLAIMER: The seller of this powerful software resource will not be > held responsible for how the purchaser chooses to use its resources. > > > > > To be removed from our mailing list please > send an email to m743@dcemail.com and put remove > in the subject. > Thank you From owner-manet@itd.nrl.navy.mil Sun Oct 15 01:24: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 SMTP id BAA12344 for ; Sun, 15 Oct 2000 01:24:29 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA14134 for manet-outgoing; Sat, 14 Oct 2000 23:35:22 -0400 (EDT) Received: from cairo.cs.uiuc.edu (cairo.cs.uiuc.edu [128.174.247.211]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA14129 for ; Sat, 14 Oct 2000 23:35:21 -0400 (EDT) From: shshah@cairo.cs.uiuc.edu Received: from localhost (shshah@localhost) by cairo.cs.uiuc.edu (8.9.3/8.8.7) with ESMTP id WAA17775 for ; Sat, 14 Oct 2000 22:33:44 -0500 Date: Sat, 14 Oct 2000 22:33:44 -0500 (CDT) To: manet@itd.nrl.navy.mil Subject: Routing/state table lookup delay? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, I was wondering, in an ad hoc network node, what would be the actual routing/state-table-lookup delay (time taken at the intermediate node to execute the instructions that look-up the routing/state table and determine the next-hop) ? What percentage of the the overall end-to-end packet transmission latency from source to destination would this lookup delay constitute? Is it negligible? I am assuming a 50 node network in a 500m x 500m area with an 802.11 MAC layer protocol. Thank you. Regards, Samarth. --------------------------------------------------------------------------- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- Calvin. From owner-manet@itd.nrl.navy.mil Mon Oct 16 06:49: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 SMTP id GAA01819 for ; Mon, 16 Oct 2000 06:49:54 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA29770 for manet-outgoing; Mon, 16 Oct 2000 05:10:12 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA29765 for ; Mon, 16 Oct 2000 05:10:10 -0400 (EDT) Received: from esebh12nok.ntc.nokia.com (esebh12nok.ntc.nokia.com [131.228.10.109]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9G98XP10054 for ; Mon, 16 Oct 2000 12:08:33 +0300 (EET DST) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id 4ZYYBAZD; Mon, 16 Oct 2000 12:08:33 +0300 Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA03645 for ; Mon, 16 Oct 2000 12:08:32 +0300 (EETDST) Received: from nokia.com (hed058-100.research.nokia.com [172.21.58.100]) by possu.research.nokia.com (8.9.1/8.9.1) with ESMTP id MAA03764 for ; Mon, 16 Oct 2000 12:08:32 +0300 (EET DST) Message-ID: <39EAC58A.E3A87AC8@nokia.com> Date: Mon, 16 Oct 2000 12:08:26 +0300 From: Manel Guerrero Zapata X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 CC: manet@itd.nrl.navy.mil Subject: Questions/Comments on AODV References: <200010102304.TAA09029@crow.cs.rochester.edu> 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 everybody :) This is about AODV draft. In the section 8.3.1, says that when a reverse route is created or updated "the hop count is copied from the Hop Count in the RREQ message". And, int the section 8.5 (generating gratuitous RREPs) says that the hop count in the RREQ is "The Hop Count as received in the RREQ". But, as I see it, if we do it the hop counts resulting from these actions are gonna be wrong. (one hop less that what it should be) I think that it should be as in the first paragraph of the section 8.3.1 were "The Hop Count field [...] is incremented by one, to account for the new hop through the intermediate node". (Then routing tables would have the right values) I was just wondering if, maybe, some of you have also noticed this. BR/Manel From owner-manet@itd.nrl.navy.mil Mon Oct 16 11:54:59 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 SMTP id LAA08468 for ; Mon, 16 Oct 2000 11:54:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA05894 for manet-outgoing; Mon, 16 Oct 2000 09:50:58 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA05889 for ; Mon, 16 Oct 2000 09:50:57 -0400 (EDT) Received: from chip (bbnt-dhcp027-161.bbn.com [128.33.27.161]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id JAA19198; Mon, 16 Oct 2000 09:49:32 -0400 (EDT) Message-Id: <3.0.3.32.20001016094922.006961d0@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 16 Oct 2000 09:49:22 -0400 To: shshah@cairo.cs.uiuc.edu, manet@itd.nrl.navy.mil From: Chip Elliott Subject: Forwarding table lookup / unicast, multicast In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 10:33 PM 10/14/00 -0500, shshah@cairo.cs.uiuc.edu wrote: >I was wondering, in an ad hoc network node, what would be the actual >routing/state-table-lookup delay (time taken at the intermediate node to >execute the instructions that look-up the routing/state table and >determine the next-hop) ? What percentage of the the overall end-to-end >packet transmission latency from source to destination would this lookup >delay constitute? Is it negligible? > It is almost certainly negligible, assuming that you already have the next-hop information in your routing table. If you use short, unique node identifiers (eg 16 bits) it can be as quick as an indexed table lookup in memory. And that memory is presumably already in your cache. So on many machines, one cycle will do it. Note that there are a few other parts to the packet forwarding path (eg decrementing TTLs etc) but on the whole the forwarding path is very quick - especially when compared to 802.11 channel access. As an aside, the multicast forwarding operation is considerably more complex than that for unicast. The main problem here is that routing loops cause much worse behavior in multicast than they do in unicast, since packets get replicated at each multicast forking point. Hence routing loops can lead to "chain reactions" of more and more forwarded copies of packets. As a result, multicast forwarding in ad hoc networks really needs some more complicated checks to prevent routing loops from wreaking such havoc. Chip Elliott BBN Technologies PS. Note that getting the right information into the forwarding table is the hard part - but I imagine that you know that. From owner-manet@itd.nrl.navy.mil Mon Oct 16 20:17: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 SMTP id UAA17856 for ; Mon, 16 Oct 2000 20:17:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA23867 for manet-outgoing; Mon, 16 Oct 2000 18:43:54 -0400 (EDT) Received: from cairo.cs.uiuc.edu (cairo.cs.uiuc.edu [128.174.247.211]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA23862 for ; Mon, 16 Oct 2000 18:43:52 -0400 (EDT) From: shshah@cairo.cs.uiuc.edu Received: from localhost (shshah@localhost) by cairo.cs.uiuc.edu (8.9.3/8.8.7) with ESMTP id RAA28798; Mon, 16 Oct 2000 17:41:59 -0500 Date: Mon, 16 Oct 2000 17:41:59 -0500 (CDT) To: Chip Elliott cc: manet@itd.nrl.navy.mil Subject: Re: Forwarding table lookup / unicast, multicast In-Reply-To: <3.0.3.32.20001016094922.006961d0@po1.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, Thank you for your reply. Yes, I was assuming that the next-hop information has been previously determined and is cached. Is there a way I can determine average end-to-end propagation delay of a flooded packet in an ad hoc network? Averaged over all senders and all recipients. And also, the corresponding standard deviation. Assuming duplicate packets are ignored and a 50-node network in a 500m x 500m area, using 2 Mbps links and given a maximum load of (say) 10 other flows in the network. Also, maximum speed is 20 m/s. Further, I am assuming that this average won't vary much with time. Thanks and regards, Samarth. On Mon, 16 Oct 2000, Chip Elliott wrote: > At 10:33 PM 10/14/00 -0500, shshah@cairo.cs.uiuc.edu wrote: > >I was wondering, in an ad hoc network node, what would be the actual > >routing/state-table-lookup delay (time taken at the intermediate node to > >execute the instructions that look-up the routing/state table and > >determine the next-hop) ? What percentage of the the overall end-to-end > >packet transmission latency from source to destination would this lookup > >delay constitute? Is it negligible? > > > > It is almost certainly negligible, assuming that you already have > the next-hop information in your routing table. If you use short, unique > node identifiers (eg 16 bits) it can be as quick as an indexed table > lookup in memory. And that memory is presumably already in your cache. > So on many machines, one cycle will do it. > > Note that there are a few other parts to the packet forwarding > path (eg decrementing TTLs etc) but on the whole the forwarding > path is very quick - especially when compared to 802.11 channel access. > > As an aside, the multicast forwarding operation is considerably > more complex than that for unicast. The main problem here is that > routing loops cause much worse behavior in multicast than they do > in unicast, since packets get replicated at each multicast forking > point. Hence routing loops can lead to "chain reactions" of more > and more forwarded copies of packets. As a result, multicast forwarding > in ad hoc networks really needs some more complicated checks to > prevent routing loops from wreaking such havoc. > > Chip Elliott > BBN Technologies > > PS. Note that getting the right information into the forwarding table > is the hard part - but I imagine that you know that. > From owner-manet@itd.nrl.navy.mil Tue Oct 17 11:06: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 SMTP id LAA13648 for ; Tue, 17 Oct 2000 11:06:34 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA08466 for manet-outgoing; Tue, 17 Oct 2000 09:35:57 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA08461 for ; Tue, 17 Oct 2000 09:35:56 -0400 (EDT) Received: from chip (bbnt-dhcp027-161.bbn.com [128.33.27.161]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id JAA20926; Tue, 17 Oct 2000 09:34:22 -0400 (EDT) Message-Id: <3.0.3.32.20001017093354.007848d4@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 17 Oct 2000 09:33:54 -0400 To: shshah@cairo.cs.uiuc.edu, Chip Elliott From: Chip Elliott Subject: Re: Forwarding table lookup / unicast, multicast Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <3.0.3.32.20001016094922.006961d0@po1.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 05:41 PM 10/16/00 -0500, shshah@cairo.cs.uiuc.edu wrote: >Is there a way I can determine average end-to-end propagation delay of a >flooded packet in an ad hoc network? Averaged over all senders and all >recipients. And also, the corresponding standard deviation. > >Assuming duplicate packets are ignored and a 50-node network in a 500m x >500m area, using 2 Mbps links and given a maximum load of (say) 10 other >flows in the network. Also, maximum speed is 20 m/s. > >Further, I am assuming that this average won't vary much with time. > Hi Samarth, Well, your previous question was very easy to answer, but this one will require a PhD thesis in response. Maybe someone else on the list is actually doing a thesis on this and cares to hold forth...? If not, I suggest that you start rummaging about in the hundreds of papers that people have writting on ad hoc networking, then get yourself a good simulator, implement some algorithms, and start measuring the results. (I suggest simulation because in general such networking performance results are not easy to reduce to closed-form math.) Cheers and good luck, Chip Elliott BBN Technologies From owner-manet@itd.nrl.navy.mil Tue Oct 17 11:09:07 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 SMTP id LAA13647 for ; Tue, 17 Oct 2000 11:06:34 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA07907 for manet-outgoing; Tue, 17 Oct 2000 09:27:29 -0400 (EDT) Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA07902 for ; Tue, 17 Oct 2000 09:27:26 -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 JAA27619 for ; Tue, 17 Oct 2000 09:25:55 -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 JAA09884 for ; Tue, 17 Oct 2000 09:25:29 -0400 (EDT) Received: from kgrace.mitre.org (129.83.41.112) by mailhub2.mitre.org with SMTP id 4782324; Tue, 17 Oct 2000 09:25:54 -0400 Message-ID: <39EC5395.6E82812@mitre.org> Date: Tue, 17 Oct 2000 09:26:45 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: MANET mailing list Subject: MobileMesh Announcement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit As part of The MITRE Corporation's Mobile Mesh research project, we have developed a suite of protocols and software tools that provide a mobile ad hoc networking capability. The protocols have been documented in Internet Drafts and can be obtained at: Mobile Mesh Link Discover Protocol: http://www.ietf.org/internet-drafts/draft-grace-manet-mmldp-00.txt Mobile Mesh Routing Protocol: http://www.ietf.org/internet-drafts/draft-grace-manet-mmrp-00.txt Mobile Mesh Border Discover Protocol: http://www.ietf.org/internet-drafts/draft-grace-manet-mmbdp-00.txt The software tools, including a network visualization tool, are publicly available as an Open Source Linux distribution. To learn more about these products, obtain documentation, and download the software, please visit: http://www.mitre.org/tech_transfer/mobilemesh/ Thanks, Kevin ------------------------------------------ Kevin Grace The MITRE Corporation 781-271-8388 202 Burlington Rd kgrace@mitre.org Bedford MA, 01730 From owner-manet@itd.nrl.navy.mil Tue Oct 17 14:43:36 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 SMTP id OAA19093 for ; Tue, 17 Oct 2000 14:43:35 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA16907 for manet-outgoing; Tue, 17 Oct 2000 13:12:12 -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 NAA16902 for ; Tue, 17 Oct 2000 13:12:09 -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 KAA02473; Tue, 17 Oct 2000 10:10:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9HHAcR31695; Tue, 17 Oct 2000 10:10:38 -0700 X-Virus-Scanned: Tue, 17 Oct 2000 10:10:38 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdy5yF3Z; Tue, 17 Oct 2000 10:10:34 PDT Message-ID: <39EC880C.6928A37B@iprg.nokia.com> Date: Tue, 17 Oct 2000 10:10:36 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Chip Elliott CC: shshah@cairo.cs.uiuc.edu, manet@itd.nrl.navy.mil Subject: Re: Forwarding table lookup / unicast, multicast References: <3.0.3.32.20001016094922.006961d0@po1.bbn.com> <3.0.3.32.20001017093354.007848d4@po1.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 Samarth, if it is simulations you are doing, you have to assume something called a 'router processing delay' at each node between the RECEIVE event and a SEND event for a packet. this is NOT negligible. combine this with a 'link propagation delay' and you have your propagation delay between two nodes in your ad hoc network. the link propagation delay depends on the bandwidth you choose for the link and the size of the packet you are sending. for eg if your packet is going from node 1 to node 5 and there are nodes 2, 3 and 4 in between the propagation delay would be = router processing delay * 3 + link propagation delay for each link router processing delay could be an average value, the same for every node. for link propagation delay, you can safely ignore the distance between two nodes. for the average router processing delay, read a few papers. a lot of simulations ignore this and in my opinion those results are wrong. regards Vijay Chip Elliott wrote: > At 05:41 PM 10/16/00 -0500, shshah@cairo.cs.uiuc.edu wrote: > >Is there a way I can determine average end-to-end propagation delay of a > >flooded packet in an ad hoc network? Averaged over all senders and all > >recipients. And also, the corresponding standard deviation. > > > >Assuming duplicate packets are ignored and a 50-node network in a 500m x > >500m area, using 2 Mbps links and given a maximum load of (say) 10 other > >flows in the network. Also, maximum speed is 20 m/s. > > > >Further, I am assuming that this average won't vary much with time. > > > > Hi Samarth, > > Well, your previous question was very easy to answer, but this one > will require a PhD thesis in response. Maybe someone else on the > list is actually doing a thesis on this and cares to hold forth...? > > If not, I suggest that you start rummaging about in the hundreds of > papers that people have writting on ad hoc networking, then get > yourself a good simulator, implement some algorithms, and start > measuring the results. (I suggest simulation because in general > such networking performance results are not easy to reduce to > closed-form math.) > > Cheers and good luck, > > Chip Elliott > BBN Technologies From owner-manet@itd.nrl.navy.mil Wed Oct 18 10:17: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 SMTP id KAA20520 for ; Wed, 18 Oct 2000 10:17:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA11017 for manet-outgoing; Wed, 18 Oct 2000 08:51:32 -0400 (EDT) Received: from fep24-svc.tin.it (mta24-acc.tin.it [212.216.176.77]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA11008 for ; Wed, 18 Oct 2000 08:51:30 -0400 (EDT) Received: from webrepository ([212.171.65.44]) by fep24-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001018124956.PGDH4963.fep24-svc.tin.it@webrepository> for ; Wed, 18 Oct 2000 14:49:56 +0200 Message-ID: <008001c03901$d51be6e0$2c41abd4@webrepository> From: "Alberto Ziglioli" To: "MANet" Subject: multicasting and DSR Date: Wed, 18 Oct 2000 14:49:17 +0200 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, about the support of multicast sessions on DSR protocol. As far as I could see in draft-ietf-manet-dsr-03.txt flow could be delivered with the RREQ packet support. Does this mean that no tree (shared or source-based) is used in multicast group? The delivery of data with piggybacking onto RREQ packet and no pruning means that high overhead will be generated on the network. Does anybody want to give some comments? Thanks, Alberto Ziglioli From owner-manet@itd.nrl.navy.mil Wed Oct 18 19:45:18 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 SMTP id TAA20104 for ; Wed, 18 Oct 2000 19:45:18 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA00393 for manet-outgoing; Wed, 18 Oct 2000 17:52:38 -0400 (EDT) Received: from allcomshweb.all-mail.net ([202.96.242.116]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA00388 for ; Wed, 18 Oct 2000 17:52:36 -0400 (EDT) Resent-From: frank65_8@norcol.ac.uk Received: from monorailpc (Administrators@localhost) by allcomshweb.all-mail.net (8.8.8/8.8.7) with SMTP id DFR00312; Thu, 19 Oct 2000 05:37:45 +0800 (PST) Resent-Date: Thu, 19 Oct 2000 05:37:45 +0800 (PST) Date: Thu, 19 Oct 2000 05:37:45 +0800 (PST) From: frank65_8@norcol.ac.uk Resent-Message-Id: <200010182137.DFR00312@allcomshweb.all-mail.net> Message-Id: <200010182137.DFR00312@allcomshweb.all-mail.net> To: frank65_8@norcol.ac.uk Subject: Hi, this is for you..... MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Friend: Do you need a change in your life? Do you remember when the entire world seemed like it was yours for the taking? Do you remember a time when all of your hopes and dreams seemed like they were attainable? First of all, let's be honest. You are not going to earn $50,000 in 20 days. It just isn't going to happen. Anyone who tells you that you can, is not being truthful. But, let me tell you about a plan that can possibly make all your dreams come true...keep reading! ******************************************************************** I would like to tell you about a plan that has changed my life. Take a calculator and figure in the worst possible scenario. Decide for yourself. If you decide that you want to take control of your life and move forward...that is your decision. ******************************************************************** Here's the step by step plan summary. 1)You order the 4 reports listed below ($5 each). They come to you by email. 2)Save a copy of this entire letter and put your name at report #1. Move all other names down. (You will be removing the person at the level 4) 3)Use any of the hundreds of bulk email services out there. 4)Orders will come right to your door. Simply email them the report they ordered.Isn't that about as easy as it gets??? ******************************************************************** Your cost to participate in this program is practically nothing (surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! The primary method of building your downline is bulk email. Let's say that you decide to start small, just to see how it goes. Let's assume that you and all those involved email out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out more than 2,000 programs. With a 0.5% response, that is only 10 orders for Report #1. Those 10 respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order 20,000. The 0.5% response rate to that is 1,000 orders for Report #3. Those 1,000 send out 2,000 each for a total of 2,000,000. The 0.5% response rate is 10,000 orders for report #4. That is 10,000 $5 bills for you. CASH!!! ********************************************************************* Your total income in this example is: $50+ $500+ $5000+ $50,000 for a total of $55,550!!! ********************************************************************* REMEMBER FRIEND. THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!!! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR EVEN HALF MAILED OUT 100,000 INSTEAD OF 2,000. Believe, most people will do just that, and more!!! Friend, you do the math. You look at the opportunity, if you decide that you would like to participate in this program, the decision is yours. Recently, the Federal Trade Commission has tried to stop chain letters which promise you will make tons of money by participating. Such chain letters are NOT legal because of this reason. This new program complies with all the rules. To be legal, a chain letter must offer a product and must not promise you will get rich by taking part. If you look at the program, do the math and decide that you will make money, it is your opinion. No such claim is here. However, I do strongly encourage you to do the calculations. Figure out the worst possible response and see how it calculates. Your orders come right to your door and you send your reports via email. You are not involved in personal selling. You do it privately in your own home, store, or office. This is the EASIEST plan anywhere. It is simply order filling by email. Order the four reports shown on the list below. You can't sell them if you don't order them!!!. For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR EMAIL ADDRESS, and YOUR NAME AND RETURN ADDRESS (in case there's a problem). MAKE SURE YOUR RETURN ADDRESS IS ON THE ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands while you sleep. Remember that 50,000+ new people are joining the Internet every month. By the way, there are over 50 million email addresses with millions more joining the Internet each year, so we don't worry about "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How often have you received the same pizza flyers on your door. Then, one day you are hungry for pizza and immediately recall the flyer. Same thing with this letter. I received this letter many times- then one day I decided it was time to try it. This program will not require you to come into contact with people or take any telephone calls. Just follow the instructions. There is no guarantee either stated or implied that anyone participating in this program will earn $50,000+. (You must include that statement to make this legal.) ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. ********************************************************************** Get started TODAY!! Notes- ALWAYS SEND $5 CASH (US CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number and name of the report you are ordering, (b) your e-mail address, and (c) your name and postal address. REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: S. STARK P.O. BOX 61009 HOUSTON, TEXAS 77208-1009 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: WAYNE ELLIOTT 11918 SE DIVISION #358 PORTLAND, OR 97266 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: RYAN ROMNEY P.O. BOX 540421 NORTH SALT LAKE, UT 84054-0421 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: RUSSELL OLSEN 5409 YARMOUTH AVE #3 ENCINO, CA 91316 ******************************************************************** This ad is being sent in compliance with Senate Bill 1618, Title 3, section 301, paragraph (a)(2)(C). Further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to this e-mail address with the words "remove" in the subject line. ******************************************************************** From owner-manet@itd.nrl.navy.mil Thu Oct 19 18:41: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 SMTP id SAA19944 for ; Thu, 19 Oct 2000 18:41:10 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA01981 for manet-outgoing; Thu, 19 Oct 2000 16:47:53 -0400 (EDT) Received: from cairo.cs.uiuc.edu (cairo.cs.uiuc.edu [128.174.247.211]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA01976 for ; Thu, 19 Oct 2000 16:47:47 -0400 (EDT) From: shshah@cairo.cs.uiuc.edu Received: from localhost (shshah@localhost) by cairo.cs.uiuc.edu (8.9.3/8.8.7) with ESMTP id PAA00678; Thu, 19 Oct 2000 15:45:25 -0500 Date: Thu, 19 Oct 2000 15:45:25 -0500 (CDT) To: Chip Elliott cc: manet@itd.nrl.navy.mil Subject: Re: Forwarding table lookup / unicast, multicast In-Reply-To: <3.0.3.32.20001017093354.007848d4@po1.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Tue, 17 Oct 2000, Chip Elliott wrote: > At 05:41 PM 10/16/00 -0500, shshah@cairo.cs.uiuc.edu wrote: > >Is there a way I can determine average end-to-end propagation delay of a > >flooded packet in an ad hoc network? Averaged over all senders and all > >recipients. And also, the corresponding standard deviation. > > > >Assuming duplicate packets are ignored and a 50-node network in a 500m x > >500m area, using 2 Mbps links and given a maximum load of (say) 10 other > >flows in the network. Also, maximum speed is 20 m/s. > > > >Further, I am assuming that this average won't vary much with time. > > > > Hi Samarth, > > Well, your previous question was very easy to answer, but this one > will require a PhD thesis in response. Maybe someone else on the > list is actually doing a thesis on this and cares to hold forth...? > > If not, I suggest that you start rummaging about in the hundreds of > papers that people have writting on ad hoc networking, then get > yourself a good simulator, implement some algorithms, and start > measuring the results. (I suggest simulation because in general > such networking performance results are not easy to reduce to > closed-form math.) I figured that this average flood-packet delay is not dissimilar to the average delay experienced by a flooded link state packet (LSP) in a link state protocol for an ad hoc network. Perhaps there exists some such protocol and such data for it exists in literature. I was just wondering if my analogy was right and if you might know of any such link-state protocol or study of average delays for LSPs. If my analogy is right, perhaps I should study OLSR in a little more detail? Many thanks and regards, Samarth. From owner-manet@itd.nrl.navy.mil Thu Oct 19 20:46: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 SMTP id UAA04707 for ; Thu, 19 Oct 2000 20:46:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA28218 for manet-outgoing; Thu, 19 Oct 2000 15:23:19 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA28212 for ; Thu, 19 Oct 2000 15:23:17 -0400 (EDT) Received: from chip (bbnt-dhcp027-161.bbn.com [128.33.27.161]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id PAA23022; Thu, 19 Oct 2000 15:21:38 -0400 (EDT) Message-Id: <3.0.3.32.20001019152133.015102f0@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 19 Oct 2000 15:21:33 -0400 To: selsheri@renp.com From: Chip Elliott Subject: Re: OPNET Simulation Code for MANET Cc: manet@itd.nrl.navy.mil In-Reply-To: <17D393926B6ED311AE1900508B73297B01509166@lnxnpvexc02-bu.re edref.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Hossam, Greetings! Yes, BBN has done a number of simulations of ad hoc networks in OPNET. Unfortunately these are simulations for protocols that are now being deployed into the US military and so we are not at libery to release the source code. However, I would be glad to answer your questions, to the best of my ability. It is not entirely easy to choose between OPNET and ns-2 because they have different strengths. OPNET's main advantage is that it has a fairly large commercial base, includes built-in features for modeling a number of existing kinds of network technology, has reasonably good display graphics and and a graphics-based user interface, and is fundamentally "object oriented" which is a very good thing for network design. In our experience, it seems essentially bug-free and does what it claims it will do. It has some noticeably bad points, though. First, it is very expensive - enough so that I doubt an academic department would really want to pay the license fees. Second, it is rather slow and thus requires a fairly high-powered machine for running good-size models. Third, its user interface has seemed rather clunky to those of us at BBN who use it a lot. Fourth, its implementations of TCP (etc) are nothing to write home about and last I knew, its implementation of OSPF was downright buggy, which is dangerous if you're trying to model behaviors of higher-level protocols. Fifth, it is commercial software so you can't see or change the source unless you are very good friends with MIL-3. ns-2's main advantages are as follows. First, it is free. Second, it is open-source. Third, it has historically had very good and extensive TCP implementations, which thus allows you to observe higher-level protocol behavior. Fourth, I think that most academic MANET researchers are using ns-2 so you stand a chance of grabbing and importing their protocols. Its disadvantages are that it's a fairly bare-bones system (very few frills and built-in features compared to OPNET), that its graphics aren't quite as pretty as OPNET, and that you'll have to do a few more things yourself rather than have them handed to you on a silver platter. On the whole, if it were me, I would choose ns-2. In fact, other groups within BBN have used ns-2 for MANET research work and are quite happy with it. In my view, it's something like the choice between Linux and Windows 98, where ns-2 is Linux and OPNET is Windows 98. There's of course a large element of personal preference involved, but on the whole I think that ns-2 is a better match for MANET research. Just my two cents but hope that it is useful. Cheers, -- Chip PS. Why then, you might ask, did we pick OPNET? Well, we were required to deliver an OPNET model under the terms of our contract. And that's not a bad choice for the US military, since they can require OPNET models from each of their subcontractors and then glue them together to make a really big overall network model - all in OPNET. A far-sighted and laudable goal, in my view. So I'm not complaining about OPNET, just saying it may not be the best tool for your research.=20 At 01:30 PM 10/19/00 -0400, you wrote:=20 >>>> Arial0000,0000,ffffChip,=20 Arial0000,0000,ffffI am a Ph.D. student in City University of New York (CUNY) working on MANET and MIP. I have read from different sources (MANET WG, Mail Archive, Papers,etc) that you and your colleagues at BBN have done some simulations in MANET using OPNET on Dec '1998 or after.=20 Arial0000,0000,ffffAs you know, OPNET 7.0 now supports 802.11 MAC. It may be helpful to use OPNET as a simulation tool since it has extra features (unified visualization tool, easy to build and modify models, better reporting tools, etc) than ns-2. However, I would appreciate if I can get these OPNET codes Or can you help me to point to any OPNET MANET codes. Please, advice if OPNET is better simulation tool than ns-2 since I have to research works in both MobileIPv4/6 and MANET Unicast and Multicast Routing Protocols. Arial0000,0000,ffffI definitely appreciate your help regarding this issue.=20 Arial0000,0000,ffffThanks=20 Arial0000,0000,ffff/Hossam=20 <<<<<<<< From owner-manet@itd.nrl.navy.mil Thu Oct 19 20:56: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 SMTP id UAA05784 for ; Thu, 19 Oct 2000 20:56:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA28968 for manet-outgoing; Thu, 19 Oct 2000 15:45:06 -0400 (EDT) Received: from ns1.renp.com (reedref.com [198.245.191.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA28961 for ; Thu, 19 Oct 2000 15:45:05 -0400 (EDT) From: selsheri@renp.com Received: from lnxnpvexc02.reedref.com ([162.4.5.24]) by ns1.renp.com (8.9.3/8.8.7) with ESMTP id PAA15127; Thu, 19 Oct 2000 15:37:34 -0400 Received: by lnxnpvexc02-bu.reedref.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 15:42:09 -0400 Message-ID: <17D393926B6ED311AE1900508B73297B01509168@lnxnpvexc02-bu.reedref.com> To: celliott@bbn.com Cc: manet@itd.nrl.navy.mil, elsherif@bellatlantic.net Subject: RE: OPNET Simulation Code for MANET Date: Thu, 19 Oct 2000 15:42:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03A04.AB41037E" 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_01C03A04.AB41037E Content-Type: text/plain; charset="iso-8859-1" Hi Chip, I appreciate very much your quick reply. I understand the code release issue. I also understand your recommendations and I agree on most of them. It is still a tough choice for me since: 1. CUNY (our school) has a license for it. It is already purchased and installed. 2. It is installed in a high-power Sun Server. 3. I have a colleague who is an expert in OPNET 7.0 (2 years experience) who will help me in my research (Please, see below a brief description). 4. He did a lot of work in TCP simulations. 5. He has a lot of friends in MIL-3 since he has been coordinating with them for more than 1.5 years. *. I also agree with your ns-2 recommendations. My research is (briefly): "MANET Internet Access". However, I designed a modified MIP (backward compatible) to work with any MANET unicast protocol. There are lot of value-added features within this developed protocol. I am in a situation to start simulation to prove the applicability of this new protocol. Since I need MIP (to change the source and add to it) + several MANET unitcast protocols (to run the simulation against) + other reasons, ns-2 looks like the best simulation vehicle for me (I am a Unix fan and Microsoft hater !!!). Thanks again for your time. /Hossam > -----Original Message----- > From: Chip Elliott [SMTP:celliott@bbn.com] > Sent: Thursday, October 19, 2000 3:22 PM > To: selsheri@renp.com > Cc: manet@itd.nrl.navy.mil > Subject: Re: OPNET Simulation Code for MANET > > > Hi Hossam, > > Greetings! Yes, BBN has done a number of simulations of ad hoc networks in > OPNET. Unfortunately these are simulations for protocols that are now > being deployed into the US military and so we are not at libery to release > the source code. > > However, I would be glad to answer your questions, to the best of my > ability. It is not entirely easy to choose between OPNET and ns-2 because > they have different strengths. > > OPNET's main advantage is that it has a fairly large commercial base, > includes built-in features for modeling a number of existing kinds of > network technology, has reasonably good display graphics and and a > graphics-based user interface, and is fundamentally "object oriented" > which is a very good thing for network design. In our experience, it seems > essentially bug-free and does what it claims it will do. It has some > noticeably bad points, though. First, it is very expensive - enough so > that I doubt an academic department would really want to pay the license > fees. Second, it is rather slow and thus requires a fairly high-powered > machine for running good-size models. Third, its user interface has seemed > rather clunky to those of us at BBN who use it a lot. Fourth, its > implementations of TCP (etc) are nothing to write home about and last I > knew, its implementation of OSPF was downright buggy, which is dangerous > if you're trying to model behaviors of higher-level protocols. Fifth, it > is commercial software so you can't see or change the source unless you > are very good friends with MIL-3. > > ns-2's main advantages are as follows. First, it is free. Second, it is > open-source. Third, it has historically had very good and extensive TCP > implementations, which thus allows you to observe higher-level protocol > behavior. Fourth, I think that most academic MANET researchers are using > ns-2 so you stand a chance of grabbing and importing their protocols. Its > disadvantages are that it's a fairly bare-bones system (very few frills > and built-in features compared to OPNET), that its graphics aren't quite > as pretty as OPNET, and that you'll have to do a few more things yourself > rather than have them handed to you on a silver platter. > > On the whole, if it were me, I would choose ns-2. In fact, other groups > within BBN have used ns-2 for MANET research work and are quite happy with > it. In my view, it's something like the choice between Linux and Windows > 98, where ns-2 is Linux and OPNET is Windows 98. There's of course a large > element of personal preference involved, but on the whole I think that > ns-2 is a better match for MANET research. > > Just my two cents but hope that it is useful. > > Cheers, > > -- Chip > > PS. Why then, you might ask, did we pick OPNET? Well, we were required to > deliver an OPNET model under the terms of our contract. And that's not a > bad choice for the US military, since they can require OPNET models from > each of their subcontractors and then glue them together to make a really > big overall network model - all in OPNET. A far-sighted and laudable goal, > in my view. So I'm not complaining about OPNET, just saying it may not be > the best tool for your research. > > > At 01:30 PM 10/19/00 -0400, you wrote: > >>>> > > > Chip, > > I am a Ph.D. student in City University of New York (CUNY) working > on MANET and MIP. I have read from different sources (MANET WG, Mail > Archive, Papers,etc) that you and your colleagues at BBN have done some > simulations in MANET using OPNET on Dec '1998 or after. > > As you know, OPNET 7.0 now supports 802.11 MAC. It may be helpful to > use OPNET as a simulation tool since it has extra features (unified > visualization tool, easy to build and modify models, better reporting > tools, etc) than ns-2. However, I would appreciate if I can get these > OPNET codes Or can you help me to point to any OPNET MANET codes. Please, > advice if OPNET is better simulation tool than ns-2 since I have to > research works in both MobileIPv4/6 and MANET Unicast and Multicast > Routing Protocols. > > I definitely appreciate your help regarding this issue. > > Thanks > /Hossam > > > <<<< > ------_=_NextPart_001_01C03A04.AB41037E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: OPNET Simulation Code for MANET

Hi Chip,

I appreciate very = much your quick reply. I understand the code release issue. I also = understand your recommendations and I agree on most of them. It is = still a tough choice for me since:

1. CUNY (our school) = has a license for it. It is already purchased and installed.
2. It is installed = in a high-power Sun Server.
3. I have a = colleague who is an expert in OPNET 7.0 (2 years experience) who will = help me in my research (Please, see below a brief = description).

4. He did a lot of = work in TCP simulations.
5. He has a lot of = friends in MIL-3 since he has been coordinating with them for more than = 1.5 years.
*. I also agree = with your ns-2 recommendations.

My research is = (briefly): "MANET Internet Access". However, I designed a = modified MIP (backward compatible) to work with any MANET unicast = protocol. There are lot of value-added features within this developed = protocol. I am in a situation to start simulation to prove the = applicability of this new protocol. Since I need MIP (to change the = source and add to it) + several MANET unitcast protocols (to run the = simulation against) + other reasons, ns-2 looks like the best = simulation vehicle for me (I am a Unix fan and Microsoft hater = !!!).

Thanks again for = your time.
/Hossam


    -----Original Message-----
    From:   Chip Elliott [SMTP:celliott@bbn.com]
    Sent:   Thursday, October 19, 2000 3:22 PM
    To:     selsheri@renp.com
    Cc:     manet@itd.nrl.navy.mil
    Subject:       = Re: OPNET Simulation Code for = MANET


    Hi Hossam,

    Greetings! Yes, BBN has done a number of = simulations of ad hoc networks in OPNET. Unfortunately these are = simulations for protocols that are now being deployed into the US = military and so we are not at libery to release the source code. =

    However, I would be glad to answer your = questions, to the best of my ability. It is not entirely easy to choose = between OPNET and ns-2 because they have different strengths. =

    OPNET's main advantage is that it has a fairly = large commercial base, includes built-in features for modeling a number = of existing kinds of network technology, has reasonably good display = graphics and and a graphics-based user interface, and is fundamentally = "object oriented" which is a very good thing for network = design. In our experience, it seems essentially bug-free and does what = it claims it will do. It has some noticeably bad points, though. First, = it is very expensive - enough so that I doubt an academic department = would really want to pay the license fees. Second, it is rather slow = and thus requires a fairly high-powered machine for running good-size = models. Third, its user interface has seemed rather clunky to those of = us at BBN who use it a lot. Fourth, its implementations of TCP (etc) = are nothing to write home about and last I knew, its implementation of = OSPF was downright buggy, which is dangerous if you're trying to model = behaviors of higher-level protocols. Fifth, it is commercial software = so you can't see or change the source unless you are very good friends = with MIL-3.

    ns-2's main advantages are as follows. First, = it is free. Second, it is open-source. Third, it has historically had = very good and extensive TCP implementations, which thus allows you to = observe higher-level protocol behavior. Fourth, I think that most = academic MANET researchers are using ns-2 so you stand a chance of = grabbing and importing their protocols. Its disadvantages are that it's = a fairly bare-bones system (very few frills and built-in features = compared to OPNET), that its graphics aren't quite as pretty as OPNET, = and that you'll have to do a few more things yourself rather than have = them handed to you on a silver platter.

    On the whole, if it were me, I would choose = ns-2. In fact, other groups within BBN have used ns-2 for MANET = research work and are quite happy with it. In my view, it's something = like the choice between Linux and Windows 98, where ns-2 is Linux and = OPNET is Windows 98. There's of course a large element of personal = preference involved, but on the whole I think that ns-2 is a better = match for MANET research.

    Just my two cents but hope that it is useful. =

    Cheers,

    -- Chip

    PS. Why then, you might ask, did we pick OPNET? = Well, we were required to deliver an OPNET model under the terms of our = contract. And that's not a bad choice for the US military, since they = can require OPNET models from each of their subcontractors and then = glue them together to make a really big overall network model - all in = OPNET. A far-sighted and laudable goal, in my view. So I'm not = complaining about OPNET, just saying it may not be the best tool for = your research. 


    At 01:30 PM 10/19/00 -0400, you wrote:  =
    >>>>


      Chip, 

      I am a Ph.D. student = in City University of New York (CUNY) working on MANET and MIP. I have = read from different sources (MANET WG, Mail Archive, Papers,etc) that = you and your colleagues at BBN have done some simulations in MANET = using OPNET on Dec '1998 or after. 

      As you know, OPNET = 7.0 now supports 802.11 MAC. It may be helpful to use OPNET as a = simulation tool since it has extra features (unified visualization = tool, easy to build and modify models, better reporting tools, etc) = than ns-2. However, I would appreciate if I can get these OPNET codes = Or can you help me to point to any OPNET MANET codes. Please, advice if = OPNET is better simulation tool than ns-2 since I have to research = works in both MobileIPv4/6 and MANET Unicast and Multicast Routing = Protocols.

      I definitely = appreciate your help regarding this issue. 

      Thanks 
      /Hossam 


    <<<<

------_=_NextPart_001_01C03A04.AB41037E-- From owner-manet@itd.nrl.navy.mil Fri Oct 20 12:13: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 SMTP id MAA08113 for ; Fri, 20 Oct 2000 12:13:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA21694 for manet-outgoing; Fri, 20 Oct 2000 10:04:07 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA21689 for ; Fri, 20 Oct 2000 10:04:04 -0400 (EDT) Received: from chip (bbnt-dhcp027-161.bbn.com [128.33.27.161]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id KAA09177; Fri, 20 Oct 2000 10:02:19 -0400 (EDT) Message-Id: <3.0.3.32.20001020100027.0143d550@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 20 Oct 2000 10:00:27 -0400 To: shshah@cairo.cs.uiuc.edu, Chip Elliott From: Chip Elliott Subject: Re: Forwarding table lookup / unicast, multicast Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <3.0.3.32.20001017093354.007848d4@po1.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 03:45 PM 10/19/00 -0500, shshah@cairo.cs.uiuc.edu wrote: >I figured that this average flood-packet delay is not dissimilar to the >average delay experienced by a flooded link state packet (LSP) in a link >state protocol for an ad hoc network. > >I was just wondering if my analogy was right and if you might know of any >such link-state protocol or study of average delays for LSPs. If my >analogy is right, perhaps I should study OLSR in a little more detail? > Hi Samarth, That seems like a good approach, if by "flooding" you mean "flooding". (That is, in classic link-state every update crosses every simplex link in the network, and an acknowledgement crosses the reverse path of each of these links. There are "smarter" though sometimes less robust flooding techniques in which packets only transit a subset of the network graph, eg, a multicast tree.) The delay time can then be estimated by graph theory, eg, the network topology's diameter is the maximal delay, etc. Real life link-state protocols are more complex than you might guess, however. In particular they generally apply some form of rate control to (a) the initial injection of routing updates into the network, and (b) the forwarding onward of these messages across network links. There are a number of different reasons for this. First, it can help avoid flooding the network with control traffic for marginal links, ie, those that keep coming up and going down. (This is often also tackled by a "hello" protocol with hysteresis.) Second, when a new router appears, delaying its initial update will allow batching of updates from all the links that it is bringing up. Third, in some situations - especially ad hoc networks - it can be desirable to provide some cap on the rate at which control traffic can be injected into a channel. Rate-limiting the updates in such cases has the further desirable property that multiple updates can be batched into a single message for transmission, thus amortizing the rather heavy channel access penalty across a number of routing updates. All these techniques have the downside, though, that they add delay to the flooding propagation time. Calculating the delays analytically can be tricky because a per-hop delay can depend on things link the average degree of the network ie, the number of neighbors for each node. You should also be extremely wary of the channel access delay in flooding cases. People often assume that these delays are statistically independent, ie, uncorrelated. This is very false in many flooding techniques, since a number of nodes (in the same channel) will have received a flooded message at about the same time, and will all be contending for the channel in order to flood it onwards to their neighbors. Hence my recommendation would that IF you are going to perform analytic computations of the delay, you should be sure that you're taking into account the correlated channel access problem. Cheers and all the best, Chip Elliott BBN Technologies From owner-manet@itd.nrl.navy.mil Sat Oct 21 13:31: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 SMTP id NAA28921 for ; Sat, 21 Oct 2000 13:31:29 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA17399 for manet-outgoing; Sat, 21 Oct 2000 11:34:53 -0400 (EDT) Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA17394 for ; Sat, 21 Oct 2000 11:34:51 -0400 (EDT) From: pianoplayerde@home.com Received: from mail.earthlink.net (1Cust148.tnt3.panama-city.fl.da.uu.net [63.15.220.148]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id IAA05711; Sat, 21 Oct 2000 08:32:02 -0700 (PDT) Received: from pianoplayerde@home.com by pianoplayerdev@home.com (8.8.5/8.6.5) with SMTP id GAA09899 for ; Sat, 21 Oct 2000 09:20:14 -0600 (EST) Date: Sat, 21 Oct 00 09:20:14 EST To: pianoplayerdev@home.com Subject: PIANO ENTHUSIAST you must see this Message-ID: <> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk THIS IS ABSOLUTELY INCREDIBLE!!! PIANO OWNERS- we offer a patented device that sits on your piano keyboard and allows you to play the piano immediately!! For more detailed information click Pianotech@iar.net type more info in the subject line! You may also reach us at 1-888-279-4455 for more info on this exciting product. If we have reached you in error and you would like to be removed from our mailing list kenjohnsonus@yahoo.com From owner-manet@itd.nrl.navy.mil Mon Oct 23 01:45: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 SMTP id BAA16200 for ; Mon, 23 Oct 2000 01:45:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA05839 for manet-outgoing; Sun, 22 Oct 2000 23:44:42 -0400 (EDT) Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp [133.1.52.49]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA05834 for ; Sun, 22 Oct 2000 23:44:36 -0400 (EDT) Received: from louis (d22.ise.eng.osaka-u.ac.jp [133.1.52.22]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with SMTP id MAA17958 for ; Mon, 23 Oct 2000 12:42:50 +0900 (JST) Message-ID: <000a01c03ca2$b2974340$16340185@ise.eng.osakau.ac.jp> From: "wooighee" To: References: <3.0.3.32.20001017093354.007848d4@po1.bbn.com> <3.0.3.32.20001020100027.0143d550@po1.bbn.com> Subject: AODV Hello Packet Date: Mon, 23 Oct 2000 12:38:23 +0900 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 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 Hai All I am reading the AODV draft and I am not quite sure about when the Hello packet of AODV is exchanged during its oparation. I wonder that the Hello packet is exchanged within neighboring nodes (a) only within nodes along which the RREP packet path is taken. (b) within nodes after receiving RREQ packet. (a) actively all of time If anyone has any idea with this, please kindly inform me. I really appreciate this. Thank you ghee From owner-manet@itd.nrl.navy.mil Mon Oct 23 01:45: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 SMTP id BAA16400 for ; Mon, 23 Oct 2000 01:45:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA05823 for manet-outgoing; Sun, 22 Oct 2000 23:41:37 -0400 (EDT) Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp [133.1.52.49]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA05818 for ; Sun, 22 Oct 2000 23:41:34 -0400 (EDT) Received: from louis (d22.ise.eng.osaka-u.ac.jp [133.1.52.22]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with SMTP id MAA17941 for ; Mon, 23 Oct 2000 12:39:42 +0900 (JST) Message-ID: <000001c03ca2$42b1f020$16340185@ise.eng.osakau.ac.jp> From: "wooighee" To: References: <3.0.3.32.20001017093354.007848d4@po1.bbn.com> <3.0.3.32.20001020100027.0143d550@po1.bbn.com> Subject: When the AODV Hello Packet is exchanged ? Date: Sun, 22 Oct 2000 23:40:38 +0900 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 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 Hai All I am wondering when the Hello packet of AODV is exchanged during its oparation. I wonder that the Hello packet is exchanged within neighboring nodes (a) only within nodes along which the RREP packet path is taken. (b) within nodes after receiving RREQ packet. (a) actively all of time If anyone has any idea with this, please kindly inform me. I really appreciate this. Thank you ghee From owner-manet@itd.nrl.navy.mil Mon Oct 23 05:14: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 SMTP id FAA29500 for ; Mon, 23 Oct 2000 05:14:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA08557 for manet-outgoing; Mon, 23 Oct 2000 03:42:47 -0400 (EDT) Received: from seed.pacific.net.sg (seed.pacific.net.sg [203.120.90.77]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA08552 for ; Mon, 23 Oct 2000 03:42:44 -0400 (EDT) Received: from pop1.pacific.net.sg (pop1.pacific.net.sg [203.120.90.85]) by seed.pacific.net.sg with ESMTP id e9N7ese07831; Mon, 23 Oct 2000 15:40:54 +0800 (SGT) Received: from pacific.net.sg (cwcsun40.cwc.nus.edu.sg [137.132.163.101]) by pop1.pacific.net.sg with ESMTP id PAA27821; Mon, 23 Oct 2000 15:40:46 +0800 (SGT) Message-ID: <39F3EA9D.CA4D1F9D@pacific.net.sg> Date: Mon, 23 Oct 2000 15:37:01 +0800 From: Wong Hau Shian X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: wooighee CC: manet@itd.nrl.navy.mil Subject: Re: When the AODV Hello Packet is exchanged ? References: <3.0.3.32.20001017093354.007848d4@po1.bbn.com> <3.0.3.32.20001020100027.0143d550@po1.bbn.com> <000001c03ca2$42b1f020$16340185@ise.eng.osakau.ac.jp> 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 packets are for neighbour discovery. So packets are exchanged periodically. Regards HS > Hai All > I am wondering when the Hello packet of AODV is exchanged during > its oparation. > > I wonder that the Hello packet is exchanged within neighboring nodes > > (a) only within nodes along which the RREP packet path is taken. > > (b) within nodes after receiving RREQ packet. > > (a) actively all of time > > If anyone has any idea with this, please kindly inform me. > I really appreciate this. > > Thank you > ghee From owner-manet@itd.nrl.navy.mil Mon Oct 23 06:31: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 SMTP id GAA16114 for ; Mon, 23 Oct 2000 06:31:44 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA09173 for manet-outgoing; Mon, 23 Oct 2000 04:37:48 -0400 (EDT) Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp [133.1.52.49]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA09168 for ; Mon, 23 Oct 2000 04:37:43 -0400 (EDT) Received: from localhost (yukon.ise.eng.osaka-u.ac.jp [133.1.52.148]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with ESMTP id RAA26921; Mon, 23 Oct 2000 17:35:17 +0900 (JST) To: mickey_dino@pacific.net.sg Cc: manet@itd.nrl.navy.mil cc: cperkins@Eng.Sun.COM Subject: Re: When the AODV Hello Packet is exchanged ? In-Reply-To: Your message of "Mon, 23 Oct 2000 15:37:01 +0800" <39F3EA9D.CA4D1F9D@pacific.net.sg> References: <39F3EA9D.CA4D1F9D@pacific.net.sg> X-Mailer: Mew version 1.93b25 on Emacs 19.28 / Mule 2.3 (=?iso-2022-jp?B?GyRCS3ZFJjJWGyhC?=) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> Date: Mon, 23 Oct 2000 17:35:17 +0900 (JST) From: WANG Wooi Ghee X-Dispatcher: imput version 20000228(IM140) Lines: 50 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hai Wong Thank you for replying to my question. If the Hello packet is exchanged periodically over ALL of the nodes, won't the hello packet waste the bandwidth and power supply of nodes that are not actively involved in forwarding of real data packet ? Besides, we might piggyback the routing table over the hello packet and spread the routing table over the whole network. But this sounds controversial to the idea of basic on-demand routing protocol where route searching is initiated ONLY WHEN a sending node originates a data packet addressed to that node. If I am wrong please kindly correct me and I really appreciate this. Thank you ghee Author Wong Hau Shian wrote: > Hello packets are for neighbour discovery. So packets are exchanged > periodically. > > Regards > HS > > > > > Hai All > > I am wondering when the Hello packet of AODV is exchanged during > > its oparation. > > > > I wonder that the Hello packet is exchanged within neighboring nodes > > > > (a) only within nodes along which the RREP packet path is taken. > > > > (b) within nodes after receiving RREQ packet. > > > > (a) actively all of time > > > > If anyone has any idea with this, please kindly inform me. > > I really appreciate this. > > > > Thank you > > ghee > > From owner-manet@itd.nrl.navy.mil Mon Oct 23 13:12: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 SMTP id NAA16034 for ; Mon, 23 Oct 2000 13:12:27 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA18852 for manet-outgoing; Mon, 23 Oct 2000 11:19:40 -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 LAA18847 for ; Mon, 23 Oct 2000 11:19:35 -0400 (EDT) Received: from ffsli (nr5-216-196-161-28.fuse.net [216.196.161.28]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with SMTP id e9NFHRj18365; Mon, 23 Oct 2000 11:17:27 -0400 (EDT) From: "Samir R. Das" To: "WANG Wooi Ghee" , Cc: Subject: RE: When the AODV Hello Packet is exchanged ? Date: Mon, 23 Oct 2000 11:17:33 -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) In-Reply-To: <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit The intent of the hello packets in AODV is not for doing the actual routing per se, but to maintain "local" connectivity information (i.e., to maintain a list of current neighbors). It is important to know the local connectivity so that link breaks on active routes are detected and routes are erased. If other mechanisms exist to detect link breaks on active routes (such as a layer-2 feedback) then hello packets are not needed. It would be certainly interesting to exchange full or partial routing tables with hello packets to add some proactive flavor to AODV. In fact, we have simulated something similar. Early results seem to indicate that this can improve performance in some situations for dense networks. Samir >-----Original Message----- >From: owner-manet@itd.nrl.navy.mil >[mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of WANG Wooi Ghee >Sent: Monday, October 23, 2000 4:35 AM >To: mickey_dino@pacific.net.sg >Cc: manet@itd.nrl.navy.mil; cperkins@Eng.Sun.COM >Subject: Re: When the AODV Hello Packet is exchanged ? > > >Hai Wong > > Thank you for replying to my question. >If the Hello packet is exchanged periodically over ALL >of the nodes, won't the hello packet waste the bandwidth >and power supply of nodes that are not actively involved >in forwarding of real data packet ? >Besides, we might piggyback the routing table over the >hello packet and spread the routing table over the >whole network. >But this sounds controversial to the idea of basic >on-demand routing protocol where route searching is >initiated ONLY WHEN a sending node originates a data >packet addressed to that node. > > If I am wrong please kindly correct me and >I really appreciate this. > >Thank you > >ghee > >Author Wong Hau Shian wrote: >> Hello packets are for neighbour discovery. So packets are exchanged >> periodically. >> >> Regards >> HS >> >> >> >> > Hai All >> > I am wondering when the Hello packet of AODV is exchanged during >> > its oparation. >> > >> > I wonder that the Hello packet is exchanged within neighboring nodes >> > >> > (a) only within nodes along which the RREP packet path is taken. >> > >> > (b) within nodes after receiving RREQ packet. >> > >> > (a) actively all of time >> > >> > If anyone has any idea with this, please kindly inform me. >> > I really appreciate this. >> > >> > Thank you >> > ghee >> >> > From owner-manet@itd.nrl.navy.mil Mon Oct 23 13:15:26 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 SMTP id NAA16467 for ; Mon, 23 Oct 2000 13:15:26 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA18646 for manet-outgoing; Mon, 23 Oct 2000 11:15:36 -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 LAA18641 for ; Mon, 23 Oct 2000 11:15:33 -0400 (EDT) Received: from aquarius.ececs.uc.edu (aquarius.ececs.uc.edu [129.137.9.160]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id e9NFDWj17064; Mon, 23 Oct 2000 11:13:34 -0400 (EDT) Date: Mon, 23 Oct 2000 11:13:29 -0400 (EDT) From: Mahesh Marina To: WANG Wooi Ghee cc: mickey_dino@pacific.net.sg, manet@itd.nrl.navy.mil, cperkins@Eng.Sun.COM Subject: Re: When the AODV Hello Packet is exchanged ? In-Reply-To: <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk > If the Hello packet is exchanged periodically over ALL > of the nodes, won't the hello packet waste the bandwidth > and power supply of nodes that are not actively involved > in forwarding of real data packet ? If the data communication is only among nodes in small section of the network, then answer to your question is certainly yes. > Besides, we might piggyback the routing table over the > hello packet and spread the routing table over the > whole network. Again, the benefit of such an approach depends on the kind of data traffic. Regards, Mahesh From owner-manet@itd.nrl.navy.mil Mon Oct 23 13:16: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 SMTP id NAA16614 for ; Mon, 23 Oct 2000 13:16:33 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA18341 for manet-outgoing; Mon, 23 Oct 2000 11:08:06 -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 LAA18330 for ; Mon, 23 Oct 2000 11:07:59 -0400 (EDT) Received: from aquarius.ececs.uc.edu (aquarius.ececs.uc.edu [129.137.9.160]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with ESMTP id e9NF65j15746; Mon, 23 Oct 2000 11:06:05 -0400 (EDT) Date: Mon, 23 Oct 2000 11:06:04 -0400 (EDT) From: Mahesh Marina To: wooighee cc: manet@itd.nrl.navy.mil Subject: Re: AODV Hello Packet In-Reply-To: <000a01c03ca2$b2974340$16340185@ise.eng.osakau.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, Hello messages are intended for neighbor discovery. When hello messages are used, they are exchanged between neighbors periodically regardless of RREQ and RREP packets. An alternative is to use link-level feedback to detect the loss of neighbors. Regards, Mahesh On Mon, 23 Oct 2000, wooighee wrote: > Hai All > I am reading the AODV draft and I am not quite sure about > when the Hello packet of AODV is exchanged during > its oparation. > > I wonder that the Hello packet is exchanged within neighboring nodes > > (a) only within nodes along which the RREP packet path is taken. > > (b) within nodes after receiving RREQ packet. > > (a) actively all of time > > If anyone has any idea with this, please kindly inform me. > I really appreciate this. > > Thank you > ghee > -- Regards, Mahesh From owner-manet@itd.nrl.navy.mil Mon Oct 23 13:32: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 SMTP id NAA18574 for ; Mon, 23 Oct 2000 13:32:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA16567 for manet-outgoing; Mon, 23 Oct 2000 10:28:06 -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 KAA16560 for ; Mon, 23 Oct 2000 10:27:57 -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 HAA24142; Mon, 23 Oct 2000 07:26:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NEPxb21998; Mon, 23 Oct 2000 07:25:59 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 07:25:59 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdosRYwi; Mon, 23 Oct 2000 07:25:54 PDT Message-ID: <39F44A75.D70FBBA9@iprg.nokia.com> Date: Mon, 23 Oct 2000 07:25:57 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: WANG Wooi Ghee CC: mickey_dino@pacific.net.sg, manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" Subject: Re: When the AODV Hello Packet is exchanged ? References: <39F3EA9D.CA4D1F9D@pacific.net.sg> <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> 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, It is true that Hello packets consume bandwidth, and that we'd like to get rid of them. According to the specification, Hello packets would be transmitted periodically by all nodes if no other means of neighbor detection were available. However, your first choice (a): > (a) only within nodes along which the RREP packet path is taken. is intriguing, and I don't recall that we ever thought of that idea before. What _could_ happen is the following: 1) Broadcast RREQ 2) Unicast RREP 3) Hello never transmitted unless precursor list nonempty. I don't see anything wrong with this scenario. Regards, Charlie P. WANG Wooi Ghee wrote: > > Hai Wong > > Thank you for replying to my question. > If the Hello packet is exchanged periodically over ALL > of the nodes, won't the hello packet waste the bandwidth > and power supply of nodes that are not actively involved > in forwarding of real data packet ? > Besides, we might piggyback the routing table over the > hello packet and spread the routing table over the > whole network. > But this sounds controversial to the idea of basic > on-demand routing protocol where route searching is > initiated ONLY WHEN a sending node originates a data > packet addressed to that node. > > If I am wrong please kindly correct me and > I really appreciate this. > > Thank you > > ghee > > Author Wong Hau Shian wrote: > > Hello packets are for neighbour discovery. So packets are exchanged > > periodically. > > > > Regards > > HS > > > > > > > > > Hai All > > > I am wondering when the Hello packet of AODV is exchanged during > > > its oparation. > > > > > > I wonder that the Hello packet is exchanged within neighboring nodes > > > > > > (a) only within nodes along which the RREP packet path is taken. > > > > > > (b) within nodes after receiving RREQ packet. > > > > > > (a) actively all of time > > > > > > If anyone has any idea with this, please kindly inform me. > > > I really appreciate this. > > > > > > Thank you > > > ghee > > > > From owner-manet@itd.nrl.navy.mil Mon Oct 23 14:19: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 SMTP id OAA25989 for ; Mon, 23 Oct 2000 14:19:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA21814 for manet-outgoing; Mon, 23 Oct 2000 12:23:15 -0400 (EDT) Received: from hermes.cti.gr (hermes.cti.gr [150.140.7.30]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id MAA21809 for ; Mon, 23 Oct 2000 12:23:13 -0400 (EDT) Received: (qmail 22287 invoked by uid 60015); 23 Oct 2000 16:19:24 -0000 Received: from nikole@cti.gr by hermes with scan4virus-0.50 (. Clean. Processed in 0.048353 secs); 23/10/2000 19:19:24 Received: from pc4822.cti.gr (HELO pc4822) (150.140.5.22) by hermes.cti.gr with SMTP; 23 Oct 2000 16:19:24 -0000 Reply-To: From: "Sotiris Nikoletseas" To: Subject: Deadline approaching -- IPDPS Workshop on Mobile Computing Date: Mon, 23 Oct 2000 19:23:07 +0300 Message-ID: <001c01c03d0d$872fcd60$16058c96@cti.gr> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Please accept my apologies if you receive multiple copies of this message. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PRELIMINARY CALL FOR PAPERS 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2001 WORKSHOPS Hyatt Regency San Francisco April 23-27, 2001 URLs: http://www.ipdps.org http://www.computing.edu.au/~kumar/ipdpswpim.html ++++++++++++++++++++++++++++++++++++++++++++++++ General Chair Sajal K. Das, The University of Texas at Arlington, USA Program Co-Chairs Mohan Kumar, Curtin University of Technology, Perth, Australia and The University of Texas at Arlington, USA Paul Spirakis, Computer Technology Institute, Patras, Greece ********************************************************* Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas, Computer Technology Institute, Patras, Greece ********************************************************* IMPORTANT DATES: October 30, 2000 Workshop Paper Due December 10, 2000 Notification of Acceptance/Rejection January 15, 2001 Camera-Ready Paper Due Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for this workshop. Accepted papers will be published in the proceedings (by IEEE CS Press) of the IPDPS workshops. Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Routing in adhoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed Wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one of the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12-point size type on 8.5 x 11 inch pages. References, figures, tables, etc. may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; and (3) Phone/fax numbers. **************************************************************************** *************** Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cs.curtin.edu.au or spirakis@cti.gr. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5 x 11 inch (US letter size) paper. For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or Paul Spirakis. All manuscripts will be reviewed. Manuscripts must be received by October 30, 2000. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be mailed by December 10, 2000. Camera-ready papers are due January 15, 2001. Proceedings will be available at the Conference. Workshop Program Co-Chairs Mohan Kumar School of Computer Science Curtin University of Technology GPO Box U 1987, Perth WA 1987 AUSTRALIA Fax: +61 8 9266 2819 E-mail: kumar@cs.curtin.edu.au Paul Spirakis Director and Senior Researcher Computer Technology Institute 61 Riga Fereou Str., 26221 Patras, Greece Patras, Greece Fax: +30 61 993 973, +30 61 222086 E-mail: spirakis@cti.gr ++++++++++++++++++++++++++++++++++++++++ Technical Program Committee Somprakash Bandopadhyay, PWC Global, Calcutta, India Stefano Basagni, University of Texas at Dallas, USA Maurizio Bonuccelli University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kwan-Wu Chin, Motorola Australia Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA Xiaohua Jia, City University of Hong Kong Jan van Leeuwen University of Utrecht, The Netherlands John Lui, The Chinese University of Hong Kong Marios Mavronicolas, University of Cyprus, Cyprus Sotiris Nikoletseas, Computer Technology Institute, Greece Cristina Pinnotti, Italian National Research Council Don Sannella University of Edinburgh, Scotland Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Jie Wu, Florida Atlantic University, USA Yongbing Zhang University of Tsukuba, Japan Albert Zomaya University of Western Australia, Perth Australia ---------------------------------------------------------------------------- -------------------- From owner-manet@itd.nrl.navy.mil Mon Oct 23 14:39: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 SMTP id OAA00664 for ; Mon, 23 Oct 2000 14:39:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA23623 for manet-outgoing; Mon, 23 Oct 2000 12:59:13 -0400 (EDT) Received: from hotmail.com (f277.pav1.hotmail.com [64.4.30.152]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA23618 for ; Mon, 23 Oct 2000 12:59:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Oct 2000 09:57:24 -0700 Received: from 63.12.250.10 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 23 Oct 2000 16:57:23 GMT X-Originating-IP: [63.12.250.10] From: "" To: manet@itd.nrl.navy.mil Cc: wooi_ghee@hotmail.com Subject: AODV HELLO PACKET Date: Mon, 23 Oct 2000 16:57:23 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Oct 2000 16:57:24.0327 (UTC) FILETIME=[50F45770:01C03D12] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Dr/Mr Charles E. Perkins,Dr/Mr Mahesh Marina,Dr/Mr Samir Thank you very much for replying to my mail. As Samir has mentioned that the Hello Packet is to maintain "local" connectivity information. I totally agree that Hello Packet is needed to check if there is any link failure in the path ACTIVELY IN USE for transfering of data. My question was do we really need to maintain "local connectivity" among nodes that is not involving in the transfering of real data ? Do we really need to maintain local connectivity of the whole network ? Imagine that there are 20 nodes in an area and they move randomly. There is a long period of time that these nodes are in SLEEPY MODE where no data is transfered among them. Do we still need to maintain the expensive cost of "local connectivity" that consumes battery power of all nodes when no actual data packet travelling in the network ? If I am wrong,please kindly correct me. Thank you very much ghee ----- Original Message ----- From: Charles E. Perkins To: WANG Wooi Ghee Cc: ; ; Elizabeth Royer ; Samir R. Das Sent: Monday, October 23, 2000 11:25 PM Subject: Re: When the AODV Hello Packet is exchanged ? >Hello, > >It is true that Hello packets consume bandwidth, >and that we'd like to get rid of them. > >According to the specification, Hello packets would >be transmitted periodically by all nodes if no >other means of neighbor detection were available. > >However, your first choice (a): > > > (a) only within nodes along which the RREP packet path is taken. > >is intriguing, and I don't recall that we ever thought of >that idea before. What _could_ happen is the following: > >1) Broadcast RREQ >2) Unicast RREP >3) Hello never transmitted unless precursor list nonempty. > >I don't see anything wrong with this scenario. > >Regards, >Charlie P. > > > >WANG Wooi Ghee wrote: > > > Hai Wong > > > Thank you for replying to my question. > > If the Hello packet is exchanged periodically over ALL > > of the nodes, won't the hello packet waste the bandwidth > > and power supply of nodes that are not actively involved > > in forwarding of real data packet ? > > Besides, we might piggyback the routing table over the > > hello packet and spread the routing table over the > > whole network. > > But this sounds controversial to the idea of basic > > on-demand routing protocol where route searching is > > initiated ONLY WHEN a sending node originates a data > > packet addressed to that node. > > > If I am wrong please kindly correct me and > > I really appreciate this. > > > Thank you > > > ghee > > > Author Wong Hau Shian wrote: > > > Hello packets are for neighbour discovery. So packets are exchanged > > > periodically. > > > > > > Regards > > > HS > > > > > > > > > > > > > Hai All > > > > I am wondering when the Hello packet of AODV is exchanged >during > > > > its oparation. > > > > > > > > I wonder that the Hello packet is exchanged within neighboring nodes > > > > > > > > (a) only within nodes along which the RREP packet path is taken. > > > > > > > > (b) within nodes after receiving RREQ packet. > > > > > > > > (a) actively all of time > > > > > > > > If anyone has any idea with this, please kindly inform me. > > > > I really appreciate this. > > > > > > > > Thank you > > > > ghee > > > > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-manet@itd.nrl.navy.mil Mon Oct 23 16:07:41 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 SMTP id QAA17439 for ; Mon, 23 Oct 2000 16:07:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA26290 for manet-outgoing; Mon, 23 Oct 2000 14:00:32 -0400 (EDT) Received: from infonegocio.com (35109.rad.tsai.es [195.235.35.109] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA26284 for ; Mon, 23 Oct 2000 14:00:29 -0400 (EDT) Received: from papa ([213.0.67.204]) by infonegocio.com with Microsoft SMTPSVC(5.5.1877.507.50); Mon, 23 Oct 2000 20:03:08 +0200 Message-ID: <014c01c03d1a$b6877ab0$cc4300d5@papa> From: "Miguel Sanchez" To: "Mahesh Marina" , "WANG Wooi Ghee" Cc: , , References: Subject: Re: When the AODV Hello Packet is exchanged ? Date: Mon, 23 Oct 2000 19:57:27 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I guess that Hello transmission can be skipped when nodes are actively forwarding data packets because these transmissions are making them visible to their neighbors. > > If the Hello packet is exchanged periodically over ALL > > of the nodes, won't the hello packet waste the bandwidth > > and power supply of nodes that are not actively involved > > in forwarding of real data packet ? > > If the data communication is only among nodes in small section of the > network, then answer to your question is certainly yes. > Regards, Miguel Sanchez From owner-manet@itd.nrl.navy.mil Mon Oct 23 16:27: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 SMTP id QAA19798 for ; Mon, 23 Oct 2000 16:27:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA28105 for manet-outgoing; Mon, 23 Oct 2000 14:36:56 -0400 (EDT) Received: from infonegocio.com (35109.rad.tsai.es [195.235.35.109] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA28100 for ; Mon, 23 Oct 2000 14:36:54 -0400 (EDT) Received: from papa ([213.0.67.204]) by infonegocio.com with Microsoft SMTPSVC(5.5.1877.507.50); Mon, 23 Oct 2000 20:40:18 +0200 Message-ID: <015501c03d1f$e682dbb0$cc4300d5@papa> From: "Miguel Sanchez" To: , References: Subject: Re: AODV HELLO PACKET Date: Mon, 23 Oct 2000 20:34:37 +0200 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ghee, I see your point but, ... how do you know when a node should be powered up again? The problem I see is that if you shutdown a node that currently is not forwarding packets, then nobody can power it up when needed. Of course some kind of negotiated and time-limited shutdown can be of some help to conserve node power. That's my thought. Regards, Miguel Sanchez ----- Original Message ----- From: To: Cc: Sent: Monday, October 23, 2000 6:57 PM Subject: AODV HELLO PACKET > Dear Dr/Mr Charles E. Perkins,Dr/Mr Mahesh Marina,Dr/Mr Samir > > Thank you very much for replying to my mail. > As Samir has mentioned that the Hello Packet is to maintain "local" > connectivity information. I totally agree that Hello Packet is needed to > check if there is any link failure in the path ACTIVELY IN USE for > transfering of data. > > My question was do we really need to maintain > "local connectivity" among nodes that is not involving in the transfering > of real data ? Do we really need to maintain local connectivity of the > whole network ? > > Imagine that there are 20 nodes in an area and > they move randomly. There is a long period of time that these > nodes are in SLEEPY MODE where no data is transfered among > them. Do we still need to maintain the expensive cost of > "local connectivity" that consumes battery power of all nodes > when no actual data packet travelling in the network ? > > If I am wrong,please kindly correct me. > Thank you very much > > ghee > From owner-manet@itd.nrl.navy.mil Mon Oct 23 17:35: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 SMTP id RAA27657 for ; Mon, 23 Oct 2000 17:35:14 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA00684 for manet-outgoing; Mon, 23 Oct 2000 15:34:44 -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 PAA00674 for ; Mon, 23 Oct 2000 15:34:42 -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 MAA23123; Mon, 23 Oct 2000 12:32:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NJWPL07954; Mon, 23 Oct 2000 12:32:25 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 12:32:25 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdcolGMj; Mon, 23 Oct 2000 12:32:21 PDT Message-ID: <39F49246.90565564@iprg.nokia.com> Date: Mon, 23 Oct 2000 12:32:22 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: wooi_ghee@hotmail.com, Mobile Ad Hoc IETF working group , "Samir R. Das" , Elizabeth Royer Subject: Re: AODV HELLO PACKET 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 again, I have not yet been able to think of any requirement why a node should have to broadcast and/or receive Hello messages when it is not actively involved with any communication or packet forwarding operations. Thus, in answer to your questions: > My question was do we really need to maintain > "local connectivity" among nodes that is not involving in the transfering > of real data ? Do we really need to maintain local connectivity of the > whole network ? I would say "probably not". But, I'll be interested to hear more discussion from other people who may have thought more about it. Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Mon Oct 23 18:08: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 SMTP id SAA01482 for ; Mon, 23 Oct 2000 18:08:30 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA02250 for manet-outgoing; Mon, 23 Oct 2000 16:11:15 -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 QAA02242 for ; Mon, 23 Oct 2000 16:11:11 -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 NAA26740; Mon, 23 Oct 2000 13:09:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NK97D13633; Mon, 23 Oct 2000 13:09:07 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 13:09:07 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdVrsJLM; Mon, 23 Oct 2000 13:08:55 PDT Message-ID: <39F49AD9.7FD0BD65@iprg.nokia.com> Date: Mon, 23 Oct 2000 13:08:57 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Miguel Sanchez CC: Mahesh Marina , WANG Wooi Ghee , mickey_dino@pacific.net.sg, manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" Subject: Re: When the AODV Hello Packet is exchanged ? References: <014c01c03d1a$b6877ab0$cc4300d5@papa> 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 Miguel, Yes, I think I agree about when Hello messages can be skipped. So, if hello messages are NOT transmitted from inactive nodes, and if they are NOT transmitted from nodes that have forwarded a packet, then the only time they would have to be transmitted is for the time interval ALLOWED_HELLO_LOSS * HELLO_INTERVAL after the last time an active forwarder sent a packet. We might have to make some relationship between ACTIVE_ROUTE_TIMEOUT (default: 3,000 Milliseconds) and ALLOWED_HELLO_LOSS * HELLO_INTERVAL so that a node deprecates a route only after some time that is related to how many Hello messages its active neighbors expect to hear. We might also have to specify that nodes interested in getting neighbor information about an active route are mandated to operate in promiscuous mode if at all possible for the abovementioned period of time. Is this something that should be fixed before AODV goes to Last Call? Regards, Charlie P. PS. Please check your CC: list to make sure that my e-mail address at Sun is removed. Thanks! Miguel Sanchez wrote: > > Hi all, > > I guess that Hello transmission can be skipped when nodes are actively > forwarding data packets because these transmissions are making them visible > to their neighbors. > > > > If the Hello packet is exchanged periodically over ALL > > > of the nodes, won't the hello packet waste the bandwidth > > > and power supply of nodes that are not actively involved > > > in forwarding of real data packet ? > > > > If the data communication is only among nodes in small section of the > > network, then answer to your question is certainly yes. > > > > Regards, > > Miguel Sanchez From owner-manet@itd.nrl.navy.mil Mon Oct 23 18:18: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 SMTP id SAA02660 for ; Mon, 23 Oct 2000 18:18:52 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA02217 for manet-outgoing; Mon, 23 Oct 2000 16:10:28 -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 QAA02212 for ; Mon, 23 Oct 2000 16:10:26 -0400 (EDT) Received: from temporary (wayside.ececs.uc.edu [129.137.9.118]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with SMTP id e9NK1Oj00599; Mon, 23 Oct 2000 16:01:25 -0400 (EDT) From: "Samir R. Das" To: "Miguel Sanchez" , , Subject: RE: AODV HELLO PACKET Date: Mon, 23 Oct 2000 16:01:23 -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.2911.0) In-Reply-To: <015501c03d1f$e682dbb0$cc4300d5@papa> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Deborah Estrin's group in UCLA/USC/ISI has extended AODV to do something very similar. They have a report on the web available from http://lecs.cs.ucla.edu/~estrin/ titled "Adaptive Energy Conserving Routing for Mobile Ad Hoc Network." Samir > -----Original Message----- > From: owner-manet@itd.nrl.navy.mil > [mailto:owner-manet@itd.nrl.navy.mil]On Behalf Of Miguel Sanchez > Sent: Monday, October 23, 2000 2:35 PM > To: wooi_ghee@hotmail.com; manet@itd.nrl.navy.mil > Subject: Re: AODV HELLO PACKET > > > Hi Ghee, > > I see your point but, ... how do you know when a node > should be powered up > again? The problem I see is that if you shutdown a node > that currently is > not forwarding packets, then nobody can power it up when needed. > > Of course some kind of negotiated and time-limited shutdown > can be of some > help to conserve node power. > > That's my thought. > > Regards, > > Miguel Sanchez > > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, October 23, 2000 6:57 PM > Subject: AODV HELLO PACKET > > > > Dear Dr/Mr Charles E. Perkins,Dr/Mr Mahesh Marina,Dr/Mr Samir > > > > Thank you very much for replying to my mail. > > As Samir has mentioned that the Hello Packet is to > maintain "local" > > connectivity information. I totally agree that Hello > Packet is needed to > > check if there is any link failure in the path ACTIVELY IN USE for > > transfering of data. > > > > My question was do we really need to maintain > > "local connectivity" among nodes that is not involving in > the transfering > > of real data ? Do we really need to maintain local > connectivity of the > > whole network ? > > > > Imagine that there are 20 nodes in an area and > > they move randomly. There is a long period of time that these > > nodes are in SLEEPY MODE where no data is transfered among > > them. Do we still need to maintain the expensive cost of > > "local connectivity" that consumes battery power of all nodes > > when no actual data packet travelling in the network ? > > > > If I am wrong,please kindly correct me. > > Thank you very much > > > > ghee > > > > From owner-manet@itd.nrl.navy.mil Mon Oct 23 18:19:09 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 SMTP id SAA02699 for ; Mon, 23 Oct 2000 18:19:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA02586 for manet-outgoing; Mon, 23 Oct 2000 16:18:52 -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 QAA02581 for ; Mon, 23 Oct 2000 16:18:49 -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 NAA28044; Mon, 23 Oct 2000 13:17:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NKH1h21708; Mon, 23 Oct 2000 13:17:01 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 13:17:01 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpd9Zviyc; Mon, 23 Oct 2000 13:16:58 PDT Message-ID: <39F49CBA.52492ED8@iprg.nokia.com> Date: Mon, 23 Oct 2000 13:16:58 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Miguel Sanchez CC: wooi_ghee@hotmail.com, manet@itd.nrl.navy.mil Subject: Re: AODV HELLO PACKET References: <015501c03d1f$e682dbb0$cc4300d5@papa> 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 again, I would assume that this strategy can only work in conjunction with some other protocol operation (perhaps at layer 2) that causes RREQ broadcasts to have the appropriate effect. If broadcasts work, then having a node go into reduced power mode will still be O.K. Regards, Charlie P. Miguel Sanchez wrote: > > Hi Ghee, > > I see your point but, ... how do you know when a node should be powered up > again? The problem I see is that if you shutdown a node that currently is > not forwarding packets, then nobody can power it up when needed. > > Of course some kind of negotiated and time-limited shutdown can be of some > help to conserve node power. > > That's my thought. > > Regards, > > Miguel Sanchez > > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, October 23, 2000 6:57 PM > Subject: AODV HELLO PACKET > > > Dear Dr/Mr Charles E. Perkins,Dr/Mr Mahesh Marina,Dr/Mr Samir > > > > Thank you very much for replying to my mail. > > As Samir has mentioned that the Hello Packet is to maintain "local" > > connectivity information. I totally agree that Hello Packet is needed to > > check if there is any link failure in the path ACTIVELY IN USE for > > transfering of data. > > > > My question was do we really need to maintain > > "local connectivity" among nodes that is not involving in the transfering > > of real data ? Do we really need to maintain local connectivity of the > > whole network ? > > > > Imagine that there are 20 nodes in an area and > > they move randomly. There is a long period of time that these > > nodes are in SLEEPY MODE where no data is transfered among > > them. Do we still need to maintain the expensive cost of > > "local connectivity" that consumes battery power of all nodes > > when no actual data packet travelling in the network ? > > > > If I am wrong,please kindly correct me. > > Thank you very much > > > > ghee > > From owner-manet@itd.nrl.navy.mil Mon Oct 23 18:39: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 SMTP id SAA04980 for ; Mon, 23 Oct 2000 18:39:08 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA04178 for manet-outgoing; Mon, 23 Oct 2000 17:01:20 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA04172 for ; Mon, 23 Oct 2000 17:01:18 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA05372 for ; Mon, 23 Oct 2000 13:59:31 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA29026 for ; Mon, 23 Oct 2000 13:59:29 -0700 (MST)] Received: from arc.corp.mot.com (fairmont.arc.corp.mot.com [217.1.10.134]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e9NKx7n14771; Tue, 24 Oct 2000 07:59:07 +1100 (EST) Message-ID: <39F4A6A6.CC752803@arc.corp.mot.com> Date: Tue, 24 Oct 2000 07:59:19 +1100 From: Kwan-Wu Chin Organization: Motorola Australia Pty. Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: wooi_ghee@hotmail.com CC: manet@itd.nrl.navy.mil Subject: Re: AODV HELLO PACKET 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 Dear Ghee, > My question was do we really need to maintain > "local connectivity" among nodes that is not involving in the transfering > of real data ? Do we really need to maintain local connectivity of the > whole network ? IMHO, you do not need to maintain local connectivity if you do NOT have active sessions going through you. If you have routes which are currently being used, then certainly yes because you would want to tell the source ASAP. > them. Do we still need to maintain the expensive cost of > "local connectivity" that consumes battery power of all nodes > when no actual data packet travelling in the network ? No, however you might want to maintain connectivity if you are thinking of doing local recovery through neigboring nodes which might not be maintaining any routes. A better way might be to just listen in to neighboring nodes transmissions and form local connectivity information. kwan From owner-manet@itd.nrl.navy.mil Mon Oct 23 18:48:17 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 SMTP id SAA06038 for ; Mon, 23 Oct 2000 18:48:16 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA04257 for manet-outgoing; Mon, 23 Oct 2000 17:03:52 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA04248 for ; Mon, 23 Oct 2000 17:03:50 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA14057; Mon, 23 Oct 2000 13:59:07 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA01351; Mon, 23 Oct 2000 14:01:53 -0700 (MST)] Received: from arc.corp.mot.com (fairmont.arc.corp.mot.com [217.1.10.134]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e9NL1Xn14809; Tue, 24 Oct 2000 08:01:33 +1100 (EST) Message-ID: <39F4A738.9935F9A@arc.corp.mot.com> Date: Tue, 24 Oct 2000 08:01:45 +1100 From: Kwan-Wu Chin Organization: Motorola Australia Pty. Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Miguel Sanchez , manet@itd.nrl.navy.mil Subject: Re: AODV HELLO PACKET References: <015501c03d1f$e682dbb0$cc4300d5@papa> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Miguel Sanchez wrote: > Hi Ghee, > > I see your point but, ... how do you know when a node should be powered up > again? The problem I see is that if you shutdown a node that currently is > not forwarding packets, then nobody can power it up when needed. > > Of course some kind of negotiated and time-limited shutdown can be of some > help to conserve node power. > > That's my thought. > > Regards, > > Dear Miguel, > Miguel Sanchez Have a look at a protocol call PAMAS, I think it does do power up and power down dynamically. Kwan From owner-manet@itd.nrl.navy.mil Tue Oct 24 04:41: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 SMTP id EAA12673 for ; Tue, 24 Oct 2000 04:41:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA15143 for manet-outgoing; Tue, 24 Oct 2000 02:31:42 -0400 (EDT) Received: from web9104.mail.yahoo.com (web9104.mail.yahoo.com [216.136.128.241]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id CAA15138 for ; Tue, 24 Oct 2000 02:31:40 -0400 (EDT) Message-ID: <20001024062948.6798.qmail@web9104.mail.yahoo.com> Received: from [192.11.189.113] by web9104.mail.yahoo.com; Mon, 23 Oct 2000 23:29:48 PDT Date: Mon, 23 Oct 2000 23:29:48 -0700 (PDT) From: hridesh rajan Subject: AODV HELLO PACKET TRADEOFF To: wooi_ghee@hotmail.com Cc: 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 All, The message complexity required for local connectivity can be adjusted according to mobilty . Let us assume that there are nodes which do not change position over time. In that case it will be wastage to continuously send location updates in the form of Hello packets. It will also be a good idea to restrict hello packets propogation on the basis of the information of position change in it. Mobility can also affect the duration of validity of a routing entry.It can be safely assumed that if there is no movement there is no need to send routing updates, because the old path is still valid. Furthur the Hello packets will be minimal in the case of ON DEMAND routing when there are a few packets to be sent after a long interval. regards Hridesh > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Monday, October 23, 2000 6:57 PM > > Subject: AODV HELLO PACKET > > > > > > > Dear Dr/Mr Charles E. Perkins,Dr/Mr Mahesh > Marina,Dr/Mr Samir > > > > > > Thank you very much for replying to my mail. > > > As Samir has mentioned that the Hello Packet is > to > > maintain "local" > > > connectivity information. I totally agree that > Hello > > Packet is needed to > > > check if there is any link failure in the path > ACTIVELY IN USE for > > > transfering of data. > > > > > > My question was do we really need to maintain > > > "local connectivity" among nodes that is not > involving in > > the transfering > > > of real data ? Do we really need to maintain > local > > connectivity of the > > > whole network ? > > > > > > Imagine that there are 20 nodes in an area and > > > they move randomly. There is a long period of > time that these > > > nodes are in SLEEPY MODE where no data is > transfered among > > > them. Do we still need to maintain the expensive > cost of > > > "local connectivity" that consumes battery power > of all nodes > > > when no actual data packet travelling in the > network ? > > > > > > If I am wrong,please kindly correct me. > > > Thank you very much > > > > > > ghee > > > > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From owner-manet@itd.nrl.navy.mil Tue Oct 24 07:28: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 SMTP id HAA22197 for ; Tue, 24 Oct 2000 07:28:51 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA16816 for manet-outgoing; Tue, 24 Oct 2000 05:00:54 -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 FAA16808 for ; Tue, 24 Oct 2000 05:00:51 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id e9O8vDv08272; Tue, 24 Oct 2000 10:57:13 +0200 (MET DST) Message-Id: <3.0.1.32.20001024110252.00ce6e90@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Tue, 24 Oct 2000 11:02:52 +0200 To: "Charles E. Perkins" , WANG Wooi Ghee Subject: Re: When the AODV Hello Packet is exchanged with unidirectional links? Cc: mickey_dino@pacific.net.sg, manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" In-Reply-To: <39F44A75.D70FBBA9@iprg.nokia.com> References: <39F3EA9D.CA4D1F9D@pacific.net.sg> <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id FAA16812 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id FAA16816 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA22197 Hello, One non solved problem may be with long term unidirectional links. A---->B 1) Broadcast RREQ from A received by B; 2) Unicast RREP from B not received by A; 3) route discovery failure. One possible way to cope with this scenario would be that B be aware that A->B is unidirectional before 1) happens, so that A is not registered in precursor list of B and 2) does not happen. In this case pro-active hellos may help to maintain this information. Regards, Philippe A 07:25 23/10/00 -0700, Charles E. Perkins a écrit : >Hello, > >It is true that Hello packets consume bandwidth, >and that we'd like to get rid of them. > >According to the specification, Hello packets would >be transmitted periodically by all nodes if no >other means of neighbor detection were available. > >However, your first choice (a): > >> (a) only within nodes along which the RREP packet path is taken. > >is intriguing, and I don't recall that we ever thought of >that idea before. What _could_ happen is the following: > >1) Broadcast RREQ >2) Unicast RREP >3) Hello never transmitted unless precursor list nonempty. > >I don't see anything wrong with this scenario. > >Regards, >Charlie P. From owner-manet@itd.nrl.navy.mil Tue Oct 24 13:20: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 SMTP id NAA02001 for ; Tue, 24 Oct 2000 13:20:49 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA27528 for manet-outgoing; Tue, 24 Oct 2000 11:18:17 -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 LAA27523 for ; Tue, 24 Oct 2000 11:18:16 -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 IAA09117; Tue, 24 Oct 2000 08:16:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9OFGNE18136; Tue, 24 Oct 2000 08:16:23 -0700 X-Virus-Scanned: Tue, 24 Oct 2000 08:16:23 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdHeWukI; Tue, 24 Oct 2000 08:16:20 PDT Message-ID: <39F5A7C5.2633BC3F@iprg.nokia.com> Date: Tue, 24 Oct 2000 08:16:21 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: hridesh rajan CC: wooi_ghee@hotmail.com, manet@itd.nrl.navy.mil Subject: Re: AODV HELLO PACKET TRADEOFF References: <20001024062948.6798.qmail@web9104.mail.yahoo.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 Hello Hridesh, > The message complexity required for local connectivity > can be adjusted according to mobilty. Does this mean "message frequency"? How can a node tell if it is moving fast or slow? > Let us assume > that there are nodes which do not change position over > > time. In that case it will be wastage to continuously > send location updates in the form of Hello packets. It > will also be a good idea to restrict hello packets > propogation on the basis of the information of > position change in it. What does it mean, "hello packets propagation"? Aren't hello messages, when transmitted for the purpose of neighborhood detection, discarded after processing (i.e., not forwarded)? > Mobility can also affect the duration of validity of > a routing entry.It can be safely assumed that if there > is no movement there is no need to send routing > updates, because the old path is still valid. Furthur > the Hello packets will be minimal in the case of ON > DEMAND routing when there are a few packets to be sent > after a long interval. But a node cannot tell if it has moved or not, especially in relation to its neighbors, without some signal that can be used for detection. And, I'm not sure how your last statement follows from the previous ideas. Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Tue Oct 24 13:21: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 SMTP id NAA02081 for ; Tue, 24 Oct 2000 13:21:24 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA27119 for manet-outgoing; Tue, 24 Oct 2000 11:09:32 -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 LAA27114 for ; Tue, 24 Oct 2000 11:09:30 -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 IAA08130; Tue, 24 Oct 2000 08:07:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9OF7SG10922; Tue, 24 Oct 2000 08:07:28 -0700 X-Virus-Scanned: Tue, 24 Oct 2000 08:07:28 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdDtTSDg; Tue, 24 Oct 2000 08:07:23 PDT Message-ID: <39F5A5AD.99795946@iprg.nokia.com> Date: Tue, 24 Oct 2000 08:07:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jacquet@menetou.inria.fr CC: manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" Subject: Re: When the AODV Hello Packet is exchanged withunidirectional links? References: <39F3EA9D.CA4D1F9D@pacific.net.sg> <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> <3.0.1.32.20001024110252.00ce6e90@menetou.inria.fr> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id LAA27119 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02081 Hello, We didn't solve the unidirectional routing problem for AODV, but at least we can get rid of long-term route discovery failures. This is the purpose of the 'A' bit for RREP, and the RREP-ACK message. Solving the general unidirectional routing problem requires broadcast RREPs, a compatible link-layer, and perhaps another unicast acknowledgement after the discoverer gets a RREP. Plus, source routes in the control messages would be handy. We have often thought about adding them to AODV's RREQ and RREP, abstaining mainly because of political considerations. They aren't needed nearly as much unless one wishes to allow unidirectional routes. There are probably simple solutions for special cases that would then need some intuitive characterization. Regards, Charlie P. jacquet@menetou.inria.fr wrote: > > Hello, > > One non solved problem may be with long term unidirectional links. > > A---->B > > 1) Broadcast RREQ from A received by B; > 2) Unicast RREP from B not received by A; > 3) route discovery failure. > > One possible way to cope with this scenario would be that B be aware that > A->B is unidirectional before 1) happens, so that A is not registered in > precursor list of B and 2) does not happen. In this case pro-active hellos > may help to maintain this information. > > Regards, > Philippe > > A 07:25 23/10/00 -0700, Charles E. Perkins a écrit : > >Hello, > > > >It is true that Hello packets consume bandwidth, > >and that we'd like to get rid of them. > > > >According to the specification, Hello packets would > >be transmitted periodically by all nodes if no > >other means of neighbor detection were available. > > > >However, your first choice (a): > > > >> (a) only within nodes along which the RREP packet path is taken. > > > >is intriguing, and I don't recall that we ever thought of > >that idea before. What _could_ happen is the following: > > > >1) Broadcast RREQ > >2) Unicast RREP > >3) Hello never transmitted unless precursor list nonempty. > > > >I don't see anything wrong with this scenario. > > > >Regards, > >Charlie P. From owner-manet@itd.nrl.navy.mil Wed Oct 25 01:25: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 SMTP id BAA22131 for ; Wed, 25 Oct 2000 01:25:25 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA16893 for manet-outgoing; Tue, 24 Oct 2000 23:44:03 -0400 (EDT) Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp [133.1.52.49]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA16888 for ; Tue, 24 Oct 2000 23:43:57 -0400 (EDT) Received: from louis (d22.ise.eng.osaka-u.ac.jp [133.1.52.22]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with SMTP id MAA05971; Wed, 25 Oct 2000 12:41:46 +0900 (JST) Message-ID: <002b01c03e34$e04343a0$16340185@ise.eng.osakau.ac.jp> From: "wooighee" To: "Kwan-Wu Chin" Cc: References: <39F4A6A6.CC752803@arc.corp.mot.com> Subject: Re: AODV HELLO PACKET Date: Wed, 25 Oct 2000 12:37:18 +0900 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 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 Hello Kwan-Wu > > > them. Do we still need to maintain the expensive cost of > > "local connectivity" that consumes battery power of all nodes > > when no actual data packet travelling in the network ? > > No, however you might want to maintain connectivity if you > are thinking of doing local recovery through neigboring nodes > which might not be maintaining any routes. Are you trying to say that local recovery is to sharing the route information cached in the neighbouring nodes ? > > A better way might be to just listen in to neighboring nodes > transmissions and form local connectivity information. > > kwan > > From owner-manet@itd.nrl.navy.mil Wed Oct 25 08:22: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 SMTP id IAA05910 for ; Wed, 25 Oct 2000 08:22:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA21663 for manet-outgoing; Wed, 25 Oct 2000 06:00:17 -0400 (EDT) Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp [133.1.52.49]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA21658 for ; Wed, 25 Oct 2000 06:00:09 -0400 (EDT) Received: from localhost (yukon.ise.eng.osaka-u.ac.jp [133.1.52.148]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with ESMTP id SAA09554 for ; Wed, 25 Oct 2000 18:58:08 +0900 (JST) To: manet@itd.nrl.navy.mil Subject: AODV cached information In-Reply-To: Your message of "Wed, 25 Oct 2000 14:55:13 +1100" <39F659A1.F1BBFC78@arc.corp.mot.com> References: <39F659A1.F1BBFC78@arc.corp.mot.com> X-Mailer: Mew version 1.93b25 on Emacs 19.28 / Mule 2.3 (=?iso-2022-jp?B?GyRCS3ZFJjJWGyhC?=) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001025185807N.wooighee@ise.eng.osaka-u.ac.jp> Date: Wed, 25 Oct 2000 18:58:07 +0900 (JST) From: WANG Wooi Ghee X-Dispatcher: imput version 20000228(IM140) Lines: 40 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hai all I have two questions here concerning the AODV protocol. If anyone has any idea on those questions please kindly comment. Thank you. Question 1 ---------- When there is a link failure occured during data transfering, how does the AODV know whether to perform "local recovery" or to inform the source node that link failure has occured in order to broadcast a new RREQ for the destination node. Question 2 ---------- Does AODV first try using the cached information before broadcasting a new RREQ ? The using of cached route information in the intermediate nodes and the source node may help limiting the propagation of RREQ. I agree with this but I really doubt that using cached route information may improve performance over all. It may end up generating more RREQ messages instead. thank you ghee From owner-manet@itd.nrl.navy.mil Wed Oct 25 10:10:12 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 SMTP id KAA08547 for ; Wed, 25 Oct 2000 10:10:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA24523 for manet-outgoing; Wed, 25 Oct 2000 08:28:29 -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 IAA24515 for ; Wed, 25 Oct 2000 08:28:27 -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.16 #1) id 13oPdO-0006FG-00; Wed, 25 Oct 2000 13:26:22 +0100 Message-ID: <39F6D15E.F0651555@ee.surrey.ac.uk> Date: Wed, 25 Oct 2000 13:26:06 +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: WANG Wooi Ghee , manet Subject: Re: AODV cached information References: <39F659A1.F1BBFC78@arc.corp.mot.com> <20001025185807N.wooighee@ise.eng.osaka-u.ac.jp> 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 Wang Wooi, We have studied the impact of query quenching (route chaching) on the performance of routing protocols and compared the performance of AODV/DSR with our RDMAR protocol. Discussion and results could be found in our WoWMoM99 paper. Also referring to you question_#1, since RDMAR performs localisation during the Route Discovery and the Route Maintenance phase, you can find useful information on when/how RDMAR nodes either repair a route locally or send error messages back to affected data sources instead.. Also D.Maltz & D. Johnson have studied the performance tradeoffs of route caching. So you may try David's homepage and see some of their papers. Regards, George A. > Hai all > > I have two questions here concerning the AODV protocol. > If anyone has any idea on those questions please kindly > comment. Thank you. > > Question 1 > ---------- > > When there is a link failure occured during data transfering, > how does the AODV know whether > > to perform "local recovery" > > or > > to inform the source node that link failure has occured > in order to broadcast a new RREQ for the destination node. > > Question 2 > ---------- > Does AODV first try using the cached information > before broadcasting a new RREQ ? > The using of cached route information in the intermediate nodes > and the source node may help limiting the propagation of RREQ. > I agree with this but I really doubt that using > cached route information may improve performance > over all. > It may end up generating more RREQ messages instead. > > thank you > ghee -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Wed Oct 25 10:42: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 SMTP id KAA15713 for ; Wed, 25 Oct 2000 10:42:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA25180 for manet-outgoing; Wed, 25 Oct 2000 08:43:14 -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 IAA25171 for ; Wed, 25 Oct 2000 08:43:12 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id e9PCfCj08178; Wed, 25 Oct 2000 14:41:12 +0200 (MET DST) Message-Id: <3.0.1.32.20001025144653.00cfa460@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 25 Oct 2000 14:46:53 +0200 To: "Charles E. Perkins" Subject: Re: When the AODV Hello Packet is exchanged withunidirectional links? Cc: manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" In-Reply-To: <39F5A5AD.99795946@iprg.nokia.com> References: <39F3EA9D.CA4D1F9D@pacific.net.sg> <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> <3.0.1.32.20001024110252.00ce6e90@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id IAA25172 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id IAA25180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15713 Hello, You mean the problem of routing packets on unidirectional links? Yes I agree this is a difficult problem calling for appropriate data link layer. But my problem is much simpler: In presence of permanent unidirectional links in the network, the route discovery process may permanently fail, even if there exists bidirectional routes. One solution to this problem may be that no node should forward RREQ packets received from unidirectional links. But this may need the use of proactive hello exchanges. Example of architecture which leads to route discovery failure from A to G A----B----C----D----E----F----G---H--- \............> Links between A and B, B-C, C-D, etc, are symmetric links. But nodes A has unidirectional links to C and D (C and D hear A but are not heared by A). Regards, Philippe A 08:07 24/10/00 -0700, Charles E. Perkins a écrit : > > >Hello, > >We didn't solve the unidirectional routing problem for AODV, >but at least we can get rid of long-term route discovery failures. >This is the purpose of the 'A' bit for RREP, and the RREP-ACK >message. > >Solving the general unidirectional routing problem requires >broadcast RREPs, a compatible link-layer, and perhaps another >unicast acknowledgement after the discoverer gets a RREP. Plus, >source routes in the control messages would be handy. We have >often thought about adding them to AODV's RREQ and RREP, abstaining >mainly because of political considerations. They aren't needed >nearly as much unless one wishes to allow unidirectional routes. > >There are probably simple solutions for special cases that >would then need some intuitive characterization. > >Regards, >Charlie P. > > > From owner-manet@itd.nrl.navy.mil Wed Oct 25 13:08:41 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 SMTP id NAA10993 for ; Wed, 25 Oct 2000 13:08:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA01457 for manet-outgoing; Wed, 25 Oct 2000 11:13:24 -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 LAA01452 for ; Wed, 25 Oct 2000 11:13:23 -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 IAA13752; Wed, 25 Oct 2000 08:11:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9PFBIl31110; Wed, 25 Oct 2000 08:11:18 -0700 X-Virus-Scanned: Wed, 25 Oct 2000 08:11:18 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdbsRCpO; Wed, 25 Oct 2000 08:11:14 PDT Message-ID: <39F6F814.25F39802@iprg.nokia.com> Date: Wed, 25 Oct 2000 08:11:16 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jacquet@menetou.inria.fr CC: manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" Subject: Re: When the AODV Hello Packet is exchanged withunidirectionallinks? References: <39F3EA9D.CA4D1F9D@pacific.net.sg> <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> <3.0.1.32.20001024110252.00ce6e90@menetou.inria.fr> <3.0.1.32.20001025144653.00cfa460@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 Philippe, jacquet@menetou.inria.fr wrote: > In presence of permanent unidirectional links in the network, the route > discovery process may permanently fail, even if there exists bidirectional > routes. One solution to this problem may be that no node should forward > RREQ packets received from unidirectional links. But this may need the use > of proactive hello exchanges. But, I had previously written: >>We didn't solve the unidirectional routing problem for AODV, >>but at least we can get rid of long-term route discovery failures. >>This is the purpose of the 'A' bit for RREP, and the RREP-ACK >>message. Do you think that our solution of allowing a node to require ACKs for RREPs fails to solve the problem? If so, can you suggest any straightforward solution to this problem? Regards, Charlie P. From owner-manet@itd.nrl.navy.mil Wed Oct 25 13:19: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 SMTP id NAA12376 for ; Wed, 25 Oct 2000 13:19:05 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA01185 for manet-outgoing; Wed, 25 Oct 2000 11:06:24 -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 LAA01177 for ; Wed, 25 Oct 2000 11:06:22 -0400 (EDT) Received: from ffsli (nr5-216-196-162-218.fuse.net [216.196.162.218]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with SMTP id e9PF4Aj13931; Wed, 25 Oct 2000 11:04:10 -0400 (EDT) From: "Samir R. Das" To: , "Charles E. Perkins" Cc: , "Elizabeth Royer" Subject: RE: When the AODV Hello Packet is exchanged withunidirectional links? Date: Wed, 25 Oct 2000 11:04:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.1.32.20001025144653.00cfa460@menetou.inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id LAA01185 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12376 Yes. This problem was discussed in the MANET list a few months back and some solutions were proposed. Of course, proactive hellos will also work. Samir >-----Original Message----- >From: jacquet@menetou.inria.fr [mailto:jacquet@menetou.inria.fr] >Sent: Wednesday, October 25, 2000 8:47 AM >To: Charles E. Perkins >Cc: manet@itd.nrl.navy.mil; Elizabeth Royer; Samir R. Das >Subject: Re: When the AODV Hello Packet is exchanged withunidirectional >links? > > >Hello, > >You mean the problem of routing packets on unidirectional links? Yes I >agree this is a difficult problem calling for appropriate data link layer. > >But my problem is much simpler: > >In presence of permanent unidirectional links in the network, the route >discovery process may permanently fail, even if there exists bidirectional >routes. One solution to this problem may be that no node should forward >RREQ packets received from unidirectional links. But this may need the use >of proactive hello exchanges. > >Example of architecture which leads to route discovery failure from A to G > >A----B----C----D----E----F----G---H--- > \............> > >Links between A and B, B-C, C-D, etc, are symmetric links. But nodes A has >unidirectional links to C and D (C and D hear A but are not heared by A). > >Regards, >Philippe > >A 08:07 24/10/00 -0700, Charles E. Perkins a écrit : >> >> >>Hello, >> >>We didn't solve the unidirectional routing problem for AODV, >>but at least we can get rid of long-term route discovery failures. >>This is the purpose of the 'A' bit for RREP, and the RREP-ACK >>message. >> >>Solving the general unidirectional routing problem requires >>broadcast RREPs, a compatible link-layer, and perhaps another >>unicast acknowledgement after the discoverer gets a RREP. Plus, >>source routes in the control messages would be handy. We have >>often thought about adding them to AODV's RREQ and RREP, abstaining >>mainly because of political considerations. They aren't needed >>nearly as much unless one wishes to allow unidirectional routes. >> >>There are probably simple solutions for special cases that >>would then need some intuitive characterization. >> >>Regards, >>Charlie P. >> >> >> > From owner-manet@itd.nrl.navy.mil Wed Oct 25 13:22:20 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 SMTP id NAA10994 for ; Wed, 25 Oct 2000 13:08:40 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA01756 for manet-outgoing; Wed, 25 Oct 2000 11:21:53 -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 LAA01746 for ; Wed, 25 Oct 2000 11:21:51 -0400 (EDT) Received: from ffsli (nr5-216-196-162-218.fuse.net [216.196.162.218]) by babbage.ececs.uc.edu (8.10.2/8.10.2) with SMTP id e9PFJoj14696; Wed, 25 Oct 2000 11:19:50 -0400 (EDT) From: "Samir R. Das" To: "WANG Wooi Ghee" , Subject: RE: AODV cached information Date: Wed, 25 Oct 2000 11:20:03 -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) In-Reply-To: <20001025185807N.wooighee@ise.eng.osaka-u.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit > >Question 1 >---------- > > When there is a link failure occured during data transfering, >how does the AODV know whether > >to perform "local recovery" > >or > >to inform the source node that link failure has occured >in order to broadcast a new RREQ for the destination node. The protocol does not really "know" which way would be better. But one can think of heuristics that would perform well. For example, if the source is too far in number of hops may be you can go for local recovery. >Question 2 >---------- >Does AODV first try using the cached information >before broadcasting a new RREQ ? >The using of cached route information in the intermediate nodes >and the source node may help limiting the propagation of RREQ. >I agree with this but I really doubt that using >cached route information may improve performance >over all. >It may end up generating more RREQ messages instead. > I don't follow your point clearly as AODV does not use caching explicitly. Do you mean that an intermediate node having a valid route to destination and replying to RREQ is equivalent to caching? Tnen AODV already does what you mentioned. Samir From owner-manet@itd.nrl.navy.mil Wed Oct 25 15: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 SMTP id PAA00287 for ; Wed, 25 Oct 2000 15:30:44 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA06184 for manet-outgoing; Wed, 25 Oct 2000 12:56:56 -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 MAA06176 for ; Wed, 25 Oct 2000 12:56:55 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id e9PGjaj12437; Wed, 25 Oct 2000 18:45:37 +0200 (MET DST) Message-Id: <3.0.1.32.20001025185118.04de3dd0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 25 Oct 2000 18:51:18 +0200 To: "Charles E. Perkins" Subject: Re: When the AODV Hello Packet is exchanged withunidirectionallinks? Cc: manet@itd.nrl.navy.mil, Elizabeth Royer , "Samir R. Das" In-Reply-To: <39F6F814.25F39802@iprg.nokia.com> References: <39F3EA9D.CA4D1F9D@pacific.net.sg> <20001023173517S.wooighee@ise.eng.osaka-u.ac.jp> <3.0.1.32.20001024110252.00ce6e90@menetou.inria.fr> <3.0.1.32.20001025144653.00cfa460@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id MAA06177 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id MAA06184 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA00287 Hello Charlie, I am not sure the RREP-ACK would suffice, because the problem comes because the node has forwarded the RREQ before. One solution could be the "black list", described few months ago. Every node manages a local black list listing known unidirectional links. Nodes don't process nor forward RREQ packets received from a node listed in black list. A node can be recorded in black list after one RREP-ACK failed (this may imply at least one route failure). Maybe nodes in black lists should be time-out in some way, because I don't see how to refresh such information without route failure or pro-active hellos. Maybe there are simpler way to handle this problem, Regards, Philippe A 08:11 25/10/00 -0700, Charles E. Perkins a écrit : > >Hello Philippe, > >jacquet@menetou.inria.fr wrote: > >> In presence of permanent unidirectional links in the network, the route >> discovery process may permanently fail, even if there exists bidirectional >> routes. One solution to this problem may be that no node should forward >> RREQ packets received from unidirectional links. But this may need the use >> of proactive hello exchanges. > >But, I had previously written: > >>>We didn't solve the unidirectional routing problem for AODV, >>>but at least we can get rid of long-term route discovery failures. >>>This is the purpose of the 'A' bit for RREP, and the RREP-ACK >>>message. > >Do you think that our solution of allowing a node to require >ACKs for RREPs fails to solve the problem? > >If so, can you suggest any straightforward solution to this >problem? > > >Regards, >Charlie P. > From owner-manet@itd.nrl.navy.mil Wed Oct 25 15:31: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 SMTP id PAA00444 for ; Wed, 25 Oct 2000 15:31:48 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA07822 for manet-outgoing; Wed, 25 Oct 2000 13:40:56 -0400 (EDT) Received: from hotmail.com (f219.pav1.hotmail.com [64.4.31.219]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA07817 for ; Wed, 25 Oct 2000 13:40:54 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Oct 2000 10:38:59 -0700 Received: from 63.12.107.185 by pv1fd.pav1.hotmail.msn.com with HTTP; Wed, 25 Oct 2000 17:38:59 GMT X-Originating-IP: [63.12.107.185] From: "" To: sdas@ececs.uc.edu, manet@itd.nrl.navy.mil Subject: Re: AODV cached information Date: Wed, 25 Oct 2000 17:38:59 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Oct 2000 17:38:59.0380 (UTC) FILETIME=[74F2B740:01C03EAA] Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello Samir > > > >Question 1 > >---------- > > > > When there is a link failure occured during data transfering, > >how does the AODV know whether > > > >to perform "local recovery" > > > >or > > > >to inform the source node that link failure has occured > >in order to broadcast a new RREQ for the destination node. > >The protocol does not really "know" which way would be better. But >one can think of heuristics that would perform well. For example, >if the source is too far in number of hops may be you can go for >local recovery. You mean that the answer to decide which way to repair the link failure is to count the no. of hop from the source node. Then how "far" should we decide that it's far enough to perform the local recovery? Futuremore, performing local recovery far from the source nodes may not bring positive performance. Imagine that there is a path where the source node is 10 hops away from the destination node. Link failure occurs at node no. 8 which is "far" away from the source node. So the local recovery is performed and RREQ is broadcasted from node no.8 While waiting for the local recovery, the relatively "long remaining active path" may break again somewhere,let say node no. 6,another RREQ is broadcasted from node. no.6 . Well, this might deteriorate the performance adversely. > > >Question 2 > >---------- > >Does AODV first try using the cached information > >before broadcasting a new RREQ ? > >The using of cached route information in the intermediate nodes > >and the source node may help limiting the propagation of RREQ. > >I agree with this but I really doubt that using > >cached route information may improve performance > >over all. > >It may end up generating more RREQ messages instead. > > > >I don't follow your point clearly as AODV does not use caching explicitly. >Do you mean that an intermediate node having a valid route to destination >and replying to RREQ is equivalent to caching? Tnen AODV already does what >you mentioned. > The AODV only use the cached information only if the destination sequence no. is higher than the current destination sequence no. This situation occurs rarely. Are you suggesting that AODV does not encourage using the cached information? I have read some of the works done by David B. Johnson, and he argues that the using of cached information might help to bring down the broadcasting of RREQ in On-Demand protocol. Would like to know your opinion. Thank you ghee _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-manet@itd.nrl.navy.mil Wed Oct 25 16:22: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 SMTP id QAA06400 for ; Wed, 25 Oct 2000 16:22:15 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA08954 for manet-outgoing; Wed, 25 Oct 2000 14:10:45 -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 OAA08949 for ; Wed, 25 Oct 2000 14:10:43 -0400 (EDT) Received: from sol.utdallas.edu (sol.utdallas.edu [129.110.34.3]) by ns0.utdallas.edu (Postfix) with ESMTP id 281C21A0569; Wed, 25 Oct 2000 13:08:50 -0500 (CDT) Received: from localhost (ravip@localhost) by sol.utdallas.edu (8.9.1/8.9.1) with ESMTP id NAA20913; Wed, 25 Oct 2000 13:06:14 -0500 (CDT) X-Authentication-Warning: sol.utdallas.edu: ravip owned process doing -bs Date: Wed, 25 Oct 2000 13:06:14 -0500 (CDT) From: Ravi Prakash To: jacquet@menetou.inria.fr Cc: manet@itd.nrl.navy.mil Subject: Re: When the AODV Hello Packet is exchanged withunidirectionallinks? In-Reply-To: <3.0.1.32.20001025185118.04de3dd0@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id OAA08950 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id OAA08954 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA06400 Hello Philippe, First, I apologize for this long message. Please be patient as there are several issues that I have tried to address in the context of unidirectional links. I have been following this discussion on unidirectional links with great interest because our group (including Sanket Nesargi and Daniel Russo) has been working on the problem of unidirectional links for over a year now. If I understand your suggestion correctly, you are suggesting that the routing protocol should ignore all unidirectional links and restrict itself to bidirectional links only. While this will work in some situations it can lead to problems in other situations. For example, let us assume that in the actual network there exists a multi-hop path from A to B and a different multi-hop path from B to A. Let both these paths have at least one unidirectional link. If these unidirectional links are ignored, the routing protocol will be unable to discover routes from A to B and from B to A. Effectively, it will conclude that A and B belong to different network partitions. So, A and B will be unable to communicate with each other. In reality A and B are in the same partition. Moreover, sometimes it may be possible to find a shorter route that uses a combination of uni- and bi-directional links, compared to a route that only uses bi-directional links. So, "black listing" has its limitations. In DIAL-M, 1999 (held in conjunction with MobiCom in August 99) I presented a paper where in an N-node network nodes end up exchanging their knowledge of the network topology by communicating N*N matrices with their neighbors whenever permitted by the directionality of the lins. Through a sequence of matrix exchanges between neighbors the downstream node of a unidirectional link is able to convey information about the existence of that link to the upsteam node. Then, the upstream node can use this link to forward packets. Of course, this requires that a path exist from the downstream node to the upstream node of a unidirectional link. Our initial goal was to see if some modifications could be made to DSDV to handle unidirectional links and we ended up incurring higher overheads. However, one has to make a choice between higher overheads in route discovery vs. erroneous conclusions of partitioning or sub-optimal paths with low overheads. In IC3N 1999, Lichun Bao and J.J. Garcia-Luna-Aceves presented a paper which also dealt with routing in wirless mobile ad hoc networks. They, too, observed that the unidirectional link needs to be part of an inclusive cycle for it to be usable for routing purposes, and presented a protocol. I will not go into the details of their work because I do not wish to utter something about their protocol that may be wrong. In IC3N 2000, held last week, Sanket Nesargi and I presented a paper on routing in ad hoc networks with unidirectional links using the tunneling approach. This idea is to offer a frame-work for a variety of routing protocols so that the unidirectionality of links can be hidden from the routing modules by performing link-layer and network layer operations. This is similar to the approach proposed by IETF's UDLR working group. Let us assume that in this framework a distance-vector based protocol is operating. Then, the downstream node of the unidirectional link would "tunnel" its route advertisement to the upstream node. Once the upstream node receives this tunneled distance vector it can use the vector to update its own distance vector as if the advertisement was received directly from the downstream node. Also, at the link layer, acknowledgments for frames sent along unidirectional links have to be handled. As the ACKs cannot be directly sent from the downstream node to the upstream node of the unidirectional link the ACKs, too, will need to be tunneled (routed at the network layer) to the upstream node. However, if care if not taken this can result in ACK explosion if the tunnel also contains a unidirectional link. We have proposed a simple fix to handle this problem. An important issue to note at this point is that RTS/CTS based link-layer handshake, as done in IEEE 802.11, will work for bidirectional links only. So, in order to be able to use unidirectional links we will need to work on MAC layer protocols as well. Having said all this, one may wonder why go to such great lengths to use unidirectional links when they create so many problems? Well, first because it is an interesting problem! But, the more important reason is that mobility, multi-path losses, interference, and uneven depletion of battery can lead to several incidences of unidirectional links. So, we cannot afford to ignore such links. If anybody is interested in copies of our papers I will be happy to email them. With best regards, ----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 On Wed, 25 Oct 2000 jacquet@menetou.inria.fr wrote: > Hello Charlie, > > I am not sure the RREP-ACK would suffice, because the problem comes because > the node has forwarded the RREQ before. > > One solution could be the "black list", described few months ago. Every > node manages a local black list listing known unidirectional links. Nodes > don't process nor forward RREQ packets received from a node listed in black > list. A node can be recorded in black list after one RREP-ACK failed (this > may imply at least one route failure). > > Maybe nodes in black lists should be time-out in some way, because I don't > see how to refresh such information without route failure or pro-active > hellos. > > Maybe there are simpler way to handle this problem, > > Regards, > Philippe > > A 08:11 25/10/00 -0700, Charles E. Perkins a écrit : > > > >Hello Philippe, > > > >jacquet@menetou.inria.fr wrote: > > > >> In presence of permanent unidirectional links in the network, the route > >> discovery process may permanently fail, even if there exists bidirectional > >> routes. One solution to this problem may be that no node should forward > >> RREQ packets received from unidirectional links. But this may need the use > >> of proactive hello exchanges. > > > >But, I had previously written: > > > >>>We didn't solve the unidirectional routing problem for AODV, > >>>but at least we can get rid of long-term route discovery failures. > >>>This is the purpose of the 'A' bit for RREP, and the RREP-ACK > >>>message. > > > >Do you think that our solution of allowing a node to require > >ACKs for RREPs fails to solve the problem? > > > >If so, can you suggest any straightforward solution to this > >problem? > > > > > >Regards, > >Charlie P. > > > From owner-manet@itd.nrl.navy.mil Thu Oct 26 04:37: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 SMTP id EAA10244 for ; Thu, 26 Oct 2000 04:37:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA24153 for manet-outgoing; Thu, 26 Oct 2000 02:30:04 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA24095 for ; Thu, 26 Oct 2000 02:30:02 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id XAA16585 for ; Wed, 25 Oct 2000 23:27:39 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id XAA05302 for ; Wed, 25 Oct 2000 23:27:36 -0700 (MST)] Received: from beast.arc.corp.mot.com (beast.arc.corp.mot.com [217.1.10.11]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e9Q6RDn21154 for ; Thu, 26 Oct 2000 17:27:13 +1100 (EST) Received: (from kwchin@localhost) by beast.arc.corp.mot.com (8.10.2/8.10.2) id e9Q6RCa11242 for manet@itd.nrl.navy.mil; Thu, 26 Oct 2000 17:27:12 +1100 From: Kwan-Wu Chin Message-Id: <200010260627.e9Q6RCa11242@beast.arc.corp.mot.com> Subject: DATELINE EXTENSION: IPDPS-2001 Workshop on PDC Issues in WNMC To: manet@itd.nrl.navy.mil Date: Thu, 26 Oct 2000 17:27:12 +1100 (EST) X-Mailer: ELM [version 2.5 PL0pre8] 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 Dear Collegues, Sorry if you received multiple copies of this CFP. Dateline Extended: ** 10th November 2000 ** Cheers Kwan Motorola Australia Research Centre (MARC) ------------------------------- CFP ------------------------------ 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2001 WORKSHOPS April 23-27, 2001 Hyatt Regency San Francisco Airport ******************************************************************* General Chair Sajal K. Das, The University of Texas at Arlington, USA Program Co-Chairs Mohan J. Kumar, Curtin University of Technology, Perth, Australia and The University of Texas at Arlington, USA Paul Spirakis, Computer Technology Institute, Patras, Greece ********************************************************************* Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing : routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for for this workshop. Accepted papers will be published in the proceedings of the IPDPS workshops Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Routing in adhoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed Wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one opf the the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12 point size type on 8.5 x 11 inch pages. References, figures, tables, etc. may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; (3) phone number; and (4) fax number. Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cs.curtin.edu.au or spirakis@cti.gr. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5 x 11 inch (US letter size) paper. For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or Paul Spirakis. All manuscripts will be reviewed. Manuscripts must be received by October 30, 2000. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be mailed by December 10, 2000. Camera-ready papers are due January 15, 2001. Proceedings will be available at the Conference. ********************************************************************* IMPORTANT DATES: November 10, 2000 Workshop Paper Due (Extended) December 10, 2000 Notification of Acceptance/Rejection January 15, 2001 Camera-Ready Paper Due ********************************************************************* Workshop Program Co-Chairs Mohan Kumar School of Computer Science Curtin University of Technology GPO Box U 1987, Perth WA 1987 AUSTRALIA Fax: +61 8 9266 2819 E-mail: kumar@cs.curtin.edu.au and Paul Spirakis Director and Senior Researcher Computer Technology Institute 61 Riga Fereou Str., 26221 Patras, Greece Patras, Greece Fax: +30 61 993 973, +30 61 222086 E-mail: spirakis@cti.gr ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Technical Program Committee ------------------------------ Maurizio Bonuccelli University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kwan-Wu Chin, Motorola Australia Research Centre Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA Xiaohua Jia, City University of Hong Kong Jan van Leeuwen University of Utrecht, The Netherlands John Lui, The Chinese University of Hong Kong Marios Mavronicolas, University of Cyprus, Cyprus Cristina Pinnotti, Italian National Research Council Sotiris Nikoletseas Computer Technology Institute, Greece Don Sannella University of Edinburgh, Scotland Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Yongbing Zhang University of Tsukuba, Japan Martha Steenstrup, BBN Technologies, USA Albert Zomaya, University of Western Australia, Perth, Australia Somprakash Bandopadhyay, PWC Global, Calcutta, India Stefano Basagni, University of Texas at Dallas, USA Steering Commitee (Under creation) ------------------------------ Victor Bahl, Microsoft, Seattle, USA Kalyan Basu, Nortel Networks, Richardson, USA Andrew Campbell, Columbia University, USA Imrich Chlamtac, The University of Texas at Dallas Sajal Das, The University of Texas at Arlington, USA Publicity Co-Chairs: ------------------------------ Kwan-Wu Chin, Motorola Australia Research Centre Sotiris Nikoletseas Computer Technology Institute From owner-manet@itd.nrl.navy.mil Fri Oct 27 02:44: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 SMTP id CAA16385 for ; Fri, 27 Oct 2000 02:44:05 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA24871 for manet-outgoing; Fri, 27 Oct 2000 01:04:49 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA24866 for ; Fri, 27 Oct 2000 01:04:47 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id AAA12206; Fri, 27 Oct 2000 00:02:50 -0500 (EST) Date: Fri, 27 Oct 2000 00:02:50 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010270502.AAA12206@realestate-webpages.com> To: manet@itd.nrl.navy.mil Subject: FREE 125 Page Real Estate Glossary Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk NOW YOU CAN OFFER YOUR CLIENTS EVERYTHING FROM A TO Z! Just check out our FREE 125 page Real Estate glossary at http://www.WebsiteUpgrades.com/glossary/free This extensive glossary explains everything they would ever want to know about real estate, mortgage and construction terms. It is one of the most comprehensive products available today. To add it to your website visit http://www.RealestateWebpages.com/content/glossary.shtml It's useful, easy to add, and best of all - FREE! If you like our glossary you should take a look at our REALTOR UPGRADE PACKAGE. It contains 25 sections of professionally written and copyrighted content that can be seamlessly inserted into your existing website. You can check it out at http://www.WebsiteUpgrades.com NEED A NEW WEBSITE? Take one of ours out for a TEST DRIVE at http://www.RealEstateWebpages.com With 10 styles to choose from we can have you up and running within days of ordering. All we need is your photo and business card. Our websites not only reflect a dedication to professionalism and service but also offer such a wide range of useful information that visitors will always find something of interest and return time after time. NEED YOUR OWN WEBSITE DOMAIN NAME? Then visit http://www.RealEstateWebpages.com/content/whois.shtml and find out if there are any good Real Estate website names available for your trading area. Look for names that combine your trading area with words like HOMES, PROPERTIES, REALESTATE, LISTINGS etc. Or check if your OWN NAME is still available. Call us at 1.800.367.9814 if you have any questions or need help choosing a name. ------------------------------------ Copyright 1999, 2000 Website Upgrades Inc. All Rights Reserved. You are receiving this message because your email address is listed in our database at WebsiteUpgrades.com. We apologize if this E-mail has reached you in error. --------------------------------------------------------------------------- To be unsubscribed from the mailing list simply click on the link below http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=manet@itd.nrl.navy.mil From owner-mmnet@itd.nrl.navy.mil Fri Oct 27 02:45: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 SMTP id CAA17162 for ; Fri, 27 Oct 2000 02:45:53 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA24864 for mmnet-outgoing; Fri, 27 Oct 2000 01:04:35 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA24856 for ; Fri, 27 Oct 2000 01:04:33 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id AAA11825; Fri, 27 Oct 2000 00:02:34 -0500 (EST) Date: Fri, 27 Oct 2000 00:02:34 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010270502.AAA11825@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: FREE 125 Page Real Estate Glossary Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk NOW YOU CAN OFFER YOUR CLIENTS EVERYTHING FROM A TO Z! Just check out our FREE 125 page Real Estate glossary at http://www.WebsiteUpgrades.com/glossary/free This extensive glossary explains everything they would ever want to know about real estate, mortgage and construction terms. It is one of the most comprehensive products available today. To add it to your website visit http://www.RealestateWebpages.com/content/glossary.shtml It's useful, easy to add, and best of all - FREE! If you like our glossary you should take a look at our REALTOR UPGRADE PACKAGE. It contains 25 sections of professionally written and copyrighted content that can be seamlessly inserted into your existing website. You can check it out at http://www.WebsiteUpgrades.com NEED A NEW WEBSITE? Take one of ours out for a TEST DRIVE at http://www.RealEstateWebpages.com With 10 styles to choose from we can have you up and running within days of ordering. All we need is your photo and business card. Our websites not only reflect a dedication to professionalism and service but also offer such a wide range of useful information that visitors will always find something of interest and return time after time. NEED YOUR OWN WEBSITE DOMAIN NAME? Then visit http://www.RealEstateWebpages.com/content/whois.shtml and find out if there are any good Real Estate website names available for your trading area. Look for names that combine your trading area with words like HOMES, PROPERTIES, REALESTATE, LISTINGS etc. Or check if your OWN NAME is still available. Call us at 1.800.367.9814 if you have any questions or need help choosing a name. ------------------------------------ Copyright 1999, 2000 Website Upgrades Inc. All Rights Reserved. You are receiving this message because your email address is listed in our database at WebsiteUpgrades.com. We apologize if this E-mail has reached you in error. --------------------------------------------------------------------------- To be unsubscribed from the mailing list simply click on the link below http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil From owner-manet@itd.nrl.navy.mil Fri Oct 27 06:58: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 SMTP id GAA12197 for ; Fri, 27 Oct 2000 06:58:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA28405 for manet-outgoing; Fri, 27 Oct 2000 05:17:19 -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 FAA28400 for ; Fri, 27 Oct 2000 05:17:17 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id e9R9FFb19644 for ; Fri, 27 Oct 2000 11:15:15 +0200 (MET DST) Message-Id: <3.0.1.32.20001027112059.04de6ce0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 27 Oct 2000 11:20:59 +0200 To: manet@itd.nrl.navy.mil Subject: Re: When the AODV Hello Packet is exchanged withunidirectionallinks? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id FAA28401 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id FAA28405 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA12197 Hello Ravi, A 13:06 25/10/00 -0500, vous avez écrit : >If I understand your suggestion correctly, you are suggesting that the >routing protocol should ignore all unidirectional links and restrict >itself to bidirectional links only. I don't have the pretention to make such statement! I just noticed that some (most) protocols needs bidirectional routes (because of the underlying data link layer) but certain can deadlock in presence of unidirectional links even if the appropriate bidirectional routes exist. The "black list" is an attempt to solve this particular case. Regarding the general concept of routing over unidirectional links, I understood this is a very difficult issue. There would be the need of deeply dedicated MAC layers as you mention in your long mail. Regards, Philippe From owner-manet@itd.nrl.navy.mil Fri Oct 27 14:26:20 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 SMTP id OAA21667 for ; Fri, 27 Oct 2000 14:26:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA09941 for manet-outgoing; Fri, 27 Oct 2000 12:02:59 -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 MAA09935 for ; Fri, 27 Oct 2000 12:02:57 -0400 (EDT) Received: from sol.utdallas.edu (sol.utdallas.edu [129.110.34.3]) by ns0.utdallas.edu (Postfix) with ESMTP id 5E2811A000D; Fri, 27 Oct 2000 11:00:56 -0500 (CDT) Received: from localhost (ravip@localhost) by sol.utdallas.edu (8.9.1/8.9.1) with ESMTP id KAA00825; Fri, 27 Oct 2000 10:58:19 -0500 (CDT) X-Authentication-Warning: sol.utdallas.edu: ravip owned process doing -bs Date: Fri, 27 Oct 2000 10:58:19 -0500 (CDT) From: Ravi Prakash To: jacquet@menetou.inria.fr Cc: manet@itd.nrl.navy.mil Subject: Re: When the AODV Hello Packet is exchanged withunidirectionallinks? In-Reply-To: <3.0.1.32.20001027112059.04de6ce0@menetou.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id MAA09936 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id MAA09941 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA21667 HI Philippe, I agree with you that several MANET routing protocols implicitly or explicitly restrict themselves to bidirectional links only, and that they will not work correctly in the presence of unidirectional links. I can think of situations of wrong routes being detected. This will either result in unnecessary transmissions or incessant route discovery attempts on the receipt of routing errors. However, I could not come across a situation in which where nodes would deadlock. The situations that I have come across would appear more like livelock. Here, I am interpreting "deadlock" in the operating system/distributed computing context. So, could you please describe a situation where a deadlock might occur? I am really interested. With best regards, ----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 On Fri, 27 Oct 2000 jacquet@menetou.inria.fr wrote: > Hello Ravi, > > A 13:06 25/10/00 -0500, vous avez écrit : > >If I understand your suggestion correctly, you are suggesting that the > >routing protocol should ignore all unidirectional links and restrict > >itself to bidirectional links only. > > I don't have the pretention to make such statement! I just noticed that > some (most) protocols needs bidirectional routes (because of the underlying > data link layer) but certain can deadlock in presence of unidirectional > links even if the appropriate bidirectional routes exist. The "black list" > is an attempt to solve this particular case. > > Regarding the general concept of routing over unidirectional links, I > understood this is a very difficult issue. There would be the need of > deeply dedicated MAC layers as you mention in your long mail. > > Regards, > Philippe > From owner-manet@itd.nrl.navy.mil Fri Oct 27 15:39:09 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 SMTP id PAA10924 for ; Fri, 27 Oct 2000 15:39:09 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA12999 for manet-outgoing; Fri, 27 Oct 2000 13:27:47 -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 NAA12994 for ; Fri, 27 Oct 2000 13:27:45 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id e9RHPdb27040; Fri, 27 Oct 2000 19:25:39 +0200 (MET DST) Message-Id: <3.0.1.32.20001027193124.04e28b90@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 27 Oct 2000 19:31:24 +0200 To: Ravi Prakash Subject: Re: When the AODV Hello Packet is exchanged withunidirectionallinks? Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <3.0.1.32.20001027112059.04de6ce0@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id NAA12995 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by itd.nrl.navy.mil id NAA12999 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA10924 Dear Ravi, Deadlock or livelock, sorry, I am a little confused. I just meant that the route discovery permanently fails for some pairs source-destination, not that the whole network crashes. Network crashes might occur if the protocol has no way to get rid of wrong information. But if the protocol has an efficient information refresh process (timeout, sequence numbers), then it should be OK. Best regards, Philippe A 10:58 27/10/00 -0500, Ravi Prakash a écrit : >HI Philippe, > >I agree with you that several MANET routing protocols implicitly or >explicitly restrict themselves to bidirectional links only, and that they >will not work correctly in the presence of unidirectional links. > >I can think of situations of wrong routes being detected. This will either >result in unnecessary transmissions or incessant route discovery attempts >on the receipt of routing errors. > >However, I could not come across a situation in which where nodes would >deadlock. The situations that I have come across would appear more >like livelock. Here, I am interpreting "deadlock" in the operating >system/distributed computing context. So, could you please describe a >situation where a deadlock might occur? I am really interested. > >With best regards, > >----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 > >On Fri, 27 Oct 2000 jacquet@menetou.inria.fr wrote: > >> Hello Ravi, >> >> A 13:06 25/10/00 -0500, vous avez écrit : >> >If I understand your suggestion correctly, you are suggesting that the >> >routing protocol should ignore all unidirectional links and restrict >> >itself to bidirectional links only. >> >> I don't have the pretention to make such statement! I just noticed that >> some (most) protocols needs bidirectional routes (because of the underlying >> data link layer) but certain can deadlock in presence of unidirectional >> links even if the appropriate bidirectional routes exist. The "black list" >> is an attempt to solve this particular case. >> >> Regarding the general concept of routing over unidirectional links, I >> understood this is a very difficult issue. There would be the need of >> deeply dedicated MAC layers as you mention in your long mail. >> >> Regards, >> Philippe >> > From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 00:27: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 SMTP id AAA17425 for ; Sat, 28 Oct 2000 00:27:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA24679 for mmnet-outgoing; Fri, 27 Oct 2000 22:11:49 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA24674 for ; Fri, 27 Oct 2000 22:11:47 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id VAA18239; Fri, 27 Oct 2000 21:09:46 -0500 (EST) Date: Fri, 27 Oct 2000 21:09:46 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280209.VAA18239@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 02:55: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 SMTP id CAA22571 for ; Sat, 28 Oct 2000 02:55:24 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id AAA26493 for mmnet-outgoing; Sat, 28 Oct 2000 00:52:25 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id AAA26486 for ; Sat, 28 Oct 2000 00:52:21 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id XAA09798; Fri, 27 Oct 2000 23:50:16 -0500 (EST) Date: Fri, 27 Oct 2000 23:50:16 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280450.XAA09798@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 03:25: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 SMTP id CAA22570 for ; Sat, 28 Oct 2000 02:55:24 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA26590 for mmnet-outgoing; Sat, 28 Oct 2000 01:08:26 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA26585 for ; Sat, 28 Oct 2000 01:08:24 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id AAA13994; Sat, 28 Oct 2000 00:06:24 -0500 (EST) Date: Sat, 28 Oct 2000 00:06:24 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280506.AAA13994@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 03:37: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 SMTP id DAA02094 for ; Sat, 28 Oct 2000 03:37:37 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA26775 for mmnet-outgoing; Sat, 28 Oct 2000 01:28:21 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA26770 for ; Sat, 28 Oct 2000 01:28:19 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id AAA19208; Sat, 28 Oct 2000 00:26:16 -0500 (EST) Date: Sat, 28 Oct 2000 00:26:16 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280526.AAA19208@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 04:10: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 SMTP id EAA09085 for ; Sat, 28 Oct 2000 04:10:07 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA27902 for mmnet-outgoing; Sat, 28 Oct 2000 02:09:04 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA27897 for ; Sat, 28 Oct 2000 02:09:02 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id BAA29251; Sat, 28 Oct 2000 01:06:56 -0500 (EST) Date: Sat, 28 Oct 2000 01:06:56 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280606.BAA29251@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 05:04: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 SMTP id FAA20755 for ; Sat, 28 Oct 2000 05:04:44 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA29057 for mmnet-outgoing; Sat, 28 Oct 2000 03:24:03 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA29052 for ; Sat, 28 Oct 2000 03:24:01 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id CAA16204; Sat, 28 Oct 2000 02:21:57 -0500 (EST) Date: Sat, 28 Oct 2000 02:21:57 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280721.CAA16204@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 05:04: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 SMTP id FAA20808 for ; Sat, 28 Oct 2000 05:04:58 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id DAA28943 for mmnet-outgoing; Sat, 28 Oct 2000 03:15:35 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id DAA28938 for ; Sat, 28 Oct 2000 03:15:34 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id CAA14178; Sat, 28 Oct 2000 02:13:28 -0500 (EST) Date: Sat, 28 Oct 2000 02:13:28 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280713.CAA14178@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 05:44:18 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 SMTP id FAA29200 for ; Sat, 28 Oct 2000 05:44:18 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA29788 for mmnet-outgoing; Sat, 28 Oct 2000 04:04:03 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA29783 for ; Sat, 28 Oct 2000 04:04:02 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id DAA26100; Sat, 28 Oct 2000 03:01:58 -0500 (EST) Date: Sat, 28 Oct 2000 03:01:58 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280801.DAA26100@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 05:46: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 SMTP id FAA29642 for ; Sat, 28 Oct 2000 05:46:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA29774 for mmnet-outgoing; Sat, 28 Oct 2000 04:03:47 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA29769 for ; Sat, 28 Oct 2000 04:03:45 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id DAA26005; Sat, 28 Oct 2000 03:01:35 -0500 (EST) Date: Sat, 28 Oct 2000 03:01:35 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280801.DAA26005@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 09:10: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 SMTP id JAA16010 for ; Sat, 28 Oct 2000 09:10:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA01605 for mmnet-outgoing; Sat, 28 Oct 2000 05:51:35 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA01600 for ; Sat, 28 Oct 2000 05:51:33 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id EAA21154; Sat, 28 Oct 2000 04:49:28 -0500 (EST) Date: Sat, 28 Oct 2000 04:49:28 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280949.EAA21154@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 09:40: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 SMTP id JAA16009 for ; Sat, 28 Oct 2000 09:10:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA01612 for mmnet-outgoing; Sat, 28 Oct 2000 05:51:49 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA01607 for ; Sat, 28 Oct 2000 05:51:47 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id EAA21213; Sat, 28 Oct 2000 04:49:43 -0500 (EST) Date: Sat, 28 Oct 2000 04:49:43 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010280949.EAA21213@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 10:21: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 SMTP id KAA01234 for ; Sat, 28 Oct 2000 10:21:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA02567 for mmnet-outgoing; Sat, 28 Oct 2000 07:15:13 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA02559 for ; Sat, 28 Oct 2000 07:15:11 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id GAA15081; Sat, 28 Oct 2000 06:13:07 -0500 (EST) Date: Sat, 28 Oct 2000 06:13:07 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281113.GAA15081@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 10:31: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 SMTP id KAA03395 for ; Sat, 28 Oct 2000 10:31:28 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA02577 for mmnet-outgoing; Sat, 28 Oct 2000 07:16:06 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA02572 for ; Sat, 28 Oct 2000 07:16:04 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id GAA15321; Sat, 28 Oct 2000 06:14:01 -0500 (EST) Date: Sat, 28 Oct 2000 06:14:01 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281114.GAA15321@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 11: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 SMTP id LAA18635 for ; Sat, 28 Oct 2000 11:42:44 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA04809 for mmnet-outgoing; Sat, 28 Oct 2000 09:41:12 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA04804 for ; Sat, 28 Oct 2000 09:41:11 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id IAA05195; Sat, 28 Oct 2000 08:39:06 -0500 (EST) Date: Sat, 28 Oct 2000 08:39:06 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281339.IAA05195@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 12:36: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 SMTP id MAA00299 for ; Sat, 28 Oct 2000 12:36:56 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA05046 for mmnet-outgoing; Sat, 28 Oct 2000 10:08:55 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA05041 for ; Sat, 28 Oct 2000 10:08:53 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id JAA16384; Sat, 28 Oct 2000 09:06:49 -0500 (EST) Date: Sat, 28 Oct 2000 09:06:49 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281406.JAA16384@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 12: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 SMTP id MAA02219 for ; Sat, 28 Oct 2000 12:45:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA04851 for mmnet-outgoing; Sat, 28 Oct 2000 09:45:22 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA04846 for ; Sat, 28 Oct 2000 09:45:20 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id IAA07093; Sat, 28 Oct 2000 08:43:16 -0500 (EST) Date: Sat, 28 Oct 2000 08:43:16 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281343.IAA07093@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 13:20: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 SMTP id NAA10007 for ; Sat, 28 Oct 2000 13:20:58 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA05535 for mmnet-outgoing; Sat, 28 Oct 2000 10:38:20 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA05530 for ; Sat, 28 Oct 2000 10:38:18 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id JAA27692; Sat, 28 Oct 2000 09:36:13 -0500 (EST) Date: Sat, 28 Oct 2000 09:36:13 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281436.JAA27692@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-manet@itd.nrl.navy.mil Sat Oct 28 14:56:12 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 SMTP id OAA03811 for ; Sat, 28 Oct 2000 14:56:12 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA07777 for manet-outgoing; Sat, 28 Oct 2000 13:01:51 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA07767 for ; Sat, 28 Oct 2000 13:01:49 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id LAA25246; Sat, 28 Oct 2000 11:59:45 -0500 (EST) Date: Sat, 28 Oct 2000 11:59:45 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281659.LAA25246@realestate-webpages.com> To: manet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go manet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=manet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 15:18: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 SMTP id PAA08563 for ; Sat, 28 Oct 2000 15:18:21 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA08234 for mmnet-outgoing; Sat, 28 Oct 2000 13:30:49 -0400 (EDT) Received: from par.allnet.ne.jp (mail2r.allnet.ne.jp [210.228.1.9]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA08229 for ; Sat, 28 Oct 2000 13:30:47 -0400 (EDT) Received: from 211.19.249.15 (all19249015.allnet.ne.jp [211.19.249.15]) by par.allnet.ne.jp (8.9.3/3.7W) with SMTP id CAA06162 for ; Sun, 29 Oct 2000 02:28:42 +0900 (JST) Date: Sun, 29 Oct 2000 02:31:10 +0900 From: takanori To: mmnet@itd.nrl.navy.mil Message-Id: <39FB0D5E1F4.51D5TAKA.N@mail.par.allnet.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.26.03 Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 15:51: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 SMTP id PAA15666 for ; Sat, 28 Oct 2000 15:51:45 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA08334 for mmnet-outgoing; Sat, 28 Oct 2000 13:40:47 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA08329 for ; Sat, 28 Oct 2000 13:40:45 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id MAA12631; Sat, 28 Oct 2000 12:38:39 -0500 (EST) Date: Sat, 28 Oct 2000 12:38:39 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010281738.MAA12631@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 17:03:07 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 SMTP id RAA03015 for ; Sat, 28 Oct 2000 17:03:06 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA09425 for mmnet-outgoing; Sat, 28 Oct 2000 14:54:40 -0400 (EDT) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA09420 for ; Sat, 28 Oct 2000 14:54:38 -0400 (EDT) Received: from [206.15.137.127] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 542870 for mmnet@itd.nrl.navy.mil; Sat, 28 Oct 2000 14:46:35 -0400 Message-ID: <39FB221D.2FEE32CB@21rst-century.com> Date: Sat, 28 Oct 2000 14:59:40 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: mmnet@itd.nrl.navy.mil Subject: Re: You've Been Removed! References: <200010281436.JAA27692@realestate-webpages.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit "RealestateWebpages.com" wrote: > > We're sorry to see you go mmnet@itd.nrl.navy.mil! > > In the near future we will be adding an extensive Real Estate newsletter > database to our agent websites. This database will allow REALTORS to > offer their clients free email newsletters online. > > If you would like to receive information on this exciting new product > click on the link below to automatically re-subscribe yourself: > > http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil > > Thank you, > The Website Upgrades Inc. team. Can this stupidity be stopped ? -- Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 201 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com From owner-mmnet@itd.nrl.navy.mil Sat Oct 28 18:03: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 SMTP id SAA16003 for ; Sat, 28 Oct 2000 18:03:38 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA10150 for mmnet-outgoing; Sat, 28 Oct 2000 15:44:05 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id PAA10145 for ; Sat, 28 Oct 2000 15:44:04 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Sat Oct 28 15:41:31 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Sat Oct 28 15:41:30 EDT 2000 Received: from research.bell-labs.com (ex-vpn76.pa.bell-labs.com [135.250.1.76]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV52062 (AUTH gja); Sat, 28 Oct 2000 12:41:29 -0700 (PDT) Message-ID: <39FB2C18.3D767A1A@research.bell-labs.com> Date: Sat, 28 Oct 2000 12:42:16 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mmnet@itd.nrl.navy.mil Subject: Re: You've Been Added! References: <200010281738.MAA12631@realestate-webpages.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit so how about, when we see the next "You've been removed" message, no-one clicks on the "add yourself back" link, hmm? gja "RealestateWebpages.com" wrote: > > This message is to confirm the addition of your > email address: mmnet@itd.nrl.navy.mil to the > Website Upgrades Inc. 1.7 mailing list. > > If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, > click the link below to remove yourself automatically. > > http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil > > Thank you, > > Website Upgrades Inc. 1.7 -- ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-manet@itd.nrl.navy.mil Sat Oct 28 18:42: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 SMTP id SAA24358 for ; Sat, 28 Oct 2000 18:42:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA10450 for manet-outgoing; Sat, 28 Oct 2000 16:09:56 -0400 (EDT) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA10445 for ; Sat, 28 Oct 2000 16:09:55 -0400 (EDT) Received: by realestate-webpages.com (8.9.3/8.9.3) id PAA19855; Sat, 28 Oct 2000 15:07:50 -0500 (EST) Date: Sat, 28 Oct 2000 15:07:50 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010282007.PAA19855@realestate-webpages.com> To: manet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: manet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=manet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sun Oct 29 14:20:18 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 SMTP id OAA29473 for ; Sun, 29 Oct 2000 14:20:18 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA21907 for mmnet-outgoing; Sun, 29 Oct 2000 11:54:19 -0500 (EST) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA21902 for ; Sun, 29 Oct 2000 11:54:17 -0500 (EST) Received: by realestate-webpages.com (8.9.3/8.9.3) id LAA21489; Sun, 29 Oct 2000 11:52:09 -0500 (EST) Date: Sun, 29 Oct 2000 11:52:09 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010291652.LAA21489@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sun Oct 29 14:55: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 SMTP id OAA06986 for ; Sun, 29 Oct 2000 14:55:27 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA21900 for mmnet-outgoing; Sun, 29 Oct 2000 11:53:51 -0500 (EST) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA21895 for ; Sun, 29 Oct 2000 11:53:48 -0500 (EST) Received: by realestate-webpages.com (8.9.3/8.9.3) id LAA21252; Sun, 29 Oct 2000 11:51:29 -0500 (EST) Date: Sun, 29 Oct 2000 11:51:29 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010291651.LAA21252@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sun Oct 29 19:32: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 SMTP id TAA06069 for ; Sun, 29 Oct 2000 19:32:49 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA25350 for mmnet-outgoing; Sun, 29 Oct 2000 17:25:36 -0500 (EST) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA25345 for ; Sun, 29 Oct 2000 17:25:34 -0500 (EST) Received: by realestate-webpages.com (8.9.3/8.9.3) id RAA23026; Sun, 29 Oct 2000 17:23:25 -0500 (EST) Date: Sun, 29 Oct 2000 17:23:25 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010292223.RAA23026@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Added! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk This message is to confirm the addition of your email address: mmnet@itd.nrl.navy.mil to the Website Upgrades Inc. 1.7 mailing list. If you would like to remove your self from the Website Upgrades Inc. 1.7 mailing list, click the link below to remove yourself automatically. http://www.realestatewebpages.com/cgi-bin/list/s.pl?r=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, Website Upgrades Inc. 1.7 From owner-mmnet@itd.nrl.navy.mil Sun Oct 29 20:21: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 SMTP id UAA16442 for ; Sun, 29 Oct 2000 20:21:29 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA26280 for mmnet-outgoing; Sun, 29 Oct 2000 18:30:45 -0500 (EST) Received: from realestate-webpages.com (realestate-webpages.com [216.122.12.253]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA26275 for ; Sun, 29 Oct 2000 18:30:43 -0500 (EST) Received: by realestate-webpages.com (8.9.3/8.9.3) id SAA21815; Sun, 29 Oct 2000 18:28:33 -0500 (EST) Date: Sun, 29 Oct 2000 18:28:33 -0500 (EST) From: "RealestateWebpages.com" Message-Id: <200010292328.SAA21815@realestate-webpages.com> To: mmnet@itd.nrl.navy.mil Subject: You've Been Removed! Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk We're sorry to see you go mmnet@itd.nrl.navy.mil! In the near future we will be adding an extensive Real Estate newsletter database to our agent websites. This database will allow REALTORS to offer their clients free email newsletters online. If you would like to receive information on this exciting new product click on the link below to automatically re-subscribe yourself: http://www.realestatewebpages.com/cgi-bin/list/s.pl?a=1&l=12&e=mmnet@itd.nrl.navy.mil Thank you, The Website Upgrades Inc. team. From owner-mmnet@itd.nrl.navy.mil Sun Oct 29 22:52: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 SMTP id WAA20787 for ; Sun, 29 Oct 2000 22:52:58 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA27896 for mmnet-outgoing; Sun, 29 Oct 2000 21:04:18 -0500 (EST) Received: from cableworks.cgocable.net (cableworks.cgocable.net [24.226.1.43]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id VAA27891 for ; Sun, 29 Oct 2000 21:04:17 -0500 (EST) Received: from RealEstateWebpages.com (d141-174-16.home.cgocable.net [24.141.174.16]) by cableworks.cgocable.net (8.9.3/8.9.3) with ESMTP id UAA22279; Sun, 29 Oct 2000 20:47:53 -0500 (EST) Message-ID: <39FCD668.C740AB2A@RealEstateWebpages.com> Date: Sun, 29 Oct 2000 21:01:12 -0500 From: "RealEstateWebpages.com" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mmnet@itd.nrl.navy.mil, info@realestate-webpages.com Subject: Frustration with unsolicited email from RealEstateWebpages.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Dear Sir/Madam: This email is being sent to the group address mmnet@itd.nrl.navy.mil. Some of you may have already received this message after complaining directly to the webmaster at RealEstateWebpages.com. I am sorry if this is the case but I am trying to ensure that all affected parties are notified. It has been brought to my attention that you have become extremely frustrated with our automated opt-in email campaign. I sincerely apologize for the inconvenience this has caused. Our company has taken the entire system off-line as of 7:00 pm Sunday October 29th until this problem is corrected. You are probably wondering why this problem occurred in the first place. It seems that this email address (mmnet@itd.nrl.navy.mil) was mistakenly included in our recent email campaign to North American Realtors. This in itself would not have normally required more than a simple unsubscribe on your part. However, it turns out that your address is a group list address for multiple email accounts in your organization. When the first email went out, it was received by your mail server and forwarded to a group of final addresses. When an individual in this group unsubscribed from our list the unsubscribe program automatically replied to all the members of the original group address that they have been successfully unsubscribed. That meant that all individuals in the group got another unsolicited message saying that they had successfully unsubscribed. We think that at this point one or more other individuals in the group also tried to unsubscribe. The unsubscribe program was not designed to deal with list submissions. Basically, when a user subscribes or unsubscribes the program just throws a toggle switch on or off. By having multiple users all unsubscribing from the same list it kept automatically re-subscribing and then unsubscribing the same group name. Each time this was done it sent out another group message to all of you saying that you have now been added or deleted from our list. This probably totally irritated some other members of the group, who then also tried to unsubscribe from our list. This started yet another round of email responses of subscribing/unsubscribing - and so on and so on. We are extremely sorry for this problem. The mistake was made on our part and we will not repeat it. It is very understandable that many of you reached a high level of frustration with our system (one individual unsubscribed over 10 times). In order to eliminate this problem and to break this cycle we decided to take our entire email list system off-line as of 7:00 pm Sunday October 29th 2000. Any further unsubscribes will not create any more email responses from us. It is unfortunate that it took us a few days to figure out what the problem actually was. We had never experienced a problem with a group list address before. By taking our system offline we will break the circular cycle of subscribing and unsubscribing that has been going on between your group of addresses and our server for the past few days. Again, we are sorry for the inconvenience this has caused and have made sure that your address has been removed (permanently) from our system. Vivian Debruyn-Smith Customer Service, RealEstateWebpages.com P.S. If for some reason this does not solve the problem please call me directly at 1.800.367.9814 or email me at... Vivian@RealEstateWebpages.com (don't worry, this will not put anyone into an automatic response system - you will be emailing my personal address). From owner-manet@itd.nrl.navy.mil Mon Oct 30 02:21:41 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 SMTP id CAA27422 for ; Mon, 30 Oct 2000 02:21:41 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA29496 for manet-outgoing; Sun, 29 Oct 2000 23:42:30 -0500 (EST) Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp [133.1.52.49]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id XAA29491 for ; Sun, 29 Oct 2000 23:42:22 -0500 (EST) Received: from louis (d16.ise.eng.osaka-u.ac.jp [133.1.52.16]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with SMTP id NAA26644 for ; Mon, 30 Oct 2000 13:40:11 +0900 (JST) Message-ID: <001601c0422a$dbe8ca60$10340185@ise.eng.osakau.ac.jp> From: "wooighee" To: References: <3.0.1.32.20001027112059.04de6ce0@menetou.inria.fr> <3.0.1.32.20001027193124.04e28b90@menetou.inria.fr> Subject: Why DSR is not selected in IETF ? Date: Mon, 30 Oct 2000 13:35:40 +0900 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 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 Hello All I wonder why DSR is not selected as one of the on-demand protocol in MANET ? Any significant shortcame of the protocol that make it not robust enough to be considered as a standardized protocol ? thank you ghee From owner-manet@itd.nrl.navy.mil Mon Oct 30 03:39:09 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 SMTP id DAA21933 for ; Mon, 30 Oct 2000 03:39:09 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA00835 for manet-outgoing; Mon, 30 Oct 2000 01:31:53 -0500 (EST) Received: from earthlink.net ([212.47.18.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id BAA00829 for manet@itd.nrl.navy.mil; Mon, 30 Oct 2000 01:31:42 -0500 (EST) Message-Id: X-Sender: daglowcg@earthlink.net X-Mailer: Mozilla 4.71 [en] (Win98; I) Date: Sun, 29 Oct 2000 22:29:28 -0700 To: gameprogrammer_list_recipients From: Marta Daglow Subject: STORMFRONT JOBS (2382bdfe) 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 Right now Stormfront Studios is adding to its staff and looking for people to create Next Gen Games for the X-BOX and PS2. We're looking for an Entry Programmer, AI Programmer, Sr. Programmer, Lead Programmer, Development Director, Sr. 3D Max Artist, 3D Animator and/or Art Director. Interested or know of anyone who may be interested? Please let me know if you can help us out - we need your talent! Thanks, Marta Daglow EMAIL: mdaglow@earthlink.net WEB: www.stormfront.com San Rafael, CA 94903 From owner-manet@itd.nrl.navy.mil Mon Oct 30 04:17: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 SMTP id EAA05964 for ; Mon, 30 Oct 2000 04:17:38 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id AAA00339 for manet-outgoing; Mon, 30 Oct 2000 00:55:37 -0500 (EST) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id AAA00334 for ; Mon, 30 Oct 2000 00:55:36 -0500 (EST) Received: from localhost (dbj@localhost) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id XAA08481; Sun, 29 Oct 2000 23:53:19 -0600 (CST) To: "wooighee" Cc: manet@itd.nrl.navy.mil In-Reply-To: Your message of "Mon, 30 Oct 2000 13:35:40 +0900" <001601c0422a$dbe8ca60$10340185@ise.eng.osakau.ac.jp> From: Dave Johnson Reply-To: Dave Johnson Subject: Re: Why DSR is not selected in IETF ? Date: Sun, 29 Oct 2000 23:53:19 -0600 Message-ID: <8480.972885199@cs.rice.edu> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk ghee, There has been no selection yet of *any* standards in the MANET Working Group of the IETF. DSR is still very much under consideration in the IETF, and we are still very actively working on DSR. As shown through many detailed simulations such as those in our paper "A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols" in MobiCom'98, DSR has excellent performance. We have also implemented the protocol and demonstrated the protocol in real operation with substantial mobility and substantial load from real application and transport protocols, showing that the protocol really works as designed and is indeed quite robust. For more information on our implementation results, see the paper "Quantitative Lessons From a Full-Scale Multi-Hop Wireless Ad Hoc Network Testbed" in WCNC 2000, or the longer technical report "Experiences Designing and Building a Multi-Hop Wireless Ad Hoc Network Testbed", both of which are available from our web pages at http://www.monarch.cs.cmu.edu/. The current Internet-Draft for DSR has expired, but it is still available also from our web pages above. All Internet-Drafts expire and are automatically deleted if not revised within 6 months. We have been busy over this time completing the initial version of QoS support in DSR and demonstrasting it in a real implementation for DARPA running Microsoft NetMeeting over a moving DSR network. Also over this time, by the way, I have moved from Carnegie Mellon University (where I had been on the faculty for 8 years) to Rice University. We are currently working on DSR at both CMU and at Rice, since I am still working with the same graduate students, although they are still at CMU temporarily. We are currently revising the DSR Internet-Draft and will be resubmitting it soon. If I can answer any other questions about DSR, please let me know. Dave -- David B. Johnson, Associate Professor of Computer Science and Electrical and Computer Engineering Department of Computer Science - MS 132 dbj@cs.rice.edu Rice University http://www.cs.rice.edu/~dbj/ 6100 Main Street Phone: (713) 348-3063 Houston, Texas 77005-1892 USA Fax: (713) 348-5930 >Hello All > > I wonder why DSR is not selected as one of the on-demand >protocol in MANET ? Any significant shortcame of the protocol >that make it not robust enough to be considered as a standardized >protocol ? > >thank you > >ghee From owner-manet@itd.nrl.navy.mil Mon Oct 30 17:57:07 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 SMTP id RAA00314 for ; Mon, 30 Oct 2000 17:57:06 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA25188 for manet-outgoing; Mon, 30 Oct 2000 15:57:28 -0500 (EST) Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.10]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA25180 for ; Mon, 30 Oct 2000 15:57:26 -0500 (EST) Received: from cadmium.cse.msu.edu (cadmium.cse.msu.edu [35.9.25.81]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with ESMTP id PAA01681; Mon, 30 Oct 2000 15:55:14 -0500 (EST) Date: Mon, 30 Oct 2000 15:55:14 -0500 (EST) From: Dmitri Deshun Perkins To: Dmitri Deshun Perkins cc: manet@itd.nrl.navy.mil Subject: clustering In-Reply-To: <39C092F6.32F3A3EC@inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello, I have read some papers discussing the advantages offered by clustering and hierarchical routing in static or almost static environments Intuitively, one would think some of these ideas may apply to MANETs especially environments with a large number of nodes. However, I am curious to know how practical clustering would be in such a dynamic(link failures, node movement, congestion, etc) network. Specifically, how would one select a clusterhead? Assuming all nodes have the ability to move at anytime, the clusterhead could possibly move. Does the leader election algorithm elect the node that has been stationary the longest. What if this node has the least power? It may not be a good choice? There would seem to be many other issues related to selecting(and reselecting) a clusterhead in a highly dynamic network such as a MANET. Your thoughts and feedback on the advantages/disadvantages surrounding these issues would be greatly appreciated. If this discussion has already taken place, please direct me to the-mail archives. Feel free to list any papers that compare hierarchical versus flat routing. Thanks for your time, D. Perkins From owner-mmnet@itd.nrl.navy.mil Mon Oct 30 18:05: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 SMTP id SAA02837 for ; Mon, 30 Oct 2000 18:05:40 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA26271 for mmnet-outgoing; Mon, 30 Oct 2000 16:29:10 -0500 (EST) Received: from tabasco.itd.nrl.navy.mil (tabasco.itd.nrl.navy.mil [132.250.92.182]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA26263; Mon, 30 Oct 2000 16:29:06 -0500 (EST) Message-Id: <5.0.0.25.2.20001030155654.02e53eb0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 16:27:18 -0500 To: Grenville Armitage , mmnet@itd.nrl.navy.mil From: Joe Macker Subject: YUK! You've Been Added! In-Reply-To: <39FB2C18.3D767A1A@research.bell-labs.com> References: <200010281738.MAA12631@realestate-webpages.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Thank you Grenville: Please relax and do not touch that ridiculously convenient "resubscribe link" and this will go away.. In light of this wonderful RealEstate list activity, we could begin to tighten subscribe/post control on the manet-related lists. I have avoided enforcing "only member" (source ID checked) postings, for convenience of traveling/ mobile users,etc. with potential multiple source mail accounts,etc. and until now I have left majordomo subscription activity reasonably unaudited. Would the list like to see this be more controlled (might catch some of this, but still nothing ideal) or continue to deal with occasional bad behavior for the increased flexibility in posting,etc? A little question of preferred sociology...I vote against an increased police state, but the group's will rules. -joe At 12:42 PM 10/28/00 -0700, Grenville Armitage wrote: >so how about, when we see the next "You've been removed" >message, no-one clicks on the "add yourself back" link, hmm? > >gja From owner-manet@itd.nrl.navy.mil Mon Oct 30 18:15: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 SMTP id SAA11301 for ; Mon, 30 Oct 2000 18:15:14 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA26897 for manet-outgoing; Mon, 30 Oct 2000 16:41:07 -0500 (EST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA26892 for ; Mon, 30 Oct 2000 16:41:06 -0500 (EST) Received: from chip (DHCP044-036.BBN.COM [128.89.44.36]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id QAA27727; Mon, 30 Oct 2000 16:38:54 -0500 (EST) Message-Id: <3.0.3.32.20001030163851.013480fc@po1.bbn.com> X-Sender: celliott@po1.bbn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 30 Oct 2000 16:38:51 -0500 To: Dmitri Deshun Perkins From: Chip Elliott Subject: Re: clustering Cc: manet@itd.nrl.navy.mil, Chip Elliott In-Reply-To: References: <39C092F6.32F3A3EC@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Dmitri, At BBN we've done several clustered (hierarchical) mobile ad hoc networks and have some experience with how they behave in (a) simulated radio environments, and (b) actual experiments. The largest real experiment to date involved about 65 radios in vehicles and took place out in the Arizona desert in an area of fairly large hills. In our networks, all nodes move, and so yes, the clusterhead may certainly move. Note that it's not such a great idea to drive your algorithms towards selecting stationary nodes, if all the other nodes are moving! What you'd like is some kind of network stability, so as to hold down the control traffic and # of failed routes, which means that your clusters should map onto the underlying structure of the moving radios, if possible. This is vaguely like trying to select working sets for paged memory systems... Most of our networks involve vehicle-based radios, which generally do not need to worry about power. However we're still interested in picking clusterheads that require minimal power in order to communicate with their members, so as to maximize the overall spatial reuse. (If everyone whispers, you can get a lot more people in a room talking at once.) Some of our work, particularly the power-based DARPA work led by Jason Redi, has had an explicit goal of power minimization to save battery life. Choosing good clusterheads is in general as much art as science, as one is always trying to predict the future: eg, which node of these N will be the best clusterhead over the next 10 minutes. That's a hard problem when all the nodes are moving through some kind of terrain and RF interference with unpredictable traffic loads! We've documented some aspects of our networking protocols and algorithms in papers, typically at MILCOM. Here's a link you can chase down to find out about our support for IP multicast routing: http://www.argreenhouse.com/society/TacCom/papers98/13_03i.pdf For general background info on our work, and for specific articles on Jason's power-conservation work, check out: http://www.jasonredi.com/ Cheers, Chip Elliott BBN Technologies At 03:55 PM 10/30/00 -0500, Dmitri Deshun Perkins wrote: > > >Hello, > >I have read some papers discussing the advantages offered by clustering and >hierarchical routing in static or almost static environments Intuitively, >one would think some of these ideas may apply to MANETs especially >environments with a large number of nodes. > >However, I am curious to know how practical clustering would be in such a >dynamic(link failures, node movement, congestion, etc) network. Specifically, >how would one select a clusterhead? Assuming all nodes have the ability to >move at anytime, the clusterhead could possibly move. Does the leader election >algorithm elect the node that has been stationary the longest. What if this >node has the least power? It may not be a good choice? There would seem to >be many other issues related to selecting(and reselecting) a clusterhead in a >highly dynamic network such as a MANET. > >Your thoughts and feedback on the advantages/disadvantages surrounding >these issues would be greatly appreciated. If this discussion has already >taken place, please direct me to the-mail archives. Feel free to list any >papers that compare hierarchical versus flat routing. > >Thanks for your time, >D. Perkins > From owner-manet@itd.nrl.navy.mil Mon Oct 30 19:00: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 SMTP id TAA26075 for ; Mon, 30 Oct 2000 19:00:50 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA27687 for manet-outgoing; Mon, 30 Oct 2000 17:12:31 -0500 (EST) Received: from tabasco.itd.nrl.navy.mil (tabasco.itd.nrl.navy.mil [132.250.92.182]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA27682; Mon, 30 Oct 2000 17:12:24 -0500 (EST) Message-Id: <5.0.0.25.2.20001030163937.02e84400@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 17:10:37 -0500 To: Dmitri Deshun Perkins From: Joe Macker Subject: Re: clustering Cc: manet@itd.nrl.navy.mil In-Reply-To: References: <39C092F6.32F3A3EC@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 03:55 PM 10/30/00 -0500, Dmitri Deshun Perkins wrote: >Hello, > >I have read some papers discussing the advantages offered by clustering and >hierarchical routing in static or almost static environments Intuitively, >one would think some of these ideas may apply to MANETs especially >environments with a large number of nodes. > >However, I am curious to know how practical clustering would be in such a >dynamic(link failures, node movement, congestion, etc) network. Specifically, >how would one select a clusterhead? Assuming all nodes have the ability to >move at anytime, the clusterhead could possibly move. Does the leader >election >algorithm elect the node that has been stationary the longest. What if this >node has the least power? It may not be a good choice? There would seem to >be many other issues related to selecting(and reselecting) a clusterhead in a >highly dynamic network such as a MANET. These are good questions. Going back aways if you have not read them see below.. (I assume you may have already seen these as they good fundamental pieces of work in this area. although there is other work as well) Special issue of the Proceedings of the IEEE on packet radio networks, vol. 75, no. 1, Jan. 1987. ...paper by Ephremides et al. uses a backbone of clusterheads and gateways. Using simple selection criteria of node number ordering. Another reference, more recent, is ``Multicluster, mobile, multimedia radio network,'' by M. Gerla and J. T.-C. Tsai, in Wireless Networks vol. 1, no. 3, 1995, pp. 255-265. Both these papers had election algorithms running, with some analysis of different techniques. I believe the results from these previous studies, opted for simpler lowest ID clusterhead election schemes, as opposed to more complex metric election schemes. >Your thoughts and feedback on the advantages/disadvantages surrounding >these issues would be greatly appreciated. If this discussion has already >taken place, please direct me to the-mail archives. Feel free to list any >papers that compare hierarchical versus flat routing. In general, to address you broader question, I think hierarchical vs. flat discussions might need to be quite subjective. As any flat algorithm has a scaling limit, it is obvious that hierarchical can help when that limit is reached. Flat algorithms can have very different scaling limits and conditional behaviors. We would like to understand those limits better so more knowledge of individual algorithms would help. Another argument against clusters, often discussed, is can overly concentrate traffic in dense networks. CBRP used such clusters to improve flooding of control, but not for data forwarding, an interesting hybrid with a potential benefit of avoiding some traffic concentration problems. We also used a hybrid approach like that for a NRL mobile networking project in the mid-90s that worked reasonably well (more of a MAC/subnet layer approach). Hope these tidbits help, Joe >Thanks for your time, >D. Perkins From owner-manet@itd.nrl.navy.mil Mon Oct 30 19:43: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 SMTP id TAA06393 for ; Mon, 30 Oct 2000 19:43:37 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA29620 for manet-outgoing; Mon, 30 Oct 2000 18:14:31 -0500 (EST) Received: from ee.cornell.edu (anise.ee.cornell.edu [128.84.239.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA29615 for ; Mon, 30 Oct 2000 18:14:30 -0500 (EST) 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 SAA16977; Mon, 30 Oct 2000 18:12:17 -0500 (EST) Date: Mon, 30 Oct 2000 18:11:37 -0500 (EST) From: Zygmunt Haas To: Dmitri Deshun Perkins cc: manet@itd.nrl.navy.mil Subject: Re: clustering 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 Dimitri, May want to take a look at: Z.J. Haas and S. Tabrizi, "On Some Challenges and Design Choices in Ad-Hoc Communications,"IEEE MILCOM'98, Bedford, MA, October 18-21, 1998 An "older" paper, but still has "some" truth in it .... 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 Mon, 30 Oct 2000, Dmitri Deshun Perkins wrote: > > > Hello, > > I have read some papers discussing the advantages offered by clustering and > hierarchical routing in static or almost static environments Intuitively, > one would think some of these ideas may apply to MANETs especially > environments with a large number of nodes. > > However, I am curious to know how practical clustering would be in such a > dynamic(link failures, node movement, congestion, etc) network. Specifically, > how would one select a clusterhead? Assuming all nodes have the ability to > move at anytime, the clusterhead could possibly move. Does the leader election > algorithm elect the node that has been stationary the longest. What if this > node has the least power? It may not be a good choice? There would seem to > be many other issues related to selecting(and reselecting) a clusterhead in a > highly dynamic network such as a MANET. > > Your thoughts and feedback on the advantages/disadvantages surrounding > these issues would be greatly appreciated. If this discussion has already > taken place, please direct me to the-mail archives. Feel free to list any > papers that compare hierarchical versus flat routing. > > Thanks for your time, > D. Perkins > > From owner-manet@itd.nrl.navy.mil Mon Oct 30 20:19: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 SMTP id UAA14114 for ; Mon, 30 Oct 2000 20:19:30 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA00626 for manet-outgoing; Mon, 30 Oct 2000 18:54:05 -0500 (EST) 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 SAA00621 for ; Mon, 30 Oct 2000 18:54:03 -0500 (EST) Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id ; Mon, 30 Oct 2000 18:51:52 -0500 Message-ID: <61891BA043DED21180920090273F1738012CB27A@argentina.telogy.com> From: Alan Amis To: "'Dmitri Deshun Perkins'" Cc: manet@itd.nrl.navy.mil Subject: RE: clustering Date: Mon, 30 Oct 2000 18:51:51 -0500 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, At UTD we have performed a good amount of research in the area of clusterhead election. In our simulations nodes may be static and/or mobile. The main criteria for the election algorithm is that no node is more than d-hops away from a clusterhead, where d is a programmable parameter. This election algorithm is called Max-Min D-Cluster Formation and completes in 2d rounds of message exchange. Max-Min uses flooding to determine the clusterheads. A paper describing Max-Min can be found in the Proceeding of the IEEE INFOCOM 2000. You are correct that there are many issues that come into play in selecting, reselecting, or releasing a clusterhead. One as you have pointed out is power. We would like to see all nodes participating in the network consume power at roughly the same rate. Therefore, it might be necessary to invoke thresholds governing how long a clusterhead stays a clusterhead before relinquishing his leadership role, clusterheads will consume more power as they do more work. Once the leadership role is relinquished we need to insure that the clusterhead will not be re-elected right away. Therefore, you need to instate some sort of load-balancing policy to manage the re-election of clusterheads. This policy could be based on power, time, number of messages, etc. Regards, Alan Amis -----Original Message----- From: Dmitri Deshun Perkins [mailto:perkin27@cse.msu.edu] Sent: Monday, October 30, 2000 2:55 PM To: Dmitri Deshun Perkins Cc: manet@itd.nrl.navy.mil Subject: clustering Hello, I have read some papers discussing the advantages offered by clustering and hierarchical routing in static or almost static environments Intuitively, one would think some of these ideas may apply to MANETs especially environments with a large number of nodes. However, I am curious to know how practical clustering would be in such a dynamic(link failures, node movement, congestion, etc) network. Specifically, how would one select a clusterhead? Assuming all nodes have the ability to move at anytime, the clusterhead could possibly move. Does the leader election algorithm elect the node that has been stationary the longest. What if this node has the least power? It may not be a good choice? There would seem to be many other issues related to selecting(and reselecting) a clusterhead in a highly dynamic network such as a MANET. Your thoughts and feedback on the advantages/disadvantages surrounding these issues would be greatly appreciated. If this discussion has already taken place, please direct me to the-mail archives. Feel free to list any papers that compare hierarchical versus flat routing. Thanks for your time, D. Perkins From owner-manet@itd.nrl.navy.mil Mon Oct 30 20:19: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 SMTP id UAA14181 for ; Mon, 30 Oct 2000 20:19:47 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA00159 for manet-outgoing; Mon, 30 Oct 2000 18:32:31 -0500 (EST) 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 SAA00153; Mon, 30 Oct 2000 18:32:28 -0500 (EST) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id AC7821A032C; Mon, 30 Oct 2000 17:30:17 -0600 (CST) Received: from localhost (basagni@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id RAA04370; Mon, 30 Oct 2000 17:30:17 -0600 (CST) X-Authentication-Warning: apache.utdallas.edu: basagni owned process doing -bs Date: Mon, 30 Oct 2000 17:30:17 -0600 (CST) From: Stefano Basagni To: Joe Macker Cc: Dmitri Deshun Perkins , manet@itd.nrl.navy.mil Subject: Re: clustering In-Reply-To: <5.0.0.25.2.20001030163937.02e84400@pop.itd.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi Dmitri, here are my two cents ;-) which have a more computer science flavor. A generalization of the algorithms proposed in the 80s by Ephremides et al. and more recently by Mario Gerla e la sua banda ;-) (more than the 1995 paper I consider more informative a paper published in JSAC in 1997), has been considered in several papers scattered in several conferences. (See the bibtex entries below.) The generalization consists of assigning to each node a generic weight that can be computed in different way, that may change in time, etc. This weight is intended to express the suitability of a node for the role of clusterhead. The first papers on this subject aim at defining a) clustering properties that have to be satisfied given the specific characteristics of ad hoc nets, b) a distributed solution that minimize bandwidth usage and energy consumption at each node, c) a study of both the time and message complexity of this distributed solution. The approach in these papers is to determine in a distributed way a maximal weight independent set (the clusterheads) which is also dominant (every non-clusterhead node has a clusterhead as neighbor). Of course this is not the only possible approach, and there have been several approaches basically based on not considering the independence of the clusterheads and build a "spine," i.e., a (minimum) connected dominating set (the clusterheads). There is also an "hybrid" solution in which the indipendence property is partially released in the sense that up to 1 < k <= n clusterheads are allowed to be neighbors. In our approach (the former), it is clear that the determination of the weight is very important. This is quite an open issue. The only paper I know about it is being published in the proceedings of Globecom 2000, and the authors are Sajal K. Das, Damla Turgut et. al. Finally, I have heard rumors that in a book soon-to-be released by Wiley's and Sons ("Ad hoc networks," C. Perkins Ed.) there is a whole chapter about clustering for ad hoc nets (Martha Steenstrup is the author). Hope this helps, cheers, St. @article{1, author = "Basagni, S.", title = "A Distributed Algorithm for Finding a Maximal Weighted Independent Set in Wireless Networks", journal = "Telecommunication Systems, Special Issue on Mobile Computing and Wireless Networks", editor = "Stojmenovic, I.", year = 2000, note = "To appear" } @inproceedings{2, author = "Basagni, S.", title = "Distributed and Mobility-Adaptive Clustering for Multimedia Support in Multi-Hop Wireless Networks", booktitle = "Proceedings of the IEEE $50$th International Vehicular Technology Conference, VTC 1999-Fall", volume = 2, pages = "889--893", address = "Amsterdam, The Netherlands", month = "September 19--22", year = 1999 } @inproceedings{3, author = "Basagni, S.", title = "Distributed Clustering for Ad Hoc Networks", booktitle = "Proceedings of the 1999 International Symposium on Parallel Architectures, Algorithms, and Networks ({I-SPAN'99})", editor = "Zomaya, A. Y. and Hsu, D. F. and Ibarra, O. and Origuchi, S. and Nassimi, D. and Palis, M.", publisher = "IEEE Computer Society", pages = "310--315", address = "Perth/Fremantle, Australia", month = "June 23--25", year = 1999 } -- Stefano Basagni, Ph.D. Assistant Professor of Computer Science Center for Advanced Telecommunications Systems and Services (CATSS) The University of Texas at Dallas MS EC31 Richardson, TX 75080 Tel. 972 883 2216 ~~~ Fax 972 883 6204 ~~~ E-mail: basagni@utdallas.edu From owner-manet@itd.nrl.navy.mil Tue Oct 31 05:59: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 SMTP id FAA22617 for ; Tue, 31 Oct 2000 05:59:02 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA09436 for manet-outgoing; Tue, 31 Oct 2000 04:08:37 -0500 (EST) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA09431 for ; Tue, 31 Oct 2000 04:08:35 -0500 (EST) Received: from oleane (dyn-1-1-204.Vin.dialup.oleane.fr [195.25.4.204]) by smtp4.cluster.oleane.net with SMTP id KAA53994 for ; Tue, 31 Oct 2000 10:06:21 +0100 (CET) Message-ID: <002701c0431a$47252040$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: The first MPLS exhibition Date: Tue, 31 Oct 2000 10:09:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C04322.A8A664C0" 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_0024_01C04322.A8A664C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The first MPLS exhibition ever organized will take place during MPLS = World in Paris.=20 Three exhibiting options are available. Please visit: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_0024_01C04322.A8A664C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The first MPLS exhibition ever = organized will take=20 place during MPLS World
in Paris.
Three exhibiting options are=20 available.
Please visit:
http://www.upperside.f= r/congress/exhi.htm
 
------=_NextPart_000_0024_01C04322.A8A664C0--