From delta@net.ie.niigata-u.ac.jp Mon Jun 1 19:51:11 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6C43A6B57 for ; Mon, 1 Jun 2009 19:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btYYbiScTmso for ; Mon, 1 Jun 2009 19:51:11 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id BBFD73A6802 for ; Mon, 1 Jun 2009 19:51:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0A4844541FA; Tue, 2 Jun 2009 11:51:10 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id 6B0C64541FA; Tue, 2 Jun 2009 11:51:02 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 10AC711DE8; Tue, 2 Jun 2009 11:51:00 +0900 (JST) Message-ID: <4A249276.2060908@net.ie.niigata-u.ac.jp> Date: Tue, 02 Jun 2009 11:46:14 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><25c114b90905260445y54449801v4398e1bdf51ad07b@mail.gmail.com> <4A1E6110.7030305@net.ie.niigata-u.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 02:51:11 -0000 Dear Christopher Dearlove, thank you for your comments, replies inline... >> An LLN only occurs on the failure of a unicast data packet to be >> forwarded from one node to the next. >> > > Note that this is not a specification of OLSRv2. OLSRv2 specifies > that if you have link layer information, you can use it. But it > doesn't specify anything about whether to use unicast data packets > or not. Our implementation of OLSR, which uses link layer information > is not specified as you have it above. > Thank you, perhaps this needs to be further explained and clarified in our draft. > I would like to know if this is simply the work previously presented > at the IETF. That work was demonstrably flawed - as could be seen > from the stationary case, and discussions then indicated a poor LLN > approach. > I know there was some mention of this previously at the IETF but am not aware to what was "demonstrably flawed." I think the LLN approach we used is very effective and our results show this. As an example, it would be more particularly useful in comparison to full path metrics where there is greater mobility and the path metric approach takes some time to build up and so may not always be accurate. This LLN approach is simple and is able to respond quickly to changes in the network, however, does create transient routing loops. When used with a Loop Detection (looping packet detection) technique with an action to respond to the loop, it is able to support greater loads and packet delivery rate whilst maintaining small end-to-end delay, showing potential to be very useful under various conditions. Thanks for your comments. Cheers, Lee -S- Lee Speakman, Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan From nagarjuna@cse.iitkgp.ernet.in Tue Jun 2 01:46:07 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DCD3A6E49 for ; Tue, 2 Jun 2009 01:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.404 X-Spam-Level: **** X-Spam-Status: No, score=4.404 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, J_CHICKENPOX_56=0.6, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, RELAY_IS_203=0.994, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoiHpmK+DW9z for ; Tue, 2 Jun 2009 01:46:07 -0700 (PDT) Received: from khatrel.iitkgp.ernet.in (unknown [203.110.243.253]) by core3.amsl.com (Postfix) with ESMTP id 7F3063A6DDC for ; Tue, 2 Jun 2009 01:46:04 -0700 (PDT) Received: from scm.iitkgp.ernet.in ([10.3.100.120]) by khatrel.iitkgp.ernet.in (8.14.3/8.14.3/Debian-4) with ESMTP id n528kVLs029427 for ; Tue, 2 Jun 2009 14:16:32 +0530 X-CAGWS-MailFrom: X-CAGWS-FileID: smtp_4A24E5A6_5E28_0000.inb X-CAGWS-Info: 30:[ 10:93 ]:manet@ietf.org # Received: from 144.16.206.206 (144.16.206.206) by scm.iitkgp.ernet.in (10.3.100.120); Tue, 02 Jun 2009 14:11:10 +0530 Received: from mymail.iitkgp.ernet.in (localhost.localdomain [127.0.0.1]) by mymail.iitkgp.ernet.in (8.13.1/8.13.1) with ESMTP id n528VheA011739 for ; Tue, 2 Jun 2009 14:01:43 +0530 Received: (from apache@localhost) by mymail.iitkgp.ernet.in (8.13.1/8.13.1/Submit) id n528VYGM011738; Tue, 2 Jun 2009 14:01:34 +0530 Message-Id: <200906020831.n528VYGM011738@mymail.iitkgp.ernet.in> X-Authentication-Warning: mymail.iitkgp.ernet.in: apache set sender to using -f To: From: Date: Tue, 2 Jun 2009 14:01:34 +0530 Errors-To: X-Priority: User-Agent: NOCC MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: [manet] =?utf-8?q?Broadcasting_in_GloMoSim?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: nagarjuna@cse.iitkgp.ernet.in List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 08:46:07 -0000 Hi, I m Nagarjuna.I m doin my Masters in Computer Science at Indian Institute of Technology, Kharagpur. My thesis is on VANET security. I m doin a simulation using GloMoSim software. I want to broadcast messages/packets to all nodes(within the transmission range). As far as I ve understood the GloMoSim s/w, traffic generation must be specified in app.conf file. But all the traffic generators listed in the GloMoSim manual like CBR, HTTP, Telnet, FTP require the source and destination node address. Please tell me how to broadcasst packets using GloMoSim. Thanks ___________________________________ IIT Kharagpur, http://www.iitkgp.ac.in From delta@net.ie.niigata-u.ac.jp Tue Jun 2 03:50:06 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AD63A6D32 for ; Tue, 2 Jun 2009 03:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwEn8kfcvtHc for ; Tue, 2 Jun 2009 03:50:05 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id 98BD03A6D3A for ; Tue, 2 Jun 2009 03:49:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EE39C4541F5; Tue, 2 Jun 2009 19:49:07 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id E5A644541D0; Tue, 2 Jun 2009 19:49:02 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 40F4911DE8; Tue, 2 Jun 2009 19:48:58 +0900 (JST) Message-ID: <4A25027E.3070503@net.ie.niigata-u.ac.jp> Date: Tue, 02 Jun 2009 19:44:14 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: jacquet References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> In-Reply-To: <4A1FE2EC.5060406@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 10:50:06 -0000 Dear Philippe, We have done simulations in which we issue a new "Instant Hello" on the loss of link, however, even though it is beneficial in some ways and solves ~10% of the loops under certain conditions, we find that it increases the overhead to an extent that it roughly counters the gain from dissolving ~10% of the loops. We find that for ~90% of the loops the loop comes about from an incoherent perception of the network between adjacent nodes through their Topology Sets and so cannot be fixes with an Instant Hello. The effect of an LLN cutting a link that is unphysical is often to cause a change such that a loop appears not only one link away (an adjacent link), but also two links or more away from the lost link. The likelihood of a loop appearing reduces as the node density (and link-density) is increased. We haven't performed the second (a TC with a new MPR selector set number). Thanks for your comments. Cheers, Lee -S- Lee Speakman, Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan jacquet さんは書きました: > Seems interesting. I remember that with old RFC 3626 we assumed that a > node which detects a link failure, either by LLN or by hello loss, > should immediately issue: > 1. a hello with lost indication > 2. a TC with a new MPR selector set number since one MPR selector is > down. > A loop could only happen after the loss detection, during the jitter > time of notification hellos and/or TC's. Here I don't see how the LLN > option could bring a significant distortion. > > Philippe > From teco@inf-net.nl Wed Jun 3 04:44:55 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8BF3A6934 for ; Wed, 3 Jun 2009 04:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqHRksrcx0bm for ; Wed, 3 Jun 2009 04:44:54 -0700 (PDT) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 3D2EA3A6856 for ; Wed, 3 Jun 2009 04:44:53 -0700 (PDT) Received: (qmail 1132 invoked from network); 3 Jun 2009 13:44:51 +0200 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 3 Jun 2009 13:44:51 +0200 From: "Teco Boot" To: "'Lee Speakman'" , "'jacquet'" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> In-Reply-To: <4A25027E.3070503@net.ie.niigata-u.ac.jp> Date: Wed, 3 Jun 2009 13:44:23 +0200 Message-ID: <002501c9e440$b60376d0$220a6470$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnjcCvzXCM9A4baT+WZ3AGH7jQ+KQAzogZg Content-Language: nl Cc: 'mase' , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:44:55 -0000 Hi, |jacquet wrote: |> Seems interesting. I remember that with old RFC 3626 we assumed that a |> node which detects a link failure, either by LLN or by hello loss, |> should immediately issue: |> 1. a hello with lost indication |> 2. a TC with a new MPR selector set number since one MPR selector is |> down. It is a MAY, not a SHOULD. Hello (RFC3626 page 43): - An additional HELLO message MAY be sent when the MPR set changes. TC (RFC3626 page 45): A node MAY transmit additional TC-messages to increase its reactiveness to link failures. We can think of changing it to SHOULD. |> A loop could only happen after the loss detection, during the jitter |> time of notification hellos and/or TC's. Here I don't see how the LLN |> option could bring a significant distortion. When link metrics are used, the goal is forecasting the failure and circumvent problems. This needs smooth increase of metric values. Not that easy, because we need hysteresis also. And the question sending TCs immediately or not. I experienced mail delivery problems on May 29, for mails from [Dearlove, Jacquet, Rogge]. Teco. From Chris.Dearlove@baesystems.com Wed Jun 3 01:33:53 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2CC3A6A99 for ; Wed, 3 Jun 2009 01:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDpBzD2Z74EH for ; Wed, 3 Jun 2009 01:33:52 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id E93123A6BB6 for ; Wed, 3 Jun 2009 01:33:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,297,1241391600"; d="scan'208";a="5307120" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 03 Jun 2009 09:33:44 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n538XicB004701; Wed, 3 Jun 2009 09:33:44 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jun 2009 09:33:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 3 Jun 2009 09:33:39 +0100 Message-ID: In-Reply-To: <200906021855.n52ItuOh017577@boreas.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Editorial Errata Reported] RFC5444 (1790) thread-index: Acnjs+XiAs0hoRbgSZ+5pnV1m2GByAAcgiUg References: <200906021855.n52ItuOh017577@boreas.isi.edu> From: "Dearlove, Christopher (UK)" To: "RFC Errata System" , , , , , , , X-OriginalArrivalTime: 03 Jun 2009 08:33:44.0180 (UTC) FILETIME=[017F9B40:01C9E426] X-Mailman-Approved-At: Wed, 03 Jun 2009 08:11:30 -0700 Cc: manet@ietf.org, yannick.lacharite@crc.gc.ca Subject: Re: [manet] [Editorial Errata Reported] RFC5444 (1790) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:33:53 -0000 This should be accepted. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: 02 June 2009 19:56 To: T.Clausen@computer.org; Dearlove, Christopher (UK); jdean@itd.nrl.navy.mil; Cedric.Adjih@inria.fr; rcallon@juniper.net; adrian.farrel@huawei.com; macker@itd.nrl.navy.mil; ian.chakeres@gmail.com Cc: yannick.lacharite@crc.gc.ca; manet@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC5444 (1790) The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=1790 -------------------------------------- Type: Editorial Reported by: Yannick Lacharit Section: Appendix E Original Text ------------- [...] The packet contains a single message with length 54 octets. ^ [...] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | ^ Corrected Text -------------- [...] The packet contains a single message with length 55 octets. ^ [...] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1| Orig Addr | ^ Notes ----- Correction to the message length, which is 55 instead of 54. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From web-usrn@ISI.EDU Tue Jun 2 12:00:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230AE28C124 for ; Tue, 2 Jun 2009 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22qSpclZtx3N for ; Tue, 2 Jun 2009 12:00:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 79E0428C1FF for ; Tue, 2 Jun 2009 11:58:52 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n52ItxRf017609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Jun 2009 11:55:59 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n52ItuOh017577; Tue, 2 Jun 2009 11:55:56 -0700 (PDT) Date: Tue, 2 Jun 2009 11:55:56 -0700 (PDT) Message-Id: <200906021855.n52ItuOh017577@boreas.isi.edu> To: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr, rcallon@juniper.net, adrian.farrel@huawei.com, macker@itd.nrl.navy.mil, ian.chakeres@gmail.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Wed, 03 Jun 2009 08:11:41 -0700 Cc: rfc-editor@rfc-editor.org, manet@ietf.org, yannick.lacharite@crc.gc.ca Subject: [manet] [Editorial Errata Reported] RFC5444 (1790) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:00:05 -0000 The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=1790 -------------------------------------- Type: Editorial Reported by: Yannick Lacharit Section: Appendix E Original Text ------------- [...] The packet contains a single message with length 54 octets. ^ [...] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | ^ Corrected Text -------------- [...] The packet contains a single message with length 55 octets. ^ [...] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1| Orig Addr | ^ Notes ----- Correction to the message length, which is 55 instead of 54. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From delta@net.ie.niigata-u.ac.jp Wed Jun 3 19:00:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A623A693E for ; Wed, 3 Jun 2009 19:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2IbQsCBFje2 for ; Wed, 3 Jun 2009 19:00:03 -0700 (PDT) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id 887B03A6844 for ; Wed, 3 Jun 2009 19:00:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0EB1C290006; Thu, 4 Jun 2009 10:59:55 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with ESMTP id 3F452290006; Thu, 4 Jun 2009 10:59:54 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 2AA4111DEA; Thu, 4 Jun 2009 10:59:52 +0900 (JST) Message-ID: <4A272979.3000809@net.ie.niigata-u.ac.jp> Date: Thu, 04 Jun 2009 10:55:05 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Henning Rogge References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <200905291554.08786.hrogge@googlemail.com> In-Reply-To: <200905291554.08786.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 02:00:04 -0000 Dear Henning Rogge, I used Qualnet 4.0 for simulations with an updated nOLSRv2 implementation. We used a data rate of 2Mbps at 2.4GHz with a two-ray propagation pathloss model. The other radio model simulation parameters are shown below. Cheers, Lee -S- Lee Speakman, Research Center for Natural Hazard and Disaster Recovery, Niigata, Japan Henning Rogge $B$5$s$O=q$-$^$7$?(B: > Am Dienstag 26 Mai 2009 11:24:50 schrieb Lee Speakman: > >> Dear MANET WG members, >> >> we at Niigata University have implemented and tested the OLSRv2 protocol >> according to a recent draft. >> >> The implementation has been put to use in simulation and real world >> physical nodes. >> >> Simulation under various scenarios indicate that the use of LLN (Link >> Layer Notification) leads to a looping packets becoming a problem in the >> network. >> >> In larger networks where the TTL or Hop Count cannot be kept small, and >> particularly at higher loads, the problem of looping packets become more >> significant. >> > I would be interested in the radio model you used for your simulations. > > Henning Rogge > > Qualnet (4.0) config part: PROPAGATION-CHANNEL-FREQUENCY 2.4e9 PROPAGATION-LIMIT -111.0 PROPAGATION-PATHLOSS-MODEL TWO-RAY PROPAGATION-SHADOWING-MODEL CONSTANT PROPAGATION-SHADOWING-MEAN 4.0 PROPAGATION-FADING-MODEL NONE PHY-MODEL PHY802.11b PHY-RX-MODEL PHY802.11b PHY-LISTENABLE-CHANNEL-MASK 1 PHY-LISTENING-CHANNEL-MASK 1 PHY-TEMPERATURE 290 PHY-NOISE-FACTOR 7.0 PHY802.11-AUTO-RATE-FALLBACK NO PHY802.11-DATA-RATE 2000000 PHY802.11-DATA-RATE-FOR-BROADCAST 2000000 PHY802.11b-TX-POWER--1MBPS 15.0 PHY802.11b-TX-POWER--2MBPS 15.0 PHY802.11b-TX-POWER--6MBPS 15.0 PHY802.11b-TX-POWER-11MBPS 15.0 PHY802.11b-RX-SENSITIVITY--1MBPS -93.0 PHY802.11b-RX-SENSITIVITY--2MBPS -89.0 PHY802.11b-RX-SENSITIVITY--6MBPS -87.0 PHY802.11b-RX-SENSITIVITY-11MBPS -83.0 ANTENNA-GAIN 0.0 ANTENNA-EFFICIENCY 0.8 ANTENNA-MISMATCH-LOSS 0.3 ANTENNA-CABLE-LOSS 0.0 ANTENNA-CONNECTION-LOSS 0.2 ANTENNA-HEIGHT 1.5 ANTENNA-MODEL OMNIDIRECTIONAL From Rogge@fgan.de Thu Jun 4 00:14:15 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E0A3A6904 for ; Thu, 4 Jun 2009 00:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ5mgv0jDVfL for ; Thu, 4 Jun 2009 00:14:15 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id D4C603A68D7 for ; Thu, 4 Jun 2009 00:14:14 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MC79S-0008H1-8R; Thu, 04 Jun 2009 09:14:14 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1MC79R-0001OU-UD; Thu, 04 Jun 2009 09:14:13 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 09:14:13 +0200 From: Henning Rogge To: manet@ietf.org Date: Thu, 4 Jun 2009 09:14:07 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28.1; KDE/4.2.2; i686; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <200905291554.08786.hrogge@googlemail.com> <4A272979.3000809@net.ie.niigata-u.ac.jp> In-Reply-To: <4A272979.3000809@net.ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2140946.H46Ck3MJF5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906040914.13358.rogge@fgan.de> X-OriginalArrivalTime: 04 Jun 2009 07:14:13.0860 (UTC) FILETIME=[10944A40:01C9E4E4] X-Virus-Scanned: yes (ClamAV 0.95.1/9419/Thu Jun 4 04:47:46 2009) by mailguard.fgan.de X-Scan-Signature: fe63cde163a9813fbfae5d53d3252e1e Cc: mase , Lee Speakman Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 07:14:16 -0000 --nextPart2140946.H46Ck3MJF5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Thursday 04 June 2009 03:55:05 schrieb Lee Speakman: > Dear Henning Rogge, > > I used Qualnet 4.0 for simulations with an updated nOLSRv2 implementation. > > We used a data rate of 2Mbps at 2.4GHz with a two-ray propagation > pathloss model. The other radio model simulation parameters are shown > below. Does you real world testbed support the results of the Qualnet simulations = ? I=20 ask because simulations with two-ray ground radio propagation and no=20 smallscale fading are sometimes not reproducable in real world hardware. =2D-=20 Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart2140946.H46Ck3MJF5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkondD8ACgkQRIfGfFXsz+Bt8QCfQrVgeXmKo82TzxhHJ5aGm56L WakAn25cpMY3nQP1nHlYJarTn2xJrywh =LfGC -----END PGP SIGNATURE----- --nextPart2140946.H46Ck3MJF5-- From philippe.jacquet@inria.fr Thu Jun 4 06:37:53 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3C43A6927 for ; Thu, 4 Jun 2009 06:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fekxhsHT5wO for ; Thu, 4 Jun 2009 06:37:53 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 722703A6A68 for ; Thu, 4 Jun 2009 06:37:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,305,1241388000"; d="scan'208";a="30508331" Received: from 75-147-71-222-philadelphia.hfc.comcastbusiness.net (HELO mp-r8.local) ([75.147.71.222]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2009 15:36:58 +0200 Message-ID: <4A27CFB4.6080701@inria.fr> Date: Thu, 04 Jun 2009 15:44:20 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Teco Boot References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> In-Reply-To: <002501c9e440$b60376d0$220a6470$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'mase' , 'Lee Speakman' , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:37:53 -0000 It was a "may" because LLN was very experimental. I remember it is very difficult to implement in real networks. It was very unclear if one must consider a neighbor off just because of a single data packet failure. Sometimes it is more convenient to consider the link on. Anyhow the underlying idea behind LLN considerations should be that instant hello and instant TC should be sent within same timing and not be considered as to be transmitted independently. This said, I still not understand why in this simulation, instant hellos (without TC) triggered by hello loss or by LLN lead to so different loop situations. Philippe Teco Boot a crit : > Hi, > > |jacquet wrote: > |> Seems interesting. I remember that with old RFC 3626 we assumed that a > |> node which detects a link failure, either by LLN or by hello loss, > |> should immediately issue: > |> 1. a hello with lost indication > |> 2. a TC with a new MPR selector set number since one MPR selector is > |> down. > > It is a MAY, not a SHOULD. > Hello (RFC3626 page 43): > - An additional HELLO message MAY be sent when the MPR set > changes. > TC (RFC3626 page 45): > A node MAY transmit additional TC-messages to increase its > reactiveness to link failures. > > We can think of changing it to SHOULD. > > > |> A loop could only happen after the loss detection, during the jitter > |> time of notification hellos and/or TC's. Here I don't see how the LLN > |> option could bring a significant distortion. > > When link metrics are used, the goal is forecasting the > failure and circumvent problems. This needs smooth increase > of metric values. Not that easy, because we need hysteresis > also. And the question sending TCs immediately or not. > > > I experienced mail delivery problems on May 29, for mails > from [Dearlove, Jacquet, Rogge]. > > > Teco. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > From delta@net.ie.niigata-u.ac.jp Thu Jun 4 23:57:08 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0FC28C0DB for ; Thu, 4 Jun 2009 23:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajUUg4PNIzH4 for ; Thu, 4 Jun 2009 23:57:07 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id 6BFD73A6AD0 for ; Thu, 4 Jun 2009 23:57:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 287E145422E; Fri, 5 Jun 2009 15:57:05 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id 31AC6454230; Fri, 5 Jun 2009 15:57:02 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 9E78C11DEA; Fri, 5 Jun 2009 15:56:58 +0900 (JST) Message-ID: <4A28C09D.2080301@net.ie.niigata-u.ac.jp> Date: Fri, 05 Jun 2009 15:52:13 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Henning Rogge References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <200905291554.08786.hrogge@googlemail.com> <4A272979.3000809@net.ie.niigata-u.ac.jp> <200906040914.13358.rogge@fgan.de> In-Reply-To: <200906040914.13358.rogge@fgan.de> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 06:57:08 -0000 Henning Rogge $B$5$s$O=q$-$^$7$?(B: > Am Thursday 04 June 2009 03:55:05 schrieb Lee Speakman: > >> Dear Henning Rogge, >> >> I used Qualnet 4.0 for simulations with an updated nOLSRv2 implementation. >> >> We used a data rate of 2Mbps at 2.4GHz with a two-ray propagation >> pathloss model. The other radio model simulation parameters are shown >> below. >> > Does you real world testbed support the results of the Qualnet simulations ? I > ask because simulations with two-ray ground radio propagation and no > smallscale fading are sometimes not reproducable in real world hardware. > > Thanks for the information regarding fading. We have detected loops occurring in the testbed with our implementation nOLSRv2 with hop count metric but have not yet compared the nature of the response (of looping packets) with respect to varying the load. We observed this by looking at various packet traces from the nodes which also have a limited collection capability, particularly as loops occur at higher loads. The testbed isn't yet capable of detecting looping packets in real time in node so it is hard to confirm everything we have observed with the same nOLSRv2 code under simulation (Qualnet 4.0). Regarding the fading in the simulation model, I understand that the physical model can have an effect on the frame being sent and thus the success or failure of a broadcast or unicast packet being received by any particular node, and thus whether an LLN is generated at any particular moment and whether a link remains or is lost (from successive non-received Hellos or an LLN in node). But as to my understanding, fading would only have an effect on the quantity of loops under any particular environment rather than the fact that they occur or not in that particular environment. As far as I can see the reason they occur (or not) would be the coherence or lack thereof between the perceived topologies of the network in each of the nodes and the nature in which they select the next hop from the information available to them at that time. So having fading may change the quantity of observed loops compared to having no fading, but I think they would still occur in some quantity if they were occurring before. So I can see the physical model may have an effect on this quantity of loops (if they occur) but not whether they occur or not. I'd very much like to know your opinion on this. We will consider fading further in our simulations and see what we get. We are very grateful for your input. Thanks, Lee -S- From teco@inf-net.nl Fri Jun 5 00:13:57 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CC43A69CE for ; Fri, 5 Jun 2009 00:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNUgf+5V6Uuv for ; Fri, 5 Jun 2009 00:13:56 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 810173A6910 for ; Fri, 5 Jun 2009 00:13:40 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Jun 2009 09:13:42 +0200 From: "Teco Boot" To: "'jacquet'" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> In-Reply-To: <4A27CFB4.6080701@inria.fr> Date: Fri, 5 Jun 2009 09:13:44 +0200 Message-ID: <000001c9e5ad$297dc120$7c794360$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnlGa+cr1uTXq8/RRWYc/k081DRqwAin04A Content-Language: nl X-OriginalArrivalTime: 05 Jun 2009 07:13:42.0450 (UTC) FILETIME=[28454120:01C9E5AD] Cc: 'mase' , 'Lee Speakman' , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 07:13:57 -0000 I think LLN for declaring a link to a neighbor as dead is a different=20 topic as instant hello / instant TC. LLN (or any other link layer feedback) is used for a better interface between link layer and network layer. There are mechanisms for detection of "link-up", "link-down" or "link-status" (data rate, signal quality etc.). My test results show clearly that immediate response on link layer feedback makes the network unstable. Dampening and hysteresis are to be used. When a link state change is detected, we have the question what to do with it. A straightforward approach is accepting this change locally=20 (update routing table) and schedule a message for notifying other=20 routers. Now we have the question when to send out this message,=20 either direct, delayed with jitter or waiting for interval timer.=20 During the delay, the routing tables of routers may be out of sync and routing loops may occur. So an immediate send out would shorten the interval that routing tables are out of sync. But this has a=20 drawback, that the load of the routing protocol becomes bursty,=20 also by the fact that the change in topology could affect many=20 routers. Moreover, the bust by itself could influence the=20 topology. This can result in a sort of melt-down of the MANET.=20 It would be nice if we have practical guidance for configuring the best setting for dampening / hysteresis and instant messages for fast routing table synchronization while not overloading the MANET. Philippe, you mentioned instant hellos and instant TCs should be sent out with same timing (same packet). Is this important? If so, I think it needs to be specified. Instant hellos would have local load, so costs are lower related to instant TCs. But do instant hellos solve the out-of-sync routing table problem? I can think of a mechanism where info in hello message is used for updating the topology set, declaring links from 1-hop neighbors to 2-hop neighbors as dead. Normally, we need TCs for this. OK, we can use instant TCs with hop-limit=20 for this. But originating TCs with hop-limit =3D 1 is not allowed=20 in OLSRv2. If one comes up with a more fundamental method circumventing loops, I am all ears! Teco. |-----Oorspronkelijk bericht----- |Van: jacquet [mailto:philippe.jacquet@inria.fr] |Verzonden: donderdag 4 juni 2009 15:44 |Aan: Teco Boot |CC: 'Lee Speakman'; 'mase'; manet@ietf.org |Onderwerp: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc |Networks (MANETs)" | |It was a "may" because LLN was very experimental. I remember it is very |difficult to implement in real networks. It was very unclear if one = must |consider a neighbor off just because of a single data packet failure. |Sometimes it is more convenient to consider the link on. | |Anyhow the underlying idea behind LLN considerations should be that |instant hello and instant TC should be sent within same timing and not |be considered as to be transmitted independently. | |This said, I still not understand why in this simulation, instant = hellos |(without TC) triggered by hello loss or by LLN lead to so different = loop |situations. | |Philippe | |Teco Boot a =E9crit : |> Hi, |> |> |jacquet wrote: |> |> Seems interesting. I remember that with old RFC 3626 we assumed |that a |> |> node which detects a link failure, either by LLN or by hello loss, |> |> should immediately issue: |> |> 1. a hello with lost indication |> |> 2. a TC with a new MPR selector set number since one MPR selector |is |> |> down. |> |> It is a MAY, not a SHOULD. |> Hello (RFC3626 page 43): |> - An additional HELLO message MAY be sent when the MPR set |> changes. |> TC (RFC3626 page 45): |> A node MAY transmit additional TC-messages to increase its |> reactiveness to link failures. |> |> We can think of changing it to SHOULD. |> |> |> |> A loop could only happen after the loss detection, during the |jitter |> |> time of notification hellos and/or TC's. Here I don't see how the |LLN |> |> option could bring a significant distortion. |> |> When link metrics are used, the goal is forecasting the |> failure and circumvent problems. This needs smooth increase |> of metric values. Not that easy, because we need hysteresis |> also. And the question sending TCs immediately or not. |> |> |> I experienced mail delivery problems on May 29, for mails |> from [Dearlove, Jacquet, Rogge]. |> |> |> Teco. |> |> |> |> _______________________________________________ |> manet mailing list |> manet@ietf.org |> https://www.ietf.org/mailman/listinfo/manet |> |> |> From delta@net.ie.niigata-u.ac.jp Fri Jun 5 02:52:06 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1793A6BFB for ; Fri, 5 Jun 2009 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiGyYVVq72Ec for ; Fri, 5 Jun 2009 02:52:06 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id C811D3A6BF0 for ; Fri, 5 Jun 2009 02:52:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5070A4F4254; Fri, 5 Jun 2009 18:52:07 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with ESMTP id 0A2E94F4252; Fri, 5 Jun 2009 18:52:01 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 8A1B211DEA; Fri, 5 Jun 2009 18:51:51 +0900 (JST) Message-ID: <4A28E99A.6050905@net.ie.niigata-u.ac.jp> Date: Fri, 05 Jun 2009 18:47:06 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: jacquet References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> In-Reply-To: <4A25027E.3070503@net.ie.niigata-u.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:52:07 -0000 Dear Philippe, in correction to my previous comment, we have actually performed the second - an "Instant TC" both separately and together with "Instant Hello" triggered on LLN. The "Instant Hello" and "Instant TC" was tried both instantly and with a fractional delay of the jitter that is used for the periodic control packets. For a variety of simulation environments we couldn't find good results from these methods, as the network was more overwhelmed by the broadcast packets triggered by the occurring LLNs than it benefited the routing mechanism. The biggest positive effect out of this research was the observation that "Instant Hello" was capable of dissolving a fraction (~10%) of the routing loops, although any gain being countered by its increased overhead as explained earlier. This is what led to our pursuit of why the majority of the loops remained which led us to find that ~90% of the loops are not over a link directly adjacent to the node in which the link break occurred and therefore cannot be solved by an Hello from that node. In our simulations, the LLN occurs only after the Link Layer (802.11b) has attempted to forward a unicast packet up to 4 or 7 times. If the sending Link Layer fails to receive a CTS, it will reattempt 7 times by new RTS (ShortRetryLimit) before a L2 notification, else it will reattempt to forward 4 times (LongRetryLimit) if it fails to receive an ACK. We have performed with and without RTS/CTS and with multiple network layer retries that are a multiple of this 4 or 7 times, but loops still exist, only in differing quantities. As it is much less likely to find looping packets where the best routes are just two or three hops, we aimed to have in our simulations cases where there are also longer multihop routes present between a given source-destination pair. With greater separation (and multi-hopped-ness) increases the likelihood that a looping packet will be observed. The likelihood of a loop appearing also increases as the load is increased. Cheers, Lee -S- Lee Speakman さんは書きました: > Dear Philippe, > > We have done simulations in which we issue a new "Instant Hello" on > the loss of link, however, even though it is beneficial in some ways > and solves ~10% of the loops under certain conditions, we find that it > increases the overhead to an extent that it roughly counters the gain > from dissolving ~10% of the loops. We find that for ~90% of the loops > the loop comes about from an incoherent perception of the network > between adjacent nodes through their Topology Sets and so cannot be > fixes with an Instant Hello. > The effect of an LLN cutting a link that is unphysical is often to > cause a change such that a loop appears not only one link away (an > adjacent link), but also two links or more away from the lost link. > > The likelihood of a loop appearing reduces as the node density (and > link-density) is increased. > > We haven't performed the second (a TC with a new MPR selector set > number). > > Thanks for your comments. > > > Cheers, > Lee -S- > > Lee Speakman, Research Center for Natural Hazard and Disaster > Recovery, Niigata, Japan > > > jacquet さんは書きました: >> Seems interesting. I remember that with old RFC 3626 we assumed that >> a node which detects a link failure, either by LLN or by hello loss, >> should immediately issue: >> 1. a hello with lost indication >> 2. a TC with a new MPR selector set number since one MPR selector is >> down. >> A loop could only happen after the loss detection, during the jitter >> time of notification hellos and/or TC's. Here I don't see how the LLN >> option could bring a significant distortion. >> >> Philippe >> > From philippe.jacquet@inria.fr Fri Jun 5 05:17:23 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A6B3A6D48 for ; Fri, 5 Jun 2009 05:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REJ+SPazQyn2 for ; Fri, 5 Jun 2009 05:17:22 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 065293A6C10 for ; Fri, 5 Jun 2009 05:17:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,311,1241388000"; d="scan'208";a="27409120" Received: from guest-rocq-135200.inria.fr ([128.93.135.200]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2009 14:17:22 +0200 Message-ID: <4A290E90.3090701@inria.fr> Date: Fri, 05 Jun 2009 14:24:48 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Teco Boot References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> In-Reply-To: <000001c9e5ad$297dc120$7c794360$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'mase' , 'Lee Speakman' , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:17:23 -0000 Teco Boot a crit : > Philippe, you mentioned instant hellos and instant TCs should be > sent out with same timing (same packet). Is this important? > If so, I think it needs to be specified. > > Instant hellos would have local load, so costs are lower related > to instant TCs. But do instant hellos solve the out-of-sync routing > table problem? I can think of a mechanism where info in hello > message is used for updating the topology set, declaring > links from 1-hop neighbors to 2-hop neighbors as dead. Normally, > we need TCs for this. OK, we can use instant TCs with hop-limit > for this. But originating TCs with hop-limit = 1 is not allowed > in OLSRv2. > I guess we should have unlimited TC. As Lee said the loop are not necessarily adjacent to the broken link. If you consider the line ...-1--2--3--4--5--6--7--8--9-... with a flow from node 1 to node 9. Assume link 7-8 breaks. Instant hello will inform node 6 about the breakage of link 7->8. Therefore a loop will occur either between node 6 and node 7 or between node 5 and node 6, if the later perform 2-hop topology update after the instant hello. Of course assuming another path exists before node 1 toward 9. The TC with TTL=x will bring the breakage information down to node 7-x and create a loop there. Thus if x=infinity, there should not be any persistent loop in an ideal world. The TC plays the role of informing about the loss of the link 7->8 to the part of the network below node 7, and is more pertinent than the instant hello regarding the routing of the flow we consider. > If one comes up with a more fundamental method circumventing loops, > I am all ears! > > Teco. > > From philippe.jacquet@inria.fr Fri Jun 5 05:45:30 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904153A69E4 for ; Fri, 5 Jun 2009 05:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm0IaHyistlM for ; Fri, 5 Jun 2009 05:45:29 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 22E6A3A687C for ; Fri, 5 Jun 2009 05:45:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,311,1241388000"; d="scan'208";a="27411361" Received: from guest-rocq-135200.inria.fr ([128.93.135.200]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2009 14:45:31 +0200 Message-ID: <4A29152A.4010007@inria.fr> Date: Fri, 05 Jun 2009 14:52:58 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Lee Speakman References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> In-Reply-To: <4A28E99A.6050905@net.ie.niigata-u.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:45:30 -0000 But the instant TC should reach the nodes far from the broken link, the instant hello not. I would be surprised that the transmission of a single instant hello and of a single instant TC bring any significant increase of overhead, at least it should be negligible compared to the loop overhead (data packets being repeated 255 times). But maybe the loops congest the network and prevent the instant TC or the instant hello to be actually received. This is a plausible explanation since you say somewhere that the loops also create other link failures, and then other loops. One remedy would be that at detection of link failure a node just cancels the route, then drop packets while sending the new TC, and AFTER do new route calculation. Philippe Lee Speakman a écrit : > Dear Philippe, > > in correction to my previous comment, we have actually performed the > second - an "Instant TC" both separately and together with "Instant > Hello" triggered on LLN. > > The "Instant Hello" and "Instant TC" was tried both instantly and with > a fractional delay of the jitter that is used for the periodic control > packets. > > For a variety of simulation environments we couldn't find good results > from these methods, as the network was more overwhelmed by the > broadcast packets triggered by the occurring LLNs than it benefited > the routing mechanism. > > The biggest positive effect out of this research was the observation > that "Instant Hello" was capable of dissolving a fraction (~10%) of > the routing loops, although any gain being countered by its increased > overhead as explained earlier. > > This is what led to our pursuit of why the majority of the loops > remained which led us to find that ~90% of the loops are not over a > link directly adjacent to the node in which the link break occurred > and therefore cannot be solved by an Hello from that node. > > > In our simulations, the LLN occurs only after the Link Layer (802.11b) > has attempted to forward a unicast packet up to 4 or 7 times. If the > sending Link Layer fails to receive a CTS, it will reattempt 7 times > by new RTS (ShortRetryLimit) before a L2 notification, else it will > reattempt to forward 4 times (LongRetryLimit) if it fails to receive > an ACK. > > We have performed with and without RTS/CTS and with multiple network > layer retries that are a multiple of this 4 or 7 times, but loops > still exist, only in differing quantities. > > > As it is much less likely to find looping packets where the best > routes are just two or three hops, we aimed to have in our simulations > cases where there are also longer multihop routes present between a > given source-destination pair. With greater separation (and > multi-hopped-ness) increases the likelihood that a looping packet will > be observed. > > The likelihood of a loop appearing also increases as the load is > increased. > > > Cheers, > Lee -S- > > > Lee Speakman さんは書きました: >> Dear Philippe, >> >> We have done simulations in which we issue a new "Instant Hello" on >> the loss of link, however, even though it is beneficial in some ways >> and solves ~10% of the loops under certain conditions, we find that >> it increases the overhead to an extent that it roughly counters the >> gain from dissolving ~10% of the loops. We find that for ~90% of the >> loops the loop comes about from an incoherent perception of the >> network between adjacent nodes through their Topology Sets and so >> cannot be fixes with an Instant Hello. >> The effect of an LLN cutting a link that is unphysical is often to >> cause a change such that a loop appears not only one link away (an >> adjacent link), but also two links or more away from the lost link. >> >> The likelihood of a loop appearing reduces as the node density (and >> link-density) is increased. >> >> We haven't performed the second (a TC with a new MPR selector set >> number). >> >> Thanks for your comments. >> >> >> Cheers, >> Lee -S- >> >> Lee Speakman, Research Center for Natural Hazard and Disaster >> Recovery, Niigata, Japan >> >> >> jacquet さんは書きました: >>> Seems interesting. I remember that with old RFC 3626 we assumed that >>> a node which detects a link failure, either by LLN or by hello loss, >>> should immediately issue: >>> 1. a hello with lost indication >>> 2. a TC with a new MPR selector set number since one MPR selector is >>> down. >>> A loop could only happen after the loss detection, during the jitter >>> time of notification hellos and/or TC's. Here I don't see how the >>> LLN option could bring a significant distortion. >>> >>> Philippe >>> >> > > > From teco@inf-net.nl Fri Jun 5 06:09:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8413A6C20 for ; Fri, 5 Jun 2009 06:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab4v2VK7C+AB for ; Fri, 5 Jun 2009 06:09:10 -0700 (PDT) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 833993A6857 for ; Fri, 5 Jun 2009 06:09:09 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Jun 2009 15:09:11 +0200 From: "Teco Boot" To: "'jacquet'" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> In-Reply-To: <4A290E90.3090701@inria.fr> Date: Fri, 5 Jun 2009 15:09:12 +0200 Message-ID: <001d01c9e5de$d23467c0$769d3740$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnl17mEg4kjaOOzQtelZ+Ty3AZZfgAAWccQ Content-Language: nl X-OriginalArrivalTime: 05 Jun 2009 13:09:11.0083 (UTC) FILETIME=[D1205FB0:01C9E5DE] Cc: 'mase' , 'Lee Speakman' , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:09:10 -0000 |Teco Boot a =E9crit : |> Philippe, you mentioned instant hellos and instant TCs should be |> sent out with same timing (same packet). Is this important? |> If so, I think it needs to be specified. |> |> Instant hellos would have local load, so costs are lower related |> to instant TCs. But do instant hellos solve the out-of-sync routing |> table problem? I can think of a mechanism where info in hello |> message is used for updating the topology set, declaring |> links from 1-hop neighbors to 2-hop neighbors as dead. Normally, |> we need TCs for this. OK, we can use instant TCs with hop-limit |> for this. But originating TCs with hop-limit =3D 1 is not allowed |> in OLSRv2. |> | |I guess we should have unlimited TC. As Lee said the loop are not |necessarily adjacent to the broken link. If you consider the line | |...-1--2--3--4--5--6--7--8--9-... |with a flow from node 1 to node 9. | |Assume link 7-8 breaks. | |Instant hello will inform node 6 about the breakage of link 7->8. |Therefore a loop will occur either between node 6 and node 7 or between |node 5 and node 6, if the later perform 2-hop topology update after = the |instant hello. Of course assuming another path exists before node 1 |toward 9. | |The TC with TTL=3Dx will bring the breakage information down to node = 7-x |and create a loop there. Thus if x=3Dinfinity, there should not be any |persistent loop in an ideal world. | |The TC plays the role of informing about the loss of the link 7->8 to |the part of the network below node 7, and is more pertinent than the |instant hello regarding the routing of the flow we consider. Yes, this is the explanation of having loops. And also an argument against the hop-limit feature. The instant hello is used for triggering a TC on the neighbor nodes and MPR selection only and doesn't help avoiding loops directly. = Correct? How to explain the 10% loop reduction by instant hellos, reported by Lee? Due to topology reduction mechanisms, where the node sending the instant hello was no longer MPR ???=20 My test results on looped packets showed micro-loops, with one router that detected the dead link. Mainly because I work with a limited set of routers and the diameter is up to 3 hops. Topology looks like: 1_____ | \___ | ____3 =20 2____/ When links to 3 fades away (movement to right, obstacle between 1&2 and 3), the loop may occur. Both 1 and 2 know their link to 3 is=20 lost (e.g. signaled in same hello message from 3), but both assume the path via the other, nearby node is still alive, we have the loop. TCs (with hop-limit >=3D 1) solve the loop. We don't need widely spread TCs for it. Lee reports network meltdown due to overload of instant TCs. I have=20 seen similar behavior in another context. For this reason I say hysteresis and dampening is essential (a MUST). Teco. | |> If one comes up with a more fundamental method circumventing loops, |> I am all ears! |> |> Teco. |> |> From onelektra@gmx.net Fri Jun 5 06:10:40 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69023A6D4F for ; Fri, 5 Jun 2009 06:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Wby-09t+Fk for ; Fri, 5 Jun 2009 06:10:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 359D63A6D44 for ; Fri, 5 Jun 2009 06:10:37 -0700 (PDT) Received: (qmail invoked by alias); 05 Jun 2009 13:10:39 -0000 Received: from brln-4dbc3631.pool.einsundeins.de (EHLO x.localnet) [77.188.54.49] by mail.gmx.net (mp057) with SMTP; 05 Jun 2009 15:10:39 +0200 X-Authenticated: #2746672 X-Provags-ID: V01U2FsdGVkX188uAc1uhA8IFaAucWlPM2YssVHyQA99I6z95LKPM zYlQrDcMq6wUjs From: Elektra Organization: open-mesh.net To: manet@ietf.org Date: Fri, 5 Jun 2009 15:10:38 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-11-generic; KDE/4.2.2; i686; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> In-Reply-To: <4A28E99A.6050905@net.ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906051510.39239.onelektra@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:10:40 -0000 Hello all! I'd dare to state that transient routing loops are normal in Olsr and other Link State protocols in a wireless environment with fluctuating link quality as long as TCs are communicated via broadcasts. (Using unicasts instead doesn't seem like a viable solution). Since the topology data base has to be synced amongst adjacent nodes via a lossy medium to avoid loops (up to 3 hops range I'd say) I have drawn and tested the following conclusions when hacking on RFC3626 for the Freifunk community mesh network in Berlin together with Tomas Lopatic and others in the years 2004 and 2005: - when we tested RFC3626 with participants of the Wizards of OS 3 conference the results were devastating in a ~25 node mesh - MPRs are contra-indicated if you want to avoid loops - the redundancy of multiple paths propagating TC information is desperately needed in a productive environment where payload saturates the links. Otherwise TC data bases get out of sync locally and things become very, very messy - MPRs don't help much in terms of scalability as long as every TC has a global TTL - RFC3626's hysteresis is a no-no - especially in combination with MPRs. MPRs are selected which frequently get kicked out by hysteresis - the problem of syncing TC information gets even worse & the protocol needs to negotiate the MPR set again. - A simple fish-eye algorithm worked much better in terms of scalability and allowed us to send TC updates more often than Hellos without suffocating our city wide mesh network of +400 nodes (mostly Linksys WRT54G) at the time. Hence TC updates were redundant which drastically mitigated the looping problem. Still under very high network load we had transient routing loops. This is still a issue. The mesh grew up to ~650 nodes in Berlin without problems - however we were pushing the CPU load to the limits before the code was optimized by the Olsr-ng project. - Minimum hop count metric optimizes packet loss, so the first thing we did was adding a metric based on ETX which communicates link quality data with every Hello message to single hop neighbors (LQ/NLQ) The experience of the Freifunk people with OLSR is described in more detail here: https://www.open-mesh.org/wiki/the-olsr-story Note that the document is summing up the experience until mid 2005. Our work was/is miserably documented to say the least. As an excuse I can say that we were focused on getting the mesh network usable for the community. The modifications are present in the Olsr implementation from olsr.org and can be switched on and off via the configuration file. Sample configurations come with the source code or can be found in the wiki pages of the wireless communities. I don't know any real-life network using the RFC3626 configuration in a productive environment. If you do know, let me know. However there are community networks in Tanzania, South Africa, India, Europe and elsewhere successfully using the Olsr daemon with the modifications. The modified Olsr daemon has been tested with up to 850 nodes in real life. It is working on low-end consumer APs running Openwrt with moderate CPU load thanks to the OLSR-NG project which has optimized the code after I ceased being active in the Olsr.org development. We have started a new community-driven mesh protocol development site in 2006 - open-mesh.net. The name of our current protocol project is BATMAN. Generation three of the algorithm is described in a document available here: http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00 A reviewer has claimed that the protocol allegedly would loop and consume too much CPU and battery power for a MANET protocol. We didn't bother to defend the draft because we have better use for our time. Please reprieve me from protocol discussion dogfights. Note that the document is referring to mark III of the algorithm, while we are currently working on designing mark 5. Implementations of mark 4 are available from our web site and as opkg-packages in Openwrt. A comparison between Batman mark IV (Batman-experimental branch) and the modified (!) OLSR daemon is available here: http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf BATMAN is a stigmeric approach which has proven to be loop-free and scalable. There are two competing implementations and change sets for OSI Layer 3 and one for "Layer 2.5". The largest real-life deployments have ~120 nodes - we are currently facing the difficulty to establish the new protocol in the community alongside the modified OLSR, because people hesitate to change their "running system" and known "standard" for something new. And some people love to defend "their" protocol. Germans tend to say: "The apple in the hand is better than the sparrow on the roof." No matter how cute the sparrow is ;-) Cheers, Elektra From makhalaf06@cit.just.edu.jo Fri Jun 5 23:02:55 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBFB3A6827 for ; Fri, 5 Jun 2009 23:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5PwbAe7YckU for ; Fri, 5 Jun 2009 23:02:55 -0700 (PDT) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by core3.amsl.com (Postfix) with ESMTP id 1CF603A680E for ; Fri, 5 Jun 2009 23:02:54 -0700 (PDT) Received: from BLU128-W16 ([65.55.116.7]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 23:02:57 -0700 Message-ID: X-Message-Routing: n04bYBGAex7XnKuNauZVISUM9unvI5JEWjTX8wcgLqy9Jgk6Nv7KHqYo8vIiiRGJn1DNqntfEgyGUWjvNJ9+rAYP33jSHH9o0u44gpZv1uD18xckuQvM/SZUBTQ5gj9+fFJ7R Content-Type: multipart/alternative; boundary="_2366b43b-e234-4622-a898-85dd1d707d39_" X-Originating-IP: [94.249.110.175] From: To: Date: Sat, 6 Jun 2009 09:02:58 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2009 06:02:57.0897 (UTC) FILETIME=[70BB9D90:01C9E66C] Subject: [manet] Hello packet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 06:02:55 -0000 --_2366b43b-e234-4622-a898-85dd1d707d39_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 8bit Hello there, I would like to ask about HELLO pakcet within AODV, is it optional or essential?, I mean if HELLO packet disabled inside AODV what will happen? Regards --_2366b43b-e234-4622-a898-85dd1d707d39_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: 8bit Hello there,
 
