From hrogge@googlemail.com Tue Oct 13 08:41: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 7DA3B3A69A9 for ; Tue, 13 Oct 2009 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 5Kq-TuCSjonR for ; Tue, 13 Oct 2009 08:41:52 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 20D633A68EB for ; Tue, 13 Oct 2009 08:41:51 -0700 (PDT) Received: by ewy4 with SMTP id 4so3497933ewy.37 for ; Tue, 13 Oct 2009 08:41:51 -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:mime-version:content-type:content-transfer-encoding :message-id; bh=TmvE6itYbFQQpmc+haXBYQXWseTJOz291dyqLQiELCQ=; b=WReH3Z3gnT39vr5P7+CVz1cBAZbSxSSpBmwYluFF1L0m3B3RyKno8d53BUzS9eQG7B uaASULADaEot83uXc06HxmkdxNNWTPg44yWyQTfx7TMIP9Ex7916TRYypR8XFIU2SMyn 70Bz8O120j07gV1xDJgvrSlDHGdxSQs3OKJSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=PLCCU80XuLZgwSWo5olxeohDwJAJechsLj0I63ParNe6uyqog3a2mRym5eNOo0gTdr XhsRR82U60RY7tQdWaALhyiIE2z1ckKeQhqN/iTV7gqU/Pj18rY0kM7FGwuxEwl2gYSj fq8zin0u0BZ3TbEarxiWWtFG3qkG9T078JkDY= Received: by 10.216.89.146 with SMTP id c18mr2444044wef.84.1255448511178; Tue, 13 Oct 2009 08:41:51 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm981847eyh.1.2009.10.13.08.41.49 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Oct 2009 08:41:50 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Tue, 13 Oct 2009 17:41:29 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5169261.N1CbeOBdOn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910131741.49152.hrogge@googlemail.com> Subject: [manet] Default metric in OLSRv2 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, 13 Oct 2009 15:41:54 -0000 --nextPart5169261.N1CbeOBdOn Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I know this mail comes a little bit early (metrics have not been merged int= o=20 OLSRv2 draft), but I would like to like to argue for more than "include=20 generic metric support in OLSRv2". Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a=20 conference about military communications. There were a couple of presentati= ons=20 which used OLSR as a mesh net protocol and they can be summarized as: "OLSR= =20 does not work well". When I tried to get some more facts about this I quick= ly=20 recognized that all of them used hopcount metrics "because it's the default= =20 described in the RFC". I think this was a mistake in the OLSRv1 RFC, it described a protocol that = did=20 not work very well in the real world because of hopcount metrics. No amount= of=20 great research for new metric or improved features have changed this later,= =20 because most people USING OLSR for their research will use the stuff descri= bed=20 in the default RFC. We should not do the same mistake in the OLSRv2 RFC. My suggestion is: include a simple version of ETX as an example metric into the OLSRv2 RFC. Why ETX ? Why not ETT/SNR/MIC/.... ? ETX is not the best metric out there, it's a very basic one. But it's VERY= =20 easy to describe and implement, it's independant from the layer 1/2 below O= LSR=20 and it allows to build much better real world networks than hopcount. I kno= w=20 no other metric that can provide these three advantages. We should add a few sentences into the chapter that this will be just the=20 "lowest common metric" which should work with all OLSRv2 agents and that th= ere=20 are much better and more specialized metrics described in other documents a= nd=20 research papers. But if we do not put a real metric into the RFC we will ha= ve=20 people saying "OLSRv2 does not work well" in years, just because they do th= eir=20 comparision based on the RFC implementation (hopcount). If there is a consensus on this I can easily write description of a simple= =20 Hello-Message based ETX implementation with a single tuning parameter for t= he=20 draft. What do you think ? Henning Rogge --nextPart5169261.N1CbeOBdOn 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) iEYEABECAAYFAkrUn70ACgkQcenvcwAcHWfMbQCfQ8db7316ctMoK45FkeamTLq7 sAEAoIZhSzI6/7yugMxRG+CyNxIprQ5M =/vl1 -----END PGP SIGNATURE----- --nextPart5169261.N1CbeOBdOn-- From aaron@lo-res.org Tue Oct 13 08:59: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 0738D28C16D for ; Tue, 13 Oct 2009 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.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 1A9Q56y3lxIe for ; Tue, 13 Oct 2009 08:59:30 -0700 (PDT) Received: from mute.lo-res.org (mute.lo-res.org [193.238.157.69]) by core3.amsl.com (Postfix) with ESMTP id 512FE28C1E3 for ; Tue, 13 Oct 2009 08:59:30 -0700 (PDT) Received: from ultrastabil.lan (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id 40844CE2053; Tue, 13 Oct 2009 18:01:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed From: "L. Aaron Kaplan" In-Reply-To: <200910131741.49152.hrogge@googlemail.com> Date: Tue, 13 Oct 2009 17:59:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200910131741.49152.hrogge@googlemail.com> To: Henning Rogge X-Mailer: Apple Mail (2.1076) Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 13 Oct 2009 15:59:31 -0000 > > > What do you think ? > ACK!! --- there's no place like 127.0.0.1 (=FC=E4=F6) From Chris.Dearlove@baesystems.com Wed Oct 14 01:32: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 5DC533A685B for ; Wed, 14 Oct 2009 01:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 8H4VHZrKtc6b for ; Wed, 14 Oct 2009 01:32:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id B84293A6873 for ; Wed, 14 Oct 2009 01:32:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,556,1249254000"; d="scan'208";a="27316497" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Oct 2009 09:32:27 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9E8WWvh019896; Wed, 14 Oct 2009 09:32:32 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Oct 2009 09:32:27 +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, 14 Oct 2009 09:32:26 +0100 Message-ID: In-Reply-To: <200910131741.49152.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpMG7btza81zxumTMetnWlLVZCa4AAjINBw References: <200910131741.49152.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 14 Oct 2009 08:32:27.0267 (UTC) FILETIME=[DC985D30:01CA4CA8] Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 08:32:31 -0000 I do not believe that a specific metric such as ETX should be in the base OLSRv2 draft. As you say, the first question would be "why ETX?". But not that the default will be a metric whose meaning is implementation specific, not hop count (which would be the default default so to speak if no one includes any metric information). But that said, I would be delighted to see an Internet Draft (which could be adopted and taken all the way to RFC in parallel if that is the WG consensus) which described ETX, and maybe one or two other, metrics and how to adopt them to the OLSRv2 metrics TLV. This work could even start now referencing draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2 when folded in to that. This would be valuable support for the metric concept. -- 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 13 October 2009 16:41 To: manet@ietf.org Subject: [manet] Default metric in OLSRv2 Hello, I know this mail comes a little bit early (metrics have not been merged into OLSRv2 draft), but I would like to like to argue for more than "include generic metric support in OLSRv2". Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a conference about military communications. There were a couple of presentations which used OLSR as a mesh net protocol and they can be summarized as: "OLSR does not work well". When I tried to get some more facts about this I quickly recognized that all of them used hopcount metrics "because it's the default described in the RFC". I think this was a mistake in the OLSRv1 RFC, it described a protocol that did not work very well in the real world because of hopcount metrics. No amount of great research for new metric or improved features have changed this later, because most people USING OLSR for their research will use the stuff described in the default RFC. We should not do the same mistake in the OLSRv2 RFC. My suggestion is: include a simple version of ETX as an example metric into the OLSRv2 RFC. Why ETX ? Why not ETT/SNR/MIC/.... ? ETX is not the best metric out there, it's a very basic one. But it's VERY easy to describe and implement, it's independant from the layer 1/2 below OLSR and it allows to build much better real world networks than hopcount. I know no other metric that can provide these three advantages. We should add a few sentences into the chapter that this will be just the "lowest common metric" which should work with all OLSRv2 agents and that there are much better and more specialized metrics described in other documents and research papers. But if we do not put a real metric into the RFC we will have people saying "OLSRv2 does not work well" in years, just because they do their comparision based on the RFC implementation (hopcount). If there is a consensus on this I can easily write description of a simple Hello-Message based ETX implementation with a single tuning parameter for the draft. What do you think ? Henning Rogge ******************************************************************** 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 Wed Oct 14 01:35:56 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 B20363A6881 for ; Wed, 14 Oct 2009 01:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.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 O5Wd8KCpDwod for ; Wed, 14 Oct 2009 01:35:55 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 4CEA53A67CC for ; Wed, 14 Oct 2009 01:35:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,556,1249254000"; d="scan'208";a="27317916" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Oct 2009 09:35:57 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9E8a2cD022656; Wed, 14 Oct 2009 09:36:02 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:35:56 +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: quoted-printable Date: Wed, 14 Oct 2009 09:35:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpMG7btza81zxumTMetnWlLVZCa4AAjINBwAAAzGLA= References: <200910131741.49152.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 14 Oct 2009 08:35:56.0566 (UTC) FILETIME=[5958DB60:01CA4CA9] Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 08:35:56 -0000 In my third line below not should be note. I also omitted to say that an initial draft on specific metrics could provide more background (such as "why ETX" and references to what's been done) than would be appropriate in the main OLSRv2 specification. --=20 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, Christopher (UK) Sent: 14 October 2009 09:32 To: Henning Rogge; manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. I do not believe that a specific metric such as ETX should be in the base OLSRv2 draft. As you say, the first question would be "why ETX?". But not that the default will be a metric whose meaning is implementation specific, not hop count (which would be the default default so to speak if no one includes any metric information).=20 But that said, I would be delighted to see an Internet Draft (which could be adopted and taken all the way to RFC in parallel if that is the WG consensus) which described ETX, and maybe one or two other, metrics and how to adopt them to the OLSRv2 metrics TLV. This work could even start now referencing draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2 when folded in to that. This would be valuable support for the metric concept. --=20 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 13 October 2009 16:41 To: manet@ietf.org Subject: [manet] Default metric in OLSRv2 Hello, I know this mail comes a little bit early (metrics have not been merged into=20 OLSRv2 draft), but I would like to like to argue for more than "include=20 generic metric support in OLSRv2". Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a=20 conference about military communications. There were a couple of presentations=20 which used OLSR as a mesh net protocol and they can be summarized as: "OLSR=20 does not work well". When I tried to get some more facts about this I quickly=20 recognized that all of them used hopcount metrics "because it's the default=20 described in the RFC". I think this was a mistake in the OLSRv1 RFC, it described a protocol that did=20 not work very well in the real world because of hopcount metrics. No amount of=20 great research for new metric or improved features have changed this later,=20 because most people USING OLSR for their research will use the stuff described=20 in the default RFC. We should not do the same mistake in the OLSRv2 RFC. My suggestion is: include a simple version of ETX as an example metric into the OLSRv2 RFC. Why ETX ? Why not ETT/SNR/MIC/.... ? ETX is not the best metric out there, it's a very basic one. But it's VERY=20 easy to describe and implement, it's independant from the layer 1/2 below OLSR=20 and it allows to build much better real world networks than hopcount. I know=20 no other metric that can provide these three advantages. We should add a few sentences into the chapter that this will be just the=20 "lowest common metric" which should work with all OLSRv2 agents and that there=20 are much better and more specialized metrics described in other documents and=20 research papers. But if we do not put a real metric into the RFC we will have=20 people saying "OLSRv2 does not work well" in years, just because they do their=20 comparision based on the RFC implementation (hopcount). If there is a consensus on this I can easily write description of a simple=20 Hello-Message based ETX implementation with a single tuning parameter for the=20 draft. What do you think ? Henning Rogge ******************************************************************** 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 emmanuel.baccelli@gmail.com Wed Oct 14 02:18: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 1B0CA3A6832 for ; Wed, 14 Oct 2009 02:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 93xgcTXTT19o for ; Wed, 14 Oct 2009 02:18:35 -0700 (PDT) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id 6919128C103 for ; Wed, 14 Oct 2009 02:18:35 -0700 (PDT) Received: by ywh27 with SMTP id 27so3960693ywh.31 for ; Wed, 14 Oct 2009 02:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=MUYSik30HPKPDA3rtzhVP+ox5z3XB94Ne0Y7Y6YrifA=; b=iwUYcdNF0/aZitVRlPjmipYxtnvxgqTbyPe5O0op1amGHSnn6TXvvHPZAdCZWpyKyM 6kzY+AwcdSKm7GoMsDL9z6xOwbes0EuSHd1zypRLfVlsD6vcD8peTDKCjvn3hAGk/v0C E3uGLh6icenQOkS3hFq1E9aurYjNWhCJw6Oew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=BU+YacvFCp6nYgnhvBbn6IYpjkbBp/pI/GhpPOYvjzBPdLQqWBsP7NZ8x18aGUsrW0 B0f0Q/oFgyR7y+uneCNeFykm+A6NXFZ/oCkOudC2nFVOsf22RvBkX4jIz1AYcSbUNHvw 9a9nPfW4fmcQU2P5P2eZ2OW6bWbNqHivdISTA= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.54.22 with SMTP id g22mr5017851agk.80.1255511914103; Wed, 14 Oct 2009 02:18:34 -0700 (PDT) In-Reply-To: References: <200910131741.49152.hrogge@googlemail.com> From: Emmanuel Baccelli Date: Wed, 14 Oct 2009 11:18:14 +0200 X-Google-Sender-Auth: 85e27262c8288cd6 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=001485f89e52a6c4190475e1a5b3 Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 09:18:37 -0000 --001485f89e52a6c4190475e1a5b3 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, I guess that what Henning was saying is: it would be nice to have a simple example of metric other than hop-count in the core doc. I also think it is a good idea. It is also necessary to have a companion doc that will be more exhaustive about metrics. But I agree with Henning: it would be unfortunate that people implementing the core spec may get the wrong impression about performance just because the hop-count metric is used because no-one gives them the hint "see, you can try other metrics too". As far as I'm concerned ETX is not a bad choice for such an example. I'm OK with other metrics too, as long as they are indeed simple to implement and all-terrain (independant of lower layers). Cheers, Emmanuel On Wed, Oct 14, 2009 at 10:35 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > In my third line below not should be note. > > I also omitted to say that an initial draft on specific > metrics could provide more background (such as "why ETX" > and references to what's been done) than would be > appropriate in the main OLSRv2 specification. > > -- > 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Dearlove, Christopher (UK) > Sent: 14 October 2009 09:32 > To: Henning Rogge; manet@ietf.org > Subject: Re: [manet] Default metric in OLSRv2 > > > *** WARNING *** > > This message has originated outside your organisation, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > I do not believe that a specific metric such as ETX should > be in the base OLSRv2 draft. As you say, the first question > would be "why ETX?". But not that the default will be a metric > whose meaning is implementation specific, not hop count (which > would be the default default so to speak if no one includes > any metric information). > > But that said, I would be delighted to see an Internet Draft > (which could be adopted and taken all the way to RFC in parallel > if that is the WG consensus) which described ETX, and maybe one > or two other, metrics and how to adopt them to the OLSRv2 metrics > TLV. This work could even start now referencing > draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2 > when folded in to that. This would be valuable support for the > metric concept. > > -- > 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Henning Rogge > Sent: 13 October 2009 16:41 > To: manet@ietf.org > Subject: [manet] Default metric in OLSRv2 > > Hello, > > I know this mail comes a little bit early (metrics have not been merged > into > OLSRv2 draft), but I would like to like to argue for more than "include > generic metric support in OLSRv2". > > Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a > conference about military communications. There were a couple of > presentations > which used OLSR as a mesh net protocol and they can be summarized as: > "OLSR > does not work well". When I tried to get some more facts about this I > quickly > recognized that all of them used hopcount metrics "because it's the > default > described in the RFC". > > I think this was a mistake in the OLSRv1 RFC, it described a protocol > that did > not work very well in the real world because of hopcount metrics. No > amount of > great research for new metric or improved features have changed this > later, > because most people USING OLSR for their research will use the stuff > described > in the default RFC. We should not do the same mistake in the OLSRv2 RFC. > > My suggestion is: > include a simple version of ETX as an example metric into the OLSRv2 > RFC. > > Why ETX ? Why not ETT/SNR/MIC/.... ? > > ETX is not the best metric out there, it's a very basic one. But it's > VERY > easy to describe and implement, it's independant from the layer 1/2 > below OLSR > and it allows to build much better real world networks than hopcount. I > know > no other metric that can provide these three advantages. > > We should add a few sentences into the chapter that this will be just > the > "lowest common metric" which should work with all OLSRv2 agents and that > there > are much better and more specialized metrics described in other > documents and > research papers. But if we do not put a real metric into the RFC we will > have > people saying "OLSRv2 does not work well" in years, just because they do > their > comparision based on the RFC implementation (hopcount). > > If there is a consensus on this I can easily write description of a > simple > Hello-Message based ETX implementation with a single tuning parameter > for the > draft. > > What do you think ? > > Henning Rogge > > ******************************************************************** > 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 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001485f89e52a6c4190475e1a5b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Chris,

I guess that what Henning was saying is: it would be= nice to have a simple example of metric other than hop-count in the core d= oc. I also think it is a good idea. It is also necessary to have a companio= n doc that will be more exhaustive about metrics.=A0

But I agree with Henning: it would be unfortunate that = people implementing the core spec may get the wrong impression about perfor= mance just because the hop-count metric is used because no-one gives them t= he hint "see, you can try other metrics too". As far as I'm c= oncerned ETX is not a bad choice for such an example.=A0

I'm OK with other metrics too, as long as they are = indeed simple to implement and all-terrain (independant of lower layers).

Cheers,=A0

Emmanuel


On Wed, Oct 14, 2009 at 10:35 AM, D= earlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
In my third line below not should be note.<= br>
I also omitted to say that an initial draft on specific
metrics could provide more background (such as "why ETX"
and references to what's been done) than would be
appropriate in the main OLSRv2 specification.

--
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 =A0Fax: +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: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf
Of Dearlove, Christopher (UK)
Sent: 14 October 2009 09:32
To: Henning Rogge; manet@ietf.org
Subject: Re: [manet] Default metric in OLSRv2


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING ***

=A0This message has originated outside your organisation,
=A0either from an external partner or the Global Internet.
=A0 =A0 =A0Keep this in mind if you answer this message.


I do not believe that a specific metric such as ETX should
be in the base OLSRv2 draft. As you say, the first question
would be "why ETX?". But not that the default will be a metric whose meaning is implementation specific, not hop count (which
would be the default default so to speak if no one includes
any metric information).

But that said, I would be delighted to see an Internet Draft
(which could be adopted and taken all the way to RFC in parallel
if that is the WG consensus) which described ETX, and maybe one
or two other, metrics and how to adopt them to the OLSRv2 metrics
TLV. This work could even start now referencing
draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2
when folded in to that. This would be valuable support for the
metric concept.

--
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 =A0Fax: +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: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On Behalf
Of Henning Rogge
Sent: 13 October 2009 16:41
To: manet@ietf.org
Subject: [manet] Default metric in OLSRv2

Hello,

I know this mail comes a little bit early (metrics have not been merged
into
OLSRv2 draft), but I would like to like to argue for more than "includ= e
generic metric support in OLSRv2".

Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a
conference about military communications. There were a couple of
presentations
which used OLSR as a mesh net protocol and they can be summarized as:
"OLSR
does not work well". When I tried to get some more facts about this I<= br> quickly
recognized that all of them used hopcount metrics "because it's th= e
default
described in the RFC".

I think this was a mistake in the OLSRv1 RFC, it described a protocol
that did
not work very well in the real world because of hopcount metrics. No
amount of
great research for new metric or improved features have changed this
later,
because most people USING OLSR for their research will use the stuff
described
in the default RFC. We should not do the same mistake in the OLSRv2 RFC.
My suggestion is:
include a simple version of ETX as an example metric into the OLSRv2
RFC.

Why ETX ? Why not ETT/SNR/MIC/.... ?

ETX is not the best metric out there, it's a very basic one. But it'= ;s
VERY
easy to describe and implement, it's independant from the layer 1/2
below OLSR
and it allows to build much better real world networks than hopcount. I
know
no other metric that can provide these three advantages.

We should add a few sentences into the chapter that this will be just
the
"lowest common metric" which should work with all OLSRv2 agents a= nd that
there
are much better and more specialized metrics described in other
documents and
research papers. But if we do not put a real metric into the RFC we will have
people saying "OLSRv2 does not work well" in years, just because = they do
their
comparision based on the RFC implementation (hopcount).

If there is a consensus on this I can easily write description of a
simple
Hello-Message based ETX implementation with a single tuning parameter
for the
draft.

What do you think ?

Henning Rogge

********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--001485f89e52a6c4190475e1a5b3-- From hrogge@googlemail.com Wed Oct 14 02:43: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 16A6B3A67E3 for ; Wed, 14 Oct 2009 02:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 5QltXtxgo2Sp for ; Wed, 14 Oct 2009 02:43:21 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 35F1328C1B0 for ; Wed, 14 Oct 2009 02:43:16 -0700 (PDT) Received: by ewy4 with SMTP id 4so4234108ewy.37 for ; Wed, 14 Oct 2009 02:43:18 -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=F5JC5mZHTHP+rNyd7R3LiG3OeYJiVYD9Wu/FZB7NJLg=; b=K23zPUCADWGwkV5b6P7l/ueMR/elvrhq6wFngSRjJktOXkiU8iLwNyt3JjUMPfZ/Rb BPVFvgkNSci9bsuKoSePp2l4+gCQmLHzPbgNQWXsuqpJmemH1ZDsNqYomvyVG+6mkXU8 YsBmstFm6wlZaLAQ29rR5fSnlxGsdI5tOyGDI= 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=vE4h6ECmENfBHCspcMYnBR1gbCV7+lBO8M92J6ixQqsSvx0z19furnceJ2nsIkwuOJ lw/mkkIwXERfSbr7A3UIl/994ZdLJhAi/JpnBT29Ws2QXA+V2T2voljMgE9nNq1MWl4e xLRL7tRXT2cQ4wyOd4RDbNKJguJLmC0mcX0IQ= Received: by 10.210.155.2 with SMTP id c2mr6956265ebe.23.1255513397869; Wed, 14 Oct 2009 02:43:17 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm1836010eyg.11.2009.10.14.02.43.16 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Oct 2009 02:43:16 -0700 (PDT) From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Wed, 14 Oct 2009 11:43:08 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <200910131741.49152.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2811798.EDF0CcuiKs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910141143.15983.hrogge@googlemail.com> Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 09:43:30 -0000 --nextPart2811798.EDF0CcuiKs Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Mittwoch 14 Oktober 2009 10:32:26 schrieb Dearlove, Christopher (UK): > I do not believe that a specific metric such as ETX should > be in the base OLSRv2 draft. As you say, the first question > would be "why ETX?". But not that the default will be a metric > whose meaning is implementation specific, not hop count (which > would be the default default so to speak if no one includes > any metric information). >=20 > But that said, I would be delighted to see an Internet Draft > (which could be adopted and taken all the way to RFC in parallel > if that is the WG consensus) which described ETX, and maybe one > or two other, metrics and how to adopt them to the OLSRv2 metrics > TLV. This work could even start now referencing > draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2 > when folded in to that. This would be valuable support for the > metric concept. I don't think this will work well for OLSRv2. Most people using OLSRv2 for= =20 research (instead of doing research on OLSRv2) will continue to use the "ba= sic=20 RFC implementation" of OLSR... if the basic RFC does only contain hopcount= =20 they will use hopcount "to have comparable results to other experiments".=20 Which will give them "still does not work well". I think we really need an appendix in the core document (similar to the=20 appendix with an example MPR algorithm) that contains a simple metric=20 algorithm. Without this "RFC conform OLSRv2" will still be nearly unusable. We could use any kind of metric algorithm for this appendix, but ETX is the= =20 only one (I'm aware of) that is a) independant of layer 1/2 b) easy to implement c) creates working mesh networks Hopcount does not provice c). Henning Rogge --nextPart2811798.EDF0CcuiKs 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) iEYEABECAAYFAkrVnTMACgkQcenvcwAcHWdeKwCfcp933keF4t39Vqkeo9inpKy4 940AnRq2uCgiwyfoitit4IrtLuGQD0pg =s64s -----END PGP SIGNATURE----- --nextPart2811798.EDF0CcuiKs-- From Chris.Dearlove@baesystems.com Wed Oct 14 02:48: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 7E36628C1AF for ; Wed, 14 Oct 2009 02:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 i1SwGq8Bay1C for ; Wed, 14 Oct 2009 02:48:42 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 27D8528C1AD for ; Wed, 14 Oct 2009 02:48:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,556,1249254000"; d="scan'208";a="27340766" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Oct 2009 10:48:06 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9E9mBIo011353; Wed, 14 Oct 2009 10:48:11 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 10:48: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: Wed, 14 Oct 2009 10:48:04 +0100 Message-ID: In-Reply-To: <200910141143.15983.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpMssQT7oztWF9FTQmdVWAw4qnOFAAABSvA References: <200910131741.49152.hrogge@googlemail.com> <200910141143.15983.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 14 Oct 2009 09:48:05.0452 (UTC) FILETIME=[6D9070C0:01CA4CB3] Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 09:48:43 -0000 > I don't think this will work well for OLSRv2. Most people using OLSRv2 for > research (instead of doing research on OLSRv2) will continue to use the "basic > RFC implementation" of OLSR... if the basic RFC does only contain hopcount That is not the proposal. See what's written in the metrics draft. (I agree what you indicate would not be acceptable. But that's why that isn't it.) The proposal is that the default is an additive metric of unspecified "real world" meaning. But it's still a metric, and not just hopcount. It's just not a specific ETC/delay/whatever metric. At least not specified as such. In a given deployment if you agree in advance that this is ETX, fine. But if you definitely want ETX then get an allocation of one of the reserved metric code points specifically for that purpose and use that. ******************************************************************** 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 Wed Oct 14 02:53: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 181563A6937 for ; Wed, 14 Oct 2009 02:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 sOX8085uBGag for ; Wed, 14 Oct 2009 02:53:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 37C7528C190 for ; Wed, 14 Oct 2009 02:53:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,556,1249254000"; d="scan'208,217";a="27342387" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Oct 2009 10:53:28 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9E9rXZ6015089; Wed, 14 Oct 2009 10:53:33 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 10:53:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4CB4.2D4FCB8A" Date: Wed, 14 Oct 2009 10:53:26 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpMr1neXJy7ulxSSuOawTApC/BiNgABB+Hg References: <200910131741.49152.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Emmanuel Baccelli" , X-OriginalArrivalTime: 14 Oct 2009 09:53:27.0627 (UTC) FILETIME=[2D9871B0:01CA4CB4] Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 09:53:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4CB4.2D4FCB8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can people please read the draft. Use of just hop count is NOT what is in the proposal. You only get hop count if you don't even use the metric TLV (so you get a default value, and all values default is - for any metric - equivalent to hop count, just not one per hop). =20 And adding more to the base draft is not the way to go. (In fact in an ideal world I'd go in exactly the opposite direction and break the base draft into about three modular pieces.) A specific discussion of the particular merits of specific metrics, and reservation of a code point (group of TLV type extensions) is highly suited as a separate document. --=20 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 =20 ________________________________ From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Emmanuel Baccelli Sent: 14 October 2009 10:18 To: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Hi Chris,=20 I guess that what Henning was saying is: it would be nice to have a simple example of metric other than hop-count in the core doc. I also think it is a good idea. It is also necessary to have a companion doc that will be more exhaustive about metrics.=20 But I agree with Henning: it would be unfortunate that people implementing the core spec may get the wrong impression about performance just because the hop-count metric is used because no-one gives them the hint "see, you can try other metrics too". As far as I'm concerned ETX is not a bad choice for such an example.=20 I'm OK with other metrics too, as long as they are indeed simple to implement and all-terrain (independant of lower layers). Cheers,=20 Emmanuel On Wed, Oct 14, 2009 at 10:35 AM, Dearlove, Christopher (UK) wrote: In my third line below not should be note. =09 I also omitted to say that an initial draft on specific metrics could provide more background (such as "why ETX" and references to what's been done) than would be appropriate in the main OLSRv2 specification. =09 -- 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 =09 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 =09 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf =09 Of Dearlove, Christopher (UK) Sent: 14 October 2009 09:32 To: Henning Rogge; manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 =09 =09 *** WARNING *** =09 This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. =09 I do not believe that a specific metric such as ETX should be in the base OLSRv2 draft. As you say, the first question would be "why ETX?". But not that the default will be a metric whose meaning is implementation specific, not hop count (which would be the default default so to speak if no one includes any metric information). =09 But that said, I would be delighted to see an Internet Draft (which could be adopted and taken all the way to RFC in parallel if that is the WG consensus) which described ETX, and maybe one or two other, metrics and how to adopt them to the OLSRv2 metrics TLV. This work could even start now referencing draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2 when folded in to that. This would be valuable support for the metric concept. =09 -- 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 =09 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 =09 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 13 October 2009 16:41 To: manet@ietf.org Subject: [manet] Default metric in OLSRv2 =09 Hello, =09 I know this mail comes a little bit early (metrics have not been merged into OLSRv2 draft), but I would like to like to argue for more than "include generic metric support in OLSRv2". =09 Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a conference about military communications. There were a couple of presentations which used OLSR as a mesh net protocol and they can be summarized as: "OLSR does not work well". When I tried to get some more facts about this I quickly recognized that all of them used hopcount metrics "because it's the default described in the RFC". =09 I think this was a mistake in the OLSRv1 RFC, it described a protocol that did not work very well in the real world because of hopcount metrics. No amount of great research for new metric or improved features have changed this later, because most people USING OLSR for their research will use the stuff described in the default RFC. We should not do the same mistake in the OLSRv2 RFC. =09 My suggestion is: include a simple version of ETX as an example metric into the OLSRv2 RFC. =09 Why ETX ? Why not ETT/SNR/MIC/.... ? =09 ETX is not the best metric out there, it's a very basic one. But it's VERY easy to describe and implement, it's independant from the layer 1/2 below OLSR and it allows to build much better real world networks than hopcount. I know no other metric that can provide these three advantages. =09 We should add a few sentences into the chapter that this will be just the "lowest common metric" which should work with all OLSRv2 agents and that there are much better and more specialized metrics described in other documents and research papers. But if we do not put a real metric into the RFC we will have people saying "OLSRv2 does not work well" in years, just because they do their comparision based on the RFC implementation (hopcount). =09 If there is a consensus on this I can easily write description of a simple Hello-Message based ETX implementation with a single tuning parameter for the draft. =09 What do you think ? =09 Henning Rogge =09 =09 ******************************************************************** 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. =09 ******************************************************************** =09 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet =09 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet =09 ------_=_NextPart_001_01CA4CB4.2D4FCB8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Can people please read the draft. Use of just = hop count is=20 NOT what
is in the proposal. You only get hop count if = you don't=20 even use the
metric TLV (so you get a default value, and all = values=20 default is - for
any metric - equivalent to hop count, just not = one per=20 hop).
 
