From sratliff@cisco.com Mon May 2 08:58:25 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCF0E06C3 for ; Mon, 2 May 2011 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZsbfPwXsnHw for ; Mon, 2 May 2011 08:58:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA2E06AD for ; Mon, 2 May 2011 08:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=824; q=dns/txt; s=iport; t=1304351903; x=1305561503; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date; bh=Uf7u+44rhgcGYUuweNcSykb0wc9QGb/WGqkevazZbK8=; b=gaY8hLjsTDSPdut330298i+mNicZKXvOUWMlhojivmeX3lAsZ55WaBaF QibDYDKdpDioFpTevHNMbcNGeqmWI5gdRErHJ5XKH3itOX9/k/bQppqdo Di8q8MXVAQ2GfvRCSDKT0gfx0sK9Ocgd9D5j4LuhN+fMFntBKisNjBG31 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKnTvk2tJV2c/2dsb2JhbACmHnejYIEdnAKGAASOeY4+ X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208";a="284163429" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 02 May 2011 15:58:23 +0000 Received: from dhcp-64-102-194-200.cisco.com (dhcp-64-102-194-200.cisco.com [64.102.194.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p42FwNHJ005311 for ; Mon, 2 May 2011 15:58:23 GMT Message-Id: <152AD12F-9868-4202-B7B8-2604B692A445@cisco.com> From: Stan Ratliff To: MANET IETF Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 May 2011 11:58:29 -0400 X-Mailer: Apple Mail (2.936) Subject: [manet] DLEP Version 01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:58:25 -0000 All, I have just posted an 01 version of the DLEP draft. First off, my apologies for this taking longer than I thought. The pressures of work... ;-) A synopsis of the version 01 DLEP changes: 1. We've gotten rid of the requirement for a 5444 packet TLV; everything is now placed into 5444 Message TLVs. 2. We've tried to clarify that DLEP messages exist as an "order" (e.g. NEIGHBOR_UP), and a collection of Sub-TLVs that convey information about the order. 3. There is now only 1 allocation required from the 5444 message TLV: DLEP_MESSAGE. Other DLEP orders and sub-TLVs exist in their own registries. 3. We have added some timer sub-TLVs; this was in response to comments by Tom Henderson in Prague concerning different setup times for different modem devices. Regards, Stan From Chris.Dearlove@baesystems.com Tue May 3 01:28:27 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96353E06F9 for ; Tue, 3 May 2011 01:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULFzJ2rZ5pN0 for ; Tue, 3 May 2011 01:28:26 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5818CE06F4 for ; Tue, 3 May 2011 01:28:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,308,1301871600"; d="scan'208";a="131170382" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 May 2011 09:28:19 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id p438SIr3031470; Tue, 3 May 2011 09:28:19 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 09:28:18 +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: Tue, 3 May 2011 09:28:16 +0100 Message-ID: In-reply-to: <7A7D1783-E567-4970-965C-ED138BD4EF79@herberg.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] WG adoption of NHDP-sec Thread-Index: AcwBohHD0Y9BbPMiRym13y0oA3rbsgHyaoDA References: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> <7A7D1783-E567-4970-965C-ED138BD4EF79@herberg.name> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" X-OriginalArrivalTime: 03 May 2011 08:28:18.0765 (UTC) FILETIME=[0E4877D0:01CC096C] Cc: Ulrich Herberg , MANET IETF , Thomas Heide Clausen Subject: Re: [manet] WG adoption of NHDP-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 08:28:27 -0000 Apologies for that, I put this together in a hurry just before leaving for a long week off, and these are, as Ulrich deduced, about packetbb-sec. I didn't get to NHDP-sec in time, though I still plan to take a look at it. --=20 Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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: Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: 23 April 2011 11:35 To: Dearlove, Christopher (UK) Cc: Joe Macker; MANET IETF; Thomas Heide Clausen; Ulrich Herberg Subject: Re: [manet] WG adoption of NHDP-sec *** 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. =20 Chris, before I will reply to your comments, I have a general question: Do your comments apply to packetbb-sec or to NHDP-sec? It seems to me they apply to packetbb-sec, rather than NHDP-sec... Ulrich On Apr 21, 2011, at 17:17, "Dearlove, Christopher (UK)" wrote: > Brief version: I think there's a two part change that should > be included before finishing WGLC. >=20 > My apologies in advance in that should this spark a discussion, > I'll be out of the loop for a week and a half and no able to > contribute. (The UK is largely shutting down, we have for a > combination of rare reasons, two four day weekends, with a > three day gap. Many of us are taking those three days off too.) >=20 > My main concern over this document is that it specifies a > signature as the composition of a hash function and a > cryptographic function, in that order. There are other ways > of constructing signatures that do not correspond to such > a decomposition. >=20 > The obvious response to that is to pick a new type extension > for such. This can't be normative text in this document, but > I think it should be described in the applicability statement, > which should say that this specification describes a general > approach to signatures (much of the document, such as how to > traety hop counts/limits is not specific to this decomposition) > and then a specific approach to signatures, and should provide > the comment that other mathematical forms of signature are > possible, and should be handled by use of alternative type > extensions. In the main body of the specification, a bit more > clarity on what is form-specific and what is not would then > help. >=20 > This then leads to the question a to whether the form described > should be the privileged type extension =3D 0 case. Actually I > would suggest it should be type extension =3D 1, with 0 reserved > for "I'm not providing any information on algorithms, this is > defined out of band, not in each packet. The reason I suggest > that as type 0 (and including it in this document) is that it > puts the two lowest-overhead options together (type extension 0, > which can be omitted, and no algorithm information). >=20 > Note that for timestamp, what other type extensions may be is > alraedy covered, but not so for signatures, and timestamp uses > the type extension 0 for the analogous case I suggest for type > extension 0 for signature, i.e. detertmined otherwise (should > the phrase "administrative action" be used in both cases?) >=20 > I think there should be another iteration before going to > SECDIR and IESG, as I think it will avoid work further down the > line, as well as being a better specification this way. >=20 > --=20 > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +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 Joe Macker > Sent: 07 April 2011 17:17 > To: MANET IETF > Subject: [manet] WG adoption of NHDP-sec >=20 >=20 > *** WARNING *** >=20 > 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. >=20 >=20 > As discussed in Prague we are presently considering adoption of NHDP > security related document as a WG document. >=20 > reference is draft-herberg-manet-nhdp-sec-01 >=20 > Please comment if you have an opinion. >=20 > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=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 From ietf-secretariat-reply@ietf.org Wed May 4 08:21:01 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDEDE0750 for ; Wed, 4 May 2011 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ0HEG6bY-MA for ; Wed, 4 May 2011 08:21:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3ECE06B6 for ; Wed, 4 May 2011 08:21:01 -0700 (PDT) Received: from mail.ietf.org ([2001:1890:1112:1::1e]) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QHdso-0008Tt-CR; Wed, 04 May 2011 08:20:59 -0700 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5A2E0794; Wed, 4 May 2011 08:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-wg3uw6XpEk; Wed, 4 May 2011 08:20:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C542E06B6; Wed, 4 May 2011 08:20:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: manet-chairs@tools.ietf.org, draft-ietf-manet-smf@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110504152057.750.80520.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 08:20:57 -0700 From: IETF Secretariat X-SA-Exim-Connect-IP: 2001:1890:1112:1::1e X-SA-Exim-Rcpt-To: draft-ietf-manet-smf@tools.ietf.org, manet-chairs@tools.ietf.org X-SA-Exim-Mail-From: ietf-secretariat-reply@ietf.org X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Mailman-Approved-At: Wed, 04 May 2011 08:26:18 -0700 Subject: [manet] ID Tracker State Update Notice: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:21:01 -0000 State changed to AD is watching::Revised ID Needed from AD Evaluation::AD F= ollowup.A number of comments were raised in the the WG after publication wa= s requested. I am therefore moving the document back to the WG for those co= mments to be addressed. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-manet-smf/ From Internet-Drafts@ietf.org Fri May 6 09:00:02 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47A6E06EA; Fri, 6 May 2011 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8tor0RSh8Qv; Fri, 6 May 2011 09:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A794FE070E; Fri, 6 May 2011 09:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506160001.16952.11802.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 09:00:01 -0700 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-dlep-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 16:00: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 : Dynamic Link Exchange Protocol (DLEP) Author(s) : S. Ratliff, et al Filename : draft-ietf-manet-dlep-01.txt Pages : 54 Date : 2011-05-02 When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dlep-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-dlep-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06085102.I-D@ietf.org> --NextPart-- From himai@adm.niigata-u.ac.jp Sun May 8 15:36:29 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA37E0799 for ; Sun, 8 May 2011 15:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.836 X-Spam-Level: *** X-Spam-Status: No, score=3.836 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcr8MuNtS5Ub for ; Sun, 8 May 2011 15:36:29 -0700 (PDT) Received: from mxav03.cc.niigata-u.ac.jp (mxav03.cc.niigata-u.ac.jp [133.35.17.131]) by ietfa.amsl.com (Postfix) with ESMTP id 71F2EE078F for ; Sun, 8 May 2011 15:36:27 -0700 (PDT) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 126472901CF for ; Mon, 9 May 2011 07:36:24 +0900 (JST) Received: from ccmail03.cc.niigata-u.ac.jp (ccmail03.cc.niigata-u.ac.jp [133.35.20.11]) by mxav03.cc.niigata-u.ac.jp (Postfix) with ESMTP id 085142901B3 for ; Mon, 9 May 2011 07:36:24 +0900 (JST) Received: from 133.35.75.72 (133.35.75.72 [133.35.75.72]) by ccmail03.cc.niigata-u.ac.jp (deepsmtpd.st 3.5.66) with ESMTP id <08BA1F1E-2161-4A71-A7EB-99D289F424AF@adm.niigata-u.ac.jp> for ; Mon, 9 May 2011 07:36:21 +0900 From: IMAI Hiroei Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 May 2011 07:36:21 +0900 To: MANET IETF Message-Id: <08BA1F1E-2161-4A71-A7EB-99D289F424AF@adm.niigata-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-FROM-DOMAIN: adm.niigata-u.ac.jp X-FROM-EMAIL: himai@adm.niigata-u.ac.jp Subject: [manet] nuOLSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 22:36:29 -0000 Dear all, We released nuOLSRv2 which is an implementation of OLSRv2. nuOLSRv2 can be built not only as a routing program, but also as a module for QualNet. It supports following RFCs and internet drafts. - rfc5444 - draft-ietf-manet-nhdp-14 - draft-ietf-manet-olsrv2-11 - draft-dearlove-olsrv2-metrics-05 - draft-funkfeuer-manet-olsrv2-etx-01 More information can be found at: http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ -- Hiroei IMAI Niigata University From henning.rogge@fkie.fraunhofer.de Wed May 11 01:46:51 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5B7E06BA for ; Wed, 11 May 2011 01:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.256 X-Spam-Level: * X-Spam-Status: No, score=1.256 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpfSZPSy58Nk for ; Wed, 11 May 2011 01:46:51 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A7148E06B4 for ; Wed, 11 May 2011 01:46:50 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QK549-0003ZS-16; Wed, 11 May 2011 10:46:45 +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.76) (envelope-from ) id 1QK548-00060E-Oy; Wed, 11 May 2011 10:46:44 +0200 From: Henning Rogge To: manet@ietf.org Date: Wed, 11 May 2011 10:46:35 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: <08BA1F1E-2161-4A71-A7EB-99D289F424AF@adm.niigata-u.ac.jp> In-Reply-To: <08BA1F1E-2161-4A71-A7EB-99D289F424AF@adm.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3538931.V8aQBbC8hP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105111046.41595.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.97/13070/Wed May 11 09:18:49 2011) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9bea0208ff5bf14e461e230ff4736cfe Subject: Re: [manet] nuOLSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 08:46:51 -0000 --nextPart3538931.V8aQBbC8hP Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon May 9 2011 00:36:21 IMAI Hiroei wrote: > Dear all, >=20 > We released nuOLSRv2 which is an implementation of OLSRv2. > nuOLSRv2 can be built not only as a routing program, but also as a > module for QualNet. > It supports following RFCs and internet drafts. >=20 > - rfc5444 > - draft-ietf-manet-nhdp-14 > - draft-ietf-manet-olsrv2-11 > - draft-dearlove-olsrv2-metrics-05 > - draft-funkfeuer-manet-olsrv2-etx-01 >=20 > More information can be found at: > http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ Great news... :) Did you had problems implementing the "funkfeuer etx" draft? 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-961, 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 --nextPart3538931.V8aQBbC8hP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3KTOwACgkQRIfGfFXsz+BjUACcCDFw1CoNP/4VBu2CqYZDRWfs O+kAoJDMSVAPoCojfcmHgoMKmtHr+ZjU =5bn0 -----END PGP SIGNATURE----- --nextPart3538931.V8aQBbC8hP-- From Chris.Dearlove@baesystems.com Wed May 11 01:48:30 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D809E0756 for ; Wed, 11 May 2011 01:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAgVqwtcdnFR for ; Wed, 11 May 2011 01:48:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2C809E06EC for ; Wed, 11 May 2011 01:48:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,351,1301871600"; d="scan'208";a="132977192" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 11 May 2011 09:48:27 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4B8mR28017535; Wed, 11 May 2011 09:48:27 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 09:48: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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 09:48:21 +0100 Message-ID: In-Reply-To: <201105111046.41595.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] nuOLSRv2 Thread-Index: AcwPt/8jewpoyhFSTy6R30uWzuYXEgAACBGw References: <08BA1F1E-2161-4A71-A7EB-99D289F424AF@adm.niigata-u.ac.jp> <201105111046.41595.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 11 May 2011 08:48:27.0183 (UTC) FILETIME=[31DC6BF0:01CC0FB8] Subject: Re: [manet] nuOLSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 08:48:30 -0000 Similar question for the metrics draft. --=20 Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability 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 H= enning Rogge Sent: 11 May 2011 09:47 To: manet@ietf.org Subject: Re: [manet] nuOLSRv2 On Mon May 9 2011 00:36:21 IMAI Hiroei wrote: > Dear all, >=20 > We released nuOLSRv2 which is an implementation of OLSRv2. > nuOLSRv2 can be built not only as a routing program, but also as a > module for QualNet. > It supports following RFCs and internet drafts. >=20 > - rfc5444 > - draft-ietf-manet-nhdp-14 > - draft-ietf-manet-olsrv2-11 > - draft-dearlove-olsrv2-metrics-05 > - draft-funkfeuer-manet-olsrv2-etx-01 >=20 > More information can be found at: > http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ Great news... :) Did you had problems implementing the "funkfeuer etx" draft? Henning Rogge --=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-961, 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 ******************************************************************** 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 Wed May 11 02:13:42 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB106E0778 for ; Wed, 11 May 2011 02:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2jvnxdvh2Pa for ; Wed, 11 May 2011 02:13:42 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A70C7E06BA for ; Wed, 11 May 2011 02:13:41 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QK5UC-0003ma-L5 for manet@ietf.org; Wed, 11 May 2011 11:13:40 +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.76) (envelope-from ) id 1QK5UC-0006HI-C2 for manet@ietf.org; Wed, 11 May 2011 11:13:40 +0200 From: Henning Rogge To: manet@ietf.org Date: Wed, 11 May 2011 11:13:28 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5417439.tguqnkns6i"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.97/13070/Wed May 11 09:18:49 2011) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 35a9245e44023dcaab5ff35535b53a1e Subject: [manet] Discussion about details of OLSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 09:13:43 -0000 --nextPart5417439.tguqnkns6i Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, since the new olsrv2 draft seems to be coming later, I would like to open a= =20 discussion about some (in my opinion) important points of the current OLSRv= 2=20 and Linkmetric drafts.=20 I would like to start with the link metric encoding. There are some other=20 important points, but we have to start somewhere. Link metric encoding =2D------------------- 1) encoding range The current metric draft does include the idea to allow metric path=20 calculation in 32 bit integer, which will limit the range of a link metric = to=20 0 - 2^24-1. I support this idea, there are a lot of embedded devices out th= ere=20 without floating point circuits and 64 bits. But the compressed metric tlv suggested in the draft does limit the link=20 metric value to 16 - 1015808, which reduce the available range to roughly 1= to=20 2^16. I think this is a bad idea, the metric encoding should use as much range as= =20 possible within the 24 bit. In additon to this it might be worthwile to add an uncompressed metric=20 encoding (just a 3 byte integer), either by using the length field of the=20 metric TLV to change between the two formats or use a different TLV. An uncompressed metric value would be a great tool to work on new metrics i= n=20 realworld networks without the influence of the compression function, which= =20 simplifies debugging the behaviour of metrics. 2) link metric value 0 I would like to hear the opinions of the working group about an encoding fo= r=20 link metric 0. Its a common use case in protocols with multiplicative metri= cs=20 to have a metric value of 1, the inclusion of 0 into our metric range would= =20 allow a similar feature in OLSRv2. To get a stable dijkstra result most of our existing implementations should= =20 already use a tie-breaker to choose between equal path costs in a stable wa= y,=20 so a link cost of 0 should not add to the complexity of our implementations. 3) link metric default value The link metric draft suggests to set the default metric value directly in = the=20 middle (logarithmic) of the metric range. In my opinion this even further restricts the useful metric values. The=20 default link cost corresponds with the hopcount metric, which does not=20 calculate metric values at all. In practice I see a lot of reasons why I have links better than a hopcount= =20 link and very few for links that have a higher cost. If normal link metrics= =20 and hopcount metric should be able to work together, it would be better to= =20 place the default link metric value in the upper range of the metric. My suggestion would be to use MAXIMUM_METRIC/16. 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-961, 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 --nextPart5417439.tguqnkns6i Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3KUzkACgkQRIfGfFXsz+DahQCfb1L9G09pwFuzbin85uPhhDa1 8HQAnRLsfNTi85TLOMYv30hBPFVepA/5 =lUmz -----END PGP SIGNATURE----- --nextPart5417439.tguqnkns6i-- From georg.wittenburg@inria.fr Wed May 11 07:11:24 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3F2E072A for ; Wed, 11 May 2011 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.835 X-Spam-Level: X-Spam-Status: No, score=-7.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUuFsVZ9DqP8 for ; Wed, 11 May 2011 07:11:23 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6F6E0758 for ; Wed, 11 May 2011 07:11:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,353,1301868000"; d="scan'208";a="82951077" Received: from sphinx.lix.polytechnique.fr (HELO marlin.localnet) ([129.104.11.1]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2011 16:11:01 +0200 From: Georg Wittenburg Organization: INRIA To: manet@ietf.org Date: Wed, 11 May 2011 16:10:58 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.38-2-686; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201105111610.58611.georg.wittenburg@inria.fr> Subject: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 14:11:24 -0000 Dear authors, all, after carefully reading draft-funkfeuer-manet-olsrv2-etx-01, here are some= =20 comments that I would like to share with the community. Regarding the current text: =2D Naming conventions: In Sec. 4, ETX is defined as (R_etx * D_etx) where = R_etx=20 and D_etx are the loss rates over the link. I feel that R_etx and D_etx are= =20 badly labeled since these names do not adequately reflect the meaning of th= ese=20 variables. Furthermore, in the original ETX paper "A High-Throughput Path=20 Metric for Multi-Hop Wireless Routing" by De Couto et al. in MobiCom '03, E= TX=20 is defined as (1 / (d_f * d_r)) where d_f and d_r are the forward and rever= se=20 delivery ratios respectively. Given the long time that this paper has been= =20 around, it may well make sense to stick to the established formalism and=20 naming scheme. =2D Size of HELLO messages: Sec. 8.1 states that HELLO messages should be=20 generated as specified in draft-ietf-manet-olsrv2 which in turn refers to R= =46C=20 6130. In the absence of other traffic, the delivery ratios of these HELLO=20 messages will be the only input to the ETX metric. The problem is that pack= et=20 delivery ratios differ depending on the size of the transmitted packet. If= =20 small packets are used to estimate link quality, this estimate will be flaw= ed=20 if the link is used for large packets later on, i.e, packets that make full= =20 use of the MTU. A workaround would be to require that if HELLO packets are = to=20 be used for link quality estimation then they must be padded to correspond = in=20 size to the average data packet, or MTU. =2D Order of processing: Secs. 8.2 and 8.3 independently state that link me= tric=20 processing is carried out *after* OLSR-related processing. In my (unrelated= )=20 experiments I found it beneficial to *first* update the link metrics and th= en=20 continue with layer 3 packet processing. The rationale is simply that routi= ng=20 decisions should be based on the most up-to-date information. Hence, I sugg= est=20 to rephrase Secs. 8.2 and 8.3 to first update the data structures related t= o=20 link metric processing, and only afterwards hand off packets to be processe= d by=20 OLSR. Similarly, periodic metric computation has the drawbacks of a) induci= ng=20 delays before the updated metrics are available to other components, and b)= =20 the computational load of having to recalculate all links at the same time.= =20 Wouldn't it be beneficial to trigger per-link recomputations based on link- related events (number of transmitted packets, sudden changes in the loss=20 ratios) and merely use periodic timers as fallbacks? Regarding possible additions: =2D Convergence time: Has it been considered to add weights to the list of= =20 measured loss ratios in order to optimize the convergence time after major= =20 changes to a link? =2D Useless links: Has it been considered to have an upper bound on the ETX= =20 value above which links are considered as being too bad to be useful? =2D Modulation issues: How does this metric deal with packets that are send= at=20 different transmission rates using different encodings? For instance, if a = link=20 is measured using broadcast packets, then the metric may well be flawed for= =20 high-speed streams of unicast packets. I hope these comments are helpful. Best regards, Georg =2D-=20 Dr. Georg Wittenburg Postdoctoral Researcher INRIA / =C9cole Polytechnique, HIPERCOM Team Laboratoire d'Informatique de l'=C9cole Polytechnique (LIX) Route de Saclay, 91128 Palaiseau (CEDEX) Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044 http://www.lix.polytechnique.fr/~wittenburg/ From himai@adm.niigata-u.ac.jp Wed May 11 18:06:58 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFFDE08EE for ; Wed, 11 May 2011 18:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.977 X-Spam-Level: * X-Spam-Status: No, score=1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcg8MoysNSSE for ; Wed, 11 May 2011 18:06:57 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (mxav02.cc.niigata-u.ac.jp [133.35.17.130]) by ietfa.amsl.com (Postfix) with ESMTP id 41C00E08E8 for ; Wed, 11 May 2011 18:06:56 -0700 (PDT) Received: from mxav02.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BD8A4541FC for ; Thu, 12 May 2011 10:06:53 +0900 (JST) Received: from ccmail03.cc.niigata-u.ac.jp (ccmail03.cc.niigata-u.ac.jp [133.35.20.11]) by mxav02.cc.niigata-u.ac.jp (Postfix) with ESMTP id 201F74540A4 for ; Thu, 12 May 2011 10:06:53 +0900 (JST) Received: from 133.35.75.72 (133.35.75.72 [133.35.75.72]) by ccmail03.cc.niigata-u.ac.jp (deepsmtpd.st 3.5.66) with ESMTP id <20110512.100642.1011197826337709781.himai@adm.niigata-u.ac.jp> for ; Thu, 12 May 2011 10:06:43 +0900 Date: Thu, 12 May 2011 10:06:42 +0900 (JST) Message-Id: <20110512.100642.1011197826337709781.himai@adm.niigata-u.ac.jp> To: Chris.Dearlove@baesystems.com From: IMAI Hiroei In-Reply-To: References: <08BA1F1E-2161-4A71-A7EB-99D289F424AF@adm.niigata-u.ac.jp> <201105111046.41595.henning.rogge@fkie.fraunhofer.de> X-Mailer: Mew version 6.3.50 on Emacs 23.3.50 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-FROM-DOMAIN: adm.niigata-u.ac.jp X-FROM-EMAIL: himai@adm.niigata-u.ac.jp Cc: manet@ietf.org Subject: Re: [manet] nuOLSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 01:06:59 -0000 In point of implementation, there were not problems as far as I remember. I implemented the processing of the link metric and etx as it is written in drafts. -- Hiroei IMAI On Wed, 11 May 2011 09:48:21 +0100, "Dearlove, Christopher (UK)" wrote: > Similar question for the metrics draft. >=20 > --=20 > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +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 Behal= f Of Henning Rogge > Sent: 11 May 2011 09:47 > To: manet@ietf.org > Subject: Re: [manet] nuOLSRv2 >=20 > On Mon May 9 2011 00:36:21 IMAI Hiroei wrote: > > Dear all, > >=20 > > We released nuOLSRv2 which is an implementation of OLSRv2. > > nuOLSRv2 can be built not only as a routing program, but also as a > > module for QualNet. > > It supports following RFCs and internet drafts. > >=20 > > - rfc5444 > > - draft-ietf-manet-nhdp-14 > > - draft-ietf-manet-olsrv2-11 > > - draft-dearlove-olsrv2-metrics-05 > > - draft-funkfeuer-manet-olsrv2-etx-01 > >=20 > > More information can be found at: > > http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ > Great news... :) >=20 > Did you had problems implementing the "funkfeuer etx" draft? >=20 > Henning Rogge > --=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-961, 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 >=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 From henning.rogge@fkie.fraunhofer.de Wed May 11 23:07:13 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAC0E06AD for ; Wed, 11 May 2011 23:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukKFdmOD1J1P for ; Wed, 11 May 2011 23:07:12 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 14CDDE06B9 for ; Wed, 11 May 2011 23:07:12 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QKP3F-0006nL-4X; Thu, 12 May 2011 08:07:09 +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.76) (envelope-from ) id 1QKP3E-0002XB-Qr; Thu, 12 May 2011 08:07:08 +0200 From: Henning Rogge To: manet@ietf.org Date: Wed, 11 May 2011 16:55:52 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> In-Reply-To: <201105111610.58611.georg.wittenburg@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1548474.QzadJJeUAd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105111655.52906.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.97/13072/Wed May 11 22:11:38 2011) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 5e3775bd051bdf3cff063c8e6fb5b700 Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 06:07:13 -0000 --nextPart1548474.QzadJJeUAd Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed May 11 2011 16:10:58 Georg Wittenburg wrote: > Dear authors, all, >=20 > after carefully reading draft-funkfeuer-manet-olsrv2-etx-01, here are some > comments that I would like to share with the community. At first, thank you for the feedback on the draft... > Regarding the current text: >=20 > - Naming conventions: In Sec. 4, ETX is defined as (R_etx * D_etx) where > R_etx and D_etx are the loss rates over the link. I feel that R_etx and > D_etx are badly labeled since these names do not adequately reflect the > meaning of these variables. Furthermore, in the original ETX paper "A > High-Throughput Path Metric for Multi-Hop Wireless Routing" by De Couto et > al. in MobiCom '03, ETX is defined as (1 / (d_f * d_r)) where d_f and d_r > are the forward and reverse delivery ratios respectively. Given the long > time that this paper has been around, it may well make sense to stick to > the established formalism and naming scheme. I see no problem renaming both variables to stay consistent with another=20 naming scheme. =20 > - Size of HELLO messages: Sec. 8.1 states that HELLO messages should be > generated as specified in draft-ietf-manet-olsrv2 which in turn refers to > RFC 6130. In the absence of other traffic, the delivery ratios of these > HELLO messages will be the only input to the ETX metric. That is not right... there will be more TC messages in the network (especia= lly=20 in larger networks) than Hellos, so they will contribute to the size of the= =20 packets too. > The problem is > that packet delivery ratios differ depending on the size of the > transmitted packet. If small packets are used to estimate link quality, > this estimate will be flawed if the link is used for large packets later > on, i.e, packets that make full use of the MTU. A workaround would be to > require that if HELLO packets are to be used for link quality estimation > then they must be padded to correspond in size to the average data packet, > or MTU. The funkfeuer metric drafts suggests to use all RFC 5444 packets for link l= oss=20 estimation, not only a certain message type. Your suggestion would make it= =20 necessary to pad all RFC5444 packets to the maximum MTU, which might be a=20 considerable overhead. =20 > - Order of processing: Secs. 8.2 and 8.3 independently state that link > metric processing is carried out *after* OLSR-related processing. In my > (unrelated) experiments I found it beneficial to *first* update the link > metrics and then continue with layer 3 packet processing. The rationale is > simply that routing decisions should be based on the most up-to-date > information. Routing decissions are done for unicast traffic, which is independent from = the=20 OLSR/NHDP processing. Even if the metric processing is done after the packe= t=20 processing, it could still be done before a potential dijkstra calculation,= =20 which would update the routing table. > Hence, I suggest to rephrase Secs. 8.2 and 8.3 to first > update the data structures related to link metric processing, and only > afterwards hand off packets to be processed by OLSR. Incoming packets don't trigger direct metric updates, so the order of both= =20 operations don't matter that much for the FUnkfeuer ETX metric. > Similarly, periodic > metric computation has the drawbacks of a) inducing delays before the > updated metrics are available to other components, and b) the > computational load of having to recalculate all links at the same time. > Wouldn't it be beneficial to trigger per-link recomputations based on > link- related events (number of transmitted packets, sudden changes in the > loss ratios) and merely use periodic timers as fallbacks? We use the timer approach to implement a sliding window, which always conta= ins=20 the total reception/loss for the last few seconds (ETX_MEMORY_LENGTH). I am not sure this can be done easily without the timer approach. > Regarding possible additions: >=20 > - Convergence time: Has it been considered to add weights to the list of > measured loss ratios in order to optimize the convergence time after major > changes to a link? Yes, but this metric has been mostly used in non-moving mesh networks where= =20 weights would only add computational overhead. It might be a tuning parameter for moving networks, but I am not able to gu= ess=20 a good value for the weight distribution. =20 > - Useless links: Has it been considered to have an upper bound on the ETX > value above which links are considered as being too bad to be useful? We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this would b= e=20 the job of the link hysteresis (which easily could be implemented based on = the=20 link cost value). > - Modulation issues: How does this metric deal with packets that are send > at different transmission rates using different encodings? For instance, > if a link is measured using broadcast packets, then the metric may well be > flawed for high-speed streams of unicast packets. ETX metrics do not consider link speed, so our metric would not encode this= =20 difference into the link cost. > I hope these comments are helpful. Yes, they are. :) 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-961, 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 --nextPart1548474.QzadJJeUAd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3Ko3gACgkQRIfGfFXsz+Ck5gCfXIEH4RjBOt0imULQxgThN1d6 C6gAn0JXBSmJIyNh7zRBJDx1XnlRB9+f =p1M1 -----END PGP SIGNATURE----- --nextPart1548474.QzadJJeUAd-- From georg.wittenburg@inria.fr Fri May 13 07:23:24 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8512E0675 for ; Fri, 13 May 2011 07:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RudSNEDkZrW1 for ; Fri, 13 May 2011 07:23:24 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id B14B4E065A for ; Fri, 13 May 2011 07:23:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,364,1301868000"; d="scan'208";a="98984554" Received: from 212-198-208-196.rev.numericable.fr (HELO vaio.localnet) ([212.198.208.196]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2011 16:23:21 +0200 From: Georg Wittenburg Organization: INRIA To: Henning Rogge Date: Fri, 13 May 2011 16:23:19 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> In-Reply-To: <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201105131623.20102.georg.wittenburg@inria.fr> Cc: manet@ietf.org Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 14:23:24 -0000 Dear Henning, all, On Thursday 12 May 2011 08:07:31 Henning Rogge wrote: > On Wed May 11 2011 16:10:58 Georg Wittenburg wrote: > [...] > > - Size of HELLO messages: Sec. 8.1 states that HELLO messages should be > > generated as specified in draft-ietf-manet-olsrv2 which in turn refers = to > > RFC 6130. In the absence of other traffic, the delivery ratios of these > > HELLO messages will be the only input to the ETX metric. >=20 > That is not right... there will be more TC messages in the network > (especially in larger networks) than Hellos, so they will contribute to > the size of the packets too. OK. But the point below still remains, doesn't it? > > The problem is > > that packet delivery ratios differ depending on the size of the > > transmitted packet. If small packets are used to estimate link quality, > > this estimate will be flawed if the link is used for large packets later > > on, i.e, packets that make full use of the MTU. A workaround would be to > > require that if HELLO packets are to be used for link quality estimation > > then they must be padded to correspond in size to the average data > > packet, or MTU. >=20 > The funkfeuer metric drafts suggests to use all RFC 5444 packets for link > loss estimation, not only a certain message type. Your suggestion would > make it necessary to pad all RFC5444 packets to the maximum MTU, which > might be a considerable overhead. I agree. However, it still remains true that link loss estimation that reli= es=20 excessively on small packets will lead to suboptimal results. I'm aware tha= t=20 the original ETX paper doesn't cover this, but it doesn't mean that it=20 shouldn't be addressed in this draft. How about, for example, only incrementing the respective counters for packe= ts=20 whose size is above a certain threshold, say MTU / 2 (or even MTU / 4)? > [...] > > Regarding possible additions: > >=20 > > - Convergence time: Has it been considered to add weights to the list of > > measured loss ratios in order to optimize the convergence time after > > major changes to a link? >=20 > Yes, but this metric has been mostly used in non-moving mesh networks whe= re > weights would only add computational overhead. >=20 > It might be a tuning parameter for moving networks, but I am not able to > guess a good value for the weight distribution. Neither am I. :) In this case, I just suggest that the wording in this draf= t=20 is chosen in such a way, that amendments regarding highly volatile or movin= g=20 networks can be made easily later on through a second complementary draft. > > - Useless links: Has it been considered to have an upper bound on the E= TX > > value above which links are considered as being too bad to be useful? >=20 > We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this would > be the job of the link hysteresis (which easily could be implemented based > on the link cost value). But since the link cost value depends on the metric used, it would be up to= =20 this draft to suggest values for this, wouldn't it? > > - Modulation issues: How does this metric deal with packets that are se= nd > > at different transmission rates using different encodings? For instance, > > if a link is measured using broadcast packets, then the metric may well > > be flawed for high-speed streams of unicast packets. >=20 > ETX metrics do not consider link speed, so our metric would not encode th= is > difference into the link cost. Yes, link speed, just as packet size, is not covered by the original ETX=20 proposal. I'm aware that properly considering link speed greatly increases = the=20 complexity of the problem. The best workaround that I see is to be relative= ly=20 conservative in what is considered a useful link (see above). Best, Georg =2D-=20 Dr. Georg Wittenburg Postdoctoral Researcher INRIA / =C9cole Polytechnique, HIPERCOM Team Laboratoire d'Informatique de l'=C9cole Polytechnique (LIX) Route de Saclay, 91128 Palaiseau (CEDEX) Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044 http://www.lix.polytechnique.fr/~wittenburg/ From emmanuel.baccelli@gmail.com Fri May 13 08:28:09 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D57E075E for ; Fri, 13 May 2011 08:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIp8azpig0A3 for ; Fri, 13 May 2011 08:28:08 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2339EE069B for ; Fri, 13 May 2011 08:28:07 -0700 (PDT) Received: by fxm15 with SMTP id 15so2138522fxm.31 for ; Fri, 13 May 2011 08:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=V43WZPyYqHCOKz3dotPKMfwIQGOuIH2Pc39r2t/S5zE=; b=ZFGN94DIurrHcCCfb5/ju2fq22jhHpROYjMAXz8/wc60RSrUovylpYBio8s5PE4Uz0 eJqrUajGuEm4litvs0jHBXV3MV+41itt2oWFij1lMgk2sxEh+xNV1vRtxfX6+nmzGP+V 55kneULynaQJwvGy1gRfwc76kn6DvACOAgTZY= 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=J4RfTGdX9+HK/N8F8E50gJ/9eCSWgdQTa4VmAU/6fbDyrvBcWh8SZPkN3lrTWdQIbA Wq4hgaPjsv0R6lWDzJLXC4Rgfelr0AUeegKy2qGn99OZwR5IU7sFYyTLlJHI3HaIA4A1 MyFRhtDcqETBeXz3j77OvUqbfu0fIhWQ4o9v0= Received: by 10.223.161.194 with SMTP id s2mr1838232fax.143.1305300487139; Fri, 13 May 2011 08:28:07 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.223.109.11 with HTTP; Fri, 13 May 2011 08:27:47 -0700 (PDT) In-Reply-To: <1098523091.2146189.1305296655318.JavaMail.root@zmbs1.inria.fr> References: <201105111610.58611.georg.wittenburg@inria.fr> <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> <1098523091.2146189.1305296655318.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Fri, 13 May 2011 17:27:47 +0200 X-Google-Sender-Auth: O3UvgR8-4rMiW-iOQVjYUx9woJo Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=002354530978dc72fd04a329f337 Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 15:28:09 -0000 --002354530978dc72fd04a329f337 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Georg, On Fri, May 13, 2011 at 4:24 PM, Georg Wittenburg wrote: > Dear Henning, all, > > On Thursday 12 May 2011 08:07:31 Henning Rogge wrote: > > On Wed May 11 2011 16:10:58 Georg Wittenburg wrote: > > [...] > > > - Size of HELLO messages: Sec. 8.1 states that HELLO messages should = be > > > generated as specified in draft-ietf-manet-olsrv2 which in turn refer= s > to > > > RFC 6130. In the absence of other traffic, the delivery ratios of the= se > > > HELLO messages will be the only input to the ETX metric. > > > > That is not right... there will be more TC messages in the network > > (especially in larger networks) than Hellos, so they will contribute to > > the size of the packets too. > > OK. But the point below still remains, doesn't it? > > > > > The problem is > > > that packet delivery ratios differ depending on the size of the > > > transmitted packet. If small packets are used to estimate link qualit= y, > > > this estimate will be flawed if the link is used for large packets > later > > > on, i.e, packets that make full use of the MTU. A workaround would be > to > > > require that if HELLO packets are to be used for link quality > estimation > > > then they must be padded to correspond in size to the average data > > > packet, or MTU. > > > > The funkfeuer metric drafts suggests to use all RFC 5444 packets for li= nk > > loss estimation, not only a certain message type. Your suggestion would > > make it necessary to pad all RFC5444 packets to the maximum MTU, which > > might be a considerable overhead. > > I agree. However, it still remains true that link loss estimation that > relies > excessively on small packets will lead to suboptimal results. I'm aware > that > the original ETX paper doesn't cover this, but it doesn't mean that it > shouldn't be addressed in this draft. > So far, this draft documents how the guys from the wireless community networks (FREIFUNK, FUNKFEUER etc.) have been using ETX in OLSR in their networks, and translating that in OLSRv2 formats. While I agree we should let some flexibility in, and try to not preclude things like you describe, in my opinion the first priority should be to specify actual operational experience with OLSR and ETX. Emmanuel > > How about, for example, only incrementing the respective counters for > packets > whose size is above a certain threshold, say MTU / 2 (or even MTU / 4)? > > > > [...] > > > Regarding possible additions: > > > > > > - Convergence time: Has it been considered to add weights to the list > of > > > measured loss ratios in order to optimize the convergence time after > > > major changes to a link? > > > > Yes, but this metric has been mostly used in non-moving mesh networks > where > > weights would only add computational overhead. > > > > It might be a tuning parameter for moving networks, but I am not able t= o > > guess a good value for the weight distribution. > > Neither am I. :) In this case, I just suggest that the wording in this > draft > is chosen in such a way, that amendments regarding highly volatile or > moving > networks can be made easily later on through a second complementary draft= . > > > > > - Useless links: Has it been considered to have an upper bound on the > ETX > > > value above which links are considered as being too bad to be useful? > > > > We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this wou= ld > > be the job of the link hysteresis (which easily could be implemented > based > > on the link cost value). > > But since the link cost value depends on the metric used, it would be up = to > this draft to suggest values for this, wouldn't it? > > > > > - Modulation issues: How does this metric deal with packets that are > send > > > at different transmission rates using different encodings? For > instance, > > > if a link is measured using broadcast packets, then the metric may we= ll > > > be flawed for high-speed streams of unicast packets. > > > > ETX metrics do not consider link speed, so our metric would not encode > this > > difference into the link cost. > > Yes, link speed, just as packet size, is not covered by the original ETX > proposal. I'm aware that properly considering link speed greatly increase= s > the > complexity of the problem. The best workaround that I see is to be > relatively > conservative in what is considered a useful link (see above). > > > Best, > > Georg > > -- > Dr. Georg Wittenburg > Postdoctoral Researcher > INRIA / =C9cole Polytechnique, HIPERCOM Team > Laboratoire d'Informatique de l'=C9cole Polytechnique (LIX) > Route de Saclay, 91128 Palaiseau (CEDEX) > Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044 > http://www.lix.polytechnique.fr/~wittenburg/ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --002354530978dc72fd04a329f337 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Georg,