I would like to ask about HELLO pakcet within AODV, is it optional or essential?, I mean if HELLO packet disabled inside AODV what will happen?
 
Regards
--_2366b43b-e234-4622-a898-85dd1d707d39_-- From karun489@gmail.com Fri Jun 5 23:29:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D023A689D for ; Fri, 5 Jun 2009 23:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plQWMrDVcYvB for ; Fri, 5 Jun 2009 23:29:29 -0700 (PDT) Received: from mail-pz0-f177.google.com (mail-pz0-f177.google.com [209.85.222.177]) by core3.amsl.com (Postfix) with ESMTP id 1ABFC3A6827 for ; Fri, 5 Jun 2009 23:29:29 -0700 (PDT) Received: by pzk7 with SMTP id 7so124131pzk.29 for ; Fri, 05 Jun 2009 23:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jOn2potGl5Zsc9ebZplCqIJt8NndIPjjzvS18YrCL5Q=; b=dIa0l2ZwePA6wZ/o4pR7v1Y03piK3GHUAeKa5IsEbWlKCSnzBtQ6uujmzLp2g26piS 8M/tzmDGfne39jaZasDGPJ1Tu/mP7e3o+x2czIg87XlroaX1A54iYeuYNgrY8bpDByxF ZX/joeEj2rnow/8PftBffE9M55XDpFKTyg2SY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JVyKEqJVXPls9w5NhAGU5HFs0Ibl3ihpc8s5lYowj9leygQV7Z/nWz9zvirxGPXeM0 pc/l8xJNp3o5TUQENyfVFj83vtdmzMElTfBA5tet91PPmULIN57SlHvv2G7ItolHNUBa B164lLqqjK7OZ3vLP4X6RTZk/o0jvrHrqAYvg= MIME-Version: 1.0 Received: by 10.114.202.15 with SMTP id z15mr5779057waf.172.1244269769573; Fri, 05 Jun 2009 23:29:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Jun 2009 11:59:29 +0530 Message-ID: <4c7b9a910906052329g4275a16cp3525385876bae1b6@mail.gmail.com> From: karun kumar To: makhalaf06@cit.just.edu.jo Content-Type: multipart/alternative; boundary=00163649a73d9ec75e046ba821a6 Cc: manet@ietf.org Subject: Re: [manet] Hello packet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 06:29:30 -0000 --00163649a73d9ec75e046ba821a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If a node want to establish a route and send messages on demand fashion initially that node has to know is there any node with in its coverage range, So hello packet must broadcast periodically by every node in Manets. 2009/6/6 > Hello there, > > I would like to ask about HELLO pakcet within AODV, is it optional or > essential?, I mean if HELLO packet disabled inside AODV what will happen? > > Regards > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Karun Kumar M Ph:+91-9441628036 mkkumar@mtech.idrbt.ac.in karun489@gmail.com --00163649a73d9ec75e046ba821a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If a node want to establish a route and send messages on demand fashion ini= tially that node has to know is there any node with in its coverage range, = So hello packet must broadcast periodically by every node in Manets.