And=20 adding more to the base draft is not the way to go. (In fact in=20 an
ideal=20 world I'd go in exactly the opposite direction and break the=20 base
draft=20 into about three modular pieces.) A specific discussion of=20 the
particular merits of specific metrics, and reservation of a = code=20 point
(group=20 of TLV type extensions) is highly suited as a separate=20 document.

-- =
Christopher=20 Dearlove
Technology Leader, Communications Group
Networks, = Security and=20 Information Systems Department
BAE Systems Advanced Technology = Centre
West=20 Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 = 1245=20 242194  Fax: +44 1245 242124

BAE Systems (Operations)=20 Limited
Registered Office: Warwick House, PO Box 87,
Farnborough = Aerospace=20 Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & = Wales=20 No: 1996687

 

From: manet-bounces@ietf.org=20 [mailto:manet-bounces@ietf.org] On Behalf Of Emmanuel=20 Baccelli
Sent: 14 October 2009 10:18
To:=20 manet@ietf.org
Subject: Re: [manet] Default metric in=20 OLSRv2

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.=20
      Keep this in mind if you answer this message.
Hi Chris,

I guess that what Henning was saying is: it would be nice to have a = simple=20 example of metric other than hop-count in the core doc. I also think it = is a=20 good idea. It is also necessary to have a companion doc that will be = more=20 exhaustive about metrics. 

But I agree with Henning: it would be unfortunate that people = implementing=20 the core spec may get the wrong impression about performance just = because the=20 hop-count metric is used because no-one gives them the hint "see, you = can try=20 other metrics too". As far as I'm concerned ETX is not a bad choice for = such an=20 example. 

I'm OK with other metrics too, as long as they are indeed simple to = implement and all-terrain (independant of lower layers).

Cheers, 

Emmanuel


On Wed, Oct 14, 2009 at 10:35 AM, Dearlove, = Christopher=20 (UK) <Chris.Dearlove@baesystems.c= om>=20 wrote:
In=20 my third line below not should be note.