On Fri, May 13, 2011 at 4:24 PM= , Georg Wittenburg <georg.wittenburg@inria.fr> wrote:
Dear Henning, all,

On Thursday 12 May 2011 08:07:31 Henning Rogge wrote:
> On Wed May 11 2011 16:10:58 Georg Wittenburg wrote:
> [...]
> > - Size of HELLO messages: Sec. 8.1 states= that HELLO messages should be
> > generated as specified in draft-ietf-manet-olsrv2 which in turn r= efers to
> > RFC 6130. In the absence of other traffic, the delivery ratios of= these
> > HELLO messages will be the only input to the ETX metric.
>
> That is not right... there will be more TC mes= sages in the network
> (especially in larger networks) than Hellos, so they will contribute t= o
> the size of the packets too.

OK. But the point below still remains, doesn't it?


> > The problem is
> > that packet delivery ratios differ depending on the size of the > > transmitted packet. If small packets are used to estimate link qu= ality,
> > this estimate will be flawed if the link is used for large packet= s later
> > on, i.e, packets that make full use of the MTU. A workaround woul= d be to
> > require that if HELLO packets are to be used for link quality est= imation
> > then they must be padded to correspond in size to the average dat= a
> > packet, or MTU.
>
> The funkfeuer metric drafts suggests to use al= l RFC 5444 packets for link
> loss estimation, not only a certain message type. Your suggestion woul= d
> make it necessary to pad all RFC5444 packets to the maximum MTU, which=
> might be a considerable overhead.