2009/6/6 <makhalaf06@cit.just.edu.jo>
Hello there,
=A0
I would like to ask about HELLO pakcet within A= ODV, is it optional or essential?, I mean if HELLO packet disabled inside A= ODV what will happen?
=A0
Regards

______________________= _________________________
manet mailing list
manet@ietf.org<= br>https://www.ietf.org/mailman/listinfo/manet




--
Karun Kumar M
Ph:+91-9441628036
mkkumar@mtech.idrbt.ac.in
karun489@gmail.com
--00163649a73d9ec75e046ba821a6-- From ogier@earthlink.net Sat Jun 6 00:10:37 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2063A6A17 for ; Sat, 6 Jun 2009 00:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK4q9v3XdcM4 for ; Sat, 6 Jun 2009 00:10:36 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 367C63A6827 for ; Sat, 6 Jun 2009 00:10:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=P7gEk6F0Y8B4ikMNbYIyksKvitxoiALlBMEKaOeiaYEtX5MJUG9X8lDgTr1CPZTa; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.223.246] by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MCq34-0000vv-I9; Sat, 06 Jun 2009 03:10:39 -0400 Message-ID: <4A2A16AA.5010107@earthlink.net> Date: Sat, 06 Jun 2009 00:11:38 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teco Boot References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> <001d01c9e5de$d23467c0$769d3740$@nl> In-Reply-To: <001d01c9e5de$d23467c0$769d3740$@nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dcb7fc5533b6bef8219922b12ea52bc2d8e2c372a62a04e1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.223.246 Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 07:10:37 -0000 Teco Boot wrote: >The instant hello is used for triggering a TC on the neighbor nodes >and MPR selection only and doesn't help avoiding loops directly. Correct? >How to explain the 10% loop reduction by instant hellos, reported by >Lee? Due to topology reduction mechanisms, where the node sending >the instant hello was no longer MPR ??? > > Here is one possible explanation. Letting X -> Y -> Z be the first two hops of a calculated path, it is possible that Y is not an MPR of Z, since the topology graph can use 2-hop neighbor info, and MPRs will not always cover all 2-hop neighbors due to topology changes. (In fact, the above path could be used even if there is another path X -> W -> Z in which W is an MPR of Z.) In this case, Y -> Z is not advertised in a TC message, so X knows about this link only from hellos. Therefore, if Y sends an instant hello when Y -> Z fails, this could avoid a loop between X and Y (if there is another path from X to Z). Richard P.S. Philippe described a similar example, but did not mention that an instant hello avoids a loop only if the failed link was not advertised in a TC message. From teco@inf-net.nl Sat Jun 6 07:06:39 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D013A6A4D for ; Sat, 6 Jun 2009 07:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd+Kpwq+w6zf for ; Sat, 6 Jun 2009 07:06:38 -0700 (PDT) Received: from CPSMTPM-EML110.kpnxchange.com (Cpsmtpm-eml110.kpnxchange.com [195.121.3.14]) by core3.amsl.com (Postfix) with ESMTP id 5A3AC3A684B for ; Sat, 6 Jun 2009 07:06:37 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 6 Jun 2009 16:06:36 +0200 From: "Teco Boot" To: "'Richard Ogier'" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> <001d01c9e5de$d23467c0$769d3740$@nl> <4A2A16AA.5010107@earthlink.net> In-Reply-To: <4A2A16AA.5010107@earthlink.net> Date: Sat, 6 Jun 2009 16:06:39 +0200 Message-ID: <006a01c9e6b0$0333aa80$099aff80$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnmdgrjAeox8v/UQxypKw6PCFYB/wANtpIQ Content-Language: nl X-OriginalArrivalTime: 06 Jun 2009 14:06:36.0769 (UTC) FILETIME=[01541510:01C9E6B0] Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 14:06:39 -0000 Hi Richard, |-----Oorspronkelijk bericht----- |Van: Richard Ogier [mailto:ogier@earthlink.net] |Verzonden: zaterdag 6 juni 2009 9:12 |Aan: Teco Boot |CC: manet@ietf.org |Onderwerp: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc |Networks (MANETs)" | | Teco Boot wrote: | |>The instant hello is used for triggering a TC on the neighbor nodes |>and MPR selection only and doesn't help avoiding loops directly. |Correct? |>How to explain the 10% loop reduction by instant hellos, reported by |>Lee? Due to topology reduction mechanisms, where the node sending |>the instant hello was no longer MPR ??? |> |> | |Here is one possible explanation. |Letting X -> Y -> Z be the first two hops of a calculated path, it is |possible that Y is not an MPR of Z, since the topology graph can use |2-hop neighbor info, and MPRs will not always cover all 2-hop neighbors |due to topology changes. I think the MPR set of Z will always cover all known 2-hop neighbors via symmetric links. But yes, due to delay in flooding, others might have other, outdated info. I am not sure this is the explanation. |(In fact, the above path could be used even if there is another |path X -> W -> Z in which W is an MPR of Z.) Using the OLSRv2 Appendix C. Algorithm, topology tuples are selected before 2-hop neighbor tuples. When the algorithm is updated for validating a routing tuple if R_dist = 2, checking the 2-Hop set, the instant hello would have effect. Update Appendix C ?? Teco. |In this case, Y -> Z is not advertised in a TC message, so X knows |about this link only from hellos. |Therefore, if Y sends an instant hello when Y -> Z fails, this could |avoid a loop between X and Y (if there is another path from X to Z). | |Richard | |P.S. Philippe described a similar example, but did not mention that |an instant hello avoids a loop only if the failed link was not |advertised in a TC message. From ogier@earthlink.net Sat Jun 6 09:04:09 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164143A6CE7 for ; Sat, 6 Jun 2009 09:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKiYYedvpWl9 for ; Sat, 6 Jun 2009 09:04:08 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id EE6B33A6CDB for ; Sat, 6 Jun 2009 09:04:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jVOXaJJ3q4MDWJSPQzlXZkHvfBYeYMZEN67h/ClveWH/Sx1bhkzwMvia7ReKXjiF; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.216.200] by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MCyNO-0002VL-9c; Sat, 06 Jun 2009 12:04:11 -0400 Message-ID: <4A2A93B8.9060204@earthlink.net> Date: Sat, 06 Jun 2009 09:05:12 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teco Boot References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> <001d01c9e5de$d23467c0$769d3740$@nl> <4A2A16AA.5010107@earthlink.net> <006a01c9e6b0$0333aa80$099aff80$@nl> In-Reply-To: <006a01c9e6b0$0333aa80$099aff80$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dcb7fc5533b6bef83cfebe246bf1f93f2f5c9149264e5022350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.216.200 Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 16:04:09 -0000 Teco Boot wrote: >Hi Richard, > >|-----Oorspronkelijk bericht----- >|Van: Richard Ogier [mailto:ogier@earthlink.net] >|Verzonden: zaterdag 6 juni 2009 9:12 >|Aan: Teco Boot >|CC: manet@ietf.org >|Onderwerp: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc >|Networks (MANETs)" >| >| Teco Boot wrote: >| >|>The instant hello is used for triggering a TC on the neighbor nodes >|>and MPR selection only and doesn't help avoiding loops directly. >|Correct? >|>How to explain the 10% loop reduction by instant hellos, reported by >|>Lee? Due to topology reduction mechanisms, where the node sending >|>the instant hello was no longer MPR ??? >|> >|> >| >|Here is one possible explanation. >|Letting X -> Y -> Z be the first two hops of a calculated path, it is >|possible that Y is not an MPR of Z, since the topology graph can use >|2-hop neighbor info, and MPRs will not always cover all 2-hop neighbors >|due to topology changes. > >I think the MPR set of Z will always cover all known 2-hop neighbors >via symmetric links. But yes, due to delay in flooding, others might >have other, outdated info. I am not sure this is the explanation. > > I'm not sure either. I'm just saying it is one possibility. For example, if Z selected W to be an MPR that covers X, and then W -> Z fails, then it could be a few seconds before Z learns of this failure (via hellos) and selects Y as MPR, and could be several seconds before X is finally informed that Y -> Z is advertised in a TC. > >|(In fact, the above path could be used even if there is another >|path X -> W -> Z in which W is an MPR of Z.) > >Using the OLSRv2 Appendix C. Algorithm, topology tuples are selected >before 2-hop neighbor tuples. > > OK, but this algorithm is not required, and I don't know if Lee used it. Also, note that this can't always be done if metrics are used. > >When the algorithm is updated for validating a routing tuple if >R_dist = 2, checking the 2-Hop set, the instant hello would have >effect. >Update Appendix C ?? > > I'm not sure what you mean. Maybe you mean that if a received hello indicates that Y -> Z failed, then that link should not be allowed even if Y -> Z is represented by a topology tuple. In other words, a topology tuple for Y -> Z, where Y is a neighbor, is valid only if Y -> Z is also in the 2-Hop set. This might help. Richard > >Teco. > > >|In this case, Y -> Z is not advertised in a TC message, so X knows >|about this link only from hellos. >|Therefore, if Y sends an instant hello when Y -> Z fails, this could >|avoid a loop between X and Y (if there is another path from X to Z). >| >|Richard >| >|P.S. Philippe described a similar example, but did not mention that >|an instant hello avoids a loop only if the failed link was not >|advertised in a TC message. > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet > > > From ogier@earthlink.net Sat Jun 6 10:57:21 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797533A6DAD for ; Sat, 6 Jun 2009 10:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC3VwJuHu6nM for ; Sat, 6 Jun 2009 10:57:20 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 86BEA3A6D98 for ; Sat, 6 Jun 2009 10:57:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nvnFYvRUPRfhBLdR4bmNSGinvnHrS+/cEObRDV9uMANp8vLOEPLROSjL9ocduQFN; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.221.192] by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MD08x-0004gu-Fo; Sat, 06 Jun 2009 13:57:24 -0400 Message-ID: <4A2AAE42.8040200@earthlink.net> Date: Sat, 06 Jun 2009 10:58:26 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teco Boot References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> <001d01c9e5de$d23467c0$769d3740$@nl> <4A2A16AA.5010107@earthlink.net> <006a01c9e6b0$0333aa80$099aff80$@nl> In-Reply-To: <006a01c9e6b0$0333aa80$099aff80$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dcb7fc5533b6bef85957c43c84ae458513d047e7751daadd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.221.192 Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 17:57:21 -0000 Teco Boot wrote: >I think the MPR set of Z will always cover all known 2-hop neighbors >via symmetric links. > Although not my main point, I will show that the above is not true. X / \ Y W \ / Z Assume Z selects W as its only MPR. Assume the link between X and W fails. (It is possible that X detects the failure before W, but this is not necessary for the example.) Assuming no instant hellos (or even if there are instant hellos, they are not reliable), it can be a few seconds before Z knows about the link failure. During this time, X is still a known 2-hop neighbor but is not covered by an MPR, although Z *thinks* it is. Of course, when X detects the failure, it will update its route to go through Y, even though Y is not is not an MPR of Z (but we agree on that). Richard From teco@inf-net.nl Sun Jun 7 00:05:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769393A6A43 for ; Sun, 7 Jun 2009 00:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS5tTmfYNEl8 for ; Sun, 7 Jun 2009 00:05:31 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id 8A4F03A6A2E for ; Sun, 7 Jun 2009 00:05:30 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sun, 7 Jun 2009 09:05:34 +0200 From: "Teco Boot" To: "'Richard Ogier'" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> <001d01c9e5de$d23467c0$769d3740$@nl> <4A2A16AA.5010107@earthlink.net> <006a01c9e6b0$0333aa80$099aff80$@nl> <4A2A93B8.9060204@earthlink.net> In-Reply-To: <4A2A93B8.9060204@earthlink.net> Date: Sun, 7 Jun 2009 09:05:38 +0200 Message-ID: <008801c9e73e$5c868c40$1593a4c0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnmwJQfYyL+G6hhSkWc4igJH3GfcAAfaA9A Content-Language: nl X-OriginalArrivalTime: 07 Jun 2009 07:05:34.0402 (UTC) FILETIME=[5A328A20:01C9E73E] Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 07:05:32 -0000 |>When the algorithm is updated for validating a routing tuple if |>R_dist = 2, checking the 2-Hop set, the instant hello would have |>effect. |>Update Appendix C ?? |> |I'm not sure what you mean. Maybe you mean that if a received hello |indicates that Y -> Z failed, then that link should not be allowed even |if Y -> Z is represented by a topology tuple. In other words, a |topology tuple for Y -> Z, where Y is a neighbor, is valid only if |Y -> Z is also in the 2-Hop set. This might help. Yes, this is my proposal. Teco. From teco@inf-net.nl Sun Jun 7 00:12:26 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8013A6A2E for ; Sun, 7 Jun 2009 00:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0tTmZGxvB4s for ; Sun, 7 Jun 2009 00:12:25 -0700 (PDT) Received: from CPSMTPM-EML103.kpnxchange.com (cpsmtpm-eml103.kpnxchange.com [195.121.3.7]) by core3.amsl.com (Postfix) with ESMTP id 164B73A67DB for ; Sun, 7 Jun 2009 00:12:24 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML103.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sun, 7 Jun 2009 09:12:28 +0200 From: "Teco Boot" To: "'Richard Ogier'" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> <4A290E90.3090701@inria.fr> <001d01c9e5de$d23467c0$769d3740$@nl> <4A2A16AA.5010107@earthlink.net> <006a01c9e6b0$0333aa80$099aff80$@nl> <4A2AAE42.8040200@earthlink.net> In-Reply-To: <4A2AAE42.8040200@earthlink.net> Date: Sun, 7 Jun 2009 09:12:32 +0200 Message-ID: <008901c9e73f$5367b070$fa371150$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnm0GPg2Tn8g0CISZKznjNURRxEBAAbkGPA Content-Language: nl X-OriginalArrivalTime: 07 Jun 2009 07:12:28.0687 (UTC) FILETIME=[512169F0:01C9E73F] Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 07:12:26 -0000 |-----Oorspronkelijk bericht----- |Van: Richard Ogier [mailto:ogier@earthlink.net] |Verzonden: zaterdag 6 juni 2009 19:58 |Aan: Teco Boot |CC: manet@ietf.org |Onderwerp: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc |Networks (MANETs)" | |Teco Boot wrote: | |>I think the MPR set of Z will always cover all known 2-hop neighbors |>via symmetric links. |> | |Although not my main point, I will show that the above is not true. | X | / \ |Y W | \ / | Z |Assume Z selects W as its only MPR. |Assume the link between X and W fails. (It is possible that X detects |the failure before W, but this is not necessary for the example.) |Assuming no instant hellos (or even if there are instant hellos, |they are not reliable), it can be a few seconds before Z knows |about the link failure. During this time, X is still a known 2-hop |neighbor but is not covered by an MPR, although Z *thinks* it is. | |Of course, when X detects the failure, it will update its route |to go through Y, even though Y is not is not an MPR of Z (but |we agree on that). Agreed. My text after the quotation: >>> But yes, due to delay in flooding, others might >>> have other, outdated info. Maybe "due to delay of detecting and flooding" and not only flooding. Our main point is loops have to do with out-of-sync Network Topology Graph and not with LLN. Teco. From hrogge@googlemail.com Sun Jun 7 00:24:37 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E413A697D for ; Sun, 7 Jun 2009 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bOjdIqhwMYZ for ; Sun, 7 Jun 2009 00:24:36 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 97EE33A6971 for ; Sun, 7 Jun 2009 00:24:35 -0700 (PDT) Received: by ewy6 with SMTP id 6so3318924ewy.37 for ; Sun, 07 Jun 2009 00:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:message-id :content-type:content-transfer-encoding; bh=EnoDGYC1GRYbCBpbo4ipCInJ4iQO4ljxQoteM3vjYV0=; b=PojUSHrJ1MLyzX6tXMjPB6xM5UHtQL5mtqJ0VXbtWh17G57Vfrb9C4rn1/xamVtaOa /LjDi8k+Gw8oLQ1VBaxjDG+wFLk2giYlAvhYChIA2PajXaBzbqHPTNk3hCMUPdg/dIGQ 1+eh8eiX7K/KO6gzcsO7XaBDul/ViqN3whLUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :message-id:content-type:content-transfer-encoding; b=ROJNFFdtNiqMRULVisMf88OTuVf0yRewWd8rn32NiNRwiv1vgOvY66xH1fs1Kl4tqR JQ4Eda2RxX5ldmFVXVFgN3xG/800FWanprI8U2y0h5u8baN8JjBThw5ku1w/+xBV1RbN ZRgiKToIenR2Nq4JGoSnS714lYQKwBnnwCH1c= Received: by 10.216.71.205 with SMTP id r55mr1845969wed.56.1244359476595; Sun, 07 Jun 2009 00:24:36 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id m5sm265874gve.3.2009.06.07.00.24.35 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Jun 2009 00:24:35 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Sun, 7 Jun 2009 09:24:16 +0200 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; x86_64; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <200906051510.39239.onelektra@gmx.net> In-Reply-To: <200906051510.39239.onelektra@gmx.net> MIME-Version: 1.0 Message-Id: <200906070924.34271.hrogge@googlemail.com> Content-Type: multipart/signed; boundary="nextPart7410959.Ri5oe3JZ3I"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 07:24:37 -0000 --nextPart7410959.Ri5oe3JZ3I Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just as a comment, both Elektras and (mostly) mine experience with mesh net= =20 protocols were made on 802.11 hardware, so it should be applicable for most= =20 CSMA-CA networks, but not for TDMA networks. Am Freitag 05 Juni 2009 15:10:38 schrieb Elektra: > - MPRs are contra-indicated if you want to avoid loops - the redundancy of > multiple paths propagating TC information is desperately needed in a > productive environment where payload saturates the links. Otherwise TC da= ta > bases get out of sync locally and things become very, very messy Yes. I think MPRs can be useful in high density situations. If you have 30 one-h= op=20 neighbors on a market place, you might not want to flood through all of the= m. But in sparse mesh networks (especially in urban terrain which=20 restricts line of sight and limit broadcast redundancy) a strict MPR set=20 combined with packet loss can easily break the flooding propagation through= =20 the mesh, leading to inconsistent topology databases and routing loops. > - MPRs don't help much in terms of scalability as long as every TC has a > global TTL The effect on scalability of MPRs depends on the node density and on the si= ze=20 of the broadcast domains. In simulations and in dense networks without=20 obstacles MPRs can be even more effective than many fisheye implementations= =20 (the OLSR.org fisheye would not reduce the number of packets for flooding b= y=20 more than a factor of 16 for example, even on a hypotetical infinite networ= k). But 802.11 adhoc networks have problems with neighborhoods of 30-50 nodes. The usage of MPR sets can create problems by itself, especially the loss of= a=20 Hello can be bad for MPR flooding. Example: A node X has two neighbors (A and B), and A is it's MPR at the moment. Now node X want to switch to B as it's MPR and begin to send a Hello with t= he=20 corresponding MPR choice. If A receives the Hello but B does NOT receive it= no=20 node will forward the packages for X unter the Hello is correctly received = by=20 B. The "MPR desynchronization could be prevented if nodes signal their MPR=20 Selector Set in hello messages. This way nodes could be sure that a new MPR= =20 has acknowledged it's status before switching off the old MPRs. > - RFC3626's hysteresis is a no-no I don't agree with this, I think the "metric" (exponential aging=20 with an aging factor of 0.5) is the problem here. The OLSR RFC suggests usi= ng=20 the last 3 Hellos as a way to determine the quality of the link, which resu= lts=20 in a nearly random result. It might be interesting to test what happens wit= h=20 hysteresis and a very low aging factor (aging 0.1 and longer Hello timeouts= ),=20 but I think using a real routing metric with Hellos AND TCs is definitely a= =20 better choice. > especially in combination with MPRs. > MPRs are selected which frequently get kicked out by hysteresis - the > problem of syncing TC information gets even worse & the protocol needs to > negotiate the MPR set again. > > - A simple fish-eye algorithm worked much better in terms of scalability > and allowed us to send TC updates more often than Hellos without > suffocating our city wide mesh network of +400 nodes (mostly Linksys > WRT54G) at the time. Hence TC updates were redundant which drastically > mitigated the looping problem. Still under very high network load we had > transient routing loops. This is still a issue. The mesh grew up to ~650 > nodes in Berlin without problems - however we were pushing the CPU load to > the limits before the code was optimized by the Olsr-ng project. > > - Minimum hop count metric optimizes packet loss, so the first thing we d= id > was adding a metric based on ETX which communicates link quality data with > every Hello message to single hop neighbors (LQ/NLQ) Hopcount metric works well in simulations without smallscale fading. I don'= t=20 think it works well in real networks outside the laboratory. Henning Rogge --nextPart7410959.Ri5oe3JZ3I Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkorazIACgkQcenvcwAcHWe5YwCfYt9EMwQq7BAhDCtP6GFY2S9L fMAAn0rtiogA7l8YjpTtWsVmEfwG/NSF =PQwZ -----END PGP SIGNATURE----- --nextPart7410959.Ri5oe3JZ3I-- From Chris.Dearlove@baesystems.com Mon Jun 8 04:18:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFD43A6DFF for ; Mon, 8 Jun 2009 04:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK33a+0E9dOl for ; Mon, 8 Jun 2009 04:18:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D63E73A6DFA for ; Mon, 8 Jun 2009 04:18:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241391600"; d="scan'208";a="6089824" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 08 Jun 2009 12:18:08 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n58BI7v7018174; Mon, 8 Jun 2009 12:18:07 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 12:18:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Jun 2009 12:18:06 +0100 Message-ID: In-Reply-To: <000001c9e5ad$297dc120$7c794360$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile AdHoc Networks (MANETs)" thread-index: AcnlGa+cr1uTXq8/RRWYc/k081DRqwAin04AAKGBixA= References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp><002501c9e440$b60376d0$220a6470$@nl> <4A27CFB4.6080701@inria.fr> <000001c9e5ad$297dc120$7c794360$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "jacquet" X-OriginalArrivalTime: 08 Jun 2009 11:18:07.0545 (UTC) FILETIME=[CC966A90:01C9E82A] Cc: mase , Lee Speakman , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile AdHoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 11:18:04 -0000 > It would be nice if we have practical guidance for configuring the > best setting for dampening / hysteresis and instant messages for > fast routing table synchronization while not overloading the MANET. In OLSRv2 there are minimum intervals that do this job. (We - BAE Systems - actually first implemented these in OLSRv1.) The suggested setting for these is 1/4 of the standard (maximum) intervals. The ideal setting will of course depend on many factors (which is why it is a parameter) but we have found 1/4 to be a reasonable value in at least some scenarios. (See paper in the 1st OLSR Interop.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Jun 8 04:21:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937613A6B15 for ; Mon, 8 Jun 2009 04:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvjHTr4Pi58f for ; Mon, 8 Jun 2009 04:21:27 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id A09B13A6A75 for ; Mon, 8 Jun 2009 04:21:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241391600"; d="scan'208";a="6090625" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 08 Jun 2009 12:21:32 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n58BLWLh020325; Mon, 8 Jun 2009 12:21:32 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 12:21:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Jun 2009 12:21:31 +0100 Message-ID: In-Reply-To: <4A28E99A.6050905@net.ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: Acnlw1CqqyifpoBZQeClPtqnqOAOxgCZ4fMA References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr><4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> From: "Dearlove, Christopher (UK)" To: "Lee Speakman" , "jacquet" X-OriginalArrivalTime: 08 Jun 2009 11:21:32.0046 (UTC) FILETIME=[467ACAE0:01C9E82B] Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 11:21:29 -0000 > For a variety of simulation environments we couldn't find good results > from these methods, as the network was more overwhelmed by the broadcast > packets triggered by the occurring LLNs than it benefited the routing > mechanism. The LLN mechanism has a hysteresis function (two thresholds) so that you can avoid flapping the link state too often. If you are getting swamped then that suggests you should possibly reduce the frequency of LLN-induced link state changes, plus managing a maximum TC sending rate - which is why we have minimum intervals in OLSRv2. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Jun 8 04:28:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031A53A6E09 for ; Mon, 8 Jun 2009 04:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgMYrxI0sKkI for ; Mon, 8 Jun 2009 04:28:41 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 142C93A6E07 for ; Mon, 8 Jun 2009 04:28:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241391600"; d="scan'208";a="6092903" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 08 Jun 2009 12:28:46 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n58BSjjB024985; Mon, 8 Jun 2009 12:28:45 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 12:28:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Jun 2009 12:28:44 +0100 Message-ID: In-Reply-To: <200906051510.39239.onelektra@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad HocNetworks (MANETs)" thread-index: Acnl3xZ6kM3Qh/H0Qyy52NdezRmWFQCTGcbg References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><4A25027E.3070503@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp> <200906051510.39239.onelektra@gmx.net> From: "Dearlove, Christopher (UK)" To: "Elektra" , X-OriginalArrivalTime: 08 Jun 2009 11:28:45.0467 (UTC) FILETIME=[48D196B0:01C9E82C] Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad HocNetworks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 11:28:42 -0000 > RFC3626's hysteresis is a no-no Except for those of us who use it in practice successfully. But we set our thresholds carefully, and with a specific requirement - to avoid the 802.11 "grey zone" problem. We don't allow over-rapid link flapping, and regulate our update frequency. We use LLNs based on SNR, but that's not the only option. Like several features in OLSR (more in OLSRv2) it's a tool to be used with care. Yes, used badly it can make things worse. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Jun 8 05:25:54 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC243A6885 for ; Mon, 8 Jun 2009 05:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZGgPPT7lBnF for ; Mon, 8 Jun 2009 05:25:53 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0C7C63A679F for ; Mon, 8 Jun 2009 05:25:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,324,1241391600"; d="scan'208";a="6109658" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 08 Jun 2009 13:25:57 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n58CPv62029156; Mon, 8 Jun 2009 13:25:57 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jun 2009 13:25:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Jun 2009 13:25:56 +0100 Message-ID: In-Reply-To: <200906070924.34271.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad HocNetworks (MANETs)" thread-index: AcnnQQp4PcmVv/GARP2L92imoCa0IgA8KhpA References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp><200906051510.39239.onelektra@gmx.net> <200906070924.34271.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 08 Jun 2009 12:25:57.0436 (UTC) FILETIME=[466E7FC0:01C9E834] Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad HocNetworks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 12:25:54 -0000 Henning Rogge wrote: > Elektra wrote: >> RFC3626's hysteresis is a no-no > I don't agree with this, I think the "metric" (exponential aging > with an aging factor of 0.5) is the problem here. I wrote the following text, then revisited the above three lines, and in short I think Henning said in two lines what's taken me a lot more than two lines (though with details). I think the first problem is that there are a number of things, which in RFC 3626 are lumpted together as hysteresis. In OLSRv2 we've attempted to clearly separate them - Having a link quality mechanism that allows the exclusion of a link based other than on HELLO reception and timeout. - What to use for that link quality. RFC 3626 first suggests a direct value (e.g. from SNR) then an alternative (next point). - That alternative, which is a "leaky integrator" approach based on packet/HELLO reception/loss. - Hysteresis, which is avoiding "flapping" by memory. The specific mechanism is the two thresholds where when in the region between them, it depends on whether you were more recently good or bad. The first of these is essential, for 802.11 in particular (but not only) because of the "grey zone" problem (differing multicast/unicast characteristics). OLSRv2 is clearer (I think) that there are various options for the second point. SNR is one option with definite value. OLSRv2 does not include the third point. It notes you can use packet/HELLO reception/loss (and even the point to avoid double-counting). But it does not include the specific leaky integrator case (though it makes a reference to that a leaky integrator - not specified is a possibility as I recall). That would be because it is (a) over-specific, and (b) debatable. (And that's not addressing the issue of whether 0.5 is a suitable factor - in OLSRv2 that's not an issue, there is no suggested factor parameter or value.) Hysteresis of some form (and two thresholds is the simplest - and many mechanism can be mapped to it) is necessary. So if the objection to RFC 3626 in this area is specific to the leaky integrator based on HELLO/packet reception loss, OK. For a start it does nothing to solve the 802.11 grey zone problem. However the other three components (ability to exclude links, various possibilities exist, using hysteresis) is something needed. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From budden@nps.edu Mon Jun 8 08:47:17 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9CF3A6B9A for ; Mon, 8 Jun 2009 08:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ3Ht+JGG24n for ; Mon, 8 Jun 2009 08:47:17 -0700 (PDT) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 0ADDC3A68E5 for ; Mon, 8 Jun 2009 08:47:17 -0700 (PDT) Received: from [172.20.57.107] ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 08:47:21 -0700 From: Rex Buddenberg To: Henning Rogge In-Reply-To: <200906070924.34271.hrogge@googlemail.com> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <200906051510.39239.onelektra@gmx.net> <200906070924.34271.hrogge@googlemail.com> Content-Type: text/plain Date: Mon, 08 Jun 2009 08:48:42 -0700 Message-Id: <1244476122.20398.24871.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2009 15:47:21.0540 (UTC) FILETIME=[691E7040:01C9E850] Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 15:47:17 -0000 On Sun, 2009-06-07 at 09:24 +0200, Henning Rogge wrote: > Just as a comment, both Elektras and (mostly) mine experience with mesh net > protocols were made on 802.11 hardware, so it should be applicable for most > CSMA-CA networks, but not for TDMA networks. Henning, Has anyone worked the same problems with scheduling algorithms? What would be the effects if you were to substitute an IEEE 802.16 or TIA LTE network for an IEEE 802.11 one? A lot of the same problems that we see in meshing also negatively affect MAC issues -- too many stations with too much traffic and the MAC stalls. This means that contention MACs are wholly unsuitable for radio-WANs ... yet this is the territory that we need good MANET performance. -- Rex Buddenberg Naval Postgraduate School Code IS/Bu Monterey, Ca 93943 831/656-3576 From hrogge@googlemail.com Mon Jun 8 10:48:15 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2995B3A6A14 for ; Mon, 8 Jun 2009 10:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjWtx1-VxDm5 for ; Mon, 8 Jun 2009 10:48:14 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 15AD73A69D7 for ; Mon, 8 Jun 2009 10:48:11 -0700 (PDT) Received: by ewy6 with SMTP id 6so4382336ewy.37 for ; Mon, 08 Jun 2009 10:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=XmUaSRr87mSamob/pRuT+gUa5wDVjmPRctNg+8RKs88=; b=MgCHpNETkN40LEhG/N12jdfwb18RMkJyY43EEz6VAqn5i8R1QR4VfaZNpcEzJWljTN 0NlJ3Xpo3NIFv2jT2Ao/aY3HxxmTBkRKCRCzDmwAJFCz2QXsTd1JiZravujYr7xuf/Cr HgSVjSRweZ9qGpw0cy9SDiJQxWWzqiJ0f3auA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=gc903Y5tQztQ4noZMK/hselPB1AYUswS+UfAQdeDe6CQeQfI27/kXRouh7A1awsVMd iSMDjMTfjHXLSGrA9DlK4pJ8n7JjlYBTilmleRThsKfmz5oG0QWalgG3qfbS39RrVBot NFDJxbmxXPbWCYm+MfbfIyoyRO6LEhSunWKW8= Received: by 10.210.60.8 with SMTP id i8mr4443035eba.12.1244483290200; Mon, 08 Jun 2009 10:48:10 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 24sm266551eyx.3.2009.06.08.10.48.08 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 10:48:09 -0700 (PDT) From: Henning Rogge To: Rex Buddenberg Date: Mon, 8 Jun 2009 19:48:03 +0200 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; x86_64; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <200906070924.34271.hrogge@googlemail.com> <1244476122.20398.24871.camel@localhost.localdomain> In-Reply-To: <1244476122.20398.24871.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1694921.Zvn85JHJX0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906081948.08065.hrogge@googlemail.com> Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 17:48:15 -0000 --nextPart1694921.Zvn85JHJX0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag 08 Juni 2009 17:48:42 schrieb Rex Buddenberg: > On Sun, 2009-06-07 at 09:24 +0200, Henning Rogge wrote: > > Just as a comment, both Elektras and (mostly) mine experience with mesh > > net protocols were made on 802.11 hardware, so it should be applicable > > for most CSMA-CA networks, but not for TDMA networks. > > Has anyone worked the same problems with scheduling algorithms? What > would be the effects if you were to substitute an IEEE 802.16 or TIA LTE > network for an IEEE 802.11 one? The problem is that a "collision avoidance" wireless network will always ha= ve=20 problems like hidden stations... and a performance decrease at a certain=20 amount of traffic. > A lot of the same problems that we see in meshing also negatively affect > MAC issues -- too many stations with too much traffic and the MAC > stalls. This means that contention MACs are wholly unsuitable for > radio-WANs ... yet this is the territory that we need good MANET > performance. neither WLAN nor WIMAX were designed for large mesh networks. According to = my=20 knowledge WIMAX is not mesh capable between the client stations, only the b= ase=20 stations can create a full mesh. We are still waiting for a special "mesh net optimized" waveform for softwa= re=20 defined radios. ;) Henning --nextPart1694921.Zvn85JHJX0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkotTtgACgkQcenvcwAcHWcTxgCbBsup+gl4TM+F054cdaAdussd SwUAn3y3R/c3MTlPaW+3PkBXAj+2tQ3I =Wspu -----END PGP SIGNATURE----- --nextPart1694921.Zvn85JHJX0-- From nani1only@gmail.com Mon Jun 8 22:00:50 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2D228C12F for ; Mon, 8 Jun 2009 22:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjETYEFwCh5q for ; Mon, 8 Jun 2009 22:00:49 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 1682E28C132 for ; Mon, 8 Jun 2009 22:00:48 -0700 (PDT) Received: by ewy6 with SMTP id 6so4813563ewy.37 for ; Mon, 08 Jun 2009 22:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=wCjPw3UK4Qhsgj9NZ4jeMmceBhhOeNsKJbICQcT+/z4=; b=nbmmdILZ3/3KuoxC6aqQPYFswbCdJxXHgJWFCAPzo+R17mdjtj1a1OgGX4nK5AxoWy luV69EKXPgM6iOO8IhjbelOoMKXbLG7ygV/6HhE2PD292rjl3s07NOxI4B3roSzHW14y nz+SQOpipuGACArjcj+TvXa0pyMYe1BSH/88A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=m9A5WkUT/awQAGMCE/dWFgfcljYduiSZ1ozAetahtzqeX6KLovjYAZ65yEXX3ePNEY UNQQT2mLlXNms7+mlnDQWWYiu2Zm8023qbXJCCcidqsjpUjmc8pptzpUmN76ZGm2dtWJ Kd2mr0jbWKdaneHugIB5eZHkoE1JH7X8Oee/o= MIME-Version: 1.0 Received: by 10.216.54.72 with SMTP id h50mr2703910wec.28.1244523652281; Mon, 08 Jun 2009 22:00:52 -0700 (PDT) Date: Tue, 9 Jun 2009 10:30:52 +0530 Message-ID: From: rahimanuddin shaik To: manet@ietf.org Content-Type: multipart/alternative; boundary=001485f1d91235752d046be33e2a Subject: [manet] MAODV improvisation regarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 05:00:50 -0000 --001485f1d91235752d046be33e2a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, this is rahmanuddin from India. I am very much interested in Adhoc networks and want to do my project of graduation on the same lines. precisely pertaining to security issues in MAODV(Multicast ad hoc on demand vector routing protocol). Can anyone guide me referring some issues concerned and also useful links for the same. Thank you with regards Rahmanuddin --001485f1d91235752d046be33e2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
=A0=A0=A0=A0=A0=A0=A0=A0=A0 this is rahmanuddin from India. I am= very much interested in Adhoc networks and want to do my project of gradua= tion on the same lines.
precisely pertaining to security issues in MAODV= (Multicast ad hoc on demand vector routing protocol).
Can anyone guide me referring some issues concerned and also useful links f= or the same.
Thank you
with regards
Rahmanuddin
--001485f1d91235752d046be33e2a-- From delta@net.ie.niigata-u.ac.jp Wed Jun 10 03:20:35 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C934E3A6B0E for ; Wed, 10 Jun 2009 03:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8PYLpQ574id for ; Wed, 10 Jun 2009 03:20:35 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id D62563A68FE for ; Wed, 10 Jun 2009 03:20:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B4EF4F4225; Wed, 10 Jun 2009 19:20:40 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with ESMTP id E87A94F4232; Wed, 10 Jun 2009 19:20:30 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id D6B7B2EF4D; Wed, 10 Jun 2009 19:20:30 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKviWgLrgFz5; Wed, 10 Jun 2009 19:20:30 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id B69612EF4C; Wed, 10 Jun 2009 19:20:30 +0900 (JST) Message-ID: <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> Date: Wed, 10 Jun 2009 19:15:40 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr><4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mase , jacquet , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 10:20:35 -0000 >> For a variety of simulation environments we couldn't find good results >> > > >> from these methods, as the network was more overwhelmed by the >> > broadcast > >> packets triggered by the occurring LLNs than it benefited the routing >> mechanism. >> > > The LLN mechanism has a hysteresis function (two thresholds) so that you > can avoid flapping the link state too often. If you are getting swamped > then that suggests you should possibly reduce the frequency of > LLN-induced > link state changes, plus managing a maximum TC sending rate - which is > why > we have minimum intervals in OLSRv2. > > We have found that the use of a hysteresis on link formation based on the reception or lack thereof of Hello Packets can only go so far in providing for link stability, particularly in networks with node mobility, and the problem of looping packets still remains somewhat, even if only triggering a link-state change in OLSRv2 after multiple LLNs. The number of LLNs in-node required before making a change to the link-state in OLSRv2 then becomes a tradeoff between forwarding packets potentially to be dropped over an unphysical link and making a premature or unnecessary link-state change. We have generally found that having a link-state change triggered only after 2 or 3 LLNs is not much different in the result to having a link-state change triggered only after 1 LLN, except in the delay in the change of link-state, as each LLN requires up to 4 or 7 retries at the link layer. The tradeoff in the use of the hysteresis is also with responsiveness to the changes in the network against more stable links. It is certainly worth having minimum intervals though. Thanks. From Chris.Dearlove@baesystems.com Wed Jun 10 03:31:38 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854133A6BCC for ; Wed, 10 Jun 2009 03:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqfdYJ09pGpu for ; Wed, 10 Jun 2009 03:31:37 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 814663A6BAA for ; Wed, 10 Jun 2009 03:31:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,340,1241391600"; d="scan'208";a="6529912" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 10 Jun 2009 11:31:43 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n5AAVg3k028060; Wed, 10 Jun 2009 11:31:43 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jun 2009 11:31:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 10 Jun 2009 11:31:42 +0100 Message-ID: In-Reply-To: <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: AcnptSIdV7nP5WNAT/evioTSFo+JCwAACdow References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr><4A25027E.3070503@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> From: "Dearlove, Christopher (UK)" To: "Lee Speakman" X-OriginalArrivalTime: 10 Jun 2009 10:31:42.0910 (UTC) FILETIME=[A5A455E0:01C9E9B6] Cc: mase , jacquet , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 10:31:38 -0000 > We have found that the use of a hysteresis on link formation based on > the reception or lack thereof of Hello Packets can only go so far in > providing for link stability If we are specifically discussing link quality (hysteresis is a mechanism used to manage link quality changes) based purely on HELLO messages and/or packets (saying Hello Packets is misleading) then I'm not defending that. While of course 802.11 is not the only game in town, it is a case where link quality based purely on HELLO messages and packets is insufficient, but the link quality mechanism is useful, or even essential (at least without link metrics, and even with them it can be usefully used) - just base it on something else, from the link layer. > We have generally found that having a > link-state change triggered only after 2 or 3 LLNs What do you mean here by an LLN? Packets and HELLOs can be done at the network layer. Or do you mean real link layer information? I think it really is helpful to separate out the concepts of link quality, hysteresis, link layer notifications, and link loss. Then we can be clear if we are discussing the same thing. Unfortunately RFC 3626 doesn't do this as well as it should - I hope NHDP is better (but of course if we've missed anything, do let us know). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Rogge@fgan.de Wed Jun 10 04:57:06 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADDF3A6AB6 for ; Wed, 10 Jun 2009 04:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnrVkvsyM2nD for ; Wed, 10 Jun 2009 04:57:05 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id BA53F3A6833 for ; Wed, 10 Jun 2009 04:57:05 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MEMQX-000206-0p; Wed, 10 Jun 2009 13:57:09 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fgan.de with esmtp (Exim 4.69) (envelope-from ) id 1MEMQW-0007lX-MP; Wed, 10 Jun 2009 13:57:08 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 13:57:08 +0200 From: Henning Rogge To: manet@ietf.org Date: Wed, 10 Jun 2009 13:57:02 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.26-1-openvz-686; KDE/4.2.2; i686; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> In-Reply-To: <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3832782.9Vr4bgecFJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906101357.08209.rogge@fgan.de> X-OriginalArrivalTime: 10 Jun 2009 11:57:08.0432 (UTC) FILETIME=[94B0ED00:01C9E9C2] X-Virus-Scanned: yes (ClamAV 0.95.1/9449/Wed Jun 10 05:33:22 2009) by mailguard.fgan.de X-Scan-Signature: d42e7dfe6399d6e5eb526d1844917fec Cc: Lee Speakman Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 11:57:06 -0000 --nextPart3832782.9Vr4bgecFJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Wednesday 10 June 2009 12:15:40 schrieb Lee Speakman: > We have found that the use of a hysteresis on link formation based on > the reception or lack thereof of Hello Packets can only go so far in > providing for link stability, particularly in networks with node > mobility, This is no supprise, it's just a result of the statistic attributes of the= =20 link quality metric. Each loss/reception of a hello is just a binary event. Even if the loss propability of the link is totally stable, you need a lot= =20 more than 3 events (Hellos) to get a good approximation of the loss=20 probability. With a loss propability of 50% (as an example) 1/8 of the possible "3 Hello= =20 events" will tell OLSR it has a perfect link (no loss), 3/8 will see a "33%= =20 loss" link, 3/8 will see a "66% loss" link and 1/8 will get no Hello at all= =2E=20 The hysteresis could not prevent a static link like this to switch on/off. It's necessary to get better data (signal strength and other layer 2=20 measurements) or more data (integrate over a longer time) for a working=20 hysteresis. =2D-=20 Henning Rogge ************************************************* Diplom Informatiker Henning Rogge =46orschungsgesellschaft f=FCr Angewandte Naturwissenschaften e. V. (FGAN)=20 Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 =46ax: 0049 (0)228 9435-685 E-Mail: rogge@fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.=20 Joachim Ender (Stellv.) --nextPart3832782.9Vr4bgecFJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkovn44ACgkQRIfGfFXsz+AUiwCeJm7++uN4YT8AByBAg00SYy6V umIAoJeI1T/EqU2cr1Jyu5xNI2eyy5VQ =PWL+ -----END PGP SIGNATURE----- --nextPart3832782.9Vr4bgecFJ-- From delta@net.ie.niigata-u.ac.jp Thu Jun 11 03:08:23 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8963A6BFD for ; Thu, 11 Jun 2009 03:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qocy56t79CdF for ; Thu, 11 Jun 2009 03:08:23 -0700 (PDT) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id A84333A69EF for ; Thu, 11 Jun 2009 03:08:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 807D1290226; Thu, 11 Jun 2009 19:08:29 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with ESMTP id 1CB14290201; Thu, 11 Jun 2009 19:08:29 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id C2E1F2EF4D; Thu, 11 Jun 2009 19:08:28 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z8pvHnlFrwS; Thu, 11 Jun 2009 19:08:28 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id A57622EF4C; Thu, 11 Jun 2009 19:08:28 +0900 (JST) Message-ID: <4A30D67A.7050702@net.ie.niigata-u.ac.jp> Date: Thu, 11 Jun 2009 19:03:38 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: jacquet References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> In-Reply-To: <4A29152A.4010007@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:08:23 -0000 > But the instant TC should reach the nodes far from the broken link, > the instant hello not. > > I would be surprised that the transmission of a single instant hello > and of a single instant TC bring any significant increase of overhead, > at least it should be negligible compared to the loop overhead (data > packets being repeated 255 times). But maybe the loops congest the > network and prevent the instant TC or the instant hello to be actually > received. This is a plausible explanation since you say somewhere that > the loops also create other link failures, and then other loops. We did not examine the Instant TC in detail, but we certainly observed the effect of the Instant Hello not being well received in the adjacent nodes. We increased the chance of this being received by scheduling one of more Instant Hellos on a trigger event - either an LLN or a Loop Detection - although at the cost of increasing the overhead. We could increase the chance that the loops would be dissolved up to a limit (~10%) by using more Instant Hello broadcasts, therefore potentially providing a gain, but the overhead from the broadcasts canceled all such gains. Yup. Once loops are formed, even though transiently, the surrounding network is effectively blocked, or particularly has significantly reduced chance to medium access, and in the neighboring flows packets are dropped, and are perceived as link failures, leading to new longer routes being selected to route the packets in those flows, this in turn leads to the likelihood of more effective load in the network and the likelihood that more loops will form. In our simulations we have a TTL of 63, rather than 255 > > One remedy would be that at detection of link failure a node just > cancels the route, then drop packets while sending the new TC, and > AFTER do new route calculation. > I'm not sure I know what you mean, but to clarify, you mean also for that node to wait for receiving a new TC before doing a new route calculation, and in the meantime just drop packets? Wouldn't this result in high loss for at least a short time? Cheers, Lee -S- From ulrich@herberg.name Thu Jun 11 03:14:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735263A6B6C for ; Thu, 11 Jun 2009 03:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sl0enSSFXN7 for ; Thu, 11 Jun 2009 03:14:04 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 7A8313A6BFD for ; Thu, 11 Jun 2009 03:14:04 -0700 (PDT) Received: by fxm9 with SMTP id 9so1406905fxm.37 for ; Thu, 11 Jun 2009 03:14:08 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.118.207 with SMTP id w15mr2343725bkq.97.1244715248362; Thu, 11 Jun 2009 03:14:08 -0700 (PDT) In-Reply-To: <4A30D67A.7050702@net.ie.niigata-u.ac.jp> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> Date: Thu, 11 Jun 2009 12:14:08 +0200 X-Google-Sender-Auth: ed01beccd21c416e Message-ID: <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> From: Ulrich Herberg To: Lee Speakman Content-Type: multipart/alternative; boundary=0016e6dd8e7439b83f046c0fda9e Cc: mase , jacquet , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:14:05 -0000 --0016e6dd8e7439b83f046c0fda9e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, On Thu, Jun 11, 2009 at 12:03 PM, Lee Speakman wrote: > [...] > We did not examine the Instant TC in detail, but we certainly observed the > effect of the Instant Hello not being well received in the adjacent nodes. > We increased the chance of this being received by scheduling one of more > Instant Hellos on a trigger event - either an LLN or a Loop Detection - > although at the cost of increasing the overhead. > [...] Can you explain why the Instant Hello is not well received? What often are they lost? Do you use jitter for the instant Hello? Do you respect minimum HELLO intervals in your implementation? Cheers, Ulrich --0016e6dd8e7439b83f046c0fda9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Thu, Jun 11, 2009 at 12:03 PM, Lee= Speakman <delta@net.ie.niigata-u.ac.jp> wrote:
[...]
We did not examine the Instant TC in detail, but we certainly observed the = effect of the Instant Hello not being well received in the adjacent nodes. = =A0We increased the chance of this being received by scheduling one of more= Instant Hellos on a trigger event - either an LLN or a Loop Detection - al= though at the cost of increasing the overhead.
[...]