I also omitted to say = that an=20 initial draft on specific
metrics could provide more background = (such as=20 "why ETX"
and references to what's been done) than would = be
appropriate=20 in the main OLSRv2 specification.

--
Christopher Dearlove
Technology Leader,=20 Communications Group
Networks, Security and Information Systems=20 Department
BAE Systems Advanced Technology Centre
West = Hanningfield=20 Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 =  Fax:=20 +44 1245 242124

BAE Systems (Operations) Limited
Registered = Office:=20 Warwick House, PO Box 87,
Farnborough Aerospace Centre, = Farnborough, Hants,=20 GU14 6YU, UK
Registered in England & Wales No:=20 1996687

-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On=20 Behalf
Of Dearlove, Christopher (UK)
Sent: 14 October 2009 = 09:32
To: Henning Rogge; manet@ietf.org
Subject: Re: = [manet]=20 Default metric in OLSRv2


          =  =20        *** WARNING ***

 This message = has=20 originated outside your organisation,
 either from an external = partner=20 or the Global Internet.
     Keep this in mind if = you answer=20 this message.


I do not believe that a specific metric such = as ETX=20 should
be in the base OLSRv2 draft. As you say, the first = question
would=20 be "why ETX?". But not that the default will be a metric
whose = meaning is=20 implementation specific, not hop count (which
would be the default = default=20 so to speak if no one includes
any metric information).

But = that=20 said, I would be delighted to see an Internet Draft
(which could be = adopted=20 and taken all the way to RFC in parallel
if that is the WG = consensus) which=20 described ETX, and maybe one
or two other, metrics and how to adopt = them to=20 the OLSRv2 metrics
TLV. This work could even start now=20 referencing
draft-dearlove-olsrv2-metrics, to be updated to = reference=20 OLSRv2
when folded in to that. This would be valuable support for=20 the
metric concept.

--
Christopher Dearlove
Technology = Leader,=20 Communications Group
Networks, Security and Information Systems=20 Department
BAE Systems Advanced Technology Centre
West = Hanningfield=20 Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 =  Fax:=20 +44 1245 242124

BAE Systems (Operations) Limited
Registered = Office:=20 Warwick House, PO Box 87,
Farnborough Aerospace Centre, = Farnborough, Hants,=20 GU14 6YU, UK
Registered in England & Wales No:=20 1996687

-----Original Message-----
From: manet-bounces@ietf.org = [mailto:manet-bounces@ietf.org] On=20 Behalf
Of Henning Rogge
Sent: 13 October 2009 16:41
To: manet@ietf.org
Subject: [manet] = Default=20 metric in OLSRv2

Hello,

I know this mail comes a little = bit=20 early (metrics have not been merged
into
OLSRv2 draft), but I = would like=20 to like to argue for more than "include
generic metric support in=20 OLSRv2".

Two weeks ago (just before the OLSR Interop 2009 in = Vienna) I=20 visited a
conference about military communications. There were a = couple=20 of
presentations
which used OLSR as a mesh net protocol and they = can be=20 summarized as:
"OLSR
does not work well". When I tried to get = some more=20 facts about this I
quickly
recognized that all of them used = hopcount=20 metrics "because it's the
default
described in the = RFC".

I think=20 this was a mistake in the OLSRv1 RFC, it described a protocol
that=20 did
not work very well in the real world because of hopcount = metrics.=20 No
amount of
great research for new metric or improved features = have=20 changed this
later,
because most people USING OLSR for their = research=20 will use the stuff
described
in the default RFC. We should not = do the=20 same mistake in the OLSRv2 RFC.

My suggestion is:
include a = simple=20 version of ETX as an example metric into the OLSRv2
RFC.

Why = ETX ?=20 Why not ETT/SNR/MIC/.... ?

ETX is not the best metric out = there, it's a=20 very basic one. But it's
VERY
easy to describe and implement, = it's=20 independant from the layer 1/2
below OLSR
and it allows to build = much=20 better real world networks than hopcount. I
know
no other metric = that=20 can provide these three advantages.

We should add a few = sentences into=20 the chapter that this will be just
the
"lowest common metric" = which=20 should work with all OLSRv2 agents and that
there
are much = better and=20 more specialized metrics described in other
documents = and
research=20 papers. But if we do not put a real metric into the RFC we=20 will
have
people saying "OLSRv2 does not work well" in years, = just=20 because they do
their
comparision based on the RFC = implementation=20 (hopcount).

If there is a consensus on this I can easily write=20 description of a
simple
Hello-Message based ETX implementation = with a=20 single tuning parameter
for the
draft.

What do you think=20 ?

Henning=20 = Rogge

************************************************************= ********
This=20 email and any attachments are confidential to the = intended
recipient and=20 may also be privileged. If you are not the intended
recipient = please delete=20 it from your system and notify the sender.
You should not copy it = or use it=20 for any purpose nor disclose or
distribute its contents to any = other=20 = person.
**************************************************************= ******

_______________________________________________
manet=20 mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

__= _____________________________________________
manet=20 mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=

------_=_NextPart_001_01CA4CB4.2D4FCB8A-- From aaron@lo-res.org Wed Oct 14 03:09: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 615FD3A6970 for ; Wed, 14 Oct 2009 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.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 2qMCavWDTNsn for ; Wed, 14 Oct 2009 03:09:39 -0700 (PDT) Received: from mute.lo-res.org (mute.lo-res.org [193.238.157.69]) by core3.amsl.com (Postfix) with ESMTP id A6CA23A6936 for ; Wed, 14 Oct 2009 03:09:38 -0700 (PDT) Received: from [10.10.0.236] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id 8E1AACE2053 for ; Wed, 14 Oct 2009 12:11:11 +0200 (CEST) From: L. Aaron Kaplan Content-Type: multipart/alternative; boundary=Apple-Mail-146-182388699 Date: Wed, 14 Oct 2009 12:09:39 +0200 References: To: manet@ietf.org Message-Id: <18291DA8-27FF-4192-BB43-6FF3F877D4E9@lo-res.org> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [manet] Default metric in OLSRv2 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, 14 Oct 2009 10:09:40 -0000 --Apple-Mail-146-182388699 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes (re-sending due to 25KB limit on the mailing list). On Oct 14, 2009, at 11:53 AM, Dearlove, Christopher (UK) wrote: > Can people please read the draft. Use of just hop count is NOT what > is in the proposal. You only get hop count if you don't even use the > metric TLV (so you get a default value, and all values default is - =20= > for > any metric - equivalent to hop count, just not one per hop). > > And adding more to the base draft is not the way to go. (In fact in an > ideal world I'd go in exactly the opposite direction and break the =20 > base > draft into about three modular pieces.) A specific discussion of the > particular merits of specific metrics, and reservation of a code point > (group of TLV type extensions) is highly suited as a separate =20 > document. > Maybe from the design point of documents you are right (adding stuff =20 just creates big clogs). But - try to read it from the perspective of OLSR implementors. They will - as you stated above - try to read as little as possible ;)) So, I am also in favor of ETX *as an example* for how to add metrics =20 but *within the v2* draft. In that example section then you can point to further documents. It is also about how people read it. a. --- there's no place like 127.0.0.1 (=FC=E4=F6) --Apple-Mail-146-182388699 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
(re-sending due to = 25KB limit on the mailing list).

On Oct 14, 2009, at 11:53 AM, = Dearlove, Christopher (UK) wrote:

Can people please read the = draft. Use of just hop count is NOT what
is in the proposal. You only = get hop count if you don't even use the
metric TLV (so you get a = default value, and all values default is - for
any metric - equivalent to = hop count, just not one per hop).
 
And adding more to the base draft is not the way to go. (In = fact in an
ideal world I'd go in exactly the opposite direction and = break the base
draft into about three modular pieces.) A specific discussion = of the
particular merits of = specific metrics, and reservation of a code = point
(group of TLV type = extensions) is highly suited as a separate = document.


Maybe from the design point of documents you are right (adding stuff = just creates big clogs).
But - try to read it from the = perspective of OLSR implementors.
They will - as you stated = above - try to read as little as possible = ;))

So, I am also in favor of ETX *as an = example* for how to add metrics but *within the v2* draft.
In = that example section then you can point to further = documents. 
It is also about how people read = it.


a.



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 v936) Date: Wed, 14 Oct 2009 12:24:40 +0200 References: <200910131741.49152.hrogge@googlemail.com> <200910141143.15983.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 10:24:42 -0000 All, Can I make a couple of rush observations and a suggestion here, without taking side in this discussion just yet? Observations: o We agree that additive metrics should be in OLSRv2. => They will be, we've got consensus on that, the metrics I-D contains that and it will be (I believe that I can safely engage all the authors) folded into the OLSRv2 specification as the WG has decided. o ETX is a valuable example of a metric. There are existence proofs (plural) hereof from operational networks. It's hard to argue against that. It's also hard to argue that ETX is the be-all-end-all metric (but I think that nobody has suggested that either). o Regardless of if ETX is to be included in the OLSRv2 spec or published as an independent spec (and I see and recognize arguments for and against both of these options), there's no current (IETF) specification of ETX. Consequently: => It's difficult for the WG to pronounce itself on the issue => There's no ETX-text to propose folding in to any specification, or to advance as a supplementary document (i.e. for the WG to adopt and to advance for publication). Suggestion: o Someone with experience in ETX and OLSR(v2) produce an individual I-D (short is good, shorter is better), and post to manet@ietf.org for further discussion. Informally, as I know that Henning and Aaron have significant operational experience with ETX in OLSR(v2) networks, I'd think it interesting and a good idea if you were to produce such a document. I'd be happy [as OLSRv2 co-author] to help out, as will Emmanuel (he just confirmed this, as he's next to me) -- and I am sure that so will others. I am sure that once a document exists, it will be a lot easier to understand what it is that we're discussing, what the right path for the content is etc. Thoughts? Thomas On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote: >> I don't think this will work well for OLSRv2. Most people using >> OLSRv2 > for >> research (instead of doing research on OLSRv2) will continue to use > the "basic >> RFC implementation" of OLSR... if the basic RFC does only contain > hopcount > > That is not the proposal. See what's written in the metrics draft. > (I agree what you indicate would not be acceptable. But that's why > that isn't it.) > > The proposal is that the default is an additive metric of unspecified > "real world" meaning. But it's still a metric, and not just hopcount. > It's just not a specific ETC/delay/whatever metric. At least not > specified as such. In a given deployment if you agree in advance that > this is ETX, fine. But if you definitely want ETX then get an > allocation > of one of the reserved metric code points specifically for that > purpose > and use that. > > ******************************************************************** > 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 Chris.Dearlove@baesystems.com Wed Oct 14 03:33: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 2AA1028C174 for ; Wed, 14 Oct 2009 03:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 5HMTHnadKmad for ; Wed, 14 Oct 2009 03:33:22 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 62F1128C1BA for ; Wed, 14 Oct 2009 03:33:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,556,1249254000"; d="scan'208";a="27355505" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Oct 2009 11:33:23 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9EAXSZC012068; Wed, 14 Oct 2009 11:33:28 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Oct 2009 11:33:22 +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: quoted-printable Date: Wed, 14 Oct 2009 11:33:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpMuI0+ZN+a1Cy2Qe27+R2Gws0mWgAAEZvA References: <200910131741.49152.hrogge@googlemail.com> <200910141143.15983.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" X-OriginalArrivalTime: 14 Oct 2009 10:33:22.0799 (UTC) FILETIME=[C13AAFF0:01CA4CB9] Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 10:33:23 -0000 I agree with almost all of Thomas's message (I might have one small nitpick, but it's not important right now) and that definitely includes the conclusion, that an ETX draft would=20 be valuable - and actually not just in an OLSRv2 context. --=20 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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 Sent: 14 October 2009 11:25 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. All, Can I make a couple of rush observations and a suggestion here, =20 without taking side in this discussion just yet? Observations: o We agree that additive metrics should be in OLSRv2. =3D> They will be, we've got consensus on that, the metrics I-D contains that and it will be (I believe that I can safely engage all the authors) folded into the OLSRv2 specification as the WG has decided. o ETX is a valuable example of a metric. There are existence proofs (plural) hereof from operational networks. It's hard to argue against that. It's also hard to argue that ETX is the be-all-end-all metric (but I think that nobody has suggested that either). o Regardless of if ETX is to be included in the OLSRv2 spec or published as an independent spec (and I see and recognize arguments for and against both of these options), there's no current (IETF) specification of ETX. Consequently: =3D> It's difficult for the WG to pronounce itself on the issue =3D> There's no ETX-text to propose folding in to any specification, or to advance as a supplementary document (i.e. for the WG to adopt and to advance for publication). Suggestion: o Someone with experience in ETX and OLSR(v2) produce an individual I-D (short is good, shorter is better), and post to manet@ietf.org for further discussion. Informally, as I know that Henning and Aaron have significant =20 operational experience with ETX in OLSR(v2) networks, I'd think it =20 interesting and a good idea if you were to produce such a document. =20 I'd be happy [as OLSRv2 co-author] to help out, as will Emmanuel (he =20 just confirmed this, as he's next to me) -- and I am sure that so will =20 others. I am sure that once a document exists, it will be a lot easier to =20 understand what it is that we're discussing, what the right path for =20 the content is etc. Thoughts? Thomas On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote: >> I don't think this will work well for OLSRv2. Most people using =20 >> OLSRv2 > for >> research (instead of doing research on OLSRv2) will continue to use > the "basic >> RFC implementation" of OLSR... if the basic RFC does only contain > hopcount > > That is not the proposal. See what's written in the metrics draft. > (I agree what you indicate would not be acceptable. But that's why > that isn't it.) > > The proposal is that the default is an additive metric of unspecified > "real world" meaning. But it's still a metric, and not just hopcount. > It's just not a specific ETC/delay/whatever metric. At least not > specified as such. In a given deployment if you agree in advance that > this is ETX, fine. But if you definitely want ETX then get an =20 > allocation > of one of the reserved metric code points specifically for that =20 > purpose > and use that. > > ******************************************************************** > 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 ulrich@herberg.name Wed Oct 14 04:26:28 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 D323D3A6820 for ; Wed, 14 Oct 2009 04:26:28 -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 3Fmhtj+dRJk7 for ; Wed, 14 Oct 2009 04:26:27 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id E434D3A67C0 for ; Wed, 14 Oct 2009 04:26:26 -0700 (PDT) Received: by fxm28 with SMTP id 28so9653496fxm.42 for ; Wed, 14 Oct 2009 04:26:24 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.48.194 with SMTP id s2mr7087623bkf.210.1255519583944; Wed, 14 Oct 2009 04:26:23 -0700 (PDT) In-Reply-To: References: <200910131741.49152.hrogge@googlemail.com> <200910141143.15983.hrogge@googlemail.com> Date: Wed, 14 Oct 2009 13:26:23 +0200 X-Google-Sender-Auth: e279b036239a2998 Message-ID: <25c114b90910140426q4fc2ce98s871744756940e13c@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=000325556f5acf3ee10475e36e1b Cc: manet@ietf.org, Thomas Heide Clausen Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 11:26:28 -0000 --000325556f5acf3ee10475e36e1b Content-Type: text/plain; charset=ISO-8859-1 I also agree with Thomas' mail that it would be very helpful to have a draft that describes the ETX metric, before continuing the discussion whether or not to include it in the OLSRv2 draft. Henning and Aaron seem to be the ideal candidates for writing such a draft, since they have running code (of OLSRv1) that includes ETX metrics, and since they have the operational experience of a big OLSR network. Henning, Aaron, if you guys agree to write such a draft, I am also offering to help out. Ulrich On Wed, Oct 14, 2009 at 12:33 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > I agree with almost all of Thomas's message (I might have one > small nitpick, but it's not important right now) and that > definitely includes the conclusion, that an ETX draft would > be valuable - and actually not just in an OLSRv2 context. > > -- > 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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > Sent: 14 October 2009 11:25 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; manet@ietf.org > Subject: Re: [manet] Default metric in OLSRv2 > > > *** WARNING *** > > This message has originated outside your organisation, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > All, > > Can I make a couple of rush observations and a suggestion here, > without taking side in this discussion just yet? > > Observations: > > o We agree that additive metrics should be in OLSRv2. > > => They will be, we've got consensus on > that, > the metrics I-D contains that and it > will be > (I believe that I can safely engage all > the authors) > folded into the OLSRv2 specification as > the WG > has decided. > > o ETX is a valuable example of a metric. There are > existence > proofs (plural) hereof from operational networks. It's > hard > to argue against that. It's also hard to argue that ETX > is the > be-all-end-all metric (but I think that nobody has > suggested > that either). > > o Regardless of if ETX is to be included in the OLSRv2 > spec > or published as an independent spec (and I see and > recognize > arguments for and against both of these options), > there's no > current (IETF) specification of ETX. Consequently: > > => It's difficult for the WG to pronounce > itself on the > issue > > => There's no ETX-text to propose folding > in to any > specification, or to advance as a > supplementary > document (i.e. for the WG to adopt and > to advance > for publication). > > Suggestion: > > o Someone with experience in ETX and OLSR(v2) produce > an individual I-D (short is good, shorter is better), > and post > to manet@ietf.org for further discussion. > > > Informally, as I know that Henning and Aaron have significant > operational experience with ETX in OLSR(v2) networks, I'd think it > interesting and a good idea if you were to produce such a document. > I'd be happy [as OLSRv2 co-author] to help out, as will Emmanuel (he > just confirmed this, as he's next to me) -- and I am sure that so will > others. > > I am sure that once a document exists, it will be a lot easier to > understand what it is that we're discussing, what the right path for > the content is etc. > > Thoughts? > > Thomas > > > On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote: > > >> I don't think this will work well for OLSRv2. Most people using > >> OLSRv2 > > for > >> research (instead of doing research on OLSRv2) will continue to use > > the "basic > >> RFC implementation" of OLSR... if the basic RFC does only contain > > hopcount > > > > That is not the proposal. See what's written in the metrics draft. > > (I agree what you indicate would not be acceptable. But that's why > > that isn't it.) > > > > The proposal is that the default is an additive metric of unspecified > > "real world" meaning. But it's still a metric, and not just hopcount. > > It's just not a specific ETC/delay/whatever metric. At least not > > specified as such. In a given deployment if you agree in advance that > > this is ETX, fine. But if you definitely want ETX then get an > > allocation > > of one of the reserved metric code points specifically for that > > purpose > > and use that. > > > > ******************************************************************** > > 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 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --000325556f5acf3ee10475e36e1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also agree with Thomas' mail that it would be very helpful to have a = draft that describes the ETX metric, before continuing the discussion wheth= er or not to include it in the OLSRv2 draft. Henning and Aaron seem to be t= he ideal candidates for writing such a draft, since they have running code = (of OLSRv1) that includes ETX metrics, and since they have the operational = experience of a big OLSR network.

Henning, Aaron, if you guys agree to write such a draft, I am also offe= ring to help out.

Ulrich


On We= d, Oct 14, 2009 at 12:33 PM, Dearlove, Christopher (UK) &= lt;Chris.Dearlove@baesyste= ms.com> wrote:
I agree with almo= st all of Thomas's message (I might have one
small nitpick, but it's not important right now) and that
definitely includes the conclusion, that an ETX draft would
be valuable - and actually not just in an OLSRv2 context.

--
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 =A0Fax: +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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 14 October 2009 11:25
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet@ietf.org
Subject: Re: [manet] Default metric in OLSRv2


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING ***

=A0This message has originated outside your organisation,
=A0either from an external partner or the Global Internet.
=A0 =A0 =A0Keep this in mind if you answer this message.


All,

Can I make a couple of rush observations and a suggestion here,
without taking side in this discussion just yet?

Observations:

=A0 =A0 =A0 =A0o =A0 =A0 =A0 We agree that additive metrics should be in O= LSRv2.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 =A0 =A0They wil= l be, we've got consensus on
that,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the metrics= I-D contains that and it
will be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(I believe = that I can safely engage all
the authors)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0folded into= the OLSRv2 specification as
the WG
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has decided= .

=A0 =A0 =A0 =A0o =A0 =A0 =A0 ETX is a valuable example of a metric. There = are
existence
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proofs (plural) hereof from operational net= works. It's
hard
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to argue against that. It's also hard t= o argue that ETX
is the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be-all-end-all metric (but I think that nob= ody has
suggested
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that either).

=A0 =A0 =A0 =A0o =A0 =A0 =A0 Regardless of if ETX is to be included in the= OLSRv2
spec
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or published as an independent spec (and I = see and
recognize
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0arguments for and against both of these opt= ions),
there's no
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0current (IETF) specification of ETX. Conseq= uently:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 =A0 =A0It's= difficult for the WG to pronounce
itself on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0issue

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 =A0 =A0There= 9;s no ETX-text to propose folding
in to any
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0specificati= on, or to advance as a
supplementary
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0document (i= .e. for the WG to adopt and
to advance
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for publica= tion).

Suggestion:

=A0 =A0 =A0 =A0o =A0 =A0 =A0 Someone with experience in ETX and OLSR(v2) p= roduce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0an individual I-D (short is good, shorter i= s better),
and post
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to manet@= ietf.org for further discussion.


Informally, as I know that Henning and Aaron have significant
operational experience with ETX in OLSR(v2) networks, I'd think it
interesting and a good idea if you were to produce such a document.
I'd be happy [as OLSRv2 co-author] to help out, as will Emmanuel (he just confirmed this, as he's next to me) -- and I am sure that so will<= br> others.