I agree. However, it still remains true that link loss estimation that reli= es
excessively on small packets will lead to suboptimal results. I'm aware= that
the original ETX paper doesn't cover this, but it doesn't mean that= it
shouldn't be addressed in this draft.


So far, this draft documents how the guys from the = wireless community networks (FREIFUNK, FUNKFEUER etc.) have been using ETX = in OLSR in their networks, and translating that in OLSRv2 formats.

While I agree we should let some flexibility in, and tr= y to not preclude things like you describe, in my opinion the first priorit= y should be to specify actual operational experience with OLSR and ETX.

Emmanuel



=A0

How about, for example, only incrementing the respective counters for packe= ts
whose size is above a certain threshold, say MTU / 2 (or even MTU / 4)?


> [...]
> > Regarding possible additions:
> >
> > - Convergence time: Has it been considered to add weights to the = list of
> > measured loss ratios in order to optimize the convergence time af= ter
> > major changes to a link?
>
> Yes, but this metric has been mostly used in n= on-moving mesh networks where
> weights would only add computational overhead.
>
> It might be a tuning parameter for moving networks, but I am not able = to
> guess a good value for the weight distribution.

Neither am I. :) In this case, I just suggest that the wording in this draf= t
is chosen in such a way, that amendments regarding highly volatile or movin= g
networks can be made easily later on through a second complementary draft.<= br>