Can you explain why the Instant Hello is not we= ll received? What often are they lost? Do you use jitter for the instant He= llo? Do you respect minimum HELLO intervals in your implementation?

Cheers,
Ulrich
--0016e6dd8e7439b83f046c0fda9e-- From delta@net.ie.niigata-u.ac.jp Thu Jun 11 03:34:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE2E28C16F for ; Thu, 11 Jun 2009 03:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFyLl6S7Dch5 for ; Thu, 11 Jun 2009 03:34:04 -0700 (PDT) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id 5DFD03A6C2B for ; Thu, 11 Jun 2009 03:34:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 39745290201; Thu, 11 Jun 2009 19:34:11 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with ESMTP id 63F66290201; Thu, 11 Jun 2009 19:34:02 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 13D4A2EF4D; Thu, 11 Jun 2009 19:34:02 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGsgbXkSBmwe; Thu, 11 Jun 2009 19:34:01 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id E67322EF4C; Thu, 11 Jun 2009 19:34:01 +0900 (JST) Message-ID: <4A30DC78.7050600@net.ie.niigata-u.ac.jp> Date: Thu, 11 Jun 2009 19:29:12 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr><4A25027E.3070503@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mase , jacquet , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:34:05 -0000 > > If we are specifically discussing link quality (hysteresis is a > mechanism > used to manage link quality changes) based purely on HELLO messages > and/or packets (saying Hello Packets is misleading) then I'm not > defending that. While of course 802.11 is not the only game in town, > it is a case where link quality based purely on HELLO messages and > packets > is insufficient, but the link quality mechanism is useful, or even > essential > (at least without link metrics, and even with them it can be usefully > used) > - just base it on something else, from the link layer. > > Agreed. >> We have generally found that having a >> link-state change triggered only after 2 or 3 LLNs >> > > What do you mean here by an LLN? Packets and HELLOs can be done at the > network layer. Or do you mean real link layer information? > > I think it really is helpful to separate out the concepts of link > quality, hysteresis, link layer notifications, and link loss. Then > we can be clear if we are discussing the same thing. Unfortunately > RFC 3626 doesn't do this as well as it should - I hope NHDP is > better (but of course if we've missed anything, do let us know). > > By "LLN", further qualified by in-node LLN, we so far use the term to indicate an in-node link layer notification to the routing protocol that occurs on the event that an acknowledgment frame is not received after attempting to forward a unicast packet to another node. For the case of 802.11b in our simulations this would occur on failure to receive an ACK after 4 (LongRetryLimit) or 7 (ShortRetryLimit) retries depending on if RTS/CTS is in use. By "link loss" I indicate the loss of the link in routing protocol, for example OLSRv2's Link Set and so also from its Routing Table that should always be consistent with the Link Set. I use the term "unphysical link" if the link is perceived to exist by a node, for example is still in OLSRv2's Link Set and the Routing Table, but no physical link could possible be supported at that time. Cheers, Lee -S- From philippe.jacquet@inria.fr Thu Jun 11 04:13:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EE53A6D93 for ; Thu, 11 Jun 2009 04:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Uoh0mQpvmXf for ; Thu, 11 Jun 2009 04:13:29 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 9348B3A6D8C for ; Thu, 11 Jun 2009 04:13:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,202,1243807200"; d="scan'208";a="27833596" Received: from guest-rocq-135050.inria.fr ([128.93.135.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jun 2009 13:13:27 +0200 Message-ID: <4A30E8AE.4080807@inria.fr> Date: Thu, 11 Jun 2009 13:21:18 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Lee Speakman References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> In-Reply-To: <4A30D67A.7050702@net.ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 11:13:29 -0000 I mean that instant hellos cannot dissolve the loops in your topology, only instant TCs could. Do you plan to simulate those TC's? I still not understand via LLNs create more loops than link failure detected by hello loss. Are you sure there are no flaws in your simulations? Maybe there are uncontrolled overheads, for example you say that extra hellos create such overhead that cancels any gain, which is obviously not true: few extra hellos should create very negligible overhead compared to datas, retried datas, and looping datas. Regards, Philippe Lee Speakman a crit : > >> But the instant TC should reach the nodes far from the broken link, >> the instant hello not. >> >> I would be surprised that the transmission of a single instant hello >> and of a single instant TC bring any significant increase of >> overhead, at least it should be negligible compared to the loop >> overhead (data packets being repeated 255 times). But maybe the loops >> congest the network and prevent the instant TC or the instant hello >> to be actually received. This is a plausible explanation since you >> say somewhere that the loops also create other link failures, and >> then other loops. > We did not examine the Instant TC in detail, but we certainly observed > the effect of the Instant Hello not being well received in the > adjacent nodes. We increased the chance of this being received by > scheduling one of more Instant Hellos on a trigger event - either an > LLN or a Loop Detection - although at the cost of increasing the > overhead. > > We could increase the chance that the loops would be dissolved up to a > limit (~10%) by using more Instant Hello broadcasts, therefore > potentially providing a gain, but the overhead from the broadcasts > canceled all such gains. > > Yup. Once loops are formed, even though transiently, the surrounding > network is effectively blocked, or particularly has significantly > reduced chance to medium access, and in the neighboring flows packets > are dropped, and are perceived as link failures, leading to new > longer routes being selected to route the packets in those flows, this > in turn leads to the likelihood of more effective load in the network > and the likelihood that more loops will form. > > In our simulations we have a TTL of 63, rather than 255 > >> >> One remedy would be that at detection of link failure a node just >> cancels the route, then drop packets while sending the new TC, and >> AFTER do new route calculation. >> > I'm not sure I know what you mean, but to clarify, you mean also for > that node to wait for receiving a new TC before doing a new route > calculation, and in the meantime just drop packets? > > Wouldn't this result in high loss for at least a short time? > > > Cheers, > Lee -S- > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From delta@net.ie.niigata-u.ac.jp Thu Jun 11 04:14:51 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75E728C20A for ; Thu, 11 Jun 2009 04:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVoqCN+Wiqdd for ; Thu, 11 Jun 2009 04:14:46 -0700 (PDT) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by core3.amsl.com (Postfix) with ESMTP id 2E4FA28C213 for ; Thu, 11 Jun 2009 04:14:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2A5B629023C; Thu, 11 Jun 2009 20:14:07 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with ESMTP id 31EE729023C; Thu, 11 Jun 2009 20:13:57 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id D80AE2EF4D; Thu, 11 Jun 2009 20:13:56 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdysktZLD5y1; Thu, 11 Jun 2009 20:13:56 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id A2CD12EF4C; Thu, 11 Jun 2009 20:13:56 +0900 (JST) Message-ID: <4A30E5D2.7020704@net.ie.niigata-u.ac.jp> Date: Thu, 11 Jun 2009 20:09:06 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Henning Rogge References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A2F87CC.2080908@net.ie.niigata-u.ac.jp> <200906101357.08209.rogge@fgan.de> In-Reply-To: <200906101357.08209.rogge@fgan.de> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 11:14:51 -0000 >> We have found that the use of a hysteresis on link formation based on >> the reception or lack thereof of Hello Packets can only go so far in >> providing for link stability, particularly in networks with node >> mobility, >> > This is no supprise, it's just a result of the statistic attributes of the > link quality metric. Each loss/reception of a hello is just a binary event. > Agreed. > Even if the loss propability of the link is totally stable, you need a lot > more than 3 events (Hellos) to get a good approximation of the loss > probability. > Yes. Admittedly hysteresis is useful in not selecting links which fluctuate on receiving Hellos (sometimes receiving packets, sometimes not). One thing though is that when nodes move out of range of each other, perhaps suddenly by going round a corner, even if previously a perfect link had existed as established by a previously consistent number of Hello receptions, if that link is supporting traffic, hysteresis is too slow a process in order to respond in the sudden unphysicalness of that link. So the LLN (a link layer notification in-node to the routing protocol on the failure of that node to receive acknowledgment of the successful forwarding of a unicast packet to a neighboring node) is required. The nature of the in-node LLN seems to be such that it causes sudden changes in perception of the network leading to the increased likelihood of loop formation. In such cases, if there are several traffic flows in the network, the combined effect of links lost through these LLN causes several incoherencies in perceived maps of the network that may lead to several transient routing loops and the looping packet over it. So even though using hysteresis to build up a fairly good set of neighboring nodes, we use LLN in order to respond quickly to sudden loss of links in the network, so as not to drop them resulting in high loss under various scenarios. The problem is intensified as even though the LLN is ideally used to remove the unphysical link where two nodes are no longer in range of each other, the effect of transient looping packets is to cause sudden intense use of the medium, reducing medium access in the vicinity of the looping packets and so further unnecessary LLNs occur due to this. > With a loss propability of 50% (as an example) 1/8 of the possible "3 Hello > events" will tell OLSR it has a perfect link (no loss), 3/8 will see a "33% > loss" link, 3/8 will see a "66% loss" link and 1/8 will get no Hello at all. > The hysteresis could not prevent a static link like this to switch on/off. > > It's necessary to get better data (signal strength and other layer 2 > measurements) or more data (integrate over a longer time) for a working > hysteresis. > Yes. I think this is an important approach. We are exploring layer 2 measurements to support a quick response to changes in the network. In a static mesh network, it may be possible to effectively do away with all loops by using a number of mechanisms, hysteresis and layer 2 measurements, as long as nodes do not suddenly fail, but with mobility, there is still the need to respond quickly to unphysical links. As far as we see, this will introduce incoherencies in the perceived topology maps between the nodes of the network, leading to routing loops and looping packets, so we need to deal with this in some way. Cheers, Lee -S- From ihokelek@telcordia.com Thu Jun 11 07:17:39 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469333A6407 for ; Thu, 11 Jun 2009 07:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr0DxzQiRlka for ; Thu, 11 Jun 2009 07:17:38 -0700 (PDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by core3.amsl.com (Postfix) with ESMTP id 5178B3A6B5E for ; Thu, 11 Jun 2009 07:17:38 -0700 (PDT) Received: from pya-dte-ieg01.dte.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n5BEHi5x020880 for ; Thu, 11 Jun 2009 10:17:44 -0400 (EDT) X-AuditID: 80601415-00000d200000055c-5a-4a3112053393 Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by pya-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 10:17:41 -0400 Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Thu, 11 Jun 2009 10:17:40 -0400 From: "Hokelek, Ibrahim" To: "'jacquet'" , Lee Speakman Date: Thu, 11 Jun 2009 10:17:40 -0400 Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" Thread-Index: AcnqhboYEDpnU0wVSE+ySdFomYXy1QAGSO0w Message-ID: <563593148DD9A040B93397F642B3C125327DE769D4@rrc-dte-exmb1.dte.telcordia.com> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> <4A30E8AE.4080807@inria.fr> In-Reply-To: <4A30E8AE.4080807@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: mase , "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 14:17:39 -0000 >>I still not understand via LLNs create more loops than link failure >>detected by hello loss. Is the reason because of more failures are detected via LLNs compared to th= e hello loss mechanism. Is there any simulation result showing how many failures detecte= d via LLNs vs hello loss? Thanks, Ibrahim From larslan@unik.no Thu Jun 11 08:02:45 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5B53A69E0 for ; Thu, 11 Jun 2009 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX+YUOUgmRQe for ; Thu, 11 Jun 2009 08:02:44 -0700 (PDT) Received: from kampala.unik.no (kampala.unik.no [193.156.97.46]) by core3.amsl.com (Postfix) with ESMTP id 0EC0E3A69BD for ; Thu, 11 Jun 2009 08:02:43 -0700 (PDT) Received: from astana.unik.no (193.156.97.31) by kampala.unik.no (193.156.97.46) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 11 Jun 2009 17:02:49 +0200 Received: from astana.unik.no ([193.156.97.31]) by astana.unik.no ([193.156.97.31]) with mapi; Thu, 11 Jun 2009 17:02:49 +0200 From: Lars Landmark To: jacquet , Lee Speakman Date: Thu, 11 Jun 2009 17:02:48 +0200 Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" Thread-Index: AcnqheKhXqNBw7yFTbSu2tx0SReMgAAHm2lF Message-ID: <9E0E279861121E408614812D358017B60191013B40@astana.unik.no> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp>,<4A30E8AE.4080807@inria.fr> In-Reply-To: <4A30E8AE.4080807@inria.fr> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:02:45 -0000 Phillip and Lee; > I mean that instant hellos cannot dissolve the loops in your topology, > only instant TCs could. Do you plan to simulate those TC's? According to the reference 6 in Lee=92s draft, on page 1217 figure 5a, majo= rity of the loops are formed over =932-way=94. Instant TC messages would on= ly help loops formed over three hops or more. Hence, instant TC messages wo= uld only have small contribution, or am I wrong? =20 > I still not understand via LLNs create more loops than link failure > detected by hello loss. I am not sure, and have neither verified the next hypothesis;=20 Assuming that the HELLO packets are scheduled within a constant hello inter= val of 2 seconds, plus jitter, then all 1-hop neighbors are notified about = a link break simultaneously 6 seconds after the last received HELLO message= . On the other hand, if LLN is being used, the node experiencing the unsucc= essful transmission will immediately tear down the link. On average, this w= ill occur approximately one second after the last scheduled HELLO message a= nd one second before the next scheduled HELLO message. That is, by the rema= ining one second until scheduling the next HELLO message the local node and= its surrounding 1-hop nodes will operate on different topology maps. Howev= er, I am not sure whether the large number of packets entering a loop can b= e explained by this short time of inconsistent topology maps. It would depe= nd on the surrounding traffic load. =20 A typical problem of high traffic load is high loss of control packets and = different system time. In this context, the system time is queuing time and= transmission time. If control packets are scheduled after experiencing hig= h system time, the local node and its suroundings will likely operate on di= fferent topology maps. The next question would then be; are the control pac= kets scheduled with priority or equal to the ordinary data traffic?=20 =20 Since the problem of route loops appear to be lower in dens networks, would= it be an idea to increasing the number of MPR=92s, i.e. covering all 2-hop= by at least 2 MPR=92s? It would not solve the problem, but perhaps reduce = the problem, at least in sparse networks, without =93to much overhead=94. = =20 Regards Lars Student =20 Are you sure there are no flaws in your simulations? Maybe there are uncontrolled overheads, for example you say that extra hellos create such overhead that cancels any gain, which is obviously not true: few extra hellos should create very negligible overhead compared to datas, retried datas, and looping datas. Regards, Philippe Lee Speakman a =E9crit : > >> But the instant TC should reach the nodes far from the broken link, >> the instant hello not. >> >> I would be surprised that the transmission of a single instant hello >> and of a single instant TC bring any significant increase of >> overhead, at least it should be negligible compared to the loop >> overhead (data packets being repeated 255 times). But maybe the loops >> congest the network and prevent the instant TC or the instant hello >> to be actually received. This is a plausible explanation since you >> say somewhere that the loops also create other link failures, and >> then other loops. > We did not examine the Instant TC in detail, but we certainly observed > the effect of the Instant Hello not being well received in the > adjacent nodes. We increased the chance of this being received by > scheduling one of more Instant Hellos on a trigger event - either an > LLN or a Loop Detection - although at the cost of increasing the > overhead. > > We could increase the chance that the loops would be dissolved up to a > limit (~10%) by using more Instant Hello broadcasts, therefore > potentially providing a gain, but the overhead from the broadcasts > canceled all such gains. > > Yup. Once loops are formed, even though transiently, the surrounding > network is effectively blocked, or particularly has significantly > reduced chance to medium access, and in the neighboring flows packets > are dropped, and are perceived as link failures, leading to new > longer routes being selected to route the packets in those flows, this > in turn leads to the likelihood of more effective load in the network > and the likelihood that more loops will form. > > In our simulations we have a TTL of 63, rather than 255 > >> >> One remedy would be that at detection of link failure a node just >> cancels the route, then drop packets while sending the new TC, and >> AFTER do new route calculation. >> > I'm not sure I know what you mean, but to clarify, you mean also for > that node to wait for receiving a new TC before doing a new route > calculation, and in the meantime just drop packets? > > Wouldn't this result in high loss for at least a short time? > > > Cheers, > Lee -S- > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet= From philippe.jacquet@inria.fr Thu Jun 11 09:20:07 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BAB3A69A3 for ; Thu, 11 Jun 2009 09:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTRgRi+82550 for ; Thu, 11 Jun 2009 09:20:07 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 8672F3A68E3 for ; Thu, 11 Jun 2009 09:20:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,203,1243807200"; d="scan'208";a="31042656" Received: from guest-rocq-135050.inria.fr ([128.93.135.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jun 2009 18:20:12 +0200 Message-ID: <4A313093.1040500@inria.fr> Date: Thu, 11 Jun 2009 18:28:03 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Lars Landmark References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp>, <4A30E8AE.4080807@inria.fr> <9E0E279861121E408614812D358017B60191013B40@astana.unik.no> In-Reply-To: <9E0E279861121E408614812D358017B60191013B40@astana.unik.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Lee Speakman , "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 16:20:07 -0000 Dear Lars and Lee, Unfortunately I cannot access this reference. :-( Is "2-way" refering to hop number or status over symmetric links? I understood from Lee's previous posts that most loops were not adjacent to the broken link. The instant hello cannot solve loops that are not adjacent to the broken link while the instant TC will do it (if correctly received). I don't think there is a significant impact on overhead. Philippe Lars Landmark a crit : > Phillip and Lee; > > >> I mean that instant hellos cannot dissolve the loops in your topology, >> only instant TCs could. Do you plan to simulate those TC's? >> > > According to the reference 6 in Lees draft, on page 1217 figure 5a, majority of the loops are formed over 2-way. Instant TC messages would only help loops formed over three hops or more. Hence, instant TC messages would only have small contribution, or am I wrong? > > From nani1only@gmail.com Thu Jun 11 07:22:31 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B083A69BF for ; Thu, 11 Jun 2009 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkrWXCRiyq2N for ; Thu, 11 Jun 2009 07:22:30 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 2EE553A6977 for ; Thu, 11 Jun 2009 07:22:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1260717fga.18 for ; Thu, 11 Jun 2009 07:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LCQmVKDWmYeZCbyTK3uWkIxmu3r9sfBkbu25z4ljjuc=; b=Y4kDMJLuiSDm2hSS/pfQ+e2PUMEjQME3zE5k+TCG10ttE5Fo26cNkpxTECoFSsTh7g kBlIZ0n/xPq8Ykkuy9ZgEc2L9mQImyXGGFH/psq2EwK6ig42y5W2xmKrKyfRQlUdWKN0 e2a3uU5jJv2fPZLMio05kO2U9jcqxzTgUhY6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QQZJn12lgRmYrRfTwFQuaJrfK0tx51kSTU2raCozihV+OrzGVo7PT0ELG6mfIV+x4M M/VCwCTxH31ukn2Zo5GvVL32jCqrUXpMxiPXU83cnlpmcanGFo0gVoN5koynwE9uFPaR AEzJ8zOcmfmDe8plLtdjjhzMc412Fsprh0OgY= MIME-Version: 1.0 Received: by 10.216.39.85 with SMTP id c63mr945238web.103.1244730153992; Thu, 11 Jun 2009 07:22:33 -0700 (PDT) Date: Thu, 11 Jun 2009 19:52:33 +0530 Message-ID: From: rahimanuddin shaik To: manet@ietf.org Content-Type: multipart/alternative; boundary=0016365ee476ab8385046c1352c4 X-Mailman-Approved-At: Thu, 11 Jun 2009 12:15:42 -0700 Subject: [manet] MAODV improvisation regarding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 14:22:31 -0000 --0016365ee476ab8385046c1352c4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, this is rahmanuddin from India. I am very much interested in Adhoc networks and want to do my project of graduation on the same lines. precisely pertaining to security issues in MAODV(Multicast ad hoc on demand vector routing protocol). Can anyone guide me referring some issues concerned and also useful links for the same. Thank you with regards Rahmanuddin --0016365ee476ab8385046c1352c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
=A0 =A0 =A0 =A0 =A0this is rahmanuddin from India. I am very much interest= ed in Adhoc
networks and want to do my project of graduation on the same lines.
precisely pertaining to security issues in MAODV(Multicast ad hoc on demand=
vector routing protocol).
Can anyone guide me referring some issues concerned and also useful links for the same.
Thank you
with regards
Rahmanuddin --0016365ee476ab8385046c1352c4-- From delta@net.ie.niigata-u.ac.jp Thu Jun 11 23:39:20 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DA13A6B72 for ; Thu, 11 Jun 2009 23:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOEzRJ-GPoKR for ; Thu, 11 Jun 2009 23:39:19 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id 689383A6AAA for ; Thu, 11 Jun 2009 23:39:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 17EB145422A; Fri, 12 Jun 2009 15:39:26 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id D0659454226; Fri, 12 Jun 2009 15:39:22 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 4A2682EF4D; Fri, 12 Jun 2009 15:39:22 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UrcFvMr0rOw; Fri, 12 Jun 2009 15:39:22 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 1E03D2EF4C; Fri, 12 Jun 2009 15:39:22 +0900 (JST) Message-ID: <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> Date: Fri, 12 Jun 2009 15:34:32 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ulrich Herberg , jacquet References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> In-Reply-To: <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 06:39:20 -0000 Dear Phillipe and Ulrich, Firstly, there are several researches we have done with the Instant Hello. I establish in more detail and more precisely what we have done before continuing. The problem of looping is observed to occur where there are higher loads in the network, in our case with multiple flows crisscrossing the network. If, on an event, we send just one Instant Hello, then in such cases, due to already circling packets around loops, there is a lesser probability that surrounding nodes will be able to successfully receive the Instant Hello compared to when there is little traffic in the network. What we first observed was that a single Instant Hello triggered on in-node LLN (caused by failure to receive successive link layer acknowledgements from attempting to forward a unicast packet) made very little difference in the PDR (end-to-end delivery) and the number of loops which we were measuring at that time, regardless of if the packet was scheduled immediately, or using the full jitter interval or a fraction of it. There were only minor improvements in PDR of a few percent when network load was such that PDR was down to ~70% in OLSRv2-LLN which was not very effective. As we were just sending one Instant Hello on LLN to explore it in the use of dissolving loops, we did not use a minimum Hello interval. To see if the cause was due to the Instant Hello not being received, we scheduled multiple Hellos, this reduced the number of loops further (showing that a single Hello had probably not been well received) but also increased the overhead. For that simulation with multiple Instant Hellos in short succession this is where we could get around ~10% of the loops dissolved, but at the cost of the overhead increasing as we increased the number of loops, thereby countering any gains from the reduced number of loops. Sorry, I had not intended to confuse when I originally expressed our observed effects of the use of Instant Hellos. I was only mentioning this briefly to express under certain scenarios how we find that for ~90% of the loops the loop comes about from an incoherent perception of the network between adjacent nodes through their Topology Sets and so cannot be fixes with an Instant Hello, and that the effect of an LLN cutting a link that is unphysical is often to cause a change such that a loop appears not only one link away (an adjacent link), but also two links or more away from the lost link. After studying various packet traces and all nodes Link Set and Topology Sets to find out why we could never dissolve more than ~10% of loops in this particularly scenario, we found that the majority of loops are more than one link-hop away from where the LLN is occur. The node in which an LLN occurs from dropping a unicast packet only selects a new route (after removal of that link), forwarding it along a different path, and further in that path a loop occurs. In more recent simulation, with the same parameters as given in our published work, we measure the number of nodes that receive each broadcast packet (control packet). This is done for 60 nodes with a maximum mobility of 5m/s (random waypoint, random mobility between 0 and 5m/s). i. At modest loads, 8 applications (CBR, UDP), then we find that OLSRv2-LLN has a ~85% PDR (end-to-end delivery) with ~1700 looping packet observations on average per simulation. An Instant Hello on LLN gives no improvement in PDR and the number of loops is approximately the same. An Instant TC on LLN gives the same result. At almost no load, a control packet is on average received by 17.5 nodes (more in the center, less on the edges), but at a load of 8 apps this is down to just over 16 nodes. This is worse at the time a transient looping packet is existing. Disregarding Instant Hellos / TCs, we can get real improvements by simply using a Loop Detection mechanism and discarding the packets (Packet Discard), bringing the PDR up to ~94.5%, and better improvements by cutting the link over which a looping packet is detected (Link Cut), bringing the PDR up to ~96%. ii. At 12 application, where there are more loops, then we find that OLSRv2-LLN has a ~74% PDR with ~4300 looping packet observations on average per simulation. An Instant Hello on LLN gives about a 3% improvement in PDR (to ~77%) and the number of observed loops is ~3700. An Instant TC on LLN gives the same result. At almost no load, a control packet is on average received by 17.5 nodes (more in the center, less on the edges), but at a load of 12 apps this is down to less than 15 nodes. This is worse at the time a transient looping packet is existing. Again, using Packet Discard on Loop Detection brings the PDR up to ~92.5%, and with Link Cut on Loop Detection we get the PDR up to ~94%. Simply discarding the observed looping packets and the improvement that has on PDR shows the negative effects of looping packets on surrounding traffic. We have also looked at Instant Hellos and Instant TC on Loop Detection which shows some improvement; to 88% PDR (up 3%) for 8 apps (removing ~24% of loops), and to 79% PDR (up 4%) for 12 apps (removing ~19% if loops). This appears to become less effective at higher loads. The looping packet is not discarded nor is the link cut over which the packet loops, so on every node the looping packet passes an Instant Hello or TC is generated on Loop Detection. None of these Instant Hellos / TCs interrupted any of the periodic scheduling of the control packet broadcasts but were done "extra." Cheers, Lee -S- From ulrich@herberg.name Fri Jun 12 00:09:20 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A6E3A6B81 for ; Fri, 12 Jun 2009 00:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpuOMJQF85sf for ; Fri, 12 Jun 2009 00:09:18 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 3DB0A3A6B75 for ; Fri, 12 Jun 2009 00:09:18 -0700 (PDT) Received: by fxm12 with SMTP id 12so431267fxm.37 for ; Fri, 12 Jun 2009 00:09:23 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.71.82 with SMTP id g18mr3283956bkj.120.1244790563273; Fri, 12 Jun 2009 00:09:23 -0700 (PDT) In-Reply-To: <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> Date: Fri, 12 Jun 2009 09:09:23 +0200 X-Google-Sender-Auth: 45ee03fd41a7b03c Message-ID: <25c114b90906120009x194e5aacjca1ed3fc134a09e6@mail.gmail.com> From: Ulrich Herberg To: Lee Speakman Content-Type: multipart/alternative; boundary=00504502daac57fc8d046c2163fe Cc: mase , jacquet , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 07:09:20 -0000 --00504502daac57fc8d046c2163fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Lee, thanks for the more detailed information. Were your simulations performed in Ns2? If so, I would be interested in having your tcl script for the scenario in order to reproduce your simulation with my OLSRv2 implementation. It's a pity that your paper is not public . Cheers, Ulrich On Fri, Jun 12, 2009 at 8:34 AM, Lee Speakman wrote: > Dear Phillipe and Ulrich, > > Firstly, there are several researches we have done with the Instant Hello. > I establish in more detail and more precisely what we have done before > continuing. > > The problem of looping is observed to occur where there are higher loads in > the network, in our case with multiple flows crisscrossing the network. > If, on an event, we send just one Instant Hello, then in such cases, due to > already circling packets around loops, there is a lesser probability that > surrounding nodes will be able to successfully receive the Instant Hello > compared to when there is little traffic in the network. > > What we first observed was that a single Instant Hello triggered on in-node > LLN (caused by failure to receive successive link layer acknowledgements > from attempting to forward a unicast packet) made very little difference in > the PDR (end-to-end delivery) and the number of loops which we were > measuring at that time, regardless of if the packet was scheduled > immediately, or using the full jitter interval or a fraction of it. There > were only minor improvements in PDR of a few percent when network load was > such that PDR was down to ~70% in OLSRv2-LLN which was not very effective. > > As we were just sending one Instant Hello on LLN to explore it in the use > of dissolving loops, we did not use a minimum Hello interval. > > To see if the cause was due to the Instant Hello not being received, we > scheduled multiple Hellos, this reduced the number of loops further (showing > that a single Hello had probably not been well received) but also increased > the overhead. For that simulation with multiple Instant Hellos in short > succession this is where we could get around ~10% of the loops dissolved, > but at the cost of the overhead increasing as we increased the number of > loops, thereby countering any gains from the reduced number of loops. > > Sorry, I had not intended to confuse when I originally expressed our > observed effects of the use of Instant Hellos. I was only mentioning this > briefly to express under certain scenarios how we find that for ~90% of the > loops the loop comes about from an incoherent perception of the network > between adjacent nodes through their Topology Sets and so cannot be fixes > with an Instant Hello, and that the effect of an LLN cutting a link that is > unphysical is often to cause a change such that a loop appears not only one > link away (an adjacent link), but also two links or more away from the lost > link. > > After studying various packet traces and all nodes Link Set and Topology > Sets to find out why we could never dissolve more than ~10% of loops in this > particularly scenario, we found that the majority of loops are more than one > link-hop away from where the LLN is occur. The node in which an LLN occurs > from dropping a unicast packet only selects a new route (after removal of > that link), forwarding it along a different path, and further in that path a > loop occurs. > > > In more recent simulation, with the same parameters as given in our > published work, we measure the number of nodes that receive each broadcast > packet (control packet). > > This is done for 60 nodes with a maximum mobility of 5m/s (random waypoint, > random mobility between 0 and 5m/s). > > > i. At modest loads, 8 applications (CBR, UDP), then we find that OLSRv2-LLN > has a ~85% PDR (end-to-end delivery) with ~1700 looping packet observations > on average per simulation. > An Instant Hello on LLN gives no improvement in PDR and the number of loops > is approximately the same. An Instant TC on LLN gives the same result. > > At almost no load, a control packet is on average received by 17.5 nodes > (more in the center, less on the edges), but at a load of 8 apps this is > down to just over 16 nodes. This is worse at the time a transient looping > packet is existing. > > Disregarding Instant Hellos / TCs, we can get real improvements by simply > using a Loop Detection mechanism and discarding the packets (Packet > Discard), bringing the PDR up to ~94.5%, and better improvements by cutting > the link over which a looping packet is detected (Link Cut), bringing the > PDR up to ~96%. > > > ii. At 12 application, where there are more loops, then we find that > OLSRv2-LLN has a ~74% PDR with ~4300 looping packet observations on average > per simulation. > An Instant Hello on LLN gives about a 3% improvement in PDR (to ~77%) and > the number of observed loops is ~3700. An Instant TC on LLN gives the same > result. > > At almost no load, a control packet is on average received by 17.5 nodes > (more in the center, less on the edges), but at a load of 12 apps this is > down to less than 15 nodes. This is worse at the time a transient looping > packet is existing. > > Again, using Packet Discard on Loop Detection brings the PDR up to ~92.5%, > and with Link Cut on Loop Detection we get the PDR up to ~94%. > > > Simply discarding the observed looping packets and the improvement that has > on PDR shows the negative effects of looping packets on surrounding traffic. > > > We have also looked at Instant Hellos and Instant TC on Loop Detection > which shows some improvement; to 88% PDR (up 3%) for 8 apps (removing ~24% > of loops), and to 79% PDR (up 4%) for 12 apps (removing ~19% if loops). > This appears to become less effective at higher loads. The looping packet > is not discarded nor is the link cut over which the packet loops, so on > every node the looping packet passes an Instant Hello or TC is generated on > Loop Detection. > > None of these Instant Hellos / TCs interrupted any of the periodic > scheduling of the control packet broadcasts but were done "extra." > > > Cheers, > Lee -S- > > > > --00504502daac57fc8d046c2163fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Lee,

thanks for the more detailed information. Were your simula= tions performed in Ns2? If so, I would be interested in having your tcl scr= ipt for the scenario in order to reproduce your simulation with my OLSRv2 i= mplementation.
It's a pity that your paper is not public .

Cheers,
Ulrich
On Fri, Jun 12, 2009 at 8:34 AM, Lee Speakm= an <de= lta@net.ie.niigata-u.ac.jp> wrote:
Dear Phillipe and= Ulrich,

Firstly, there are several researches we have done with the Instant Hello. = =A0I establish in more detail and more precisely what we have done before c= ontinuing.

The problem of looping is observed to occur where there are higher loads in= the network, in our case with multiple flows crisscrossing the network. If, on an event, we send just one Instant Hello, then in such cases, due to= already circling packets around loops, there is a lesser probability that = surrounding nodes will be able to successfully receive the Instant Hello co= mpared to when there is little traffic in the network.

What we first observed was that a single Instant Hello triggered on in-node= LLN (caused by failure to receive successive link layer acknowledgements f= rom attempting to forward a unicast packet) made very little difference in = the PDR (end-to-end delivery) and the number of loops which we were measuri= ng at that time, regardless of if the packet was scheduled immediately, or = using the full jitter interval or a fraction of it. =A0There were only mino= r improvements in PDR of a few percent when network load was such that PDR = was down to ~70% in OLSRv2-LLN which was not very effective.

As we were just sending one Instant Hello on LLN to explore it in the use o= f dissolving loops, we did not use a minimum Hello interval.

To see if the cause was due to the Instant Hello not being received, we sch= eduled multiple Hellos, this reduced the number of loops further (showing t= hat a single Hello had probably not been well received) but also increased = the overhead. =A0For that simulation with multiple Instant Hellos in short = succession this is where we could get around ~10% of the loops dissolved, b= ut at the cost of the overhead increasing as we increased the number of loo= ps, thereby countering any gains from the reduced number of loops.

Sorry, I had not intended to confuse when I originally expressed our observ= ed effects of the use of Instant Hellos. =A0I was only mentioning this brie= fly to express under certain scenarios how we find that for ~90% of the loo= ps the loop comes about from an incoherent perception of the network betwee= n adjacent nodes through their Topology Sets and so cannot be fixes with an= Instant Hello, and that the effect of an LLN cutting a link that is unphys= ical is often to cause a change such that a loop appears not only one link = away (an adjacent link), but also two links or more away from the lost link= .

After studying various packet traces and all nodes Link Set and Topology Se= ts to find out why we could never dissolve more than ~10% of loops in this = particularly scenario, we found that the majority of loops are more than on= e link-hop away from where the LLN is occur. =A0The node in which an LLN oc= curs from dropping a unicast packet only selects a new route (after removal= of that link), forwarding it along a different path, and further in that p= ath a loop occurs.


In more recent simulation, with the same parameters as given in our publish= ed work, we measure the number of nodes that receive each broadcast packet = (control packet).

This is done for 60 nodes with a maximum mobility of 5m/s (random waypoint,= random mobility between 0 and 5m/s).


i. At modest loads, 8 applications (CBR, UDP), then we find that OLSRv2-LLN= has a ~85% PDR (end-to-end delivery) with ~1700 looping packet observation= s on average per simulation.
An Instant Hello on LLN gives no improvement in PDR and the number of loops= is approximately the same. =A0An Instant TC on LLN gives the same result.<= br>
At almost no load, a control packet is on average received by 17.5 nodes (m= ore in the center, less on the edges), but at a load of 8 apps this is down= to just over 16 nodes. =A0This is worse at the time a transient looping pa= cket is existing.

Disregarding Instant Hellos / TCs, we can get real improvements by simply u= sing a Loop Detection mechanism and discarding the packets (Packet Discard)= , bringing the PDR up to ~94.5%, and better improvements by cutting the lin= k over which a looping packet is detected (Link Cut), bringing the PDR up t= o ~96%.


ii. At 12 application, where there are more loops, then we find that OLSRv2= -LLN has a ~74% PDR with ~4300 looping packet observations on average per s= imulation.
An Instant Hello on LLN gives about a 3% improvement in PDR (to ~77%) and t= he number of observed loops is ~3700. =A0An Instant TC on LLN gives the sam= e result.

At almost no load, a control packet is on average received by 17.5 nodes (m= ore in the center, less on the edges), but at a load of 12 apps this is dow= n to less than 15 nodes. =A0This is worse at the time a transient looping p= acket is existing.

Again, using Packet Discard on Loop Detection brings the PDR up to ~92.5%, = and with Link Cut on Loop Detection we get the PDR up to ~94%.


Simply discarding the observed looping packets and the improvement that has= on PDR shows the negative effects of looping packets on surrounding traffi= c.


We have also looked at Instant Hellos and Instant TC on Loop Detection whic= h shows some improvement; to 88% PDR (up 3%) for 8 apps (removing ~24% of l= oops), and to 79% PDR (up 4%) for 12 apps (removing ~19% if loops). =A0This= appears to become less effective at higher loads. =A0The looping packet is= not discarded nor is the link cut over which the packet loops, so on every= node the looping packet passes an Instant Hello or TC is generated on Loop= Detection.

None of these Instant Hellos / TCs interrupted any of the periodic scheduli= ng of the control packet broadcasts but were done "extra."


Cheers,
=A0Lee -S-




--00504502daac57fc8d046c2163fe-- From delta@net.ie.niigata-u.ac.jp Fri Jun 12 00:35:53 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABBA28C16E for ; Fri, 12 Jun 2009 00:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyhohjX+Ry3o for ; Fri, 12 Jun 2009 00:35:52 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by core3.amsl.com (Postfix) with ESMTP id 3BF7828C14D for ; Fri, 12 Jun 2009 00:35:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F233F454230; Fri, 12 Jun 2009 16:35:59 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id B313545422F; Fri, 12 Jun 2009 16:35:58 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 2A9742EF4D; Fri, 12 Jun 2009 16:35:58 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nXxbXCDle4z; Fri, 12 Jun 2009 16:35:58 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 08FA62EF4C; Fri, 12 Jun 2009 16:35:58 +0900 (JST) Message-ID: <4A32043C.8020706@net.ie.niigata-u.ac.jp> Date: Fri, 12 Jun 2009 16:31:08 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: jacquet , Lars Landmark References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp>, <4A30E8AE.4080807@inria.fr> <9E0E279861121E408614812D358017B60191013B40@astana.unik.no> <4A313093.1040500@inria.fr> In-Reply-To: <4A313093.1040500@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 07:35:53 -0000 Dear Philippe and Lars, I used "2 way" loops to refer to packets that loop back and forth between just 2 nodes; A --> B --> A --> B --> ... (A <--> B). Where, for example, 3-way loops would be triangular loops between 3 node; A --> B --> C --> A --> B --> C --> ... . About 93% of observed looping packets are "2-way", except at lighter loads with few loops in which almost all of these looping packets tend to be "2-way". The remaining 7% are "3-way" or higher, where "3-way" loops are more dominant than "4-way" and so on to higher order. This is just the observed nature of the looping packet and may not be directly related to if they are adjacent to nodes that have had a LLN. In what way the loops exist is dependent on a number of factors; load, node-density (link density) and mobility being three we have explored. From the use of Instant Hello on LLN (at 12 app load), we come to the conclusion that for this case perhaps around ~13% of loops are adjacent to and dissolvable by Instant Hellos triggered on LLN (one Instant Hello triggered per LLN). There's unlikely to be significant impact on overhead from this but it only gives a 3% improvement in PDR (to ~77%). In the event that there are looping packets, for a short time the network is busy forwarding looping packets, the medium is kept very busy and the probability that control packets are received is also decreased. We plan to look further at Instant TCs, perhaps in use with a Packet Discard technique on Loop Detection so that the Hellos and TCs can once again be successfully received by the surrounding nodes. Cheers, Lee -S- jacquet さんは書きました: > Dear Lars and Lee, > > Unfortunately I cannot access this reference. :-( > > Is "2-way" refering to hop number or status over symmetric links? I > understood from Lee's previous posts that most loops were not adjacent > to the broken link. The instant hello cannot solve loops that are not > adjacent to the broken link while the instant TC will do it (if > correctly received). > > I don't think there is a significant impact on overhead. > > Philippe > > > Lars Landmark a écrit : >> Phillip and Lee; >> >>> I mean that instant hellos cannot dissolve the loops in your topology, >>> only instant TCs could. Do you plan to simulate those TC's? >> >> According to the reference 6 in Lee’s draft, on page 1217 figure 5a, >> majority of the loops are formed over “2-way”. Instant TC messages >> would only help loops formed over three hops or more. Hence, instant >> TC messages would only have small contribution, or am I wrong? > > From delta@net.ie.niigata-u.ac.jp Fri Jun 12 00:49:34 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EE83A6A86 for ; Fri, 12 Jun 2009 00:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBn-bHwWBVta for ; Fri, 12 Jun 2009 00:49:33 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id 73A273A6A80 for ; Fri, 12 Jun 2009 00:49:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CFDCE4F422F; Fri, 12 Jun 2009 16:49:40 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with ESMTP id DB1A84F4223; Fri, 12 Jun 2009 16:49:35 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 553522EF4D; Fri, 12 Jun 2009 16:49:35 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkpkEfazsjbb; Fri, 12 Jun 2009 16:49:35 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 3A14E2EF4C; Fri, 12 Jun 2009 16:49:35 +0900 (JST) Message-ID: <4A32076D.9000807@net.ie.niigata-u.ac.jp> Date: Fri, 12 Jun 2009 16:44:45 +0900 From: Lee Speakman User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ulrich Herberg References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> <25c114b90906120009x194e5aacjca1ed3fc134a09e6@mail.gmail.com> In-Reply-To: <25c114b90906120009x194e5aacjca1ed3fc134a09e6@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , jacquet , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 07:49:34 -0000 Dear Ulrich, we performed the simulations with Qualnet 4.0 with an updated version of nOLSRv2. We have the simulation config and other files for this in order to recreate the simulations. Though to track looping packets, count them and see their nature ("2-way" etc.) we made modification to the simulation suite in simulation space. It would be good to be able to recreate such results in Ns2 with another implementation of OSLRv2. Cheers, Lee -S- Ulrich Herberg さんは書きました: > Dear Lee, > > thanks for the more detailed information. Were your simulations > performed in Ns2? If so, I would be interested in having your tcl > script for the scenario in order to reproduce your simulation with my > OLSRv2 implementation. > It's a pity that your paper is not public . > > Cheers, > Ulrich > From Chris.Dearlove@baesystems.com Fri Jun 12 02:02:12 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793573A6D9B for ; Fri, 12 Jun 2009 02:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqfboNWcOg6Q for ; Fri, 12 Jun 2009 02:02:11 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 1ED293A6C86 for ; Fri, 12 Jun 2009 02:02:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,208,1243810800"; d="scan'208";a="6975736" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 12 Jun 2009 10:02:15 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n5C92FYj022594; Fri, 12 Jun 2009 10:02:15 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 10:02:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 2009 10:02:11 +0100 Message-ID: In-Reply-To: <4A30E5D2.7020704@net.ie.niigata-u.ac.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: AcnqhfERaXPBZbX0RnadxuqnR22bVgAss8lw References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><4A2F87CC.2080908@net.ie.niigata-u.ac.jp><200906101357.08209.rogge@fgan.de> <4A30E5D2.7020704@net.ie.niigata-u.ac.jp> From: "Dearlove, Christopher (UK)" To: "Lee Speakman" , "Henning Rogge" X-OriginalArrivalTime: 12 Jun 2009 09:02:15.0396 (UTC) FILETIME=[7B2E3240:01C9EB3C] Cc: mase , manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 09:02:12 -0000 > One thing though is that when nodes move out of range of each other, > perhaps suddenly by going round a corner, even if previously a perfect > link had existed as established by a previously consistent number of > Hello receptions, if that link is supporting traffic, hysteresis is too > slow a process in order to respond in the sudden unphysicalness of that > link. Can I make another appeal for precise terminology (although I admit RFC 3626 encourages the poor use). This is not hysteresis. Hysteresis is about link state having memory, in OLSR (v1 and v2) implemented using higher and lower thresholds for a good link. The process that's too slow is one of (I think - and that's why precision is important, so we know what we are talking about) counting HELLO messages and/or packets. > So the LLN (a link layer notification in-node to the routing > protocol on the failure of that node to receive acknowledgment of the > successful forwarding of a unicast packet to a neighboring node) is > required. I would agree that, if possible, information from the link layer is desirable. > The nature of the in-node LLN seems to be such that it causes sudden > changes in perception of the network leading to the increased likelihood > of loop formation. Since there are different possible LLN mechanisms, whether one such causes multiple sudden changes depends entirely on the nature of that LLN mechanism - and in particular on what hysteresis (in the proper sense of the term) you apply to it. But in the case of your example of going round a corner, a sudden (how sudden depends on speed and the nature of the propagation round the corner) loss of link is what actually happens physically. The ideal is to discard that link locally, and by signalling, remotely as soon as possible (consistent with managing signalling load, a standard tradeoff). But this is about link loss. There's nothing new in using LLN, you will lose that link going round the corner at some point (expiry of Link Tuple in particular). The point of LLNs in this case is to accelerate the loss - in the case of a sharp corner there is no extra problem in using LLNs, you get the same one event, just earlier. This makes things better, not worse (shorter period when packets will actually be lost despite having an entry in the routing table) and no extra signalling is required, just signalling earlier. The only case when LLNs add to the frequency of link state changes is when (e.g. using SNR) you are marginal, and the link fluctuates good and bad. But that's the point of the hysteresis (again, the precise usage) to prevent such fluctuations. In short, a properly configured use of suitable LLNs, in most scenarios, accelerates link removal, it doesn't cause a significant increase in the frequency of link loss (and similarly link formation). If turning on LLNs is significantly adding to the rate, the nature of the LLNs, and the hysteresis used, need careful examination. Now, whether using LLNs or not, there will be link losses. And until signalled, there will be transients in the consistency of routing tables. And that's what responsive (as we say in OLSRv2) HELLO and TC messages are for, to ensure that those transients are short enough. (If the full message interval is short enough, you don't need them, if it's too long, you do - we make this cleaner in OLSRv2 with minimum intervals.) (Of course there's also the well-known fisheye principle that says out of date long distance information may be sufficient. This depends a lot on your network density and other factors. It might mean that responsive TC messages can have a smaller hop limit. Or it might not.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Jun 12 02:06:58 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61083A6DDB for ; Fri, 12 Jun 2009 02:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0IgNSEhRzkw for ; Fri, 12 Jun 2009 02:06:58 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 001913A6870 for ; Fri, 12 Jun 2009 02:06:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,208,1243810800"; d="scan'208";a="6977740" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 12 Jun 2009 10:07:05 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n5C975p9026032; Fri, 12 Jun 2009 10:07:05 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 10:07:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 2009 10:07:04 +0100 Message-ID: In-Reply-To: <9E0E279861121E408614812D358017B60191013B40@astana.unik.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: AcnqheKhXqNBw7yFTbSu2tx0SReMgAAHm2lFACYP0/A= References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr><4A30D67A.7050702@net.ie.niigata-u.ac.jp>, <4A30E8AE.4080807@inria.fr> <9E0E279861121E408614812D358017B60191013B40@astana.unik.no> From: "Dearlove, Christopher (UK)" To: "Lars Landmark" , "jacquet" , "Lee Speakman" X-OriginalArrivalTime: 12 Jun 2009 09:07:05.0240 (UTC) FILETIME=[27F0E180:01C9EB3D] Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 09:06:59 -0000 > According to the reference 6 in Lee's draft, on page 1217 figure 5a, > majority of the loops are formed over "2-way". Instant TC messages > would only help loops formed over three hops or more. Hence, instant > TC messages would only have small contribution, or am I wrong? TC-message created Topology Tuples are also used for links from 1-hop to 2-hop neighbours. There are good reasons for this in the steady state (using MPRs - which is good because it makes willingness work properly). But there may be an issue in the transient case where the 2-Hop Tuple disappears but the Topology Tuple remains. Teco Boot has suggested a modification to prevent this, and the OLSRv2 authors are considering it (but a higher priority is to get NHDP finished). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From larslan@unik.no Fri Jun 12 05:00:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D343A68A6 for ; Fri, 12 Jun 2009 05:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk1JoaXrSDFu for ; Fri, 12 Jun 2009 05:00:42 -0700 (PDT) Received: from kampala.unik.no (kampala.unik.no [193.156.97.46]) by core3.amsl.com (Postfix) with ESMTP id A0D4A3A6898 for ; Fri, 12 Jun 2009 05:00:41 -0700 (PDT) Received: from astana.unik.no (193.156.97.31) by kampala.unik.no (193.156.97.46) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 12 Jun 2009 14:00:47 +0200 Received: from astana.unik.no ([193.156.97.31]) by astana.unik.no ([193.156.97.31]) with mapi; Fri, 12 Jun 2009 14:00:47 +0200 From: Lars Landmark To: "Dearlove, Christopher (UK)" , jacquet , Lee Speakman Date: Fri, 12 Jun 2009 14:00:46 +0200 Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" Thread-Index: AcnqheKhXqNBw7yFTbSu2tx0SReMgAAHm2lFACYP0/AABgVYAw== Message-ID: <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr><4A30D67A.7050702@net.ie.niigata-u.ac.jp>, <4A30E8AE.4080807@inria.fr> <9E0E279861121E408614812D358017B60191013B40@astana.unik.no>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 12:00:42 -0000 > TC-message created Topology Tuples are also used for links from 1-hop > to 2-hop neighbours. There are good reasons for this in the steady state > (using MPRs - which is good because it makes willingness work properly). > But there may be an issue in the transient case where the 2-Hop Tuple > disappears but the Topology Tuple remains. Teco Boot has suggested a > modification to prevent this, and the OLSRv2 authors are considering it > (but a higher priority is to get NHDP finished). I see, however this point out the importance of operating over similar link= attributes, i.e. using links with different timeouts, within similar hop d= istance, causes different topology maps. It does not mean that topology li= nks are not to be used within the same scope as HELLO links, but they MUST = share the link timeout. >From the wired domain, it exist different proposals for loop preventions. O= ne suggestion is not-via, which will not direct looping packets over this n= ot-via address. A simple method, or a start, would be to route traffic, alr= eady involved in a loop, over an alternative next-hop node knowing to be re= achable to the not-via address. This alternative node address may be retrie= ved from HELLO messages. I am not sure whether this would be a suggestion, = but at least the packets are prevented from being discarded.=20 A curios question, is the loop problem an OLSRv2 issue or does it also appl= y for OLSR?=20 Regards Lars= From hrogge@googlemail.com Fri Jun 12 05:08:08 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36523A6BFE for ; Fri, 12 Jun 2009 05:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c94X8LWSa8by for ; Fri, 12 Jun 2009 05:08:08 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id D9BFA3A68A6 for ; Fri, 12 Jun 2009 05:08:07 -0700 (PDT) Received: by ewy6 with SMTP id 6so2923503ewy.37 for ; Fri, 12 Jun 2009 05:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=CWOnaBcc38nVYYBwoqN+8fdqw0LzzVyYxPjmLIpaxfM=; b=bA76HPvh1eNG5AWY+/JooaNWNCZnnyGIZl1uCoSNTG8mFh6SbdyDoddEPYfZ8W+XUR MBVGZkoVNsBSXsIcu0B8/eZ9HaI7uAqxKzRTvldOdBzcDW21zrlh8BVSZ4VBLDGa0lE/ EhKjiowQJvJN3CnfU/1L71oO2ynOhE3xnOpXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=i4hWOc8Y+mqrtBos9d79UPVBaacgxi5nfDK6LsbmZ+kX147pAQgauna2hDgGZSuLoe NWKAhVRD8iXnbmFpUtb4sPbkkJDBgXXprcgTlYs1YgXP6vzzOtE2TzWX2kyVnSKvHRY3 V6cb5cxiA8uulLcdQgC6iLsAcJrYr3vwjG+bE= Received: by 10.210.128.5 with SMTP id a5mr730398ebd.85.1244808491541; Fri, 12 Jun 2009 05:08:11 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 10sm224247eyd.32.2009.06.12.05.08.10 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 05:08:10 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Fri, 12 Jun 2009 14:08:04 +0200 User-Agent: KMail/1.11.4 (Linux/2.6.30-gentoo; KDE/4.2.4; x86_64; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> In-Reply-To: <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5064033.GOhI0HffYY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906121408.09322.hrogge@googlemail.com> Cc: "Dearlove, Christopher \(UK\)" , jacquet , Lee Speakman Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 12:08:08 -0000 --nextPart5064033.GOhI0HffYY Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Am Freitag 12 Juni 2009 14:00:46 schrieb Lars Landmark: > A curios question, is the loop problem an OLSRv2 issue or does it also > apply for OLSR? It does definitely also apply for OLSR. Henning Rogge --nextPart5064033.GOhI0HffYY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoyRSkACgkQcenvcwAcHWfu+gCfVTOJEsHEITBBnnWoBw7Dfb4N 89gAnA+CaBpVJ34Yoq5GbuudRo51jR8y =HbJv -----END PGP SIGNATURE----- --nextPart5064033.GOhI0HffYY-- From Chris.Dearlove@baesystems.com Fri Jun 12 05:44:05 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B703A63C9 for ; Fri, 12 Jun 2009 05:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-f5iuyOSvoW for ; Fri, 12 Jun 2009 05:44:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 1845F3A6918 for ; Fri, 12 Jun 2009 05:44:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,209,1243810800"; d="scan'208";a="7040227" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 12 Jun 2009 13:44:08 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n5CCi81u032678; Fri, 12 Jun 2009 13:44:08 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 13:44:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 2009 13:44:06 +0100 Message-ID: In-Reply-To: <200906121408.09322.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: AcnrVnYXaD2SsMiTQA+bpwBUtDt8JwABHw/Q References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> <200906121408.09322.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 12 Jun 2009 12:44:07.0934 (UTC) FILETIME=[7A1249E0:01C9EB5B] Cc: Lee Speakman , jacquet Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 12:44:05 -0000 Am Freitag 12 Juni 2009 14:00:46 schrieb Lars Landmark: >> A curios question, is the loop problem an OLSRv2 issue or does it also >> apply for OLSR? > It does definitely also apply for OLSR. Looping is a possibility with any decentralised routing protocol (here, link state protocols) where topological information can become transiently inconsistent. I have however not seen anything that doesn't make me believe the particular issues seen here of large problems aren't the result of poor practices in use of link quality and the failure to use responsive messages well. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From philippe.jacquet@inria.fr Fri Jun 12 06:13:12 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8193A6DFD for ; Fri, 12 Jun 2009 06:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1XJKH9lXqL9 for ; Fri, 12 Jun 2009 06:13:11 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id B84153A68E5 for ; Fri, 12 Jun 2009 06:13:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,209,1243807200"; d="scan'208";a="27925544" Received: from guest-rocq-135050.inria.fr ([128.93.135.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jun 2009 15:13:17 +0200 Message-ID: <4A325647.1040108@inria.fr> Date: Fri, 12 Jun 2009 15:21:11 +0200 From: jacquet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Lee Speakman References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> In-Reply-To: <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:13:12 -0000 Dear Lee, It is still not clear if you properly simulate the instant TC. Instant hellos can only push loops one hop away the failed link but would not suppress them (unless the source is one hop away). What surprise me is this 10% loop reduction means 170 packet transmission less, and you assume it is still smaller than the instant hello overhead. Do you mean you attempt to send more than 170 instant hellos for the same LLN? I think you may have a MAC issue if the first packet loop blocks the transmission of hellos. If this phenomenon is not a simulation artefact (look strange anyhow) then Chris proposal to send instant TC before clearing link in the local routing table may work well and suppress transient loops. Loop Deduction mechanism would locally suppress loops but would not increase delivery rate (since packets don't reach destination). To make it working you must send the instant TC anyhow. Best regards, Philippe Lee Speakman a crit : > Dear Phillipe and Ulrich, > > Firstly, there are several researches we have done with the Instant > Hello. I establish in more detail and more precisely what we have > done before continuing. > > The problem of looping is observed to occur where there are higher > loads in the network, in our case with multiple flows crisscrossing > the network. > If, on an event, we send just one Instant Hello, then in such cases, > due to already circling packets around loops, there is a lesser > probability that surrounding nodes will be able to successfully > receive the Instant Hello compared to when there is little traffic in > the network. > > What we first observed was that a single Instant Hello triggered on > in-node LLN (caused by failure to receive successive link layer > acknowledgements from attempting to forward a unicast packet) made > very little difference in the PDR (end-to-end delivery) and the number > of loops which we were measuring at that time, regardless of if the > packet was scheduled immediately, or using the full jitter interval or > a fraction of it. There were only minor improvements in PDR of a few > percent when network load was such that PDR was down to ~70% in > OLSRv2-LLN which was not very effective. > > As we were just sending one Instant Hello on LLN to explore it in the > use of dissolving loops, we did not use a minimum Hello interval. > > To see if the cause was due to the Instant Hello not being received, > we scheduled multiple Hellos, this reduced the number of loops further > (showing that a single Hello had probably not been well received) but > also increased the overhead. For that simulation with multiple > Instant Hellos in short succession this is where we could get around > ~10% of the loops dissolved, but at the cost of the overhead > increasing as we increased the number of loops, thereby countering any > gains from the reduced number of loops. > > Sorry, I had not intended to confuse when I originally expressed our > observed effects of the use of Instant Hellos. I was only mentioning > this briefly to express under certain scenarios how we find that for > ~90% of the loops the loop comes about from an incoherent perception > of the network between adjacent nodes through their Topology Sets and > so cannot be fixes with an Instant Hello, and that the effect of an > LLN cutting a link that is unphysical is often to cause a change such > that a loop appears not only one link away (an adjacent link), but > also two links or more away from the lost link. > > After studying various packet traces and all nodes Link Set and > Topology Sets to find out why we could never dissolve more than ~10% > of loops in this particularly scenario, we found that the majority of > loops are more than one link-hop away from where the LLN is occur. > The node in which an LLN occurs from dropping a unicast packet only > selects a new route (after removal of that link), forwarding it along > a different path, and further in that path a loop occurs. > > > In more recent simulation, with the same parameters as given in our > published work, we measure the number of nodes that receive each > broadcast packet (control packet). > > This is done for 60 nodes with a maximum mobility of 5m/s (random > waypoint, random mobility between 0 and 5m/s). > > > i. At modest loads, 8 applications (CBR, UDP), then we find that > OLSRv2-LLN has a ~85% PDR (end-to-end delivery) with ~1700 looping > packet observations on average per simulation. > An Instant Hello on LLN gives no improvement in PDR and the number of > loops is approximately the same. An Instant TC on LLN gives the same > result. > > At almost no load, a control packet is on average received by 17.5 > nodes (more in the center, less on the edges), but at a load of 8 apps > this is down to just over 16 nodes. This is worse at the time a > transient looping packet is existing. > > Disregarding Instant Hellos / TCs, we can get real improvements by > simply using a Loop Detection mechanism and discarding the packets > (Packet Discard), bringing the PDR up to ~94.5%, and better > improvements by cutting the link over which a looping packet is > detected (Link Cut), bringing the PDR up to ~96%. > > > ii. At 12 application, where there are more loops, then we find that > OLSRv2-LLN has a ~74% PDR with ~4300 looping packet observations on > average per simulation. > An Instant Hello on LLN gives about a 3% improvement in PDR (to ~77%) > and the number of observed loops is ~3700. An Instant TC on LLN gives > the same result. > > At almost no load, a control packet is on average received by 17.5 > nodes (more in the center, less on the edges), but at a load of 12 > apps this is down to less than 15 nodes. This is worse at the time a > transient looping packet is existing. > > Again, using Packet Discard on Loop Detection brings the PDR up to > ~92.5%, and with Link Cut on Loop Detection we get the PDR up to ~94%. > > > Simply discarding the observed looping packets and the improvement > that has on PDR shows the negative effects of looping packets on > surrounding traffic. > > > We have also looked at Instant Hellos and Instant TC on Loop Detection > which shows some improvement; to 88% PDR (up 3%) for 8 apps (removing > ~24% of loops), and to 79% PDR (up 4%) for 12 apps (removing ~19% if > loops). This appears to become less effective at higher loads. The > looping packet is not discarded nor is the link cut over which the > packet loops, so on every node the looping packet passes an Instant > Hello or TC is generated on Loop Detection. > > None of these Instant Hellos / TCs interrupted any of the periodic > scheduling of the control packet broadcasts but were done "extra." > > > Cheers, > Lee -S- > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > From hrogge@googlemail.com Fri Jun 12 06:16:18 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2533A6CFF for ; Fri, 12 Jun 2009 06:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXxlLJPai7Xw for ; Fri, 12 Jun 2009 06:16:17 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 762BA3A6A16 for ; Fri, 12 Jun 2009 06:16:17 -0700 (PDT) Received: by ewy6 with SMTP id 6so2976720ewy.37 for ; Fri, 12 Jun 2009 06:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=p9+RbS3LDkV31VP11lA/UpRadO5PZcUMI6/4iz0Zo30=; b=wXUe3EpO6Wx0qh1mDviCuT9XqxFjQAd6w8swnukpVjzFxCi+PDYBdG7OHu9lCR/2sy Oi53NZRKcBo8HOtM8gfGEmhYAYYRz1z+Fa8kkTJHhQV70Zf6Qudpke8SgwP9b7SQGofd tKDHfqFX/fve5twuXOxzfupdarvhl/pNpEFDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=pfPjqLY3rI2ZnNPcoRhTYdTSoNxtNHiI5WfL4XJmcpncxUym0Q8beiO2wmy+kbhZ/8 33C58MPuJ/lKIWmKPMooTA7W5bRh0LgT71/QoQgw0swIVFhRjTBHJyMkfI4sXAeR27El OyAXpcx9ReeUXstSSAhB+dUU570qymEmaSrks= Received: by 10.210.28.18 with SMTP id b18mr4404054ebb.22.1244812582929; Fri, 12 Jun 2009 06:16:22 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 10sm1513717eyd.42.2009.06.12.06.16.22 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 06:16:22 -0700 (PDT) From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Fri, 12 Jun 2009 15:16:16 +0200 User-Agent: KMail/1.11.4 (Linux/2.6.30-gentoo; KDE/4.2.4; x86_64; ; ) References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <200906121408.09322.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17056063.XbbuhKrHDp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906121516.21093.hrogge@googlemail.com> Cc: Lee Speakman , manet@ietf.org, jacquet Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:16:18 -0000 --nextPart17056063.XbbuhKrHDp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag 12 Juni 2009 14:44:06 schrieb Dearlove, Christopher (UK): > Am Freitag 12 Juni 2009 14:00:46 schrieb Lars Landmark: >>> A curios question, is the loop problem an OLSRv2 issue or does it >>> also apply for OLSR? > > > > It does definitely also apply for OLSR. > > Looping is a possibility with any decentralised routing > protocol (here, link state protocols) where topological > information can become transiently inconsistent. Yes. > I have however not seen anything that doesn't make me > believe the particular issues seen here of large problems > aren't the result of poor practices in use of link quality > and the failure to use responsive messages well. The problem with big networks is that you have choose a tradeoff between=20 network resources and responsiveness of the network. Henning --nextPart17056063.XbbuhKrHDp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoyVSUACgkQcenvcwAcHWddLACfSeqX4165XBYVuHNQ6tBnSPTC sMwAn34hKLBRLEvEiqnxO4TNlgfcuPKj =rZQ+ -----END PGP SIGNATURE----- --nextPart17056063.XbbuhKrHDp-- From Chris.Dearlove@baesystems.com Fri Jun 12 06:21:58 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0393A6CFF for ; Fri, 12 Jun 2009 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvBD4OzgQ9Ee for ; Fri, 12 Jun 2009 06:21:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 0B25B3A6A16 for ; Fri, 12 Jun 2009 06:21:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,209,1243810800"; d="scan'208";a="7048654" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 12 Jun 2009 14:22:04 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n5CDM4mJ020960; Fri, 12 Jun 2009 14:22:04 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 14:22:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 2009 14:22:03 +0100 Message-ID: In-Reply-To: <200906121516.21093.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" thread-index: AcnrX/0skXk1xW3CQceMBKNSltZGfQAAB5yQ References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <200906121408.09322.hrogge@googlemail.com> <200906121516.21093.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 12 Jun 2009 13:22:04.0262 (UTC) FILETIME=[C6DE6060:01C9EB60] Cc: Lee Speakman , manet@ietf.org, jacquet Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:21:58 -0000 > The problem with big networks is that you have choose a tradeoff between > network resources and responsiveness of the network. Indeed. And there's a special case of fisheye - or similarly HSLS - that makes an additional tradeoff of short and long distance responsiveness. And no doubt others. But the specific issue discussed here was about how use of link quality in OLSR impacts on this. And that isn't adding up. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ihokelek@telcordia.com Fri Jun 12 08:27:41 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B523A68AA for ; Fri, 12 Jun 2009 08:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfkTagWdzHqg for ; Fri, 12 Jun 2009 08:27:40 -0700 (PDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by core3.amsl.com (Postfix) with ESMTP id AC34D28C17E for ; Fri, 12 Jun 2009 08:27:38 -0700 (PDT) Received: from pya-dte-ieg01.dte.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n5CFRk1v004121 for ; Fri, 12 Jun 2009 11:27:46 -0400 (EDT) X-AuditID: 80601415-00000d340000055c-06-4a3273ef692b Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by pya-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 11:27:43 -0400 Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Fri, 12 Jun 2009 11:27:42 -0400 From: "Hokelek, Ibrahim" To: "'Lars Landmark'" , "Dearlove, Christopher (UK)" , jacquet , Lee Speakman Date: Fri, 12 Jun 2009 11:27:42 -0400 Thread-Topic: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" Thread-Index: AcnqheKhXqNBw7yFTbSu2tx0SReMgAAHm2lFACYP0/AABgVYAwAF/R1Q Message-ID: <563593148DD9A040B93397F642B3C125327DE769DD@rrc-dte-exmb1.dte.telcordia.com> References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp><4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp><4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr><4A30D67A.7050702@net.ie.niigata-u.ac.jp>, <4A30E8AE.4080807@inria.fr> <9E0E279861121E408614812D358017B60191013B40@astana.unik.no>, <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> In-Reply-To: <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:27:41 -0000 >From the wired domain, it exist different proposals for loop preventions. = One suggestion is not-via, which will >not direct looping packets over this= not-via address. A simple method, or a start, would be to route traffic, >already involved in a loop, over an alternative next-hop node knowing to b= e reachable to the not-via address. >This alternative node address may be r= etrieved from HELLO messages. I am not sure whether this would be a >sugges= tion, but at least the packets are prevented from being discarded. >A curios question, is the loop problem an OLSRv2 issue or does it also app= ly for OLSR? When a link is decided as "failed" by a failure detection mechanism running= at the local node (using hello loss mechanism, LLN, or any other), ideally= the nodes affected from this topology change should update their Routing T= ables (RTs) as fast as possible in order to prevent any micro-looping issue= due to this link failure or minimize its effects. It is essential to send = the failure information to the nodes affected from this failure immediately= (other nodes can get this info later). The fast convergence to new RTs can= be achieved using Fast Reroute techniques which usually pre-compute loop-f= ree alternative paths (LFAPs) for anticipated topology changes. However, th= e requirements of a fast reroute technique in MANETs are different than the= wired network, where, i) overhead should be minimal, ii) more frequent fai= lures (specifically multiple simultaneous failures) should be handled, iii)= transient failures need to be handled carefully (e.g., link flapping case)= . There is a clearly benefit of detecting a link failure earlier using link l= ayer information for the case where the link is really failed, however how = to use this information in order to get the maximum benefit requires furthe= r thoughts. Regards, Ibrahim From ogier@earthlink.net Fri Jun 12 10:48:49 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1DF3A69D1 for ; Fri, 12 Jun 2009 10:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zeKeL859NQJ for ; Fri, 12 Jun 2009 10:48:49 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DEF123A68D8 for ; Fri, 12 Jun 2009 10:48:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=b61saFNZvpLd/KCRtRYFEmAWYEvp+gvvaq8vtbisag6OwTzoEoxY7l6CpQRsNQE/; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [66.81.217.26] by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MFAs3-0007o5-Qs; Fri, 12 Jun 2009 13:48:57 -0400 Message-ID: <4A329556.7050805@earthlink.net> Date: Fri, 12 Jun 2009 10:50:14 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <9E0E279861121E408614812D358017B60193665F64@astana.unik.no> <200906121408.09322.hrogge@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a073897a9455599e74bf435c0eb9d478dcb7fc5533b6bef80a715ff925fd11347c062ca0f6ecaa7a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.81.217.26 Cc: manet@ietf.org Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 17:48:49 -0000 Dearlove, Christopher (UK) wrote: >Am Freitag 12 Juni 2009 14:00:46 schrieb Lars Landmark: > > >>>A curios question, is the loop problem an OLSRv2 issue or does it >>> >>> >also > > >>>apply for OLSR? >>> >>> >>It does definitely also apply for OLSR. >> >> > >Looping is a possibility with any decentralised routing >protocol (here, link state protocols) where topological >information can become transiently inconsistent. > > Sure, but there exist MANET protocols where topological (or distance) information never becomes inconsistent. For example, the paper by Perkins and Bhagwat states "At all instants, the DSDV protocol guarantees loop-free paths to each destination." Also, I believe TBRPF will avoid loops with a small modification: the removal of the following feature summarized in Section 5.2 of RFC 3684: "To allow immediate rerouting, the restriction that each link (u,v) in TG must be reported by p(u) is relaxed temporarily if p(u) changes to a neighbor that is not reporting the link." (It is not known how this modification would affect performance, but the point is there are ways to avoid all routing loops.) It is possible that most (or many) of the loops observed by Lee are simply a result of unreliable TC flooding, which would occur even if instant TC messages are sent. If a node several hops from the failed link does not receive the first TC message reporting the failure, it may have to wait 5 or more seconds before receiving the correct information. As Philippe mentioned, instant TC messages need to be sent, and we need to see how much this reduces looping. I think that if an instant hello is sent, then an instant TC should also be sent if the failed link was a topology tuple. In this case, there should be no need to validate a topology tuple based on the 2-hop set. Richard >I have however not seen anything that doesn't make me >believe the particular issues seen here of large problems >aren't the result of poor practices in use of link quality >and the failure to use responsive messages well. > >******************************************************************** >This email and any attachments are confidential to the intended >recipient and may also be privileged. If you are not the intended >recipient please delete it from your system and notify the sender. >You should not copy it or use it for any purpose nor disclose or >distribute its contents to any other person. >******************************************************************** > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet > > > From ghadjich@gmail.com Sun Jun 14 13:09:53 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6E93A6B2E for ; Sun, 14 Jun 2009 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qxmFBCwRZ75 for ; Sun, 14 Jun 2009 13:09:52 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 4866C3A6A14 for ; Sun, 14 Jun 2009 13:09:52 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so891309fge.18 for ; Sun, 14 Jun 2009 13:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=8IjVyYReZGBj7V/4YDNy77W+VYhzrerp3gDWdhRb03I=; b=iEt75bRvPPZhSYsHFQwtHfN1rQ3rFRX/sFyPSSFqSnh2Dt849BE8QO+NniA2CmRa4i RYDBX4TyGYEl6FS7CmQaeWZk2Mhkv9yLciqj/+eOEj2vFtZ2mHqEyq7k/CV+vBhNOwbK Qft+zW8q0uqFMSwHOXaEbZUxTyR/QbX6PPXBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=PpPvpsNKwmR+Dq17BFpVohlFHhIwBkVJ8vMDrnv+/OXDBqION+7MhINfcT+olkzKFb eCP5brLtg4U/k4AVULyIV7uOqCwej5/33Ggc2CyK5EfJ+NpYTJeahZkXaW1W5qVsJLSZ ko0X6/KMH8xz3jvRNTK6qjOdTkYAMyCLdlBMY= MIME-Version: 1.0 Received: by 10.86.92.9 with SMTP id p9mr6078194fgb.15.1245010190879; Sun, 14 Jun 2009 13:09:50 -0700 (PDT) Date: Sun, 14 Jun 2009 23:09:50 +0300 Message-ID: From: George Hadjichristofi To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 15 Jun 2009 08:30:36 -0700 Subject: [manet] mobility models X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 20:12:23 -0000 Dear All, Which are the preferred mobility models for MANETs? Is the random waypoint model still in use? Any help is appreciated. Regards, George -- GH From Thabotharan.Kathiravelu@it.uu.se Mon Jun 15 12:14:06 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8803A6CC0 for ; Mon, 15 Jun 2009 12:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCkJNWXia6WQ for ; Mon, 15 Jun 2009 12:14:04 -0700 (PDT) Received: from klais.its.uu.se (klais.its.uu.se [130.238.7.59]) by core3.amsl.com (Postfix) with ESMTP id D8CD63A6CBD for ; Mon, 15 Jun 2009 12:14:03 -0700 (PDT) Received: from dhcp-8-198.it.uu.se (dhcp-8-198.it.uu.se [130.238.8.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by klais.its.uu.se (Postfix) with ESMTP id 6527C382B4D for ; Mon, 15 Jun 2009 21:13:48 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v0.6.4 klais.its.uu.se 6527C382B4D DKIM-Signature: v=0.5; a=rsa-sha256; c=simple/simple; d=uu.se; s=centralsmtp; t=1245093228; bh=I/pi7BWyKuIdLPlPqzEqHS3/wcodt6tpnNY O70v+xbc=; h=Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer:X-Virus-Scanned; b=OFzaSPFAi4GkZroLcvZhpBEN3cmE0W6aRfCq7k 69ATUtntHeiG5j/53e29HIvt9VUuMdw4KprBWqWb0gw2gice1b+WXRTdQBH+UO2247b Lbt4t1Y2NbWtaSkaLBDpScilJ8Jej3mfCoQnR9x+tldyi8Xs9MYiABo+lf6VSnVDRg= Message-Id: <4E6500BB-A95B-4640-B46D-337277120FFD@it.uu.se> From: Thabotharan Kathiravelu To: manet@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 21:13:47 +0200 References: X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: Debian amavisd-new at klais.its.uu.se X-Mailman-Approved-At: Tue, 16 Jun 2009 08:02:58 -0700 Subject: Re: [manet] mobility models X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:29:51 -0000 Hi George, Yes still few people use RWP, but it is often criticized by other researchers. Another one is : A. Jardosh, E. M. Belding-Royer, K. C. Almeroth, and S. Suri. Real world Environment Models for Mobile Ad hoc Networks. IEEE Journal on Special Areas in Communications - Special Issue on Wireless Ad hoc Networks, 23(3), March 2005. A recent one by Musolesi et al is : Musolesi, Mirco and Mascolo, Cecilia, A community based mobility model for ad hoc network research, REALMAN '06: Proceedings of the 2nd international workshop on Multi-hop ad hoc networks: from theory to reality, 2006, Just google for the name Mirco musolesi and you will find some of their recent works. > Dear All, > Which are the preferred mobility models for MANETs? Is the random > waypoint model still in use? > Any help is appreciated. > Regards, > George Hope it helps. /Thabo K ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thabotharan Kathiravelu PhD Student, Division of Computer Systems, Department of Information Technology, Box 337, Uppsala University, 751 05 Uppsala , Sweden. Phone Off: 0046 18 471 6231 Mobile: 0046 70 435 7673 skype: thabo2006 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From aschenbruck@cs.uni-bonn.de Tue Jun 16 08:31:36 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7203A6969 for ; Tue, 16 Jun 2009 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=1.484, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umwF7UVOXrkZ for ; Tue, 16 Jun 2009 08:31:35 -0700 (PDT) Received: from postfix.iai.uni-bonn.de (postfix.iai.uni-bonn.de [131.220.8.4]) by core3.amsl.com (Postfix) with ESMTP id 9171A3A691F for ; Tue, 16 Jun 2009 08:31:35 -0700 (PDT) X-IAI-Env-From: : [131.220.243.84] Received: from [131.220.243.84] (unknown [131.220.243.84]) by postfix.iai.uni-bonn.de (Postfix) with ESMTP id D25E05C82D; Tue, 16 Jun 2009 17:30:31 +0200 (MEST) (envelope-from aschenbruck@cs.uni-bonn.de) (envelope-to VARIOUS) (3) (internal use: ta=1, tu=1, te=1, am=P, au=na) Message-ID: <4A37BA94.9070301@cs.uni-bonn.de> Date: Tue, 16 Jun 2009 17:30:28 +0200 From: Nils Aschenbruck User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: George Hadjichristofi References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 Jun 2009 08:12:15 -0700 Cc: manet@ietf.org Subject: Re: [manet] mobility models X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:39:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi George, maybe our motion generator BonnMotion is of some interest for you: http://bonnmotion.iv.cs.uni-bonn.de/ We published a new release last week. Regards Nils - -- Nils Aschenbruck University of Bonn Tel: +49-228-73-4117 Institute of Computer Science IV Fax: +49-228-73-4571 Roemerstr. 164 E-mail: aschenbruck@cs.uni-bonn.de 53117 Bonn http://iv.cs.uni-bonn.de/na/ George Hadjichristofi wrote on 06/14/2009 10:09 PM: > Dear All, > > Which are the preferred mobility models for MANETs? Is the random > waypoint model still in use? > Any help is appreciated. > > Regards, > George > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3upQACgkQ7yFWoQPJHpl2XwCfVuL2rE8JPkWWw+4q5w2sLSHu 7vsAnjtDV/MPe6bLfJYZKLWmEx3K0d9g =efWm -----END PGP SIGNATURE----- From cc1986x@gmail.com Sun Jun 21 20:30:37 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5A128C138 for ; Sun, 21 Jun 2009 20:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOH+jgJqTxJD for ; Sun, 21 Jun 2009 20:30:36 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id C8F6D28C142 for ; Sun, 21 Jun 2009 20:30:36 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1260917ywj.49 for ; Sun, 21 Jun 2009 20:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Zz7tcURtCCG7yoxlbtT7Y2FeCeNVo15gi7WWxbFIoFM=; b=tf7T2blF9Mo8593pDmkjoyANRLZJTGwnzJthiMibKJzQajqnWGLIjmIBm9Tz2YXbP3 GrtJ02Ftb6EvFiXDWJ8WRo4kWTJdC8BuGwLnyEkKMcsi4+6b+fXLqfdKezx7v59Ol3pO W92Ay3wRe6DgdmfdPpMcCsfPVMyJ9W4c/KN6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Hg/2xEjLAKfH/c9cQa4TCbsFEVO1rJJT2kFutNj7x3BSAyTIAN7XiMlLMK3WiOLaPl aehaa52rVzYQ5pHDw7RxhQ0TNAAMqOT4xuCDuuyyfLBVvSAgiRL5NNUUzHPOi2HzgQRN ZWtqgOxuMqgFY1h2x6AGF9VSBHEDMGRpSo0W0= MIME-Version: 1.0 Received: by 10.231.40.4 with SMTP id i4mr1771955ibe.18.1245641449389; Sun, 21 Jun 2009 20:30:49 -0700 (PDT) Date: Mon, 22 Jun 2009 11:30:49 +0800 Message-ID: <3b07a9230906212030o3c57a8ftcad51afde35a5454@mail.gmail.com> From: chenchen chen To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [manet] about aodv local repair X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 03:32:31 -0000 hello, is aodv loacl repair visible to the source of the established node? whether the hop count in the route table of the source node will alter according to the new route. thanks chen From themq15@yahoo.com Tue Jun 23 06:59:43 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435BE28C0DC for ; Tue, 23 Jun 2009 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYuOvL4jpLGu for ; Tue, 23 Jun 2009 06:59:42 -0700 (PDT) Received: from n65.bullet.mail.sp1.yahoo.com (n65.bullet.mail.sp1.yahoo.com [98.136.44.190]) by core3.amsl.com (Postfix) with SMTP id AD94B3A6B32 for ; Tue, 23 Jun 2009 06:59:42 -0700 (PDT) Received: from [216.252.122.216] by n65.bullet.mail.sp1.yahoo.com with NNFMP; 23 Jun 2009 13:59:57 -0000 Received: from [69.147.84.109] by t1.bullet.sp1.yahoo.com with NNFMP; 23 Jun 2009 13:59:57 -0000 Received: from [127.0.0.1] by omp207.mail.sp1.yahoo.com with NNFMP; 23 Jun 2009 13:59:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 618718.64737.bm@omp207.mail.sp1.yahoo.com Received: (qmail 35733 invoked by uid 60001); 23 Jun 2009 13:59:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245765597; bh=laQze0NmfeGaTSHhyay4ruTovj+nYSt1na4Wigl2aEE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=5hFG3ZdST8AnfVndnenm4v14ZsDQRO7cmNTZWr2VZwptK2OPa1hriv7jxT4lg25mgmD3YXmtlSquORE3UL4nniFwUCgiIog7XP4Er5eIqIpCXDKt/PFTDP2zb6V7Ey2oUhi+cSrOMjuARaywO1qXe9tcrVuYNyKYTH51eHv7dL8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=tOptr4Dgbolifi5xB3AaJGFY4L+hfD+zwsUJKFLw0234r1f9bANH6XBQd3YGZZueKUbS78pIoCNMqTpoGaeP1wSdtKK7ggKe7VoBzZ84KM7L55NX4lF4vU3J562ogLXgET24tjdTPDIxyg/jbkk8STnTwcot6DPUG9SdjCrIPY0=; Message-ID: <329644.31013.qm@web43401.mail.sp1.yahoo.com> X-YMail-OSG: 7yOxPQwVM1ngLMnjvThYi6lzuvzG39m5jFjcJ9cJxnheOtfHJtI3YrzlZ4eiXhW_M1xxvz_0TSGuchz5Lf6Wa1QthBtvO68KzcizvI1Wve.oWPsf5e_LK7SW1PxABMZBoiWDWUF9KijYzVWrpkoBViFCe3lJpQGRa_ScgWfeAHVEgqhIMJqTFK4Stnwnql4D4tADePc7ZeFB37bHuYePt.2E6MKLk.EtjtPHxfW3jOeckGMZKtAFv5mcKIjHtiuS.DrKkTXQ3JV_upkdzLw6GtzOcSnrsTTe9HZ923OzkbvWv6sF_XoWKMHogoM9jzFp_hlOatlaY0LIYEeV_PmdgEKLW_ZpHr4s81uinPgUq7DAraPOw9YYryVvbWEgHtYiYR9kD.6HDk24je5WxLQV5mVpTPKmgGcWbOPrc9X8RyeO2wqygsBPcOtKghk.j8VJyOOY6Dmj5zKcsTGJvoEHV5igrJD2eONsZ7Hmb9k2MBwFkhoSmDwtoqfFfo67.THtFAZo9Kl22nyy7BhK_EHOjUJCcEgBFDCLfU7jsgajIISCFTBnzQiENQF_gN4EJV1r75Kxp0Nhcl.USiSACywE5Eq3ePNasAMZUtVnP7d_duG.k6xmTNkIUB0Q_eUdOwxnhF6m7CpeSaKg0LegTGTm7ZZAgGR7vI73cy37XNafW8hoJ5X19KDzTp.UN5xUAmYmJ1W56Ie7vgV6hT_xGItrOxSzIKrBCehKUjKYHDM4lPyqpI.d_limVtf0TeC6S.Derwdl586ZsjyNYSwUOoBJmeECwB6dc.tTsgeiYENT Received: from [116.71.223.151] by web43401.mail.sp1.yahoo.com via HTTP; Tue, 23 Jun 2009 06:59:57 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.15 Date: Tue, 23 Jun 2009 06:59:57 -0700 (PDT) From: Bringo Shawn To: IETFManet MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1883357206-1245765597=:31013" Subject: [manet] What are Short Range and Long Rang Links? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 13:59:43 -0000 --0-1883357206-1245765597=:31013 Content-Type: text/plain; charset=us-ascii Helo friends, Please someone get me understand what are short range and long range links (routing point of view ). Regards. --0-1883357206-1245765597=:31013 Content-Type: text/html; charset=us-ascii
Helo friends,
Please someone get me understand what are short range and long range links (routing point of view ).
Regards.

--0-1883357206-1245765597=:31013--