I am sure that once a document exists, it will be a lot easier to
understand what it is that we're discussing, what the right path for the content is etc.

Thoughts?

Thomas


On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote:

>> I don't think this will work well for OLSRv2. Most people usin= g
>> OLSRv2
> for
>> research (instead of doing research on OLSRv2) will continue to us= e
> the "basic
>> RFC implementation" of OLSR... if the basic RFC does only con= tain
> hopcount
>
> That is not the proposal. See what's written in the metrics draft.=
> (I agree what you indicate would not be acceptable. But that's why=
> that isn't it.)
>
> The proposal is that the default is an additive metric of unspecified<= br> > "real world" meaning. But it's still a metric, and not j= ust hopcount.
> It's just not a specific ETC/delay/whatever metric. At least not > specified as such. In a given deployment if you agree in advance that<= br> > this is ETX, fine. But if you definitely want ETX then get an
> allocation
> of one of the reserved metric code points specifically for that
> purpose
> and use that.
>
> ******************************************************************** > 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


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--000325556f5acf3ee10475e36e1b-- From emmanuel.baccelli@gmail.com Wed Oct 14 04:31: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 CF30A28C112 for ; Wed, 14 Oct 2009 04:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_28=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 TbFK75pXK5yE for ; Wed, 14 Oct 2009 04:31:42 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 883293A68F0 for ; Wed, 14 Oct 2009 04:31:42 -0700 (PDT) Received: by gxk4 with SMTP id 4so11844362gxk.8 for ; Wed, 14 Oct 2009 04:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=vjWAJP9SR3/AcBPbKuS04hsaYbrNls1jlKpV1KMBXcQ=; b=qZTupu+3bLOjqylWWD2qAN+oAMkk9PJbgOfx4e/C185nxA5gqzc1umtGs2xpeAKJMM sqVvSAWzq2HuZHpyYCggJzGijy0tUYQi7mc1/qkQ57e+DVL8Dr+DxfaqxTZIs/rwB0LA lx3SFjX/CICMVbLj0egeO9yhNDsgD0r7sdz6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=sk1IpA1/+QmR6Ug/NPhbltbOZPnzw2EkrcaefJMQixLIxxq9shuN0XPQpregYauMPI 5KmeIHGQhS25oDBg4+OzhQv+SzkwQe2VjNihsWymbJN11vscJbut6TFLpFW7/bIx+mFo g3S2lLOyhHCjvVx6YZnmbP9Cz5CgARrpokBeY= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.11.30 with SMTP id 30mr5033043agk.42.1255519902101; Wed, 14 Oct 2009 04:31:42 -0700 (PDT) In-Reply-To: References: <200910131741.49152.hrogge@googlemail.com> <200910141143.15983.hrogge@googlemail.com> From: Emmanuel Baccelli Date: Wed, 14 Oct 2009 13:31:22 +0200 X-Google-Sender-Auth: 707ea9f8681bc388 Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=00163616421fc5f2a60475e3811f Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 11:31:43 -0000 --00163616421fc5f2a60475e3811f Content-Type: text/plain; charset=ISO-8859-1 I agree with Thomas: we need text to agree on ;) Let's do it!Emmanuel On Wed, Oct 14, 2009 at 12:24 PM, Thomas Heide Clausen < thomas@thomasclausen.org> wrote: > All, > > Can I make a couple of rush observations and a suggestion here, without > taking side in this discussion just yet? > > Observations: > > o We agree that additive metrics should be in OLSRv2. > > => They will be, we've got consensus on that, > the metrics I-D contains that and it will be > (I believe that I can safely engage all the > authors) > folded into the OLSRv2 specification as the > WG > has decided. > > o ETX is a valuable example of a metric. There are existence > proofs (plural) hereof from operational networks. It's hard > to argue against that. It's also hard to argue that ETX is > the > be-all-end-all metric (but I think that nobody has suggested > that either). > > o Regardless of if ETX is to be included in the OLSRv2 spec > or published as an independent spec (and I see and recognize > arguments for and against both of these options), there's no > current (IETF) specification of ETX. Consequently: > > => It's difficult for the WG to pronounce > itself on the > issue > > => There's no ETX-text to propose folding in to > any > specification, or to advance as a > supplementary > document (i.e. for the WG to adopt and to > advance > for publication). > > Suggestion: > > o Someone with experience in ETX and OLSR(v2) produce > an individual I-D (short is good, shorter is better), and > post > to manet@ietf.org for further discussion. > > > Informally, as I know that Henning and Aaron have significant operational > experience with ETX in OLSR(v2) networks, I'd think it interesting and a > good idea if you were to produce such a document. I'd be happy [as OLSRv2 > co-author] to help out, as will Emmanuel (he just confirmed this, as he's > next to me) -- and I am sure that so will others. > > I am sure that once a document exists, it will be a lot easier to > understand what it is that we're discussing, what the right path for the > content is etc. > > Thoughts? > > Thomas > > > > On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote: > > I don't think this will work well for OLSRv2. Most people using OLSRv2 >>> >> for >> >>> research (instead of doing research on OLSRv2) will continue to use >>> >> the "basic >> >>> RFC implementation" of OLSR... if the basic RFC does only contain >>> >> hopcount >> >> That is not the proposal. See what's written in the metrics draft. >> (I agree what you indicate would not be acceptable. But that's why >> that isn't it.) >> >> The proposal is that the default is an additive metric of unspecified >> "real world" meaning. But it's still a metric, and not just hopcount. >> It's just not a specific ETC/delay/whatever metric. At least not >> specified as such. In a given deployment if you agree in advance that >> this is ETX, fine. But if you definitely want ETX then get an allocation >> of one of the reserved metric code points specifically for that purpose >> and use that. >> >> ******************************************************************** >> 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 >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --00163616421fc5f2a60475e3811f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Thomas: we need text to agree on ;) Let's do it!
Emman= uel


On Wed, Oct 14, 2009 at 12= :24 PM, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
All,

Can I make a couple of rush observations and a suggestion here, without tak= ing side in this discussion just yet?

Observations:

=A0 =A0 =A0 =A0o =A0 =A0 =A0 We agree that additive metrics should be in O= LSRv2.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 =A0 =A0They wil= l be, we've got consensus on that,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the metrics= I-D contains that and it will be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(I believe = that I can safely engage all the authors)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0folded into= the OLSRv2 specification as the WG
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has decided= .

=A0 =A0 =A0 =A0o =A0 =A0 =A0 ETX is a valuable example of a metric. There = are existence
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0proofs (plural) hereof from operational net= works. It's hard
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to argue against that. It's also hard t= o argue that ETX is the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be-all-end-all metric (but I think that nob= ody has suggested
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that either).

=A0 =A0 =A0 =A0o =A0 =A0 =A0 Regardless of if ETX is to be included in the= OLSRv2 spec
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or published as an independent spec (and I = see and recognize
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0arguments for and against both of these opt= ions), there's no
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0current (IETF) specification of ETX. Conseq= uently:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 =A0 =A0It's= difficult for the WG to pronounce itself on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0issue

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D> =A0 =A0 =A0There= 9;s no ETX-text to propose folding in to any
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0specificati= on, or to advance as a supplementary
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0document (i= .e. for the WG to adopt and to advance
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for publica= tion).

Suggestion:

=A0 =A0 =A0 =A0o =A0 =A0 =A0 Someone with experience in ETX and OLSR(v2) p= roduce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0an individual I-D (short is good, shorter i= s better), and post
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to manet@ietf.org for further discussion.