> > - Useless links: Has it been considered t= o have an upper bound on the ETX
> > value above which links are considered as being too bad to be use= ful?
>
> We do this in the Freifunk/Funkfeuer meshs, bu= t in NHDP/OLSRv2 this would
> be the job of the link hysteresis (which easily could be implemented b= ased
> on the link cost value).

But since the link cost value depends on the metric used, it would be up to=
this draft to suggest values for this, wouldn't it?


> > - Modulation issues: How does this metric= deal with packets that are send
> > at different transmission rates using different encodings? For in= stance,
> > if a link is measured using broadcast packets, then the metric ma= y well
> > be flawed for high-speed streams of unicast packets.
>
> ETX metrics do not consider link speed, so our= metric would not encode this
> difference into the link cost.

Yes, link speed, just as packet size, is not covered by the original ETX proposal. I'm aware that properly considering link speed greatly increa= ses the
complexity of the problem. The best workaround that I see is to be relative= ly
conservative in what is considered a useful link (see above).


Best,

=A0 =A0 =A0 =A0Georg

--
Dr. Georg Wittenburg
Postdoctoral Researcher
INRIA / =C9cole Polytechnique, HIPERCOM Team
Laboratoire d'Informatique de l'=C9cole Polytechnique (LIX)
Route de Saclay, 91128 Palaiseau (CEDEX)
Phone: +33-(= 0)1-69334126, Fax: +33-(0)1-69334044
= http://www.lix.polytechnique.fr/~wittenburg/
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--002354530978dc72fd04a329f337-- From teco@inf-net.nl Fri May 13 08:53:59 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E57DE074D for ; Fri, 13 May 2011 08:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nAJ4iXu6Vt7 for ; Fri, 13 May 2011 08:53:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71E89E06DF for ; Fri, 13 May 2011 08:53:58 -0700 (PDT) Received: by wwa36 with SMTP id 36so2080316wwa.13 for ; Fri, 13 May 2011 08:53:57 -0700 (PDT) Received: by 10.227.156.20 with SMTP id u20mr1661992wbw.7.1305302037230; Fri, 13 May 2011 08:53:57 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id k2sm1171951wby.34.2011.05.13.08.53.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 08:53:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201105131623.20102.georg.wittenburg@inria.fr> Date: Fri, 13 May 2011 17:53:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105111610.58611.georg.wittenburg@inria.fr> <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> <201105131623.20102.georg.wittenburg@inria.fr> To: Georg Wittenburg X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 15:53:59 -0000 Op 13 mei 2011, om 16:23 heeft Georg Wittenburg het volgende geschreven: >>>=20 >>> The problem is >>> that packet delivery ratios differ depending on the size of the >>> transmitted packet. If small packets are used to estimate link = quality, >>> this estimate will be flawed if the link is used for large packets = later >>> on, i.e, packets that make full use of the MTU. A workaround would = be to >>> require that if HELLO packets are to be used for link quality = estimation >>> then they must be padded to correspond in size to the average data >>> packet, or MTU. >>=20 >> The funkfeuer metric drafts suggests to use all RFC 5444 packets for = link >> loss estimation, not only a certain message type. Your suggestion = would >> make it necessary to pad all RFC5444 packets to the maximum MTU, = which >> might be a considerable overhead. >=20 > I agree. However, it still remains true that link loss estimation that = relies=20 > excessively on small packets will lead to suboptimal results. I'm = aware that=20 > the original ETX paper doesn't cover this, but it doesn't mean that it=20= > shouldn't be addressed in this draft. >=20 > How about, for example, only incrementing the respective counters for = packets=20 > whose size is above a certain threshold, say MTU / 2 (or even MTU / = 4)? How can packet sizes of lost packets be measured? Teco= From dyoung@ojctech.com Fri May 13 09:46:35 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B087AE07FF for ; Fri, 13 May 2011 09:46:35 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqF8ujRpSgtM for ; Fri, 13 May 2011 09:46:35 -0700 (PDT) Received: from elmendorf.ojctech.com (legacy-10.ojctech.com [64.198.255.10]) by ietfa.amsl.com (Postfix) with ESMTP id ABEB8E07F4 for ; Fri, 13 May 2011 09:46:34 -0700 (PDT) Received: by elmendorf.ojctech.com (Postfix, from userid 1000) id F032D1C027F; Fri, 13 May 2011 11:46:30 -0500 (CDT) Date: Fri, 13 May 2011 11:46:30 -0500 From: David Young To: manet@ietf.org Message-ID: <20110513164630.GO20998@ojctech.com> Mail-Followup-To: manet@ietf.org References: <201105111610.58611.georg.wittenburg@inria.fr> <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> <201105131623.20102.georg.wittenburg@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105131623.20102.georg.wittenburg@inria.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 16:46:35 -0000 On Fri, May 13, 2011 at 04:23:19PM +0200, Georg Wittenburg wrote: > Dear Henning, all, > > On Thursday 12 May 2011 08:07:31 Henning Rogge wrote: > > On Wed May 11 2011 16:10:58 Georg Wittenburg wrote: > > [...] > > > - Size of HELLO messages: Sec. 8.1 states that HELLO messages should be > > > generated as specified in draft-ietf-manet-olsrv2 which in turn refers to > > > RFC 6130. In the absence of other traffic, the delivery ratios of these > > > HELLO messages will be the only input to the ETX metric. > > > > That is not right... there will be more TC messages in the network > > (especially in larger networks) than Hellos, so they will contribute to > > the size of the packets too. > > OK. But the point below still remains, doesn't it? > > > > > The problem is > > > that packet delivery ratios differ depending on the size of the > > > transmitted packet. If small packets are used to estimate link quality, > > > this estimate will be flawed if the link is used for large packets later > > > on, i.e, packets that make full use of the MTU. A workaround would be to > > > require that if HELLO packets are to be used for link quality estimation > > > then they must be padded to correspond in size to the average data > > > packet, or MTU. > > > > The funkfeuer metric drafts suggests to use all RFC 5444 packets for link > > loss estimation, not only a certain message type. Your suggestion would > > make it necessary to pad all RFC5444 packets to the maximum MTU, which > > might be a considerable overhead. > > I agree. However, it still remains true that link loss estimation that relies > excessively on small packets will lead to suboptimal results. I'm aware that > the original ETX paper doesn't cover this, but it doesn't mean that it > shouldn't be addressed in this draft. > > How about, for example, only incrementing the respective counters for packets > whose size is above a certain threshold, say MTU / 2 (or even MTU / 4)? Suppose that there is a function that for a certain bit error rate (BER) maps the packet size to the delivery ratio. If we know the delivery ratio at two or more packet sizes, it seems that we can fit a curve to those ratios and derive the BER from the curve. Then we can use the BER to roughly predict the delivery ratio at each packet size. > > > - Modulation issues: How does this metric deal with packets that are send > > > at different transmission rates using different encodings? For instance, > > > if a link is measured using broadcast packets, then the metric may well > > > be flawed for high-speed streams of unicast packets. > > > > ETX metrics do not consider link speed, so our metric would not encode this > > difference into the link cost. > > Yes, link speed, just as packet size, is not covered by the original ETX > proposal. I'm aware that properly considering link speed greatly increases the > complexity of the problem. The best workaround that I see is to be relatively > conservative in what is considered a useful link (see above). You can probably derive a much better metric than ETX by tapping into information that the rate adaptation collects. More than one 802.11 rate adaptation in the literature has tried to optimize the so-called goodput of a link by choosing a suitable bitrate for each packet based on packet properties such as size. Advantages of collecting information from the rate adaptation are that you avoid duplicating any code or computational effort, and you collect the information from a more suitable (IMO) place in the network stack. All the world's MANETs are not built on 802.11, it is true, but the same general principles apply: don't needlessly compute the same metric twice, and collect the link metric at the most suitable place. Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 344-0444 x24 From hrogge@googlemail.com Sat May 14 11:33:16 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35420E06E0 for ; Sat, 14 May 2011 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob6PFs7JPBPf for ; Sat, 14 May 2011 11:33:15 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0471E0659 for ; Sat, 14 May 2011 11:33:14 -0700 (PDT) Received: by ewy19 with SMTP id 19so1208770ewy.31 for ; Sat, 14 May 2011 11:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=n5hWXgGHK4qeu3hTweprGpV43+Itxbnt6YSIAMjUhiM=; b=hzCf8osGcudWe+lV7vd3tAO7GOfqa0WIt5LyKgi6QHrSeuzEjBzuUB0S+Q//TqdJxZ S84QLEPLcBCYyJh34Op6a6uuZb4PfkqigHvvZSydxUjGcMF3aAodLqf37Hox1yr3R7Hy W23l51QZD3EJ3keRYltLjug+pvGcyTRt/XP7A= 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=XyVeM56/kyCs2X34S7X9WnenQRLnm2XlqjfKpT1ZzzTXSa0B1JAJFvkZWtsrugNd6S GDAtW8pNRKNjB4kvI7VKScSsSJc48oLjYwuOAUxZgXvhymSLCrgqeKKTjkaOSCNK//5M XSqYlcD42abkxe0AsQUQi/0EayNbnTRWbHi18= Received: by 10.14.11.83 with SMTP id 59mr1158819eew.39.1305397993945; Sat, 14 May 2011 11:33:13 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id y2sm2247562eeh.11.2011.05.14.11.33.11 (version=SSLv3 cipher=OTHER); Sat, 14 May 2011 11:33:12 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Sat, 14 May 2011 20:33:05 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.38-gentoo-r4; KDE/4.6.2; x86_64; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> <201105131623.20102.georg.wittenburg@inria.fr> In-Reply-To: <201105131623.20102.georg.wittenburg@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1442268.3L6o25sLJM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105142033.10407.hrogge@googlemail.com> Cc: David Young Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 18:33:16 -0000 --nextPart1442268.3L6o25sLJM Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Answer to Georg Wittenburg, Teco Boot and David Young... Am Freitag 13 Mai 2011, 16:23:19 schrieb Georg Wittenburg: > > The funkfeuer metric drafts suggests to use all RFC 5444 packets for li= nk > > loss estimation, not only a certain message type. Your suggestion would > > make it necessary to pad all RFC5444 packets to the maximum MTU, which > > might be a considerable overhead. >=20 > I agree. However, it still remains true that link loss estimation that > relies excessively on small packets will lead to suboptimal results. I'm > aware that the original ETX paper doesn't cover this, but it doesn't mean > that it shouldn't be addressed in this draft. >=20 > How about, for example, only incrementing the respective counters for > packets whose size is above a certain threshold, say MTU / 2 (or even MTU > / 4)? What if no OLSR packets are that large ? Do we add padding to get at least = one=20 or multiple large packets each second ? =20 > > We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this wou= ld > > be the job of the link hysteresis (which easily could be implemented > > based on the link cost value). >=20 > But since the link cost value depends on the metric used, it would be up = to > this draft to suggest values for this, wouldn't it? We had some discussion about this, but it seems that most people here don't= =20 like to use the link metric to do the hysteresis. In Freifunk/Funkfeuer, we ignore each link with an link quality below 0.1 i= n=20 one direction. =20 Am Freitag 13 Mai 2011, 17:53:53 schrieb Teco Boot: > > How about, for example, only incrementing the respective counters for > > packets whose size is above a certain threshold, say MTU / 2 (or even > > MTU / 4)? >=20 > How can packet sizes of lost packets be measured? Maybe with a second packet sequence number that is only increased for large= =20 packets ? Am Freitag 13 Mai 2011, 18:46:30 schrieb David Young: > You can probably derive a much better metric than ETX by tapping into > information that the rate adaptation collects. More than one 802.11 > rate adaptation in the literature has tried to optimize the so-called > goodput of a link by choosing a suitable bitrate for each packet based > on packet properties such as size. Advantages of collecting information > from the rate adaptation are that you avoid duplicating any code or > computational effort, and you collect the information from a more > suitable (IMO) place in the network stack. All the world's MANETs are > not built on 802.11, it is true, but the same general principles apply: > don't needlessly compute the same metric twice, and collect the link > metric at the most suitable place. Doing this on one operation system with different wireless cards is hard...= =20 doing it for multiple operation systems and different cards will get you=20 insane pretty quickly... I personally like the idea to get the rate control data of the mac80211 sta= ck=20 in linux, unfortunately that only solves the problem for a very special cas= e,=20 and only for unicast traffic. If you rely on the rate control, you need to send unicast probing packets t= o=20 all of your neighbors regularly if you have no traffic in this direction. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1442268.3L6o25sLJM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk3OyuYACgkQcenvcwAcHWe44QCdGiBOvU6UDjWdaSpAA/Uz4rXl pUgAn2q8Z3vWIqeqHu60de8k/fRCnsnm =IlKh -----END PGP SIGNATURE----- --nextPart1442268.3L6o25sLJM-- From georg.wittenburg@inria.fr Wed May 18 13:16:26 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A53E072C for ; Wed, 18 May 2011 13:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKY0Ypg5Qsq2 for ; Wed, 18 May 2011 13:16:21 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 72CCAE068B for ; Wed, 18 May 2011 13:16:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,232,1304287200"; d="scan'208";a="94957164" Received: from 212-198-208-196.rev.numericable.fr (HELO vaio.localnet) ([212.198.208.196]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2011 22:16:13 +0200 From: Georg Wittenburg Organization: INRIA To: Henning Rogge Date: Wed, 18 May 2011 22:16:06 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.3; i686; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> <201105131623.20102.georg.wittenburg@inria.fr> <136923972.1117761.1305397995016.JavaMail.root@zmbs2.inria.fr> In-Reply-To: <136923972.1117761.1305397995016.JavaMail.root@zmbs2.inria.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201105182216.06862.georg.wittenburg@inria.fr> Cc: manet@ietf.org, David Young Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 20:16:26 -0000 Hi Henning, Teco, David, all, On Saturday 14 May 2011 20:33:15 Henning Rogge wrote: > Answer to Georg Wittenburg, Teco Boot and David Young... >=20 > Am Freitag 13 Mai 2011, 16:23:19 schrieb Georg Wittenburg: > > > The funkfeuer metric drafts suggests to use all RFC 5444 packets for > > > link loss estimation, not only a certain message type. Your suggestion > > > would make it necessary to pad all RFC5444 packets to the maximum MTU, > > > which might be a considerable overhead. > >=20 > > I agree. However, it still remains true that link loss estimation that > > relies excessively on small packets will lead to suboptimal results. I'm > > aware that the original ETX paper doesn't cover this, but it doesn't me= an > > that it shouldn't be addressed in this draft. > >=20 > > How about, for example, only incrementing the respective counters for > > packets whose size is above a certain threshold, say MTU / 2 (or even M= TU > > / 4)? >=20 > What if no OLSR packets are that large ? Do we add padding to get at least > one or multiple large packets each second ? Sounds like an acceptable trade-off. Another option would be to include dat= a=20 packets in the link loss estimation. Was there any particular reason why yo= u=20 decided against including them? > > > We do this in the Freifunk/Funkfeuer meshs, but in NHDP/OLSRv2 this > > > would be the job of the link hysteresis (which easily could be > > > implemented based on the link cost value). > >=20 > > But since the link cost value depends on the metric used, it would be up > > to this draft to suggest values for this, wouldn't it? >=20 > We had some discussion about this, but it seems that most people here don= 't > like to use the link metric to do the hysteresis. >=20 > In Freifunk/Funkfeuer, we ignore each link with an link quality below 0.1 > in one direction. >=20 > Am Freitag 13 Mai 2011, 17:53:53 schrieb Teco Boot: > > > How about, for example, only incrementing the respective counters for > > > packets whose size is above a certain threshold, say MTU / 2 (or even > > > MTU / 4)? > >=20 > > How can packet sizes of lost packets be measured? >=20 > Maybe with a second packet sequence number that is only increased for lar= ge > packets ? I don't see the problem here. Both sender and receiver can increment their= =20 respective packet counters based on the packets (above a certain size, or=20 matching other conditions) which they see and ETX should just work as=20 expected. Am I overlooking something? > Am Freitag 13 Mai 2011, 18:46:30 schrieb David Young: > > You can probably derive a much better metric than ETX by tapping into > > information that the rate adaptation collects. More than one 802.11 > > rate adaptation in the literature has tried to optimize the so-called > > goodput of a link by choosing a suitable bitrate for each packet based > > on packet properties such as size. Advantages of collecting information > > from the rate adaptation are that you avoid duplicating any code or > > computational effort, and you collect the information from a more > > suitable (IMO) place in the network stack. All the world's MANETs are > > not built on 802.11, it is true, but the same general principles apply: > > don't needlessly compute the same metric twice, and collect the link > > metric at the most suitable place. >=20 > Doing this on one operation system with different wireless cards is hard.= =2E. > doing it for multiple operation systems and different cards will get you > insane pretty quickly... >=20 > I personally like the idea to get the rate control data of the mac80211 > stack in linux, unfortunately that only solves the problem for a very > special case, and only for unicast traffic. >=20 > If you rely on the rate control, you need to send unicast probing packets > to all of your neighbors regularly if you have no traffic in this > direction. Best, Georg =2D-=20 Dr. Georg Wittenburg Postdoctoral Researcher INRIA / =C9cole Polytechnique, HIPERCOM Team Laboratoire d'Informatique de l'=C9cole Polytechnique (LIX) Route de Saclay, 91128 Palaiseau (CEDEX) Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044 http://www.lix.polytechnique.fr/~wittenburg/ From dyoung@ojctech.com Wed May 18 13:35:48 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012A1E06B1 for ; Wed, 18 May 2011 13:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhebxdxKzupO for ; Wed, 18 May 2011 13:35:47 -0700 (PDT) Received: from elmendorf.ojctech.com (elmendorf.ojctech.com [IPv6:2002:4cbf:1101:2:2a1:b0ff:fe80:335d]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE4DE06B0 for ; Wed, 18 May 2011 13:35:46 -0700 (PDT) Received: by elmendorf.ojctech.com (Postfix, from userid 1000) id AED8A1C027F; Wed, 18 May 2011 15:35:39 -0500 (CDT) Date: Wed, 18 May 2011 15:35:39 -0500 From: David Young To: manet@ietf.org Message-ID: <20110518203539.GG20998@ojctech.com> Mail-Followup-To: manet@ietf.org References: <201105111610.58611.georg.wittenburg@inria.fr> <235011815.1087321.1305180451563.JavaMail.root@zmbs2.inria.fr> <201105131623.20102.georg.wittenburg@inria.fr> <201105142033.10407.hrogge@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105142033.10407.hrogge@googlemail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 20:35:48 -0000 > Am Freitag 13 Mai 2011, 18:46:30 schrieb David Young: > > You can probably derive a much better metric than ETX by tapping into > > information that the rate adaptation collects. More than one 802.11 > > rate adaptation in the literature has tried to optimize the so-called > > goodput of a link by choosing a suitable bitrate for each packet based > > on packet properties such as size. Advantages of collecting information > > from the rate adaptation are that you avoid duplicating any code or > > computational effort, and you collect the information from a more > > suitable (IMO) place in the network stack. All the world's MANETs are > > not built on 802.11, it is true, but the same general principles apply: > > don't needlessly compute the same metric twice, and collect the link > > metric at the most suitable place. > Doing this on one operation system with different wireless cards is hard... > doing it for multiple operation systems and different cards will get you > insane pretty quickly... Let us cross our fingers and hope that each OS provides a uniform API. :-) > If you rely on the rate control, you need to send unicast probing packets to > all of your neighbors regularly if you have no traffic in this direction. It seems to me, too, that that is a problem with using a rate adaptation. One hopes that there are probe packets or else that the inherent background unicast traffic keeps the rate adaptation fresh. I think that having to induce some unicast traffic may be a reasonable trade-off for being able to derive a link metric from the rate adaptation. FWIW, I have lingering doubts whether or not a link metric can be updated or link metrics propagated nearly as quickly as the channel makes a substantial change of state. From N hops away, a single metric for a link may not be nearly as useful in a routing decision as the historical range or distribution of metrics on a link. People have experimented with "opportunistic" routing/forwarding, I think this is why. Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 344-0444 x24 From henning.rogge@fkie.fraunhofer.de Wed May 18 23:17:34 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE4EE068F for ; Wed, 18 May 2011 23:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb2apwMfd6we for ; Wed, 18 May 2011 23:17:33 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 36248E06E6 for ; Wed, 18 May 2011 23:17:33 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QMwWq-0006i5-MB; Thu, 19 May 2011 08:16:12 +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.76) (envelope-from ) id 1QMwWq-0005Wz-3s; Thu, 19 May 2011 08:16:12 +0200 From: Henning Rogge To: Georg Wittenburg Date: Thu, 19 May 2011 08:16:03 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> <136923972.1117761.1305397995016.JavaMail.root@zmbs2.inria.fr> <201105182216.06862.georg.wittenburg@inria.fr> In-Reply-To: <201105182216.06862.georg.wittenburg@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2640115.qySzKri4kh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105190816.08515.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.97/13090/Thu May 19 02:18:37 2011) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4db47a2f8fc8763431e9cacb4f9c6041 Cc: manet@ietf.org, David Young Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 06:17:34 -0000 --nextPart2640115.qySzKri4kh Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Wed May 18 2011 22:16:06 Georg Wittenburg wrote: > > What if no OLSR packets are that large ? Do we add padding to get at > > least one or multiple large packets each second ? >=20 > Sounds like an acceptable trade-off.=20 We could use some kind of dummy message (maybe with TTL 0 so it will be=20 automatically dropped) for the padding I think. > Another option would be to include > data packets in the link loss estimation. Was there any particular reason > why you decided against including them? Data traffic is send as unicast, so it includes retransmissions and a diffe= rent=20 modulation in WLAN. Its not intuitively clear how to combine this with=20 broadcast measurements. =20 > > > How can packet sizes of lost packets be measured? > >=20 > > Maybe with a second packet sequence number that is only increased for > > large packets ? >=20 > I don't see the problem here. Both sender and receiver can increment their > respective packet counters based on the packets (above a certain size, or > matching other conditions) which they see and ETX should just work as > expected. Am I overlooking something? The receiver on a link must estimate the number of lost packets. Our draft= =20 does this by looking at the packet sequence number to detect missing packet= s. If you only want to count packets of a certain size this does not work. =20 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-961, 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 --nextPart2640115.qySzKri4kh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3UtaMACgkQRIfGfFXsz+DtiQCfcx8z/WaYoJdwgSW6Kn4Aagwy P2kAoIWYuWQwAC7nGW9VTpDWPJFWctW/ =GxPz -----END PGP SIGNATURE----- --nextPart2640115.qySzKri4kh-- From henning.rogge@fkie.fraunhofer.de Wed May 18 23:18:02 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6FE0724 for ; Wed, 18 May 2011 23:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XSq+R2EbSup for ; Wed, 18 May 2011 23:18:02 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id CE674E0713 for ; Wed, 18 May 2011 23:18:01 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QMwYa-0006mT-QZ; Thu, 19 May 2011 08:18:00 +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.76) (envelope-from ) id 1QMwYa-0005XW-GD; Thu, 19 May 2011 08:18:00 +0200 From: Henning Rogge To: manet@ietf.org Date: Thu, 19 May 2011 08:17:56 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> <201105142033.10407.hrogge@googlemail.com> <20110518203539.GG20998@ojctech.com> In-Reply-To: <20110518203539.GG20998@ojctech.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1437093.hKiTKlJmuN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105190817.57269.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.97/13090/Thu May 19 02:18:37 2011) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 711cfe84e8f62d248cc13f80a51c6aa9 Cc: David Young Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 06:18:03 -0000 --nextPart1437093.hKiTKlJmuN Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed May 18 2011 22:35:39 David Young wrote: > Let us cross our fingers and hope that each OS provides a uniform API. And that all drivers use the API... ;) > > If you rely on the rate control, you need to send unicast probing packe= ts > > to all of your neighbors regularly if you have no traffic in this > > direction. >=20 > It seems to me, too, that that is a problem with using a rate > adaptation. One hopes that there are probe packets or else that the > inherent background unicast traffic keeps the rate adaptation fresh. I > think that having to induce some unicast traffic may be a reasonable > trade-off for being able to derive a link metric from the rate > adaptation. It would be necessary to do so if no unicast traffic is on a link. =20 > FWIW, I have lingering doubts whether or not a link metric can be > updated or link metrics propagated nearly as quickly as the channel > makes a substantial change of state. From N hops away, a single metric > for a link may not be nearly as useful in a routing decision as the > historical range or distribution of metrics on a link. People have > experimented with "opportunistic" routing/forwarding, I think this is > why. I think this hysteresis/history of a link could be directly included into=20 metric calculation of a link. The Draft is doing it in a very limited way b= y=20 averaging over a certain period of time. 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-961, 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 --nextPart1437093.hKiTKlJmuN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3UthUACgkQRIfGfFXsz+C+NACfZll9gYjAfIUuxUI9vUl9tkFA EKsAnA3rKpwvmwAfP3q1v9nWAIoNlY2D =u5ut -----END PGP SIGNATURE----- --nextPart1437093.hKiTKlJmuN-- From abdussalambaryun@gmail.com Mon May 23 10:46:48 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19423E0670 for ; Mon, 23 May 2011 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdA-Gap365fv for ; Mon, 23 May 2011 10:46:47 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2071FE0658 for ; Mon, 23 May 2011 10:46:47 -0700 (PDT) Received: by qwc23 with SMTP id 23so4719652qwc.31 for ; Mon, 23 May 2011 10:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=/8NOonGSpsakJCtX0V1Xi+qTGg0PIuHv4pFQnZuRM9E=; b=dwnBm5bi5TGA7o1XLw+inCrpspz2yIdU1jXedoqANcXTqiyR81SY3zN/noWFWf1u3j eZmtJm898w48z52Sm1PF/l5ApB8NBXqBeM4vUi1CPezAzAMBCQ6GngDbyfM9ayYgZAoS uEkgnRM2sMUyFLbv6ZMYw8bKFRUMcfup26hZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vSKk+7WRu7x4xGmKKQyNwJjhJaUewVuLGucmjtzxV2b4Kx35iKFDimipDUQd6QlajA nN+8+lxiCdhy+HU+lsbnSqdwF4NyMZyG7chgX6Hxr1cDAKc5tt6mM2+BQcgW7h3uCOUj 5CuBj7J5MCv4PDdAjOSzOyD5qrIKtzFNYIws8= MIME-Version: 1.0 Received: by 10.229.56.148 with SMTP id y20mr1963740qcg.283.1306172806497; Mon, 23 May 2011 10:46:46 -0700 (PDT) Received: by 10.229.89.72 with HTTP; Mon, 23 May 2011 10:46:46 -0700 (PDT) Date: Mon, 23 May 2011 18:46:46 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5cb6225870b04a3f50ef4 X-Mailman-Approved-At: Mon, 23 May 2011 11:48:57 -0700 Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:46:48 -0000 --000e0cd5cb6225870b04a3f50ef4 Content-Type: text/plain; charset=ISO-8859-1 > > > How can packet sizes of lost packets be measured? > > Maybe with a second packet sequence number that is only increased for > > large packets ? If we want exact information it seems that the source or dest_nieghbours may inform the destination of the lost packets sizes if requested by the destination. The source should be able to list all the sent packets SQ number with its size index by the packets destinations. The destination sends to source a request of the sizes of packets (using special packet for measure). Or more simple method can be called the size SQ method proposed above, so the source, path_nodes and destination are counting the packet by possible categorized of size information/measured. We may have second/third/more sequence (size_sequence) in three or four as very large, large, medium, small. Therefore, when the dest size sequence count is different from the source it will notice the lost and measure the size. --000e0cd5cb6225870b04a3f50ef4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> > > = How can packet sizes of lost packets be measured?

> >= ; Maybe with a second packet sequence number that is only increased for

> > lar= ge packets ?

=A0

If we want ex= act information it seems that the source or dest_nieghbours may inform the = destination of the lost packets sizes if requested by the destination.=A0Th= e source should be able to=A0list all the sent packets SQ number with=A0its= size index by the packets destinations. The destination sends to source a = request of the sizes of packets=A0(using special packet for measure).

=A0

Or more simpl= e method can be called the size=A0SQ method proposed above, so the source, = path_nodes=A0and destination are counting the packet by possible categorize= d=A0of size information/measured.=A0We may have second/third/more sequence = (size_sequence)=A0in three or four as very large, large, medium, small. The= refore, when the dest size sequence count is different from the source it w= ill notice the lost and measure the size.

=A0
--000e0cd5cb6225870b04a3f50ef4-- From georg.wittenburg@inria.fr Tue May 24 06:37:36 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB05E06AF for ; Tue, 24 May 2011 06:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.042 X-Spam-Level: X-Spam-Status: No, score=-9.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyh2Gt34wV-7 for ; Tue, 24 May 2011 06:37:34 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id B8C19E068D for ; Tue, 24 May 2011 06:37:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,261,1304287200"; d="scan'208";a="95358304" Received: from sphinx.lix.polytechnique.fr (HELO latitude-e6410.localnet) ([129.104.11.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 May 2011 15:37:31 +0200 From: Georg Wittenburg Organization: INRIA To: Henning Rogge Date: Tue, 24 May 2011 15:37:30 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.3; i686; ; ) References: <201105111610.58611.georg.wittenburg@inria.fr> <201105182216.06862.georg.wittenburg@inria.fr> <488247879.1174003.1305785851528.JavaMail.root@zmbs2.inria.fr> In-Reply-To: <488247879.1174003.1305785851528.JavaMail.root@zmbs2.inria.fr> MIME-Version: 1.0 X-UID: 97 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201105241537.31066.georg.wittenburg@inria.fr> Cc: manet@ietf.org, David Young Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:37:36 -0000 Hi Henning, all, > [...] > > > > How can packet sizes of lost packets be measured? > > >=20 > > > Maybe with a second packet sequence number that is only increased for > > > large packets ? > >=20 > > I don't see the problem here. Both sender and receiver can increment > > their respective packet counters based on the packets (above a certain > > size, or matching other conditions) which they see and ETX should just > > work as expected. Am I overlooking something? >=20 > The receiver on a link must estimate the number of lost packets. Our draft > does this by looking at the packet sequence number to detect missing > packets. >=20 > If you only want to count packets of a certain size this does not work. I see. And I agree with you that in this case you would indeed need a secon= d=20 counter just for relevant packets. Possibly another TLV, if the overhead is= =20 acceptable. Best, Georg =2D-=20 Dr. Georg Wittenburg Postdoctoral Researcher INRIA / =C9cole Polytechnique, HIPERCOM Team Laboratoire d'Informatique de l'=C9cole Polytechnique (LIX) Route de Saclay, 91128 Palaiseau (CEDEX) Phone: +33-(0)1-69334126, Fax: +33-(0)1-69334044 http://www.lix.polytechnique.fr/~wittenburg/ From henning.rogge@fkie.fraunhofer.de Tue May 24 07:29:23 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACAFE0762 for ; Tue, 24 May 2011 07:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKHVRCXHSl6U for ; Tue, 24 May 2011 07:29:22 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 730F2E075D for ; Tue, 24 May 2011 07:29:22 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1QOsbh-0001pm-Vk; Tue, 24 May 2011 16:29:14 +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.76) (envelope-from ) id 1QOsbh-0006Kf-NO; Tue, 24 May 2011 16:29:13 +0200 From: Henning Rogge To: manet@ietf.org Date: Tue, 24 May 2011 16:29:03 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1391736.V6Up5ctUWq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201105241629.09204.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.97/13107/Tue May 24 03:23:47 2011) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 054ccd22e44c7b570fe3109fd6105c99 Cc: David Young , Abdussalam Baryun Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:29:23 -0000 --nextPart1391736.V6Up5ctUWq Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon May 23 2011 19:46:46 Abdussalam Baryun wrote: > > > > How can packet sizes of lost packets be measured? > > >=20 > > > Maybe with a second packet sequence number that is only increased for > > >=20 > > > large packets ? >=20 > If we want exact information it seems that the source or dest_nieghbours > may inform the destination of the lost packets sizes if requested by the > destination. The source should be able to list all the sent packets SQ > number with its size index by the packets destinations. The destination > sends to source a request of the sizes of packets (using special packet > for measure). This might require a huge amount of data inside the packages because long=20 bursts of packages might be lost. =20 > Or more simple method can be called the size SQ method proposed above, so > the source, path_nodes and destination are counting the packet by possible > categorized of size information/measured. We may have second/third/more > sequence (size_sequence) in three or four as very large, large, medium, > small. Therefore, when the dest size sequence count is different from the > source it will notice the lost and measure the size. On Tue May 24 2011 15:37:30 Georg Wittenburg wrote: > Hi Henning, all, >=20 > I see. And I agree with you that in this case you would indeed need a > second counter just for relevant packets. Possibly another TLV, if the > overhead is acceptable. I think it should be acceptable, we might even get away with a single byte= =20 sequence number, because we can detect overflows (more than 255 lost packag= es)=20 with the help of the default package number. Links which lost 200+ packages in a row would most likely be considered ver= y=20 bad anyways. 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-961, 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 --nextPart1391736.V6Up5ctUWq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3bwLAACgkQRIfGfFXsz+BeVgCdE8zxcMphnYrRc9C6UuR+XlAy zzkAnjwVA7QVkdsTBxf6uTf+jEhtY1mw =ktcJ -----END PGP SIGNATURE----- --nextPart1391736.V6Up5ctUWq-- From ulrich@herberg.name Tue May 24 08:34:33 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80391E0730 for ; Tue, 24 May 2011 08:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRCjBLcJ+a4m for ; Tue, 24 May 2011 08:34:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26C8AE0752 for ; Tue, 24 May 2011 08:34:28 -0700 (PDT) Received: by vws12 with SMTP id 12so6069910vws.31 for ; Tue, 24 May 2011 08:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=tcrb4Bq4qMkob5sp+c0ccd5OJoNIcEM0GhD3M+mO/Wo=; b=rJCz0KEaF22fZUsTnbW1V9a3kqwX57FB39GqS/wLO1fh4S9K1b2Eu1BF7Vwsg9HUTA pPa4nlIyL/szdvIvVSxZb9ZvKalUlKnFwgWDKx2ZqYypfny0oa2W0OZb9Mtl5d0/Jv5j wAQJVnMZ5q5TO5D4ArV+RPsnCB9Lst83IwKQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=1uHu6+4MUldtl7pNrF6EJdCFFvmbVpaL+6jea6e24LoAJ/kNABX21Ofsnq4TNkQAjL xUhF4eaXa2wOUdgy1422RvEIt9rviVjcfeoHNJO35TnNgjLKMsRCgu5eDOR/FWG9KU/z IdDKDsVlOf5vuoUnSm6uWBvvNttH4B1IW2IdE= MIME-Version: 1.0 Received: by 10.52.112.106 with SMTP id ip10mr791760vdb.127.1306251267441; Tue, 24 May 2011 08:34:27 -0700 (PDT) Received: by 10.220.158.138 with HTTP; Tue, 24 May 2011 08:34:27 -0700 (PDT) Date: Tue, 24 May 2011 17:34:27 +0200 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=bcaec548a1cfc882ce04a407528b Cc: MANET IETF , Thomas Heide Clausen Subject: [manet] packetbb-sec WGLC comments (was: Re: WG adoption of NHDP-sec) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:34:33 -0000 --bcaec548a1cfc882ce04a407528b Content-Type: text/plain; charset=ISO-8859-1 Chris, sorry for the late reply, I was very busy these last weeks ;-) On Thu, Apr 21, 2011 at 5:17 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Brief version: I think there's a two part change that should > be included before finishing WGLC. > > My apologies in advance in that should this spark a discussion, > I'll be out of the loop for a week and a half and no able to > contribute. (The UK is largely shutting down, we have for a > combination of rare reasons, two four day weekends, with a > three day gap. Many of us are taking those three days off too.) > > My main concern over this document is that it specifies a > signature as the composition of a hash function and a > cryptographic function, in that order. There are other ways > of constructing signatures that do not correspond to such > a decomposition. > I agree that there other ways of constructing signatures. In your case, couldn't you just select the identity function as hash function and then only use the cryptographic function for creating the signature (i.e. chris_special_signature_function(id(message)) )? If that is not suitable, of course, a new type extension could be used: > > The obvious response to that is to pick a new type extension > for such. yes > This can't be normative text in this document, but > I think it should be described in the applicability statement, > which should say that this specification describes a general > approach to signatures (much of the document, such as how to > traety hop counts/limits is not specific to this decomposition) > and then a specific approach to signatures, and should provide > the comment that other mathematical forms of signature are > possible, and should be handled by use of alternative type > extensions. In the main body of the specification, a bit more > clarity on what is form-specific and what is not would then > help. > Yes, I agree to that and will update the text accordingly. > > This then leads to the question a to whether the form described > should be the privileged type extension = 0 case. Actually I > would suggest it should be type extension = 1, with 0 reserved > for "I'm not providing any information on algorithms, this is > defined out of band, not in each packet. The reason I suggest > that as type 0 (and including it in this document) is that it > puts the two lowest-overhead options together (type extension 0, > which can be omitted, and no algorithm information). > > Note that for timestamp, what other type extensions may be is > alraedy covered, but not so for signatures, and timestamp uses > the type extension 0 for the analogous case I suggest for type > extension 0 for signature, i.e. detertmined otherwise (should > the phrase "administrative action" be used in both cases?) > I see your point. However, I am not convinced that the additional overhead of setting the type extension for the proposed decomposition into hash+crypto is desirable. Most signatures mechanisms that I am aware of use this decomposition. There are certainly other ways of calculating a signature, but sending an additional octet in every message for these -- at least currently -- rare cases needs to be justified. As for timestamps, I don't see one single prevalent way of representing a timestamp, which is why we use the type extension 0 for a general case. Ulrich > > I think there should be another iteration before going to > SECDIR and IESG, as I think it will avoid work further down the > line, as well as being a better specification this way. > > -- > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > 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 Joe Macker > Sent: 07 April 2011 17:17 > To: MANET IETF > Subject: [manet] WG adoption of NHDP-sec > > > *** 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. > > > As discussed in Prague we are presently considering adoption of NHDP > security related document as a WG document. > > reference is draft-herberg-manet-nhdp-sec-01 > > Please comment if you have an opinion. > > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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. > ******************************************************************** > > --bcaec548a1cfc882ce04a407528b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chris,