Informally, as I know that Henning and Aaron have significant operational e= xperience with ETX in OLSR(v2) networks, I'd think it interesting and a= good idea if you were to produce such a document. I'd be happy [as OLS= Rv2 co-author] to help out, as will Emmanuel (he just confirmed this, as he= 's next to me) -- and I am sure that so will others.

I am sure that once a document exists, it will be a lot easier to understan= d what it is that we're discussing, what the right path for the content= is etc.

Thoughts?

Thomas



On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote:

I don't think this will work well for OLSRv2. Most people using OLSRv2<= br>
for
research (instead of doing research on OLSRv2) will continue to use
the "basic
RFC implementation" of OLSR... if the basic RFC does only contain
hopcount

That is not the proposal. See what's written in the metrics draft.
(I agree what you indicate would not be acceptable. But that's why
that isn't it.)

The proposal is that the default is an additive metric of unspecified
"real world" meaning. But it's still a metric, and not just h= opcount.
It's just not a specific ETC/delay/whatever metric. At least not
specified as such. In a given deployment if you agree in advance that
this is ETX, fine. But if you definitely want ETX then get an allocation of one of the reserved metric code points specifically for that purpose
and use that.

********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--00163616421fc5f2a60475e3811f-- From drp@moviquity.com Wed Oct 14 00:31:59 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 5C7A43A69E1 for ; Wed, 14 Oct 2009 00:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_GIF_ATTACH=1.42] 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 bhPqvmotvsUS for ; Wed, 14 Oct 2009 00:31:58 -0700 (PDT) Received: from mail.moviquity.com (mail.moviquity.com [213.134.42.80]) by core3.amsl.com (Postfix) with ESMTP id A98E73A69E2 for ; Wed, 14 Oct 2009 00:31:57 -0700 (PDT) Received: from danielrodriba41 (80.Red-80-38-94.staticIP.rima-tde.net [80.38.94.80]) (Authenticated sender: drp@moviquity.com) by mail.moviquity.com (Postfix) with ESMTPA id CC3B3520372 for ; Wed, 14 Oct 2009 09:31:55 +0200 (CEST) From: =?iso-8859-1?Q?Daniel_Rodr=EDguez_Pag=E9s?= To: Date: Wed, 14 Oct 2009 09:33:17 +0200 Message-ID: <00ea01ca4ca0$9939a290$cbace7b0$@com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00EB_01CA4CB1.5CC27290" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpMoJdosZJuiDkERDmuJ7b2ueNv/g== Content-Language: es X-Virus-Scanned: clamav-milter 0.95.2 at moviquity-mail X-Virus-Status: Clean X-Mailman-Approved-At: Wed, 14 Oct 2009 10:36:22 -0700 Subject: [manet] New Update OLSR .Net Implementation 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, 14 Oct 2009 07:31:59 -0000 Este es un mensaje con varias partes en formato MIME. ------=_NextPart_000_00EB_01CA4CB1.5CC27290 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00EC_01CA4CB1.5CC27290" ------=_NextPart_001_00EC_01CA4CB1.5CC27290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 We are glad to announce a new release of the protocol OLSR = implementation for .Net platforms (PC and Compact Framework).=20 =20 Within this new release, ETX proposed network metric implementation for = new RFC, has been upgraded according to the requirements of the platform = (named TFLLN: Time From Last Lost Neighbor). New package, contains both Desktop = and Compact Framework implementations just in one download. =20 You can access to the main packages through: http://sourceforge.net/projects/wmolsr/=20 Release Notes: http://sourceforge.net/projects/wmolsr/files/Integration/Releas_Notes_PDA= %20 _%20PC.txt/download=20 =20 Furthermore we are aiming to provide pillars for further implementations into this platform for commercial appliances, therefore any further = contact for collaboration will be really welcomed. =20 Best Regards, =20 Daniel R. =20 =20 =20 logomoviquity http://www.moviquity.com =20 Daniel Rodr=EDguez Pag=E9s Gerente de Desarrollo Software Development Manager C/Isabel Colbrand 10, pl. 5=AA, Oficina 150 28050 MADRID Spain ( Mob: +34 638 540 947=20 ( Tlf: +34 91 431 98 59 4 Fax: :+34 91 431 22 06=20 - drp@moviquity.com =20 ------=_NextPart_001_00EC_01CA4CB1.5CC27290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

We are glad to announce a new = release of the protocol OLSR implementation for .Net platforms (PC and Compact = Framework).

 

Within this new release, ETX = proposed network metric implementation for new RFC, has been upgraded according = to the requirements of the platform (named TFLLN: Time From Last Lost = Neighbor). New package, contains both Desktop and Compact Framework implementations = just in one download.

 

You can access to the main = packages through: http://sourceforge.net/p= rojects/wmolsr/

Release Notes: http://sourceforge.net/projects/wmolsr/fi= les/Integration/Releas_Notes_PDA%20_%20PC.txt/download

 

Furthermore we are aiming to = provide pillars for further implementations into this platform for commercial appliances, therefore any further contact for collaboration will be = really welcomed.

 

Best = Regards,

 

Daniel R.

 

 

 

3Dlogomoviquity

http://www.moviquity.com

Daniel Rodr=EDguez = Pag=E9s

Gerente de = Desarrollo

Software = Development Manager

C/Isabel Colbrand 10, pl. 5=AA, Oficina 150

28050 MADRID Spain

( = Mob: +34 638 540 947 =
( = Tlf: +34 91 431 98 = 59
4 Fax: :+34 91 431 = 22 06 =
- drp@moviquity.com

 

------=_NextPart_001_00EC_01CA4CB1.5CC27290-- ------=_NextPart_000_00EB_01CA4CB1.5CC27290 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhvQAgALP/AAAAAP///9nd4D+NuG+qyqPI3ezu78vLy6ysrHp6ej09Pf///wAAAAAAAAAA AAAAACwAAAAAvQAgAAAE/zDIGYwoZAzCi6FgKI5kaZ6mAqjKgb7wxK5ubE+Ypu+Dd//AoAxABAiE SFWxJkE4nR9kJcOrao7SrJaiJDK3sC7gK8YKBda0pgBuC8Vfd6o45tLNQIN6j5f7TQgJgglRfyWB g4UBXQp9N1Q7BAUClDlViigGmBOaMZqbhhSdf6ASYqUvBVU+IAKQGgQiAogJLgcJCrkKCBMCuLq8 JAa3urm1ILeDwciDxwGBiJsGCMXHvoNmyYJ908oU0IIf13QAggjdg3EVtISvA4697o4HdLXkRAkB B2JEjSL794oQmoCAXBwDYoLBQcbPS8EiyxIio6PAzpJnAfvdohjiYT80O//YlACpQyQFegIzlmvY D5NHlf4qSDxJMUoZmhlz0WGSYGermkMuvrw3jWKfngJfxZIwC54qHQQwoVRJlc4yfVWLKIiCtB+I ruWCEjGDMCvECWCvBhDAyOJYjA1zaZopoeySVybZ7sJEUoNUcrsOULsXGOwKt/gQCOaXD6tWRQtN +WwCOEGghhGtTtSKuAYlOJQqgG3MlCMPM3pzfdGzo89UL1HstkTLkbJmCmC3yry9trbkIlhkryjE 1iDtsxQEAP3txW1M27OhA+B1ulcxBQMlYOAQdbNXxKR7c5YwOoTwYOWlh78p/iJO5AHStmor1ghi PMKZLHxF9vq5F69VhBv/b+0Nx9x0IqSn3Hjx3XGfdAKKEtkiBDr23YFkODigQHXRh5d1xsBDQoBf EVjcd/mZ9xJpN8kWIYbk1ZMgb/IltxyF7jH3nAQkWohgAEpZ50wMPR5HxFULokgOKC9F+BIvr6nF XnolwlfjBABdiGNz9XFzE1hYPKVDcOoAKOOGR9r42G7AibBiL/UYABYmU55ZJZdb/ggng3niwR6a CHZBGmtQoWImnw3CtxZ9KYZAZaLDCRpCZG9OSmOFSR5WX4YfhfAaIQSKCYuIh2opp4m+PVrfVU92 oVafEGJyXl1Xxrrpg5b249GOhIYkgKEj+hajopnqhpGGBJGDx4krrAlC/2QGkKOWYTzZeeCLE8La EUWIrqWGSTAUOWyae17I7ArnWGBYeONa26WRR/7qyz3LGIbArxsJ+2eeZb5WoXZpLEWksJDquaiz x1LEkiNDkfsssv72kxETEetEWGeIhfgwYKX0BdUN4p5KLMGGZfTqgZrmimfBVV3FksQIZ7swCA2z C4IB7ggcLsmoIloUTGW2G5YI+7IsUK3najWYltlW3EfSJ7diic4vpIbdV8V84Ysu2SWHC2D/kWD1 jrgVw7AYV2e71tf9HPPL1WiZzcx1jqANLCcW3A1GIahYcMDfercxDODtnizA339zkocFlDDpbiiQ Rx7Gv5LfWUflmGc+Yy6Omlfwc3Sdh145XZpTw5joqEsOVtCRN2xs6rD7QXrmDUcd++1ImK6a6Evn YnsEADs= ------=_NextPart_000_00EB_01CA4CB1.5CC27290-- From sratliff@cisco.com Wed Oct 14 10:44: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 1589E3A694E for ; Wed, 14 Oct 2009 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 gmP+CYYP7u74 for ; Wed, 14 Oct 2009 10:44:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D6A813A6918 for ; Wed, 14 Oct 2009 10:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=16817; q=dns/txt; s=sjiport02001; t=1255542280; x=1256751880; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20sratliff=20|Subject:=20Re: =20[manet]=20Default=20metric=20in=20OLSRv2|Date:=20Wed, =2014=20Oct=202009=2013:44:35=20-0400|Message-ID:=20|To:=20Emmanuel=20Baccelli =20,=20 |Mime-version:=201.0|In-Reply-To:=20; bh=3UrFnCzpiqvc3+FBP2XsN1aBivvdaIrPX1kGzhcwDV4=; b=eC2rNBIpQUWDjHyvI74pEtvEOhVdfN0WvkUK1vXeVUKmp4hcUFFZu8j6 +8lOmtYFYXe89oxY+xUhg5wAjEcO+K4p5cLy4v/qaEJH5P2eHovvmpPoa 23QdltdOkY2fBkqgKCkOhRYrvK7OhUBN0pfAlrsBDGT+iwzc6Nep/xpgl E=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggGADer1UqrR7H+/2dsb2JhbACCJDGXEYEKp1+YXYQuBIFb X-IronPort-AV: E=Sophos;i="4.44,559,1249257600"; d="scan'208,217";a="214481086" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2009 17:44:39 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9EHiRZA022020; Wed, 14 Oct 2009 17:44:39 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:44:35 -0400 Received: from 64.102.54.119 ([64.102.54.119]) by xmb-rtp-208.amer.cisco.com ([64.102.31.43]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Oct 2009 17:44:35 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 14 Oct 2009 13:44:35 -0400 From: sratliff To: Emmanuel Baccelli , Message-ID: Thread-Topic: [manet] Default metric in OLSRv2 Thread-Index: AcpM9f5DJ6zPwa6PrkWbsVC/Jfz+Eg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3338372675_816613" X-OriginalArrivalTime: 14 Oct 2009 17:44:35.0874 (UTC) FILETIME=[FEC8A020:01CA4CF5] Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 17:44:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3338372675_816613 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable RFC4938 makes an attempt to document a set of protocol independent metrics for inclusion into route cost metrics. Perhaps this would be of interest to the MANET WG? Regards, Stan On 10/14/09 5:18 AM, "Emmanuel Baccelli" wrote= : > Hi Chris, >=20 > I guess that what Henning was saying is: it would be nice to have a simpl= e > example of metric other than hop-count in the core doc. I also think it i= s a > good idea. It is also necessary to have a companion doc that will be more > exhaustive about metrics.=A0 >=20 > But I agree with Henning: it would be unfortunate that people implementin= g the > core spec may get the wrong impression about performance just because the > hop-count metric is used because no-one gives them the hint "see, you can= try > other metrics too". As far as I'm concerned ETX is not a bad choice for s= uch > an example.=A0 >=20 > I'm OK with other metrics too, as long as they are indeed simple to imple= ment > and all-terrain (independant of lower layers). >=20 > Cheers,=A0 >=20 > Emmanuel >=20 >=20 > On Wed, Oct 14, 2009 at 10:35 AM, Dearlove, Christopher (UK) > wrote: >> In my third line below not should be note. >>=20 >> I also omitted to say that an initial draft on specific >> metrics could provide more background (such as "why ETX" >> and references to what's been done) than would be >> appropriate in the main OLSRv2 specification. >>=20 >> -- >> 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 =A0Fax: +44 1245 242124 >>=20 >> 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 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Dearlove, Christopher (UK) >> Sent: 14 October 2009 09:32 >> To: Henning Rogge; manet@ietf.org >> Subject: Re: [manet] Default metric in OLSRv2 >>=20 >>=20 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING *** >>=20 >> =A0This message has originated outside your organisation, >> =A0either from an external partner or the Global Internet. >> =A0 =A0 =A0Keep this in mind if you answer this message. >>=20 >>=20 >> I do not believe that a specific metric such as ETX should >> be in the base OLSRv2 draft. As you say, the first question >> would be "why ETX?". But not that the default will be a metric >> whose meaning is implementation specific, not hop count (which >> would be the default default so to speak if no one includes >> any metric information). >>=20 >> But that said, I would be delighted to see an Internet Draft >> (which could be adopted and taken all the way to RFC in parallel >> if that is the WG consensus) which described ETX, and maybe one >> or two other, metrics and how to adopt them to the OLSRv2 metrics >> TLV. This work could even start now referencing >> draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2 >> when folded in to that. This would be valuable support for the >> metric concept. >>=20 >> -- >> 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 =A0Fax: +44 1245 242124 >>=20 >> 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 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Henning Rogge >> Sent: 13 October 2009 16:41 >> To: manet@ietf.org >> Subject: [manet] Default metric in OLSRv2 >>=20 >> Hello, >>=20 >> I know this mail comes a little bit early (metrics have not been merged >> into >> OLSRv2 draft), but I would like to like to argue for more than "include >> generic metric support in OLSRv2". >>=20 >> Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a >> conference about military communications. There were a couple of >> presentations >> which used OLSR as a mesh net protocol and they can be summarized as: >> "OLSR >> does not work well". When I tried to get some more facts about this I >> quickly >> recognized that all of them used hopcount metrics "because it's the >> default >> described in the RFC". >>=20 >> I think this was a mistake in the OLSRv1 RFC, it described a protocol >> that did >> not work very well in the real world because of hopcount metrics. No >> amount of >> great research for new metric or improved features have changed this >> later, >> because most people USING OLSR for their research will use the stuff >> described >> in the default RFC. We should not do the same mistake in the OLSRv2 RFC. >>=20 >> My suggestion is: >> include a simple version of ETX as an example metric into the OLSRv2 >> RFC. >>=20 >> Why ETX ? Why not ETT/SNR/MIC/.... ? >>=20 >> ETX is not the best metric out there, it's a very basic one. But it's >> VERY >> easy to describe and implement, it's independant from the layer 1/2 >> below OLSR >> and it allows to build much better real world networks than hopcount. I >> know >> no other metric that can provide these three advantages. >>=20 >> We should add a few sentences into the chapter that this will be just >> the >> "lowest common metric" which should work with all OLSRv2 agents and that >> there >> are much better and more specialized metrics described in other >> documents and >> research papers. But if we do not put a real metric into the RFC we will >> have >> people saying "OLSRv2 does not work well" in years, just because they do >> their >> comparision based on the RFC implementation (hopcount). >>=20 >> If there is a consensus on this I can easily write description of a >> simple >> Hello-Message based ETX implementation with a single tuning parameter >> for the >> draft. >>=20 >> What do you think ? >>=20 >> Henning Rogge >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --B_3338372675_816613 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [manet] Default metric in OLSRv2 RFC4938 makes an attempt to document a set of protocol independent metrics= for inclusion into route cost metrics. Perhaps this would be of interest to= the MANET WG?

Regards,
Stan



On 10/14/09 5:18 AM, "Emmanuel Baccelli" <Emmanuel.Baccelli@inria.fr> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Chris,

I guess that what Henning was saying is: it would be nice to have a simple = example of metric other than hop-count in the core doc. I also think it is a= good idea. It is also necessary to have a companion doc that will be more e= xhaustive about metrics.=A0

But I agree with Henning: it would be unfortunate that people implementing = the core spec may get the wrong impression about performance just because th= e hop-count metric is used because no-one gives them the hint "see, you= can try other metrics too". As far as I'm concerned ETX is not a bad c= hoice for such an example.=A0

I'm OK with other metrics too, as long as they are indeed simple to impleme= nt and all-terrain (independant of lower layers).

Cheers,=A0

Emmanuel


On Wed, Oct 14, 2009 at 10:35 AM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>In my third line below not should be note.

I also omitted to say that an initial draft on specific
metrics could provide more background (such as "why ETX"
and references to what's been done) than would be
appropriate in the main OLSRv2 specification.

--
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 =A0Fax: +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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf=
Of Dearlove, Christopher (UK)
Sent: 14 October 2009 09:32
To: Henning Rogge; manet@ietf.org
Subject: Re: [manet] Default metric in OLSRv2


 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*** WARNING ***

 =A0This message has originated outside your organisation,
 =A0either from an external partner or the Global Internet.
 =A0 =A0 =A0Keep this in mind if you answer this message.


I do not believe that a specific metric such as ETX should
be in the base OLSRv2 draft. As you say, the first question
would be "why ETX?". But not that the default will be a metric whose meaning is implementation specific, not hop count (which
would be the default default so to speak if no one includes
any metric information).

But that said, I would be delighted to see an Internet Draft
(which could be adopted and taken all the way to RFC in parallel
if that is the WG consensus) which described ETX, and maybe one
or two other, metrics and how to adopt them to the OLSRv2 metrics
TLV. This work could even start now referencing
draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2
when folded in to that. This would be valuable support for the
metric concept.

--
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 =A0Fax: +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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf=
Of Henning Rogge
Sent: 13 October 2009 16:41
To: manet@ietf.org
Subject: [manet] Default metric in OLSRv2

Hello,

I know this mail comes a little bit early (metrics have not been merged
into
OLSRv2 draft), but I would like to like to argue for more than "includ= e
generic metric support in OLSRv2".

Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a
conference about military communications. There were a couple of
presentations
which used OLSR as a mesh net protocol and they can be summarized as:
"OLSR
does not work well". When I tried to get some more facts about this I<= BR> quickly
recognized that all of them used hopcount metrics "because it's the default
described in the RFC".

I think this was a mistake in the OLSRv1 RFC, it described a protocol
that did
not work very well in the real world because of hopcount metrics. No
amount of
great research for new metric or improved features have changed this
later,
because most people USING OLSR for their research will use the stuff
described
in the default RFC. We should not do the same mistake in the OLSRv2 RFC.
My suggestion is:
include a simple version of ETX as an example metric into the OLSRv2
RFC.

Why ETX ? Why not ETT/SNR/MIC/.... ?

ETX is not the best metric out there, it's a very basic one. But it's
VERY
easy to describe and implement, it's independant from the layer 1/2
below OLSR
and it allows to build much better real world networks than hopcount. I
know
no other metric that can provide these three advantages.

We should add a few sentences into the chapter that this will be just
the
"lowest common metric" which should work with all OLSRv2 agents a= nd that
there
are much better and more specialized metrics described in other
documents and
research papers. But if we do not put a real metric into the RFC we will have
people saying "OLSRv2 does not work well" in years, just because = they do
their
comparision based on the RFC implementation (hopcount).

If there is a consensus on this I can easily write description of a
simple
Hello-Message based ETX implementation with a single tuning parameter
for the
draft.

What do you think ?

Henning Rogge

********************************************************************
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

_______________________________________________
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
--B_3338372675_816613-- From teco@inf-net.nl Wed Oct 14 14:30: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 8F6CC28C100 for ; Wed, 14 Oct 2009 14:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MISSING_MIMEOLE=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 4dhfsRe9hosB for ; Wed, 14 Oct 2009 14:30:41 -0700 (PDT) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id 6E74428C10E for ; Wed, 14 Oct 2009 14:30:40 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 14 Oct 2009 23:30:42 +0200 From: "Teco Boot" To: References: In-Reply-To: Date: Wed, 14 Oct 2009 23:30:42 +0200 Message-ID: <001b01ca4d15$95306830$bf913890$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpM9f5DJ6zPwa6PrkWbsVC/Jfz+EgAGoSaw Content-Language: nl Importance: High X-OriginalArrivalTime: 14 Oct 2009 21:30:42.0290 (UTC) FILETIME=[94FF6D20:01CA4D15] Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 21:30:42 -0000 I support a strong recommendation for using link metrics in a MANET. I think ETX is the poor men solution, which I would not recommend for real networks. But yes, ETX is not dependent of sub-IP layer information. I've no objection against adding it in an appendix. Reading dearlove-olsrv2-metrics-04, it is recommended that in a well-designed network, all routers will use the same physical metric type. I agree on this, but I highly prefer an OLSR specification that uses dimensionless metrics, in TC and Hello. This enables using different physical metric types, without incompatibility. I'm not sure if this is fully supported in dearlove-olsrv2-metrics-04. Using for example ETX and sub-IP layer information such as RFC4938 in the same network and a need of transfer of data from receiver to sender (e.g. RSSI, hello loss ratio etc.) could cause problems. Let's try to avoid such problems. My suggestion: When router A is the originator of a TC, it is responsible for the advertized metric for outbound, from A to whatever neighbor. A's neighbors should send a helpful, dimensionless metric to A. In addition, the neighbors may send metrics to A with dimensions, but MUST NOT rely on these metrics being used. A reason for neighbors of A not sending a helpful, dimensionless metric to A is the awareness of A having the information already (e.g. the sub-IP layer transfers such information already) or too much overhead. Regards, Teco From thomas@thomasclausen.org Wed Oct 14 14:49: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 615AD3A6838 for ; Wed, 14 Oct 2009 14:49:07 -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 d2TOREHOY+K5 for ; Wed, 14 Oct 2009 14:49:06 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 89E763A6811 for ; Wed, 14 Oct 2009 14:49:06 -0700 (PDT) Received: from aste-genev-bois-153-1-42-87.w83-200.abo.wanadoo.fr ([83.200.92.87] helo=[192.168.147.148]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MyBiW-0003m2-AZ; Wed, 14 Oct 2009 21:49:08 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.200.92.87 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/TShLyVMMZN35qzQoZNtNN From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <001b01ca4d15$95306830$bf913890$@nl> X-Priority: 1 (Highest) References: <001b01ca4d15$95306830$bf913890$@nl> Message-Id: <30D3CC2E-120B-4A31-A188-96CAF5663AED@thomasclausen.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 23:49:04 +0200 X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 14 Oct 2009 21:49:07 -0000 Teco, I believe that if you would read draft-dearlove-olsrv2-metrics, you would find that it provides exactly dimensionless metrics. Thomas On Oct 14, 2009, at 11:30 PM, Teco Boot wrote: > I support a strong recommendation for using link metrics in a MANET. > > I think ETX is the poor men solution, which I would not recommend > for real networks. > But yes, ETX is not dependent of sub-IP layer information. > I've no objection against adding it in an appendix. > > Reading dearlove-olsrv2-metrics-04, it is recommended that in a > well-designed network, all routers will use the same physical > metric type. I agree on this, but I highly prefer an OLSR > specification > that uses dimensionless metrics, in TC and Hello. This enables using > different physical metric types, without incompatibility. > I'm not sure if this is fully supported in dearlove-olsrv2-metrics-04. > Using for example ETX and sub-IP layer information such as RFC4938 in > the same network and a need of transfer of data from receiver to > sender > (e.g. RSSI, hello loss ratio etc.) could cause problems. Let's try to > avoid such problems. > My suggestion: When router A is the originator of a TC, it is > responsible for the advertized metric for outbound, from A to whatever > neighbor. A's neighbors should send a helpful, dimensionless metric > to A. > In addition, the neighbors may send metrics to A with dimensions, > but MUST NOT rely on these metrics being used. > > A reason for neighbors of A not sending a helpful, dimensionless > metric > to A is the awareness of A having the information already (e.g. the > sub-IP > layer transfers such information already) or too much overhead. > > Regards, Teco > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chiang.Tan@thalesgroup.com Thu Oct 15 04:14:33 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 EE7343A68DF for ; Thu, 15 Oct 2009 04:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 u0OxvAzQW19a for ; Thu, 15 Oct 2009 04:14:33 -0700 (PDT) Received: from thsmsgxrt13p.thalesgroup.com (thsmsgxrt13p.thalesgroup.com [192.54.144.136]) by core3.amsl.com (Postfix) with ESMTP id D95373A68DA for ; Thu, 15 Oct 2009 04:14:32 -0700 (PDT) Received: from thsmsgirt26p.corp.thales (unknown [10.33.231.4]) by thsmsgxrt13p.thalesgroup.com (Postfix) with ESMTP id 2B51B3610A3 for ; Thu, 15 Oct 2009 13:14:35 +0200 (CEST) Received: from thsmsgiav11p.corp.thales (10.33.231.31) by thsmsgirt26p.corp.thales (8.5.103) id 4AAF98EF003CC094 for manet@ietf.org; Thu, 15 Oct 2009 13:14:35 +0200 Received: from (unknown [10.33.231.2]) by thsmsgiav11p.corp.thales with smtp id 21eb_2afd_eb7caad2_b97b_11de_92c2_001143d32df6; Thu, 15 Oct 2009 13:14:35 +0200 Received: from msw002.uk.trt.thales (unknown [10.33.5.101]) by thsmsgirt12p.corp.thales (Postfix) with ESMTP id 380C2391BC1 for ; Thu, 15 Oct 2009 13:14:33 +0200 (CEST) Received: from NTS013.uk.trt.thales (nts013.uk.trt.thales) by msw002.uk.trt.thales (Clearswift SMTPRS 5.3.2) with ESMTP id ; Thu, 15 Oct 2009 12:14:24 +0100 Received: by nts013.uk.trt.thales with Internet Mail Service (5.5.2657.72) id <4FY9LS4S>; Thu, 15 Oct 2009 12:14:24 +0100 Message-ID: <51BF576D5A02CC4CB2591F50994FD766051F1DB6@nts013.uk.trt.thales> From: "Tan, Chiang Kang " To: 'Henning Rogge' , manet@ietf.org Date: Thu, 15 Oct 2009 12:14:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [manet] Default metric in OLSRv2 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, 15 Oct 2009 11:14:34 -0000 >Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a >conference about military communications. There were a couple of presentations >which used OLSR as a mesh net protocol and they can be summarized as: "OLSR >does not work well". When I tried to get some more facts about this I quickly >recognized that all of them used hopcount metrics "because it's the default >described in the RFC". Many apologies if my question is a bit off from your original post. So happened that I'm seeing this I believe a hop count related problem in the OLSR protocol I'm using in my testbed environment. My observation in one scenario is a source node uses a forward path that is different from a return path from a destination node, both paths 3 hops apart. So my question is does this commonly happen using OLSR with hop count as a metric? I'm not absolutely certain if this is giving me the problem I'm experiencing, but I'm interested to know if this is also one of those "does not work well" points presented to you recently. Thank you. Regards, Chiang **************************************************************************** Please consider the environment before printing this email. **************************************************************************** Thales Research and Technology (UK) Limited DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained herein. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0)1293 575987 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. The registered office of Thales Research and Technology (UK) Limited is at: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered in England No. 774298. **************************************************************************** From Chris.Dearlove@baesystems.com Fri Oct 16 02:21: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 1EE903A69BB for ; Fri, 16 Oct 2009 02:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_20=-0.74] 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 V38MFIfjKFsP for ; Fri, 16 Oct 2009 02:21:20 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2230D3A69AA for ; Fri, 16 Oct 2009 02:21:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,572,1249254000"; d="scan'208";a="27801334" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Oct 2009 10:21:24 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9G9LScE022688; Fri, 16 Oct 2009 10:21:28 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Oct 2009 10:21:22 +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, 16 Oct 2009 10:21:21 +0100 Message-ID: In-Reply-To: <001b01ca4d15$95306830$bf913890$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpM9f5DJ6zPwa6PrkWbsVC/Jfz+EgAGoSawAExFoVA= References: <001b01ca4d15$95306830$bf913890$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , X-OriginalArrivalTime: 16 Oct 2009 09:21:22.0863 (UTC) FILETIME=[072C43F0:01CA4E42] Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 09:21:21 -0000 > Reading dearlove-olsrv2-metrics-04, it is recommended that in a > well-designed network, all routers will use the same physical > metric type. I agree on this, but I highly prefer an OLSR specification > that uses dimensionless metrics, in TC and Hello. That is precisely what those metrics are. ******************************************************************** 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 Oct 16 02:40: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 A7F703A68A8 for ; Fri, 16 Oct 2009 02:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 EgRjul4Vwkur for ; Fri, 16 Oct 2009 02:40:42 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2E7193A67DA for ; Fri, 16 Oct 2009 02:40:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,572,1249254000"; d="scan'208";a="27807950" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Oct 2009 10:40:45 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9G9eptn004452; Fri, 16 Oct 2009 10:40:51 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Oct 2009 10:40: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: Fri, 16 Oct 2009 10:40:44 +0100 Message-ID: In-Reply-To: <51BF576D5A02CC4CB2591F50994FD766051F1DB6@nts013.uk.trt.thales> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpNiLLZhxrzkArwQxOAwq66dNUkqgAuWBTA References: <51BF576D5A02CC4CB2591F50994FD766051F1DB6@nts013.uk.trt.thales> From: "Dearlove, Christopher (UK)" To: "Tan, Chiang Kang " , "Henning Rogge" , X-OriginalArrivalTime: 16 Oct 2009 09:40:45.0503 (UTC) FILETIME=[BC290CF0:01CA4E44] Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 09:40:43 -0000 > My observation in one > scenario is a source node uses a forward path that is different from a > return path from a destination node, both paths 3 hops apart. So my question > is does this commonly happen using OLSR with hop count as a metric? Yes. Let's consider the simplest interesting network, one with four nodes in a square, with no diagonal connections, ABCD round the square. I'm going to discuss two hop paths, obviously this generalises to more than two hops. Actually any node can send information "left" or "right" to its opposite node, because it can use two hop information directly without considering MPRs. But use of MPRs is preferred by RFC 3626 (and in OLSRv2) so we'll assume that. What that means is that if A is routing to C it will choose B as a preferred route if it has a B to C link in its Topology Set, i.e. (assuming only MPR selectors are advertised in TC messages) if C selected B as an MPR. A will choose D as a preferred route if C selected D as an MPR. C must choose one or the other. It may choose both if there is more to this network, in which case A has a choice, rather than its choice being dictated by C. But in general that means choices. Choices can't be avoided (with extra nodes hanging off B and D, C must choose both as MPRs). Sometimes those choices are made (in this case) by A, sometimes by C, sometiimes (in more complicated cases) by A and C and by other nodes on the path between them. Going back to the square, we can in that case make consistent choices (other than by extra signalling, which rather defeats the object of the OLSR exercise) only by consistent MPR selection. In general that's not possible. In the square case it's not impossible, some coordination can be done. But without coordination everyone might pick MPRs such that all traffic flow over two hops is, say, clockwise. There's also a question as to whether this matters, and if so why. But if that is a desirable feature then you need either a significant modification of OLSR (and not having considered it I don't know how easy it would be, but my guess is that it would be tricky with limited topology, easier with fuller topology) or a new routing algorithm. (And how maintainable it is in the face of dynamism would be another question.) And finally, if a wide range of metrics is used, and metrics are the same in both directions, then this gets less likely with metrics (as it requires what becomes more of a coincidence of there being equal length routes). But with unidirectional metrics (as we intend to add) it becomes quite likely with metrics also. ******************************************************************** 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 Oct 16 03:03: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 935663A67A1 for ; Fri, 16 Oct 2009 03:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_QP_LONG_LINE=1.396, 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 mGOMOWvZAIuI for ; Fri, 16 Oct 2009 03:03:56 -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 465863A6859 for ; Fri, 16 Oct 2009 03:03:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,572,1249250400"; d="scan'208";a="35043459" Received: from pericui.inria.fr (HELO localhost) ([128.93.24.186]) by mail2-relais-roc.national.inria.fr with ESMTP; 16 Oct 2009 12:03:58 +0200 Received: from sphinx.lix.polytechnique.fr (sphinx.lix.polytechnique.fr [129.104.11.1]) by pops-rocq.inria.fr (Horde MIME library) with HTTP; Fri, 16 Oct 2009 12:03:58 +0200 Message-ID: <20091016120358.8s28fkzkg84kgo8c@pops-rocq.inria.fr> Date: Fri, 16 Oct 2009 12:03:58 +0200 From: Philippe Jacquet To: Henning Rogge References: <200910131741.49152.hrogge@googlemail.com> In-Reply-To: <200910131741.49152.hrogge@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 10:03:57 -0000 Hello, Henning, I would add two points to the discussion which is interesting and important. First point: there are many ways to have a MANET/OLSR not working =20 well: bugs, badly tuned parameters. The main source of trouble is in =20 general how neighbor sensing asserts the quality of a link in order to =20 accept it or reject it, and I agree that using a metric will greatly =20 help. Anyhow RFC 3626 was not excluding the use of link quality in neighbor =20 sensing, and was suggesting some. The hop count should not be problem =20 as long as the links that are on the path are good links. In other =20 words I would see the use of path quality as a minor improvement over =20 the use link quality in neighbor sensing. Anyhow this would help =20 traffic engineering. Second point: adding a default link quality in OLSRv2 may be as =20 complicated as inserting general metric in OLSv2, eg in MPR selection, =20 so we might be careful if we hurry too much. Anyhow I am looking forward a draft that describes the ETX metric that =20 has got very good experimental records and personnaly I like the =20 dimensionless metrics (we designed and experimented some with IEEE =20 802.11/ OLSR cross layering). Best regards Henning Rogge a ?it=A0: > Hello, > > I know this mail comes a little bit early (metrics have not been merged in= to > OLSRv2 draft), but I would like to like to argue for more than "include > generic metric support in OLSRv2". > > Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a > conference about military communications. There were a couple of =20 > presentations > which used OLSR as a mesh net protocol and they can be summarized as: "OLS= R > does not work well". When I tried to get some more facts about this I quic= kly > recognized that all of them used hopcount metrics "because it's the defaul= t > described in the RFC". > > I think this was a mistake in the OLSRv1 RFC, it described a =20 > protocol that did > not work very well in the real world because of hopcount metrics. No =20 > amount of > great research for new metric or improved features have changed this later= , > because most people USING OLSR for their research will use the stuff =20 > described > in the default RFC. We should not do the same mistake in the OLSRv2 RFC. > > My suggestion is: > include a simple version of ETX as an example metric into the OLSRv2 RFC. > > Why ETX ? Why not ETT/SNR/MIC/.... ? > > ETX is not the best metric out there, it's a very basic one. But it's VERY > easy to describe and implement, it's independant from the layer 1/2 =20 > below OLSR > and it allows to build much better real world networks than hopcount. I kn= ow > no other metric that can provide these three advantages. > > We should add a few sentences into the chapter that this will be just the > "lowest common metric" which should work with all OLSRv2 agents and =20 > that there > are much better and more specialized metrics described in other documents = and > research papers. But if we do not put a real metric into the RFC we will h= ave > people saying "OLSRv2 does not work well" in years, just because =20 > they do their > comparision based on the RFC implementation (hopcount). > > If there is a consensus on this I can easily write description of a simple > Hello-Message based ETX implementation with a single tuning parameter for = the > draft. > > What do you think ? > > Henning Rogge > --=20 Philippe Jacquet Hipercom project team leader INRIA tel: +33 1 39 63 52 63 fax: +33 1 39 63 55 66 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From henning.rogge@fkie.fraunhofer.de Fri Oct 16 03:23:16 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 B71303A6873 for ; Fri, 16 Oct 2009 03:23:16 -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 tkPxitfiTwYL for ; Fri, 16 Oct 2009 03:23:15 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 9ABE23A6859 for ; Fri, 16 Oct 2009 03:23:15 -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 1Myjxu-0006Jr-9n; Fri, 16 Oct 2009 12:23:18 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Myjxu-0005uY-1I; Fri, 16 Oct 2009 12:23:18 +0200 From: Henning Rogge To: manet@ietf.org Date: Fri, 16 Oct 2009 12:23:47 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200910131741.49152.hrogge@googlemail.com> <20091016120358.8s28fkzkg84kgo8c@pops-rocq.inria.fr> In-Reply-To: <20091016120358.8s28fkzkg84kgo8c@pops-rocq.inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3190950.fNlVpasJ0k"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910161223.47842.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9905/Fri Oct 16 10:23:35 2009) by mailguard.fgan.de X-Scan-Signature: 881f1349a4369b9786c211f3f02fb772 Cc: Philippe Jacquet Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 10:23:16 -0000 --nextPart3190950.fNlVpasJ0k Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri October 16 2009 12:03:58 schrieb Philippe Jacquet: > Hello, Henning, > > I would add two points to the discussion which is interesting and > important. > > First point: there are many ways to have a MANET/OLSR not working > well: bugs, badly tuned parameters. The main source of trouble is in > general how neighbor sensing asserts the quality of a link in order to > accept it or reject it, and I agree that using a metric will greatly > help. > > Anyhow RFC 3626 was not excluding the use of link quality in neighbor > sensing, and was suggesting some. The hop count should not be problem > as long as the links that are on the path are good links. In other > words I would see the use of path quality as a minor improvement over > the use link quality in neighbor sensing. Anyhow this would help > traffic engineering. I don't agree. In practice it's very difficult to decide if a link is "good" or "bad" as a= =20 binary decission. Maybe the bad link is really important for another node,= =20 maybe it is not. Link sensing and hysteresis, even with a local metric, is no replacement fo= r a=20 good additive routing metric used for the dijkstra algorithm in global=20 routing. > Second point: adding a default link quality in OLSRv2 may be as > complicated as inserting general metric in OLSv2, eg in MPR selection, > so we might be careful if we hurry too much. If we put only hop count metric into the main document that's what most=20 research projects will be using as a comparision. And you will hear things= =20 like "yes, AODV has lot's of delay for route creation, but OLSR has 30% pac= ket=20 loss". It's more a matter of perception. People will use "Core RFC OLSR without=20 extensions" and will get bad results from it. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3190950.fNlVpasJ0k 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) iEYEABECAAYFAkrYSbMACgkQRIfGfFXsz+DkdwCgoTFLI6laYbJyuV5vx1RX4zk7 u+AAoIbYDP+nWsnRa3mgx9w7Z27ztfxC =7fOo -----END PGP SIGNATURE----- --nextPart3190950.fNlVpasJ0k-- From Chris.Dearlove@baesystems.com Fri Oct 16 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 2CBA128C1B2 for ; Fri, 16 Oct 2009 03:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 6mEvg-QqU9LD for ; Fri, 16 Oct 2009 03:34:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 391CC3A6873 for ; Fri, 16 Oct 2009 03:34:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,572,1249254000"; d="scan'208";a="27826445" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Oct 2009 11:34:08 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9GAYDXn011711; Fri, 16 Oct 2009 11:34:13 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 11:34: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, 16 Oct 2009 11:34:06 +0100 Message-ID: In-Reply-To: <200910161223.47842.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpOSrdM7Lq4JtyISN6oHhokDgURrQAALSeg References: <200910131741.49152.hrogge@googlemail.com><20091016120358.8s28fkzkg84kgo8c@pops-rocq.inria.fr> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 16 Oct 2009 10:34:07.0359 (UTC) FILETIME=[309D80F0:01CA4E4C] Cc: Philippe Jacquet Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 10:34:05 -0000 > Link sensing and hysteresis, even with a local metric, is no replacement for a > good additive routing metric used for the dijkstra algorithm in global > routing. Agreed. It is worth noting however that at least in some systems (802.11) link sensing (hysteresis - when the word is properly used - is just a detail there) makes the difference between a system that doesn't work (due to the differences in 802.11 broadcast and multicast) and one that works. Link metrics make the difference between a system that works (for at least some uses) and one that may work better. > If we put only hop count metric into the main document that's what most > research projects will be using as a comparision. Will you please read the metrics draft, and my postings here, which have said, again and again, that this is NOT the proposal. ******************************************************************** 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 henning.rogge@fkie.fraunhofer.de Fri Oct 16 04:04: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 BFF843A69DC for ; Fri, 16 Oct 2009 04:04:36 -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 aTTPMwPAEbR7 for ; Fri, 16 Oct 2009 04:04:35 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 9A4743A69E0 for ; Fri, 16 Oct 2009 04:04:35 -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 1Mykbu-0000oB-4w; Fri, 16 Oct 2009 13:04:38 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Mykbt-00065p-JD; Fri, 16 Oct 2009 13:04:37 +0200 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Fri, 16 Oct 2009 13:05:03 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200910131741.49152.hrogge@googlemail.com> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2864268.L0VXbZfm6J"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910161305.08377.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9905/Fri Oct 16 10:23:35 2009) by mailguard.fgan.de X-Scan-Signature: 4bd55a28bd80295bcea19a4a30c6a3ea Cc: Philippe Jacquet , manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 11:04:36 -0000 --nextPart2864268.L0VXbZfm6J Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri October 16 2009 12:34:06 schrieb Dearlove, Christopher (UK): > > Link sensing and hysteresis, even with a local metric, is no > > replacement for a > > > good additive routing metric used for the dijkstra algorithm in global > > > > routing. > > Agreed. It is worth noting however that at least in some systems > (802.11) link sensing (hysteresis - when the word is properly used > - is just a detail there) makes the difference between a system > that doesn't work (due to the differences in 802.11 broadcast and > multicast) and one that works. Link metrics make the difference > between a system that works (for at least some uses) and one that > may work better. It might even make sense to use the calculated routing metric value for lin= k=20 sensing too (deciding if you include the link into your routing set). (activating a new link if it's get better than ETX 8 and drop it completely= if=20 it goes beyond ETX 16 for example) > > If we put only hop count metric into the main document that's what > > most research projects will be using as a comparision. > > Will you please read the metrics draft, and my postings here, which have > said, again and again, that this is NOT the proposal. The default value in your metric draft will still create a hopcount metric.= =20 And there is no other example for a working link metric inside the current= =20 metric draft. So if we include the metric draft into the OLSRv2 draft, the default=20 implementation will still be hopcount and there will be no other metric ins= ide=20 the OLSRv2 draft. We all know that the purpose of the draft is to say the=20 people "use a good link metric"... but I fear there will be still a lot of= =20 researchers around that will use "default rfc olsrv2". Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart2864268.L0VXbZfm6J 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) iEYEABECAAYFAkrYU18ACgkQRIfGfFXsz+A5hwCeLfDTrR5yiBWMBJpe6e8h2AcQ h4cAn1V3xS12olqkUI2m7K04JhoOS2Pa =xK8T -----END PGP SIGNATURE----- --nextPart2864268.L0VXbZfm6J-- From Chris.Dearlove@baesystems.com Fri Oct 16 04:16:03 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 0AD763A6A20 for ; Fri, 16 Oct 2009 04:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 I9iWoWay8gKB for ; Fri, 16 Oct 2009 04:16:02 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 062223A6A1C for ; Fri, 16 Oct 2009 04:16:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,573,1249254000"; d="scan'208";a="27842551" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Oct 2009 12:16:06 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9GBGASA011284; Fri, 16 Oct 2009 12:16:11 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 12:16: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, 16 Oct 2009 12:16:04 +0100 Message-ID: In-Reply-To: <200910161305.08377.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpOUHhChdB/vrCrS6WETNsHcsJHpAAABkZg References: <200910131741.49152.hrogge@googlemail.com> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> <200910161305.08377.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 16 Oct 2009 11:16:05.0202 (UTC) FILETIME=[0D5DDB20:01CA4E52] Cc: Philippe Jacquet , manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 11:16:03 -0000 >> Will you please read the metrics draft, and my postings here, which have >> said, again and again, that this is NOT the proposal. > The default value in your metric draft will still create a hopcount metric. Yes, that's the default value. But that is not using a hop count metric. > And there is no other example for a working link metric inside the current > metric draft. That's a separation of responsibility. While particular metrics make motivation, it's putting too much into OLSRv2 to specify the metric and how it is to be created. All of that is ideal for another draft, which can discuss motivation, definition, IANA codepoints (from the TLV defined) etc. I am hoping you will, with the various people who have offered support, take up that task. We may well reference, from the motivation part of the document, something external (NOT the draft we're taling about below, that creates a circular, possibly down, reference that is not appropriate) to note the desirability of metrics. (The existing draft rather glosses over that as preaching to the converted.) But this wants to be about metrics in general, not (however suitable it may be as a first choice) ETX or anything else. > So if we include the metric draft into the OLSRv2 draft, the default > implementation will still be hopcount NO. An implementation will not be compliant unless it implements metrics, how to handle metrics in incoming messages. If it chooses never to use that code it has implemented itself, there's really not much one can do about that. But a pure hopcount implementation will not be compliant. Note that the default metric meaning will be up to local configuration. But it will be there, and must be implemented. > I fear there will be still a lot of > researchers around that will use "default rfc olsrv2". They won't be doing that. If they don't implement metrics, they won't have implemented the RFC. ******************************************************************** 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 teco@inf-net.nl Fri Oct 16 04:31:48 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 EABA628B23E for ; Fri, 16 Oct 2009 04:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=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 CjiSfZEaLGY6 for ; Fri, 16 Oct 2009 04:31:48 -0700 (PDT) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id E9B273A6A25 for ; Fri, 16 Oct 2009 04:31:47 -0700 (PDT) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 16 Oct 2009 13:31:50 +0200 From: "Teco Boot" To: References: <200910131741.49152.hrogge@googlemail.com> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> <200910161305.08377.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Date: Fri, 16 Oct 2009 13:31:50 +0200 Message-ID: <002001ca4e54$4107a580$c316f080$@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: AcpOUHhChdB/vrCrS6WETNsHcsJHpAAABkZgAACYNCA= Content-Language: nl X-OriginalArrivalTime: 16 Oct 2009 11:31:50.0104 (UTC) FILETIME=[40927580:01CA4E54] Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 11:31:49 -0000 All, Henning Rogge: >> I fear there will be still a lot of >> researchers around that will use "default rfc olsrv2". Christopher Dearlove: >They won't be doing that. If they don't implement metrics, they >won't have implemented the RFC. It seems we all agree on recommending usage of link metrics. This is great. We can have endless discussions on what researchers will do. But IETF has little influence here. I think we shall focus on implementations for real users. We define practical and interoperable protocols. I'm looking forward to the updated OLSRv2 draft, which includes metrics. Regards, Teco From ulrich@herberg.name Fri Oct 16 04:38:28 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 CD57C28C0DB for ; Fri, 16 Oct 2009 04:38:28 -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 c7Pmuv8XBSWz for ; Fri, 16 Oct 2009 04:38:28 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C2CA43A68D6 for ; Fri, 16 Oct 2009 04:38:27 -0700 (PDT) Received: by fxm18 with SMTP id 18so2287328fxm.37 for ; Fri, 16 Oct 2009 04:38:31 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.153.198 with SMTP id l6mr1172202bkw.191.1255693111108; Fri, 16 Oct 2009 04:38:31 -0700 (PDT) In-Reply-To: <002001ca4e54$4107a580$c316f080$@nl> References: <200910131741.49152.hrogge@googlemail.com> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> <200910161305.08377.henning.rogge@fkie.fraunhofer.de> <002001ca4e54$4107a580$c316f080$@nl> Date: Fri, 16 Oct 2009 13:38:30 +0200 X-Google-Sender-Auth: b94cf659b23cbef8 Message-ID: <25c114b90910160438s1c48bf3eu91924930d0e3b723@mail.gmail.com> From: Ulrich Herberg To: Teco Boot Content-Type: multipart/alternative; boundary=0015175ce28cd5b5fe04760bd55d Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 11:38:28 -0000 --0015175ce28cd5b5fe04760bd55d Content-Type: text/plain; charset=ISO-8859-1 Hi, On Fri, Oct 16, 2009 at 1:31 PM, Teco Boot wrote: > [...] > It seems we all agree on recommending usage of link metrics. > This is great. > > We can have endless discussions on what researchers will do. > But IETF has little influence here. > I think we shall focus on implementations for real users. > We define practical and interoperable protocols. > > I'm looking forward to the updated OLSRv2 draft, which includes metrics. > I agree with Teco. Before continuing this discussion, I think it would be very helpful to write an ETX metrics draft, then to integrate the metrics draft into OLSRv2, and only *then* consider whether to explicitly mention a metric other than hop-count in the OLSRv2 draft (e.g. in the appendix, as suggested), or whether it's enough to set up the code points for different metrics. Ulrich --0015175ce28cd5b5fe04760bd55d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Fri, Oct 16, 2009 at 1:31 PM, Teco= Boot <teco@inf-net= .nl> wrote:
[...]
It seems we all agree on recommending usage of link metrics.
This is great.

We can have endless discussions on what researchers will do.
But IETF has little influence here.
I think we shall focus on implementations for real users.
We define practical and interoperable protocols.

I'm looking forward to the updated OLSRv2 draft, which includes metrics= .

I agree with Teco. Before continuing this discu= ssion, I think it would be very helpful to write an ETX metrics draft, then= to integrate the metrics draft into OLSRv2, and only *then* consider wheth= er to explicitly mention a metric other than hop-count in the OLSRv2 draft = (e.g. in the appendix, as suggested), or whether it's enough to set up = the code points for different metrics.

Ulrich
--0015175ce28cd5b5fe04760bd55d-- From philippe.jacquet@inria.fr Fri Oct 16 05:00:48 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 588D728C20B for ; Fri, 16 Oct 2009 05:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_QP_LONG_LINE=1.396, 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 JY2tF0sXrGEK for ; Fri, 16 Oct 2009 05:00:47 -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 EFE6728C207 for ; Fri, 16 Oct 2009 05:00:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,573,1249250400"; d="scan'208";a="38387102" Received: from pericui.inria.fr (HELO localhost) ([128.93.24.186]) by mail1-relais-roc.national.inria.fr with ESMTP; 16 Oct 2009 14:00:49 +0200 Received: from sphinx.lix.polytechnique.fr (sphinx.lix.polytechnique.fr [129.104.11.1]) by pops-rocq.inria.fr (Horde MIME library) with HTTP; Fri, 16 Oct 2009 14:00:49 +0200 Message-ID: <20091016140049.qdr5e3okoo48cgwc@pops-rocq.inria.fr> Date: Fri, 16 Oct 2009 14:00:49 +0200 From: Philippe Jacquet To: Henning Rogge References: <200910131741.49152.hrogge@googlemail.com> <20091016120358.8s28fkzkg84kgo8c@pops-rocq.inria.fr> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200910161223.47842.henning.rogge@fkie.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 12:00:48 -0000 Henning Rogge a ?it=A0: >> Anyhow RFC 3626 was not excluding the use of link quality in neighbor >> sensing, and was suggesting some. The hop count should not be problem >> as long as the links that are on the path are good links. In other >> words I would see the use of path quality as a minor improvement over >> the use link quality in neighbor sensing. Anyhow this would help >> traffic engineering. > I don't agree. > > In practice it's very difficult to decide if a link is "good" or "bad" as = a > binary decission. Maybe the bad link is really important for another node, > maybe it is not. Dear Henning, we are in agreement, protocol solely based on link admissions control =20 have basically two defaults: 1. either the link admission conditions are too loose and the network =20 accepts links that are too instable for sustained data traffics 2. or the conditions are too tight and the network excludes too many =20 links and makes the graph disconnected. What is difficult is to get experimental situations where you have =20 both cases. I don't say it is impossible, but it is likely marginal, =20 anyhow worthy enough to include path metrics in OLSR. Anyhow an =20 additive path metric won't give the garantee that all links in the =20 path are good enough, one may have one very bad link, hidden by the =20 quality of the other links that are good enough to make the overall =20 path optimal by Dijskstra. There are no perfect specifications but one cannot say that all buggy =20 situations necessarily come from the absence of good specifications. =20 Some may come from a too strict application of the default values of =20 the tuning parameters parameters proposed in the RFC. I remember an experiment that concludes that OLSR between high speed =20 cars was great to reduce overhead but led to too faulty links. I =20 remember of another similar experiment that use much faster hellos =20 between high speed cars, that lead to still very good overhead =20 reduction and made link failure detection very good (good enough at =20 least to open succesful TCP/IP connections between cars moving in =20 opposite direction at 100 km/h). Notice that path metric won't help =20 when bad or delayed estimate of link qualities are advertized. A last point: one must be careful in defining default metrics if it =20 requires some link layer notification that are not easy to implement. I am looking forward the draft about ETX, it will be useful in =20 improving the practice of use of metrics in OLSR. Best regards, Philippe ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From henning.rogge@fkie.fraunhofer.de Fri Oct 16 05:51:27 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 BDEBD3A6A1C for ; Fri, 16 Oct 2009 05:51:27 -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=[AWL=-0.000, 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 TNwqfCcfDATk for ; Fri, 16 Oct 2009 05:51:26 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 460583A6781 for ; Fri, 16 Oct 2009 05:51:25 -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 1MymHI-0006fE-ND; Fri, 16 Oct 2009 14:51:28 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MymHI-0006hS-Cb; Fri, 16 Oct 2009 14:51:28 +0200 From: Henning Rogge To: Philippe Jacquet Date: Fri, 16 Oct 2009 14:51:54 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200910131741.49152.hrogge@googlemail.com> <200910161223.47842.henning.rogge@fkie.fraunhofer.de> <20091016140049.qdr5e3okoo48cgwc@pops-rocq.inria.fr> In-Reply-To: <20091016140049.qdr5e3okoo48cgwc@pops-rocq.inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1634699.ijmGlqQqsp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910161451.59751.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9905/Fri Oct 16 10:23:35 2009) by mailguard.fgan.de X-Scan-Signature: a44ad90b87c1147b5edf0a173c47bafd Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 12:51:27 -0000 --nextPart1634699.ijmGlqQqsp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri October 16 2009 14:00:49 schrieb Philippe Jacquet: > Henning Rogge a ?it : > >> Anyhow RFC 3626 was not excluding the use of link quality in neighbor > >> sensing, and was suggesting some. The hop count should not be problem > >> as long as the links that are on the path are good links. In other > >> words I would see the use of path quality as a minor improvement over > >> the use link quality in neighbor sensing. Anyhow this would help > >> traffic engineering. > > > > I don't agree. > > > > In practice it's very difficult to decide if a link is "good" or "bad" = as > > a binary decission. Maybe the bad link is really important for another > > node, maybe it is not. > > Dear Henning, > > we are in agreement, protocol solely based on link admissions control > have basically two defaults: > > 1. either the link admission conditions are too loose and the network > accepts links that are too instable for sustained data traffics > 2. or the conditions are too tight and the network excludes too many > links and makes the graph disconnected. > > > What is difficult is to get experimental situations where you have > both cases. I don't say it is impossible, but it is likely marginal, > anyhow worthy enough to include path metrics in OLSR. Anyhow an > additive path metric won't give the garantee that all links in the > path are good enough, one may have one very bad link, hidden by the > quality of the other links that are good enough to make the overall > path optimal by Dijskstra. I still disagree. The problem with hopcount and local "filtering" of links is that hopcount=20 still optimize to use the "worst" of your good links. Which might still not= be=20 a good idea. > There are no perfect specifications but one cannot say that all buggy > situations necessarily come from the absence of good specifications. > Some may come from a too strict application of the default values of > the tuning parameters parameters proposed in the RFC. > > I remember an experiment that concludes that OLSR between high speed > cars was great to reduce overhead but led to too faulty links. I > remember of another similar experiment that use much faster hellos > between high speed cars, that lead to still very good overhead > reduction and made link failure detection very good (good enough at > least to open succesful TCP/IP connections between cars moving in > opposite direction at 100 km/h). Notice that path metric won't help > when bad or delayed estimate of link qualities are advertized. > > A last point: one must be careful in defining default metrics if it > requires some link layer notification that are not easy to implement. > > I am looking forward the draft about ETX, it will be useful in > improving the practice of use of metrics in OLSR. A good link hysteresis/filtering can enhance a path metric based OLSR netwo= rk,=20 thats true. But I think path metric is at least as important as link=20 hysteresis. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1634699.ijmGlqQqsp 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) iEYEABECAAYFAkrYbGoACgkQRIfGfFXsz+Cv9gCcDQ8+AydRUICdjW3cbuiopgjs z1wAnAxkrxyDtabJaWoek88+lfCVfwFO =FlVg -----END PGP SIGNATURE----- --nextPart1634699.ijmGlqQqsp-- From Chris.Dearlove@baesystems.com Fri Oct 16 06:00: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 0D3703A6A34 for ; Fri, 16 Oct 2009 06:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 cWlkTnwXa5L1 for ; Fri, 16 Oct 2009 06:00:38 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 014323A67FB for ; Fri, 16 Oct 2009 06:00:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,573,1249254000"; d="scan'208";a="27870486" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Oct 2009 14:00:42 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9GD0lCS013284; Fri, 16 Oct 2009 14:00:47 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 14:00:41 +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, 16 Oct 2009 14:00:40 +0100 Message-ID: In-Reply-To: <200910161451.59751.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Default metric in OLSRv2 thread-index: AcpOX2en8Tgkj5nqSB+peLedQN0sTAAAPRFA References: <200910131741.49152.hrogge@googlemail.com><200910161223.47842.henning.rogge@fkie.fraunhofer.de><20091016140049.qdr5e3okoo48cgwc@pops-rocq.inria.fr> <200910161451.59751.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , "Philippe Jacquet" X-OriginalArrivalTime: 16 Oct 2009 13:00:41.0256 (UTC) FILETIME=[AA2FB280:01CA4E60] Cc: manet@ietf.org Subject: Re: [manet] Default metric in OLSRv2 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, 16 Oct 2009 13:00:39 -0000 > A good link hysteresis/filtering can enhance a path metric based OLSR network, > thats true. But I think path metric is at least as important as link > hysteresis. I think debating which is most important is not worthwhile. Both pass the test of being useful enough to include, so which is more useful doesn't really matter. ******************************************************************** 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 barry_jce@yahoo.com Sat Oct 17 11:11:25 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 6D0EB3A6923 for ; Sat, 17 Oct 2009 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.101 X-Spam-Level: **** X-Spam-Status: No, score=4.101 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 LLUA78PVmGtn for ; Sat, 17 Oct 2009 11:11:24 -0700 (PDT) Received: from web36108.mail.mud.yahoo.com (web36108.mail.mud.yahoo.com [66.163.179.222]) by core3.amsl.com (Postfix) with SMTP id BB95B3A68C1 for ; Sat, 17 Oct 2009 11:11:24 -0700 (PDT) Received: (qmail 85991 invoked by uid 60001); 17 Oct 2009 18:11:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1255803088; bh=cf+37PiVIPyD22ZttBKh5af8ZD4XV1eRogT5iyfEMLk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=IODXHQTdHHadKnNKMDXk3m9BO4qNRqcuWZrzdhUGR3b8jFUIwrOaSE9qFwPVbT9/DbSq/ZTquhvhwhOcSQTuaWhMLxi7cEONVW319OVt9xrJXWCJ1fqGP4r1Yih82/4wBpQ5b8Kig6B+Gm3OINU7dYLIhJWjrsjRmYscgbESjKQ= 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=bqes0Yr2qtxpx2Yr13JEPsa4h8xkY2YCIBCK/8Lot5cKWZaHeyvG8ET1pKUReC3qXYQx4mE+fvWWiFEfm/TK7KjuiJjRtEq9d2Wn2hTxYJA1Awo3xp5vJWCKopIWUolqb+MTDmaV88FSauYCvEtu9GUZrOOKQKko9scNSzdTPpI=; Message-ID: <371871.85577.qm@web36108.mail.mud.yahoo.com> X-YMail-OSG: b0sxmCIVM1kq6FxwgBms46S7.8gSkGMBA7rkxSxMoasPQMHo7d4ARdW3O7MExlI97A04WQxq1QwGUEyg7GF7aHRzf.9WNwWJ5gmh7vSRUWj_rOueYuksu7.Ws.VpZRl9bVItu4OXW0JgggawHanuMWxVbTR3ndq.LwwSA217GI9gVaiskc4xtUIvgP87pBK_32h_B7LsS9Y5MyUIwKob1zrgRZeTY0df6xnKtiTeSkSOf6.ycpukw0ZjDIiW2_oM6zhaQWbMKGic2uqQpgcut7qTC.yekp6mSCWpsnzjbgYN_7l.Ob3XBmcwsblZBJ9shXsqD_gBPKS6ysHSRfEuMwfrTWsbghS65g-- Received: from [220.225.140.104] by web36108.mail.mud.yahoo.com via HTTP; Sat, 17 Oct 2009 11:11:27 PDT X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.3 Date: Sat, 17 Oct 2009 11:11:27 -0700 (PDT) From: barry samuel To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1399831322-1255803087=:85577" Subject: [manet] routing for 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, 17 Oct 2009 19:50:52 -0000 --0-1399831322-1255803087=:85577 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi ... Can any one provide me information for efficient routing for MANETS ; Please provide me the simulation code for Epidemic routing ,PROPET routing,= Spray and Wait routing algorithms..or one of these... =A0=20 =0A=0A=0A --0-1399831322-1255803087=:85577 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi ...

Can any one provide me info= rmation for efficient routing for MANETS ;
Please provide me the simulat= ion code for Epidemic routing ,PROPET routing,Spray and Wait routing algori= thms..or one of these...
 <= strong>

=0A=0A --0-1399831322-1255803087=:85577-- From root@core3.amsl.com Wed Oct 21 01:45:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9F4233A67E7; Wed, 21 Oct 2009 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091021084501.9F4233A67E7@core3.amsl.com> Date: Wed, 21 Oct 2009 01:45:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-nhdp-mib-01.txt 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, 21 Oct 2009 08:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the Neighborhood Discovery Protocol Author(s) : U. Herberg, et al. Filename : draft-ietf-manet-nhdp-mib-01.txt Pages : 68 Date : 2009-10-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-21013702.I-D@ietf.org> --NextPart-- From robert.cole@jhuapl.edu Sun Oct 25 12:43: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 D747C3A69AE for ; Sun, 25 Oct 2009 12:43:36 -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 4I-uDmeWNMFC for ; Sun, 25 Oct 2009 12:43:36 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id D99743A67BD for ; Sun, 25 Oct 2009 12:43:35 -0700 (PDT) Received: from ([128.244.198.90]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.31490073; Sun, 25 Oct 2009 15:43:45 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Sun, 25 Oct 2009 15:43:45 -0400 From: "Cole, Robert G." To: "manet@ietf.org" Date: Sun, 25 Oct 2009 15:43:44 -0400 Thread-Topic: New Version Notification for draft-cole-manet-report-mib-01 Thread-Index: AcpVqTqGWTa9WpX3TiqnjYqKsHmJOAAASLgm Message-ID: <0A8F66C42F49E448A40E99946404EE5B713E0A7101@aplesstar.dom1.jhuapl.edu> References: <20091025192728.BD6B828C14F@core3.amsl.com> In-Reply-To: <20091025192728.BD6B828C14F@core3.amsl.com> 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 Subject: [manet] FW: New Version Notification for draft-cole-manet-report-mib-01 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, 25 Oct 2009 19:43:36 -0000 To all: Just updated the Report-MIB. Some significant changes were made based up a= discovery of a related capability within the RMON2 usrHistory Group. Than= ks to Andy Bierman and Bert Wijnen for pointing this out. The usrHistory G= roup allows for the bulk collection of raw object values stored in 'buckets= ' with other values all associated with a same time sample point. These b= uckets are collected into reports which can then be retrieved in bulk from = the remote device. So now the Report-MIB has the ability to generate a) statistical reports an= d b) raw history reports. Compliance groups allow for implementations of e= ither or of both. Also cleaned up the MIB somewhat. Should be more clear in its capabilities= . Thanks, Bob ________________________________________ From: IETF I-D Submission Tool [idsubmission@ietf.org] Sent: Sunday, October 25, 2009 3:27 PM To: Cole, Robert G. Cc: macker@itd.nrl.navy.mil; amorton@att.com Subject: New Version Notification for draft-cole-manet-report-mib-01 A new version of I-D, draft-cole-manet-report-mib-01.txt has been successfu= ly submitted by Robert Cole and posted to the IETF repository. Filename: draft-cole-manet-report-mib Revision: 01 Title: Definition of Managed Objects for Performance Reporting Creation_date: 2009-10-25 WG ID: Independent Submission Number_of_pages: 54 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. The IETF Secretariat. From root@core3.amsl.com Sun Oct 25 12:45:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C2E0F3A69AE; Sun, 25 Oct 2009 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091025194501.C2E0F3A69AE@core3.amsl.com> Date: Sun, 25 Oct 2009 12:45:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-dymo-mib-03.txt 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, 25 Oct 2009 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the DYMO Manet Routing Protocol Author(s) : S. Harnedy, et al. Filename : draft-ietf-manet-dymo-mib-03.txt Pages : 38 Date : 2009-10-25 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the DYMO routing process. The DYMO-MIB also reports state information, performance information, and notifications. In addition to configuration, this additional state and performance information is useful to management operators troubleshooting DYMO routing problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-dymo-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-25123432.I-D@ietf.org> --NextPart-- From robert.cole@jhuapl.edu Sun Oct 25 12:48: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 39A583A69AE for ; Sun, 25 Oct 2009 12:48: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 TmvUBtYyioiC for ; Sun, 25 Oct 2009 12:48:44 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.26.33]) by core3.amsl.com (Postfix) with ESMTP id 1F1E03A6927 for ; Sun, 25 Oct 2009 12:48:43 -0700 (PDT) Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.31510501; Sun, 25 Oct 2009 15:48:46 -0400 Received: from aplesstar.dom1.jhuapl.edu ([128.244.198.212]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Sun, 25 Oct 2009 15:48:52 -0400 From: "Cole, Robert G." To: "manet@ietf.org" Date: Sun, 25 Oct 2009 15:44:01 -0400 Thread-Topic: New Version Notification for draft-ietf-manet-dymo-mib-03 Thread-Index: AcpVqjfQ4LRulGuHQmGsbgxQuehTMwAAUhpa Message-ID: <0A8F66C42F49E448A40E99946404EE5B713E0A7102@aplesstar.dom1.jhuapl.edu> References: <20091025193432.B648A3A69AE@core3.amsl.com> In-Reply-To: <20091025193432.B648A3A69AE@core3.amsl.com> 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 Subject: [manet] FW: New Version Notification for draft-ietf-manet-dymo-mib-03 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, 25 Oct 2009 19:48:45 -0000 To All: Sean, Ian and I have just updated the DYMO-MIB. I believe that this is get= ting close to completion, pending the completion of the DYMO draft. This n= ew updated version cleaned up some text and added DEFVAL clauses to read-wr= ite configuration objects. I think the only items left to finalize are: + Identify all objects requiring non-volatile storage, and + security section. =20 Thanks, Bob ________________________________________ From: IETF I-D Submission Tool [idsubmission@ietf.org] Sent: Sunday, October 25, 2009 3:34 PM To: Cole, Robert G. Cc: harnedy_sean@bah.com; ian.chakeres@gmail.com Subject: New Version Notification for draft-ietf-manet-dymo-mib-03 A new version of I-D, draft-ietf-manet-dymo-mib-03.txt has been successfuly= submitted by Robert Cole and posted to the IETF repository. Filename: draft-ietf-manet-dymo-mib Revision: 03 Title: Definition of Managed Objects for the DYMO Manet Routing P= rotocol Creation_date: 2009-10-25 WG ID: manet Number_of_pages: 38 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the DYMO routing process. The DYMO-MIB also reports state information, performance information, and notifications. In addition to configuration, this additional state and performance information is useful to management operators troubleshooting DYMO routing problems. The IETF Secretariat. From root@core3.amsl.com Mon Oct 26 06:30:02 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E043328C0F1; Mon, 26 Oct 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026133001.E043328C0F1@core3.amsl.com> Date: Mon, 26 Oct 2009 06:30:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-smf-mib-01.txt 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, 26 Oct 2009 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process Author(s) : R. Cole, et al. Filename : draft-ietf-manet-smf-mib-01.txt Pages : 46 Date : 2009-10-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to operators troubleshooting multicast forwarding problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-smf-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26061505.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 15:15:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D72E328C301; Mon, 26 Oct 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026221501.D72E328C301@core3.amsl.com> Date: Mon, 26 Oct 2009 15:15:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-nhdp-11.txt 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, 26 Oct 2009 22:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-nhdp-11.txt Pages : 84 Date : 2009-10-26 This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26150809.I-D@ietf.org> --NextPart-- From ulrich@herberg.name Mon Oct 26 16:32: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 5596228C429 for ; Mon, 26 Oct 2009 16:32:12 -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 SXJ1e6A95UVt for ; Mon, 26 Oct 2009 16:32:11 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 3123328C435 for ; Mon, 26 Oct 2009 16:32:11 -0700 (PDT) Received: by bwz19 with SMTP id 19so2612527bwz.28 for ; Mon, 26 Oct 2009 16:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.3.19 with SMTP id 19mr2480322bkl.151.1256599938996; Mon, 26 Oct 2009 16:32:18 -0700 (PDT) In-Reply-To: <20091026221501.D72E328C301@core3.amsl.com> References: <20091026221501.D72E328C301@core3.amsl.com> Date: Tue, 27 Oct 2009 00:32:18 +0100 Message-ID: <25c114b90910261632x55de6eeaya908491ba78bc2c1@mail.gmail.com> From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=0015174bf2aafd1ce40476def86c Subject: Re: [manet] I-D Action:draft-ietf-manet-nhdp-11.txt 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, 26 Oct 2009 23:32:12 -0000 --0015174bf2aafd1ce40476def86c Content-Type: text/plain; charset=ISO-8859-1 Thanks for updating the NHDP draft (but please, publish it before we need a three-digit version of the draft ;-) Is that even possible for IETF drafts? I like the updated security considerations as well as the examples in the appendix. I have one question about the Originator Address, which seems to be removed. Why? Couldn't this affect security when using digital signatures for signing HELLO messages? (ok, that were 2 questions ;-) How can I prove the identity of a node (in particular in the case that the HELLO messages do not contain the THIS_IF TLV value?) Ulrich On Mon, Oct 26, 2009 at 11:15 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > > Title : Mobile Ad Hoc Network (MANET) Neighborhood > Discovery Protocol (NHDP) > Author(s) : T. Clausen, et al. > Filename : draft-ietf-manet-nhdp-11.txt > Pages : 84 > Date : 2009-10-26 > > This document describes a 1-hop and symmetric 2-hop neighborhood > discovery protocol (NHDP) for mobile ad hoc networks (MANETs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --0015174bf2aafd1ce40476def86c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for updating the NHDP draft (but please, publish it before we need a= three-digit version of the draft ;-) Is that even possible for IETF drafts= ?

I like the updated security considerations as well as the examples= in the appendix. I have one question about the Originator Address, which s= eems to be removed. Why? Couldn't this affect security when using digit= al signatures for signing HELLO messages? (ok, that were 2 questions ;-) Ho= w can I prove the identity of a node (in particular in the case that the HE= LLO messages do not contain the THIS_IF TLV value?)

Ulrich

On Mon, Oct 26, 2009 at 11:15 = PM, <Inte= rnet-Drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of th= e IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Mobile Ad Hoc Network (MANET) N= eighborhood Discovery Protocol (NHDP)
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Clausen, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-manet-nhdp-11.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 84
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-10-26

This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nh= dp-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--0015174bf2aafd1ce40476def86c--