sorry for the late reply, I was very busy these last weeks ;-= )

On Thu, Apr 21, 2011 at 5:17 PM, Dearlo= ve, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
Brief version: I think there's a two pa= rt change that should
be included before finishing WGLC.

My apologies in advance in that should this spark a discussion,
I'll be out of the loop for a week and a half and no able to
contribute. (The UK is largely shutting down, we have for a
combination of rare reasons, two four day weekends, with a
three day gap. Many of us are taking those three days off too.)

My main concern over this document is that it specifies a
signature as the composition of a hash function and a
cryptographic function, in that order. There are other ways
of constructing signatures that do not correspond to such
a decomposition.

I agree that there other ways of = constructing signatures. In your case, couldn't you just select the ide= ntity function as hash function and then only use the cryptographic functio= n for creating the signature (i.e. chris_special_signature_function(id(mess= age)) )?

If that is not suitable, of course, a new type extension could be used:=
=A0

The obvious response to that is to pick a new type extension
for such.

yes
=A0
This can't be normative text in this doc= ument, but
I think it should be described in the applicability statement,
which should say that this specification describes a general
approach to signatures (much of the document, such as how to
traety hop counts/limits is not specific to this decomposition)
and then a specific approach to signatures, and should provide
the comment that other mathematical forms of signature are
possible, and should be handled by use of alternative type
extensions. In the main body of the specification, a bit more
clarity on what is form-specific and what is not would then
help.

Yes, I agree to that and will update the tex= t accordingly.
=A0

This then leads to the question a to whether the form described
should be the privileged type extension =3D 0 case. Actually I
would suggest it should be type extension =3D 1, with 0 reserved
for "I'm not providing any information on algorithms, this is
defined out of band, not in each packet. The reason I suggest
that as type 0 (and including it in this document) is that it
puts the two lowest-overhead options together (type extension 0,
which can be omitted, and no algorithm information).

Note that for timestamp, what other type extensions may be is
alraedy covered, but not so for signatures, and timestamp uses
the type extension 0 for the analogous case I suggest for type
extension 0 for signature, i.e. detertmined otherwise (should
the phrase "administrative action" be used in both cases?)

I see your point. However, I am not convinced that the a= dditional overhead of setting the type extension for the proposed decomposi= tion into hash+crypto is desirable. Most signatures mechanisms that I am aw= are of use this decomposition. There are certainly other ways of calculatin= g a signature, but sending an additional octet in every message for these -= - at least currently -- rare cases needs to be justified. As for timestamps= , I don't see one single prevalent way of representing a timestamp, whi= ch is why we use the type extension 0 for a general case.

Ulrich
=A0

I think there should be another iteration before going to
SECDIR and IESG, as I think it will avoid work further down the
line, as well as being a better specification this way.

--
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
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 Joe Macker
Sent: 07 April 2011 17:17
To: MANET IETF
Subject: [manet] WG adoption of NHDP-sec


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


--bcaec548a1cfc882ce04a407528b-- From gmarfia@gmail.com Wed May 25 05:45:33 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72565E0723 for ; Wed, 25 May 2011 05:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNufJvNpQym5 for ; Wed, 25 May 2011 05:45:32 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6980BE071D for ; Wed, 25 May 2011 05:45:32 -0700 (PDT) Received: by qwc23 with SMTP id 23so6151285qwc.31 for ; Wed, 25 May 2011 05:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=W4ICqvDE96Wc85LrXxxGVU5BlkjCj/PJ75rSARhb+dE=; b=M7Uubx32FOyhQCvFMGKvXTeeyy+8Yr7EUhIr26NfZvJAAj4lhlLv/oQDDLyUEf8SX+ 3/Vy8/IzNaUX7E/1Z0Zni0xXSfvGD6zR7N6BjKIK+KmWteX6EQJijEbcyaTyKbhtKghk xXjSLh2i5P0l//CohmpjtMp+GxyPilLH/ePPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YU3J/iiXFox8A6fH7A6ex4EXNbS/n2TDsPTZRRMGvZawD/vAHwU/9LAGo5QQoGrwxX HpKKd/x2yjkMcZFvxoFP6Z/NhpDBvezBvB4mqzE9pxiEj/MYqIflcnnJLys1zKjfZK1u zYsT52VfhKpWq6UC6iYS4OMKblrz4LwzoijRc= MIME-Version: 1.0 Received: by 10.229.45.3 with SMTP id c3mr3605079qcf.249.1306327531916; Wed, 25 May 2011 05:45:31 -0700 (PDT) Received: by 10.229.192.140 with HTTP; Wed, 25 May 2011 05:45:31 -0700 (PDT) Date: Wed, 25 May 2011 14:45:31 +0200 Message-ID: From: Gustavo Marfia To: manet@ietf.org Content-Type: multipart/alternative; boundary=0016363b9ce0800e3304a4191468 Subject: [manet] "Inventare il Futuro" Contest X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:45:33 -0000 --0016363b9ce0800e3304a4191468 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear All, If you have an innovative idea involving new technologies which could contribute to improve the quality of civil and social life, take part in *Inventare il Futuro*, the ideas competition launched by the University of Bologna, Italy, with the contribution of the =93Fondazione del Monte di Bologna e Ravenna=94. The competition is open to young people who, on the competition deadline, fulfil the following requirements: - Max. age 30 (you must not yet have turned 31); - You must be enrolled to a study programme at, or have graduated from, a university in the European Union. The ideas presented must be prevalently based on digital technologies, and must fall into one of the following fields of application: - City and citizens; - Health and the Environment; - Children, the Third Age, Disability; - Cultural and Artistic Heritage; - Education; - Media, Arts, Entertainment. The first prize, for each field of application, is of 7000 Euro. More information may be found at: http://www.facebook.com/pages/Inventare-il-Futuro-Un-Concorso-per-Giovani-I= dee/221824417827746 http://www.unibo.it/inventarefuturo/en/partecipa.html Best Regards, Gustavo Marfia, PhD Postdoctoral Research Fellow Computer Science Department University of Bologna, Italy --0016363b9ce0800e3304a4191468 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear All,

to improve the quality= of civil and social life, take part in=A0Inventare il Futuro, the=A0
ideas competition laun= ched by the University of Bologna, Italy, with the contribution=A0
of the =93Fondazione d= el Monte di Bologna e Ravenna=94.

The compe= tition is open to young people who, on the competition deadline, fulfil the= =A0
following requirements= :

- Max. age 30 (you must not yet have turned 31);
- You must be enrolled= to a study programme at, or have graduated from, a university=A0
in the European Union.=

The ideas= presented must be prevalently based on digital technologies, and must=A0
fall into one of the f= ollowing fields of application:

  • City and citizens;
  • Health and the Environment;
  • Children, the = Third Age, Disability;
  • Education;
  • Media, Arts, Entertainment.
    • The first prize, for each field of application, is of 7000 E= uro.
    More in= formation may be found at:

    = Best Regards,

    <= /font>
    =
    Gustavo Marfia, PhD
    Postdoctoral Research Fellow
    Computer Sci= ence Department
    University of Bologna, Italy
    --0016363b9ce0800e3304a4191468-- From haas@ece.cornell.edu Wed May 25 07:47:17 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A102130061 for ; Wed, 25 May 2011 07:47:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT+UHvaqDzf2 for ; Wed, 25 May 2011 07:47:16 -0700 (PDT) Received: from smtp.ece.cornell.edu (odin.ece.cornell.edu [128.84.81.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1A6130056 for ; Wed, 25 May 2011 07:47:15 -0700 (PDT) Received: from MOBILE3 (215.sub-69-97-205.myvzw.com [69.97.205.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.ece.cornell.edu (Postfix) with ESMTP id 3D01054004B; Wed, 25 May 2011 10:47:14 -0400 (EDT) Date: Mon, 23 May 2011 10:46:58 -0400 (Eastern Daylight Time) From: zhaas To: manet@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: haas@imap.ece.cornell.edu MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; boundary="===============7010688644060376636==" Subject: Re: [manet] "Inventare il Futuro" Contest X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:47:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============7010688644060376636== Content-Type: TEXT/Plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >From a recent posting: > > If you have an innovative idea involving new technologies which > could contribute to improve the quality of civil and social life, > take part in *Inventare il Futuro*, the ideas competition launched > by the University of Bologna, Italy, with the contribution > of the “Fondazione del Monte di Bologna e Ravenna”. > > The competition is open to young people who, on the competition > deadline, fulfil the following requirements: > > - Max. age 30 (you must not yet have turned 31); Yes, the world belongs to the young people ... no one is interested in hearing from us, the "old folks" about "il Futuro" ... (;-). Sorry, could not resist (:-) ... Zygmunt. ==--==-=-== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Dr. Zygmunt J. Haas http://people.ece.cornell.edu/haas Professor School of Electrical Engineering Wireless Networks Laboratory, Director http://wnl.ece.cornell.edu Cornell University tel: +1-607-255-3454 324 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 U.S.A e-mail: haas(at)ece(dot)cornell(dot)edu WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ "I would found an institution where any person could find instruction in any study." - Ezra Cornell, 1868 --===============7010688644060376636==-- From ulrich@herberg.name Thu May 26 01:37:33 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D1DE06E0 for ; Thu, 26 May 2011 01:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab6u81kq5zE7 for ; Thu, 26 May 2011 01:37:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF1CE06B7 for ; Thu, 26 May 2011 01:37:31 -0700 (PDT) Received: by vws12 with SMTP id 12so435909vws.31 for ; Thu, 26 May 2011 01:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x1LqMkIyTE7yti/FljmmRRG/tbJNK4ilITMY+bdO0Uo=; b=JvVFmlBDNtQAHlutkh820UTytbnU5AXVo4seeQP2LxW8bmkcCAJcrJmK7fYINoQsZw tNStJXXwitS7HzbI1X2fTIE4odDanFIN453yjSL3+xhZceTZowENvQ4iGF22JVbMvdlH pScYOzpaFezetYUiAMDQsy7/g7rWkfEQfV3pk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=1IGwMdlOVp9Pl4THviEXYRbP/4t9XK9k9QWuNfamaoDWZzi8zZH1hhvnTW3vWe/msg SlpE6bbFUEhMtH446WMyNNqDfuG6IMAUlVNKfHa0xOUbAWuooJkZ4A+cwMC6hsutuRWk vlTJfGIHUBIxmpsKrLNP4+T1WOEVXnt37HpnQ= MIME-Version: 1.0 Received: by 10.220.9.8 with SMTP id j8mr195411vcj.228.1306399050541; Thu, 26 May 2011 01:37:30 -0700 (PDT) Received: by 10.220.158.138 with HTTP; Thu, 26 May 2011 01:37:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 May 2011 10:37:30 +0200 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=bcaec54eecd657abc704a429bbd8 Cc: MANET IETF , Thomas Heide Clausen Subject: Re: [manet] packetbb-sec WGLC comments (was: Re: WG adoption of NHDP-sec) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:37:33 -0000 --bcaec54eecd657abc704a429bbd8 Content-Type: text/plain; charset=ISO-8859-1 Chris, after some more discussions between the authors of packetbb-sec, we can agree with your point of view. We will work on a new revision, which we will submit soon. Regards Ulrich On Tue, May 24, 2011 at 5:34 PM, Ulrich Herberg wrote: > Chris, > > sorry for the late reply, I was very busy these last weeks ;-) > > On Thu, Apr 21, 2011 at 5:17 PM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> Brief version: I think there's a two part change that should >> be included before finishing WGLC. >> >> My apologies in advance in that should this spark a discussion, >> I'll be out of the loop for a week and a half and no able to >> contribute. (The UK is largely shutting down, we have for a >> combination of rare reasons, two four day weekends, with a >> three day gap. Many of us are taking those three days off too.) >> >> My main concern over this document is that it specifies a >> signature as the composition of a hash function and a >> cryptographic function, in that order. There are other ways >> of constructing signatures that do not correspond to such >> a decomposition. >> > > I agree that there other ways of constructing signatures. In your case, > couldn't you just select the identity function as hash function and then > only use the cryptographic function for creating the signature (i.e. > chris_special_signature_function(id(message)) )? > > If that is not suitable, of course, a new type extension could be used: > > >> >> The obvious response to that is to pick a new type extension >> for such. > > > yes > > >> This can't be normative text in this document, but >> I think it should be described in the applicability statement, >> which should say that this specification describes a general >> approach to signatures (much of the document, such as how to >> traety hop counts/limits is not specific to this decomposition) >> and then a specific approach to signatures, and should provide >> the comment that other mathematical forms of signature are >> possible, and should be handled by use of alternative type >> extensions. In the main body of the specification, a bit more >> clarity on what is form-specific and what is not would then >> help. >> > > Yes, I agree to that and will update the text accordingly. > > >> >> This then leads to the question a to whether the form described >> should be the privileged type extension = 0 case. Actually I >> would suggest it should be type extension = 1, with 0 reserved >> for "I'm not providing any information on algorithms, this is >> defined out of band, not in each packet. The reason I suggest >> that as type 0 (and including it in this document) is that it >> puts the two lowest-overhead options together (type extension 0, >> which can be omitted, and no algorithm information). >> >> Note that for timestamp, what other type extensions may be is >> alraedy covered, but not so for signatures, and timestamp uses >> the type extension 0 for the analogous case I suggest for type >> extension 0 for signature, i.e. detertmined otherwise (should >> the phrase "administrative action" be used in both cases?) >> > > I see your point. However, I am not convinced that the additional overhead > of setting the type extension for the proposed decomposition into > hash+crypto is desirable. Most signatures mechanisms that I am aware of use > this decomposition. There are certainly other ways of calculating a > signature, but sending an additional octet in every message for these -- at > least currently -- rare cases needs to be justified. As for timestamps, I > don't see one single prevalent way of representing a timestamp, which is why > we use the type extension 0 for a general case. > > Ulrich > > >> >> I think there should be another iteration before going to >> SECDIR and IESG, as I think it will avoid work further down the >> line, as well as being a better specification this way. >> >> -- >> Christopher Dearlove >> Technology Leader, Communications Group >> Communications and Networks Capability >> 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 Joe Macker >> Sent: 07 April 2011 17:17 >> To: MANET IETF >> Subject: [manet] WG adoption of NHDP-sec >> >> >> *** 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. >> >> >> As discussed in Prague we are presently considering adoption of NHDP >> security related document as a WG document. >> >> reference is draft-herberg-manet-nhdp-sec-01 >> >> Please comment if you have an opinion. >> >> -Joe >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> 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 > > --bcaec54eecd657abc704a429bbd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chris,

    after some more discussions between the authors of packetbb-s= ec, we can agree with your point of view. We will work on a new revision, w= hich we will submit soon.

    Regards
    Ulrich

    On Tue, May 24, 2011 at 5:34 PM, Ulrich Herberg <ulrich@herberg.name> wrote:=
    Chris,

    sorry for the late reply, I was very busy these last weeks ;-= )

    On Thu, Apr 21, 2011 at 5:17 PM, Dearlo= ve, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:
    Brief version: I think there's a two par= t change that should
    be included before finishing WGLC.

    My apologies in advance in that should this spark a discussion,
    I'll be out of the loop for a week and a half and no able to
    contribute. (The UK is largely shutting down, we have for a
    combination of rare reasons, two four day weekends, with a
    three day gap. Many of us are taking those three days off too.)

    My main concern over this document is that it specifies a
    signature as the composition of a hash function and a
    cryptographic function, in that order. There are other ways
    of constructing signatures that do not correspond to such
    a decomposition.

    I agree that there other ways of = constructing signatures. In your case, couldn't you just select the ide= ntity function as hash function and then only use the cryptographic functio= n for creating the signature (i.e. chris_special_signature_function(id(mess= age)) )?

    If that is not suitable, of course, a new type extension could be used:=
    =A0

    The obvious response to that is to pick a new type extension
    for such.

    yes
    =A0
    This can't be normative text in this document,= but
    I think it should be described in the applicability statement,
    which should say that this specification describes a general
    approach to signatures (much of the document, such as how to
    traety hop counts/limits is not specific to this decomposition)
    and then a specific approach to signatures, and should provide
    the comment that other mathematical forms of signature are
    possible, and should be handled by use of alternative type
    extensions. In the main body of the specification, a bit more
    clarity on what is form-specific and what is not would then
    help.

    Yes, I agree to that and will update the tex= t accordingly.
    =A0

    This then leads to the question a to whether the form described
    should be the privileged type extension =3D 0 case. Actually I
    would suggest it should be type extension =3D 1, with 0 reserved
    for "I'm not providing any information on algorithms, this is
    defined out of band, not in each packet. The reason I suggest
    that as type 0 (and including it in this document) is that it
    puts the two lowest-overhead options together (type extension 0,
    which can be omitted, and no algorithm information).

    Note that for timestamp, what other type extensions may be is
    alraedy covered, but not so for signatures, and timestamp uses
    the type extension 0 for the analogous case I suggest for type
    extension 0 for signature, i.e. detertmined otherwise (should
    the phrase "administrative action" be used in both cases?)

    I see your point. However, I am not convinced that the a= dditional overhead of setting the type extension for the proposed decomposi= tion into hash+crypto is desirable. Most signatures mechanisms that I am aw= are of use this decomposition. There are certainly other ways of calculatin= g a signature, but sending an additional octet in every message for these -= - at least currently -- rare cases needs to be justified. As for timestamps= , I don't see one single prevalent way of representing a timestamp, whi= ch is why we use the type extension 0 for a general case.

    Ulrich
    =A0

    I think there should be another iteration before going to
    SECDIR and IESG, as I think it will avoid work further down the
    line, as well as being a better specification this way.

    --
    Christopher Dearlove
    Technology Leader, Communications Group
    Communications and Networks Capability
    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-bou= nces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
    Of Joe Macker
    Sent: 07 April 2011 17:17
    To: MANET IETF
    Subject: [manet] WG adoption of NHDP-sec


    =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.


    As discussed in Prague we are presently considering adoption of NHDP
    security related document as a WG document.

    reference is draft-herberg-manet-nhdp-sec-01

    Please comment if you have an opinion.

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


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


    --bcaec54eecd657abc704a429bbd8-- From eeeesti@gmail.com Thu May 26 13:24:33 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011E8E0721 for ; Thu, 26 May 2011 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx3wx5SxlCaw for ; Thu, 26 May 2011 13:24:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D452E0696 for ; Thu, 26 May 2011 13:24:32 -0700 (PDT) Received: by yxk30 with SMTP id 30so614420yxk.31 for ; Thu, 26 May 2011 13:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=LBYOLa42i9H5bkeDUHcqLYXNIaG1mHNBSnHygGL0DKA=; b=TnxwjnZctMtsSHnNWAS1OqlIeJGQ+pex/nCPe5iG9JnvwCHkprVLRM8XCC3DzEDW9D XWxHPHk+SuLzOjb+DZZcEhF1gUobU98rhGgakFJbiwqkcnLUAAviW9HoJSVC+mkqnAZR R61HnqNW+PaRmiqsS+asWbbPtBWocwRN0cUzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=kAwylQfWGTrH97pozay8w9F0XLZQmpQdkz7uK+XjoUBbFAYPNUF0lq4Ds5bUPQM7EP 50DCTTZpPIOjRrKujxPxgoI4seS1aQW7TOGcdnnHH9GAHqYM5W49dmHTTOAhTYJZ3NRx 0gBhc1lOV3ZVZXbY12A2BVfzGtVin67MiH68E= Received: by 10.236.176.36 with SMTP id a24mr1839340yhm.284.1306441471616; Thu, 26 May 2011 13:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.35.16 with HTTP; Thu, 26 May 2011 13:16:26 -0700 (PDT) From: Sergio Correia Date: Thu, 26 May 2011 17:16:26 -0300 Message-ID: To: IETF MANET Content-Type: multipart/alternative; boundary=20cf303b3cc1d5e79c04a4339b20 Subject: [manet] Status of DYMO draft? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 20:24:33 -0000 --20cf303b3cc1d5e79c04a4339b20 Content-Type: text/plain; charset=ISO-8859-1 Hello folks, what's the current status of the DYMO protocol? The latest published draft (#21) expired a few months ago and I couldn't find much recent activity on this mail list regarding it. Has it been obsoleted/replaced or something like that? thanks, sergio --20cf303b3cc1d5e79c04a4339b20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello folks,

    what's the current status of the DYMO p= rotocol? The latest published draft (#21) expired a few months ago and I co= uldn't find much recent activity on this mail list regarding it. Has it= been obsoleted/replaced or something like that?

    thanks,
    sergio

    --20cf303b3cc1d5e79c04a4339b20-- From jpmacker@gmail.com Thu May 26 14:41:55 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F39E06E1 for ; Thu, 26 May 2011 14:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+nBBEQhv+Ur for ; Thu, 26 May 2011 14:41:54 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54C25E0694 for ; Thu, 26 May 2011 14:41:54 -0700 (PDT) Received: by wyb29 with SMTP id 29so952435wyb.31 for ; Thu, 26 May 2011 14:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=uxDYF0AeMqJFe6yOhPih/+Q4mIKsskgxaDkRLzY6Qrc=; b=drxx6ROTs5B1vXfDB1jMrl/7Mp33sLXp/ucjWBNDMBTdmm4jjCtVLCmMGzRBz2bASC uYVTL/Pa9HsJQHnl21gHDf7ZrY65GpeK50gxl0nquEB3lc5eY0cdaaQjNzcMLYXGbq8K +ZvnBGetbfdyDUqzZBw/uURHN4zAajbT7Hh1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TCJYsBGW/2YJRjdd9BYXIAOZnJO3w9CDhSeCveCAjtk9XssO+nbm4SDGPFKiBgdoYo JkuUEPRBBj/bOFNzYRZ2ax+V1IXfl01uXnLJqdl1dbMXRntPHAH9z6gLuuhSw5AwyzYx jpjks5dmuHrqpwTkzQQEqupM/f3tLXJEQzd4Q= MIME-Version: 1.0 Received: by 10.216.255.206 with SMTP id j56mr6964546wes.39.1306446113224; Thu, 26 May 2011 14:41:53 -0700 (PDT) Received: by 10.216.173.199 with HTTP; Thu, 26 May 2011 14:41:53 -0700 (PDT) Date: Thu, 26 May 2011 17:41:53 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] WGLC results for packetbb-src X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:41:55 -0000 WGLC of draft-ietf-manet-packetbb-sec has ended on April 22. Christopher Dearlove had some issues with the draft, which will be addressed by the authors in a new revision. A new WGLC will then be initiated. -Joe From jpmacker@gmail.com Thu May 26 14:45:03 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577A0E075A for ; Thu, 26 May 2011 14:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DTYgmWB98HC for ; Thu, 26 May 2011 14:45:02 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E81BE06E1 for ; Thu, 26 May 2011 14:45:02 -0700 (PDT) Received: by wwk4 with SMTP id 4so4878730wwk.1 for ; Thu, 26 May 2011 14:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=eCw1CMVKUfAqH4QDFO0c9gbv7sZ27cUAmTILwAEJ6ws=; b=UZeZOyhoIljNvdnnpFbwdAiDgcEnyBn9iRU3dQpOGW4NClFEAJHwc48OLONSnF8qU5 eja55J9rztw0APSFVkndeAnC0QIN0Ndeycy+ZCWYOFBtZUiqHuYHDXUgB6JkHcgPK3cY /yVb9bh55NizZz6JGtLaXJj2YRG7enMJKyepA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SdxhnE5JKrlttGjKJNmhy5dIEiWGmtEjU0/Mww6KAvWJ4IstAd/TdEFqHle/GbAr6v 8wKrO5hx40pMwpsLVMakrAW60wXduISZwalysS7GlLJr8lglFouJS/1c2h2KBS8mGN7p M0Wfi4EG7mrOr5cNudAsaGHcU3/++yoATz73A= MIME-Version: 1.0 Received: by 10.216.241.132 with SMTP id g4mr1450632wer.9.1306446301544; Thu, 26 May 2011 14:45:01 -0700 (PDT) Received: by 10.216.173.199 with HTTP; Thu, 26 May 2011 14:45:01 -0700 (PDT) Date: Thu, 26 May 2011 17:45:01 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Status on WG adoption of draft-herberg-manet-nhdp-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:45:03 -0000 Since the WG discussion on this issue there was not much feedback on draft-herberg-manet-nhdp-sec. However, I encourage the authors to continue to work on the draft and I reencourage the WG to read the draft and to send any comments to the mailing list. At a later time, I will poll the WG again for adopting the document as WG draft. -Joe From jpmacker@gmail.com Thu May 26 14:47:46 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F48E0790 for ; Thu, 26 May 2011 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUPe01tI15wE for ; Thu, 26 May 2011 14:47:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E00AE0796 for ; Thu, 26 May 2011 14:47:45 -0700 (PDT) Received: by wyb29 with SMTP id 29so955196wyb.31 for ; Thu, 26 May 2011 14:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=hDl+yz2KqpbjkKLzWqXMbGMPUUE6N5Dj4yHDySDhzcE=; b=RuZ/chBRajvSfqejc3pZhUUT6u539nq2YTBa6gnZD7MYop7jgrXQRnXtCDuCbLqbIr 0hHb/bS+OOYJqExyeFZb+YYLfxKtt6DDF/0U385hSIZu+GINYBDGuON8XGg49/EtaD6Y 8EoSGepPyBZkT5tJrh1Ss4TZyVCvU00Yy+PAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uv2oB02Mrk7ZiejKgAuR0I5ebqqewhEcWQv0g4937vQ+63GtSfeM+cJx5yhtlGdkWK 8KGQo/UT1Wn2syHXpRvTpIqfWIXosiyWieOBuPve8EnaY9kH8eW2eqNhOmOz4oBXNvPH 3VLqBuYF1Xm3MwseBACG0GQQPO51AjYveP2fg= MIME-Version: 1.0 Received: by 10.216.231.198 with SMTP id l48mr361205weq.54.1306446464209; Thu, 26 May 2011 14:47:44 -0700 (PDT) Received: by 10.216.173.199 with HTTP; Thu, 26 May 2011 14:47:44 -0700 (PDT) Date: Thu, 26 May 2011 17:47:44 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Status of WGLC for SMF X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:47:46 -0000 The WGLC of draft-ietf-manet-smf has ended on April 22. Three reviews were submitted to the author (by Ulrich, Thomas and Jiazi). The reviews were mostly positive and addressed only minor nits and editorial issues, however there was an interpretation issue in a state table that was discovered and is being fixed. The authors will address these comments and submit a new revision soon, followed by a new WGLC. The document is being actively edited to include all comments and will be forwarded soon. I recommend to go forward with the document once the three reviewers are satisifed with the new revision during the new WGLC. From jpmacker@gmail.com Thu May 26 14:50:57 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961C8E07A8 for ; Thu, 26 May 2011 14:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhT9u+ZT+0SM for ; Thu, 26 May 2011 14:50:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D2E0793 for ; Thu, 26 May 2011 14:50:56 -0700 (PDT) Received: by wyb29 with SMTP id 29so956784wyb.31 for ; Thu, 26 May 2011 14:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=c+vhCNJbLrXCkON9qx2vgDkTgbX9/5NrIBCDqLel/i8=; b=QBw1grq2M4P0r/wTOaMN+HJ+UEJA0CTPjtU3ldcwWIVX6wO9ZVXrCh4EEbF5qsXENq uTdu8Omz0DcGu2ima4dMqZa4fi/s5wpSmNLSmjSkGUEuvrXzldFLvkimVQg9Mm4kutCD f3kpg44W0eBPixoRJCkYp2jIHBtz5Vyw4IqGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AYblETaOqvjpAq2HWG73CYLfZizeJ6xUlyxnvnY9FWWhIHNoI/c+1viPsSdfokgwYP JroyapUE+Hty6JXvnayR1oej70qro2tjo7pQuYfqNpUf+Ln56ON7f7MxbODUL2qLueGf f8KqhsQ4MQ5puLLh1oTkIuKSeG3uAUW424Dak= MIME-Version: 1.0 Received: by 10.216.65.203 with SMTP id f53mr6797571wed.54.1306446655863; Thu, 26 May 2011 14:50:55 -0700 (PDT) Received: by 10.216.173.199 with HTTP; Thu, 26 May 2011 14:50:55 -0700 (PDT) Date: Thu, 26 May 2011 17:50:55 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] WGLC Status for draft-ietf-manet-nhdp-mib X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 21:50:57 -0000 The WGLC of draft-ietf-manet-nhdp-mib has ended on May 6. Some comments were raised by Justin Dean, and the authors agreed to address the comments in a new revision. Once this revision is out, a new WGLC will be issued. -Joe From teco@inf-net.nl Fri May 27 06:20:10 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA35E06CE for ; Fri, 27 May 2011 06:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9IYd5mWuw94 for ; Fri, 27 May 2011 06:20:09 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90A93E0679 for ; Fri, 27 May 2011 06:20:08 -0700 (PDT) Received: by ewy19 with SMTP id 19so827232ewy.31 for ; Fri, 27 May 2011 06:20:07 -0700 (PDT) Received: by 10.14.100.195 with SMTP id z43mr790073eef.31.1306502407282; Fri, 27 May 2011 06:20:07 -0700 (PDT) Received: from [192.168.178.150] (524A158D.cm-4-3a.dynamic.ziggo.nl [82.74.21.141]) by mx.google.com with ESMTPS id c46sm1250374eei.3.2011.05.27.06.20.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 06:20:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> Date: Fri, 27 May 2011 15:20:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] Discussion about details of OLSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 13:20:10 -0000 It took some time to respond. Not because this subject has no priority. = In the contrary! Op 11 mei 2011, om 11:13 heeft Henning Rogge het volgende geschreven: > Hello, >=20 > since the new olsrv2 draft seems to be coming later, I would like to = open a=20 > discussion about some (in my opinion) important points of the current = OLSRv2=20 > and Linkmetric drafts.=20 >=20 > I would like to start with the link metric encoding. There are some = other=20 > important points, but we have to start somewhere. >=20 >=20 > Link metric encoding > -------------------- >=20 > 1) encoding range >=20 > The current metric draft does include the idea to allow metric path=20 > calculation in 32 bit integer, which will limit the range of a link = metric to=20 > 0 - 2^24-1. I support this idea, there are a lot of embedded devices = out there=20 > without floating point circuits and 64 bits. Ack. > But the compressed metric tlv suggested in the draft does limit the = link=20 > metric value to 16 - 1015808, which reduce the available range to = roughly 1 to=20 > 2^16. I highly prefer a change, which allows full range of 2^24. I have to = deal with network infrastructures, where links vary from multi-Gig to sub-kilo. = And link can have very different costs ($$$), shared/fdx, high loss/high = reliable, and high/no delay.=20 I need metric exchanges between different subsystems. This could be in = the=20 netwerk layer (e.g. OSPF-OLSR) or middleware (use network topology = info). I am able to map what I have in 2^24. 2^10 is hard. > I think this is a bad idea, the metric encoding should use as much = range as=20 > possible within the 24 bit. Ack, as explained above. > In additon to this it might be worthwile to add an uncompressed metric=20= > encoding (just a 3 byte integer), either by using the length field of = the=20 > metric TLV to change between the two formats or use a different TLV. Having multiple options in a single network is a bad idea. With 8-bits, we loose some granularity. I don't see this as a problem. This applies = to=20 the dimensionless additive metric only. > An uncompressed metric value would be a great tool to work on new = metrics in=20 > realworld networks without the influence of the compression function, = which=20 > simplifies debugging the behaviour of metrics. At the cost of overhead. We need averaging and hysteresis anyway, to=20 stabilize the network. This also helps loop prevention.=20 More on encoding: I prefer having values 1, 2, 3, ... 10. And integers = only.=20 > 2) link metric value 0 >=20 > I would like to hear the opinions of the working group about an = encoding for=20 > link metric 0. Its a common use case in protocols with multiplicative = metrics=20 > to have a metric value of 1, the inclusion of 0 into our metric range = would=20 > allow a similar feature in OLSRv2. With 2^24 range, a minimum value of 1 will do. I really want the = protocol=20 to work nicely on a high speed wired network (e.g. GB Ethernet). It must = be=20 able to select multi-GB over 1GB and 1-hop over multi-hop. > To get a stable dijkstra result most of our existing implementations = should=20 > already use a tie-breaker to choose between equal path costs in a = stable way,=20 > so a link cost of 0 should not add to the complexity of our = implementations. I don't think so. With multi-path and multi-hop zero-cost links, I think = tie- breakers easily break. > 3) link metric default value >=20 > The link metric draft suggests to set the default metric value = directly in the=20 > middle (logarithmic) of the metric range. >=20 > In my opinion this even further restricts the useful metric values. = The=20 > default link cost corresponds with the hopcount metric, which does not=20= > calculate metric values at all. Maybe we discuss different defaults. 1) OLSR messages without a metric, therefore the protocol uses a default=20= metric. 2) There is no information for getting metric data available, therefore = the=20 protocol uses a default metric. The metric draft discusses 1). It also says that if all nodes don't send=20= metrics, the result is exactly as it was before, with hopcount. I think you want to combine 1) and 2), because you want to use "useful=20= metrics" and discuss this in relation with the DEFAULT_METRIC value. > In practice I see a lot of reasons why I have links better than a = hopcount=20 > link and very few for links that have a higher cost. I see a lot of reasons for not using hopcount at all :-) More serious: your scenario is using a mix of defaults and specified = metric=20 values, right? And the default is used for nodes that are unaware of = link=20 type, rate, loss etc. The metric is used on nodes that have better = knowledge, or just assume something that is not default. But what prevents you to configure a high default, e.g. 2^20, for links = with=20 type "unknown"?=20 > If normal link metrics=20 > and hopcount metric should be able to work together, it would be = better to=20 > place the default link metric value in the upper range of the metric. We don't have hopcount metrics anymore. We may face nodes that are = unaware of=20 link type and therefore use a (configured or coded) default or the = OLSRv2 link=20 metric default (coded).=20 > My suggestion would be to use MAXIMUM_METRIC/16. The outcome should be an integer, OK? If we have a range of 1 to 2^24-1 (or somewhat nearby maximum value), I = think a default of 2^16, 65536 (or nearby), will do. Or the 2^20 as suggested = above. Thanks, Teco