From sratliff@cisco.com Fri Jun 3 09:24: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 6B26DE078D for ; Fri, 3 Jun 2011 09:24:59 -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=[AWL=0.000, 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 VM+QleKHQ4p4 for ; Fri, 3 Jun 2011 09:24:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A0718E078C for ; Fri, 3 Jun 2011 09:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=392; q=dns/txt; s=iport; t=1307118298; x=1308327898; h=message-id:from:to:in-reply-to:content-transfer-encoding: mime-version:subject:date:references; bh=g1haGUktxZFvlUqHtmtpLExgF4mhrQwxa8/Sn/4xxqM=; b=V08hGOE137A5u2LhiS06JyOPJDz3r1d7Q91Se3dxefd9ugbsuadnucCn j6k5v4Np2YAXpoNROMjnNj4snbvZH52fNOO31afHpuSd7+uRAPHK0wDvP /mChjQQ0a9rAQoshd44dekEVGaepYhOht8CEAoOnbFIiOH0byhaAO8w+0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM0J6U2tJXG8/2dsb2JhbABTpjp3q2CdcoYhBJB0j1U X-IronPort-AV: E=Sophos;i="4.65,315,1304294400"; d="scan'208";a="459373479" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 03 Jun 2011 16:24:57 +0000 Received: from dhcp-64-102-54-197.cisco.com (dhcp-64-102-54-197.cisco.com [64.102.54.197]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p53GOvnE015824 for ; Fri, 3 Jun 2011 16:24:57 GMT Message-Id: From: Stan Ratliff To: MANET IETF In-Reply-To: <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 3 Jun 2011 12:24:58 -0400 References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> X-Mailer: Apple Mail (2.936) Subject: [manet] DLEP 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, 03 Jun 2011 16:24:59 -0000 Hello everyone. The latest version of the DLEP draft - http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ was posted on May 2. As of this writing, there has been no discussion on the mailing list about the 01 version of the draft. Taking the optimistic viewpoint that there are no objections, I'll ask the group - Can we proceed to WGLC on this document? Regards, Stan From thomas.r.henderson@boeing.com Sat Jun 4 09:09: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 B626AE0675 for ; Sat, 4 Jun 2011 09:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 qhoPsw2mIvfe for ; Sat, 4 Jun 2011 09:09:57 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id B4716E0685 for ; Sat, 4 Jun 2011 09:09:57 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p54G9qlY018735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Jun 2011 09:09:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p54G9qMi014206; Sat, 4 Jun 2011 11:09:52 -0500 (CDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p54G9pZ5014199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sat, 4 Jun 2011 11:09:52 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Sat, 4 Jun 2011 09:09:51 -0700 From: "Henderson, Thomas R" To: "'Stan Ratliff'" , MANET IETF Date: Sat, 4 Jun 2011 09:09:50 -0700 Thread-Topic: [manet] DLEP Thread-Index: AcwiCtDHnwm0wY2XRleEBQpQT7qaygAu3gqA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEED7191E@XCH-NW-10V.nw.nos.boeing.com> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de><69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP 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, 04 Jun 2011 16:09:59 -0000 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Stan Ratliff > Sent: Friday, June 03, 2011 9:25 AM > To: MANET IETF > Subject: [manet] DLEP >=20 > Hello everyone. >=20 > The latest version of the DLEP draft - > http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > was posted on May 2. As of this writing, there has been no discussion > on the mailing list about the 01 version of the draft. Taking the > optimistic viewpoint that there are no objections, I'll ask the group > - Can we proceed to WGLC on this document? >=20 Stan and all, Sorry for the delay in reviewing the draft. I don't think it is ready for = WGLC because it doesn't seem complete enough to build interoperable impleme= ntations, and at least for the use cases that I'm thinking of applying it t= o (existing users of RFC 4938, and multi-channel DAMA-based systems), the f= eatures don't seem complete enough. I've previously raised a few initial questions that I think would be worthw= hile to try to discuss and come to consensus on. First, what would be the = overall document set necessary for vendors to build interoperable implement= ations? Since this document considers transport out of scope, it seems at = a minimum that this document plus some kind of transport profile (e.g. "DLE= P over UDP") would be the minimum. I also think that it will be the case t= hat future radio systems will need to extend DLEP; I would like to see the = document describe how DLEP is expected to be extended, and explicitly consi= der extensibility.=20 Second, besides TLV specifications, the document defines a basic point-to-p= oint session protocol, but it presently is not specified fully (e.g. no sta= te machine, not much detail in how exceptions are handled). This sort of p= rotocol must have been done many times before in the IETF (e.g. service dis= covery, neighbor discovery, DHCP, key management protocols) so I wonder whe= ther the working group should try to define a new one from scratch, or try = to find one that is close in functionality and well specified, and either r= un over that protocol or copy that protocol over as much as possible. It is not clear to me how it relates to RFC 4938/5578. I had thought that = DLEP was supposed to be a standards-track protocol to replace the (informat= ional) PPPoE-based protocol, but credit-based flow control is left out of t= his specification. =20 The draft is missing a terminology session. The terms "first-speaker" and = "passive-listener" could probably be replaced by "initiator" and "responder= " for consistency with other IETF terminology. The assumptions section should try to clarify some more details about scope= of applicability, such as any restrictions on how routers and radios are i= nterconnected that might require loop detection mechanisms, whether DLEP re= quires both sides (local and remote) to have active sessions (or can be app= lied only on one side of the link), whether DLEP requires that no reorderin= g occur between router and radio, and whether multicast is handled. It wasn't clear to me why sequence number 0 needs to be invalid. It wasn't= clear whether the protocol requires (enforces) that sequence numbers be mo= notonically increasing. The alignment of the TLVs seems to be on byte boundaries, leading to some o= dd-length TLVs. Many recent protocols have tried to align on larger bounda= ries for implementation convenience, and was wondering what drove you away = from the use of any padding (perhaps it was the concept of detached session= s that you introduced later, where over-the-air bandwidth needs to be conse= rved). The Router Id and Client Id seem to be used instead as session ids; should = they be renamed? If the intent is really to be router Ids, 4 bytes is not = large enough for all routing protocols, so I might suggest 6 bytes, which w= ould allow for use of mac addresses. It wasn't clear why there is a requirement for major and minor version numb= ers; I would suggest to remove this unless requirements are clear. Also, i= t seems like Version Sub-TLV ought to be mandatory in session initiation me= ssages. It wasn't clear why the detached peer discovery use case needed to be suppo= rted, and if so, whether it places additional requirements on the protocol = since the link between router and radio is no longer guaranteed to be highl= y available. Suggest to delete this option unless it has clear requirement= s. Is specific ordering of TLVs enforced or not? Also, it is probably suffici= ent to list the sub-TLVs when messages are specified (e.g. section 9.1) rat= her than enumerate all of their fields. =20 Should the sequence number in Peer Offer message echo the Discovery sequenc= e number, so that the Offer is associated with the right Discovery? It wasn't clear how the Peer Update procedure would work if the clients ign= ored the message because they didn't care about the layer 3 addresses. The= router may conclude that the session has failed if it kept retrying the Up= date that was being ignored at the modem. There seems to be normative elements of procedure (message sequences) in an= Appendix A; suggest to move these to the main body of the specification. = In general, other protocol specifications tend to define message formats an= d elements of procedure separately, but this draft seems to spread the elem= ents of procedure between the message formats and Appendix A sections. - Tom From Chris.Dearlove@baesystems.com Mon Jun 6 02:03:31 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 9B76D11E80D5 for ; Mon, 6 Jun 2011 02:03:31 -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 9ci9HuzWPHL9 for ; Mon, 6 Jun 2011 02:03:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id A80FB11E80D2 for ; Mon, 6 Jun 2011 02:03:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,325,1304290800"; d="scan'208";a="138209824" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 06 Jun 2011 10:03:29 +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 p5693TAm007873; Mon, 6 Jun 2011 10:03:29 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 10:03:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Jun 2011 10:03:27 +0100 Message-ID: In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEED7191E@XCH-NW-10V.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP Thread-Index: AcwiCtDHnwm0wY2XRleEBQpQT7qaygAu3gqAAFgq8CA= References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de><69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <7CC566635CFE364D87DC5803D4712A6C4CEED7191E@XCH-NW-10V.nw.nos.boeing.com> From: "Dearlove, Christopher (UK)" To: "Henderson, Thomas R" , "Stan Ratliff" , "MANET IETF" X-OriginalArrivalTime: 06 Jun 2011 09:03:29.0004 (UTC) FILETIME=[9A20E2C0:01CC2428] Subject: Re: [manet] DLEP 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, 06 Jun 2011 09:03:31 -0000 Thomas Henderson wrote: > The alignment of the TLVs seems to be on byte boundaries, > leading to some odd-length TLVs. That is due to using RFC 5444, rather than being introduced by DLEP. Even if TLV value fields are multiples of 2, 4 or whatever bytes, the actual start of the value field won't be so constrained. > Many recent protocols have tried to align on larger boundaries > for implementation convenience, and was wondering what drove you > away from the use of any padding (perhaps it was the concept of > detached sessions that you introduced later, where over-the-air > bandwidth needs to be conserved). 5444 was created for MANETs, which are most commonly wireless networks where bandwidth matters. There was creative tension, let's say, between people who regarded (and may still regard) it as being able to be made even more efficient, and people who were prepared to nake things simpler (for more than one definition of simpler) at the cost of some bytes. (There was also a third axis of flexibility.) The final result is a compromise in all these regards. ******************************************************************** 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 thomas.r.henderson@boeing.com Mon Jun 6 21:55: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 637D311E8070 for ; Mon, 6 Jun 2011 21:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 J-BsazIEUo7d for ; Mon, 6 Jun 2011 21:55:01 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F97E21F84B3 for ; Mon, 6 Jun 2011 21:55:01 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p574srvm012043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2011 21:54:53 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p574sqCM026226; Mon, 6 Jun 2011 23:54:52 -0500 (CDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p574sq1l026221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 6 Jun 2011 23:54:52 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Mon, 6 Jun 2011 21:54:51 -0700 From: "Henderson, Thomas R" To: "'Dearlove, Christopher (UK)'" , Stan Ratliff , MANET IETF Date: Mon, 6 Jun 2011 21:54:51 -0700 Thread-Topic: [manet] DLEP Thread-Index: AcwiCtDHnwm0wY2XRleEBQpQT7qaygAu3gqAAFgq8CAAKfBBMA== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEED7194F@XCH-NW-10V.nw.nos.boeing.com> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de><69CF2839-A 101-4D22-A16F-85E9F0CD2169@inf-net.nl> <7CC566635CFE364D87DC5803D4712A6C4CEED7191E@XCH-NW-10V.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18184.003 x-tm-as-result: No--63.922900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP 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, 07 Jun 2011 04:55:02 -0000 > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Sent: Monday, June 06, 2011 2:03 AM > To: Henderson, Thomas R; Stan Ratliff; MANET IETF > Subject: RE: [manet] DLEP >=20 > Thomas Henderson wrote: > > The alignment of the TLVs seems to be on byte boundaries, > > leading to some odd-length TLVs. >=20 > That is due to using RFC 5444, rather than being introduced by DLEP. > Even if TLV value fields are multiples of 2, 4 or whatever bytes, > the actual start of the value field won't be so constrained. >=20 > > Many recent protocols have tried to align on larger boundaries > > for implementation convenience, and was wondering what drove you > > away from the use of any padding (perhaps it was the concept of > > detached sessions that you introduced later, where over-the-air > > bandwidth needs to be conserved). >=20 > 5444 was created for MANETs, which are most commonly wireless > networks where bandwidth matters. There was creative tension, let's > say, between people who regarded (and may still regard) it as being > able to be made even more efficient, and people who were prepared > to nake things simpler (for more than one definition of simpler) > at the cost of some bytes. (There was also a third axis of > flexibility.) The final result is a compromise in all these regards. >=20 Thanks for the explanation; I didn't participate in developing 5444 and was= n't aware of that history (and didn't intend to open up any old debates wit= h my question). - Tom From adrian@olddog.co.uk Fri Jun 17 10:14: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 73B4521F84CC; Fri, 17 Jun 2011 10:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 MngzfUUrTBXq; Fri, 17 Jun 2011 10:14:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A9C6121F84CB; Fri, 17 Jun 2011 10:14:32 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5HHETD7014187; Fri, 17 Jun 2011 18:14:29 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5HHERFh014174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Jun 2011 18:14:28 +0100 From: "Adrian Farrel" To: Date: Fri, 17 Jun 2011 18:14:21 +0100 Message-ID: <17ca01cc2d12$003c39f0$00b4add0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwtEf5Rpfv0T+slSQ6Ey9RNK9cq5Q== Content-Language: en-gb Cc: manet-chairs@ietf.org Subject: [manet] Responsible AD for MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:14:33 -0000 Hi MANET, Just to let you know that Stewart and I are doing a bit of load balancing. We are moving this WG to my care. Looking forward to working with you. Adrian From itsme.rahulgoel@gmail.com Tue Jun 28 04:49:00 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 D5D3921F85E8 for ; Tue, 28 Jun 2011 04:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, 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 dKUpiFoKaEuG for ; Tue, 28 Jun 2011 04:49:00 -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 4F18121F85CB for ; Tue, 28 Jun 2011 04:49:00 -0700 (PDT) Received: by vws12 with SMTP id 12so96408vws.31 for ; Tue, 28 Jun 2011 04:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=96TlWWnPu2N5oRGB4P/GwyM4KFXE9EWvnkrAg8WVAoA=; b=j54QBkMoo1CEQ0Ql1cWybqns7xK5HtQKfblIiv812fQNsKckEkedNbXzlKif0pW9d3 2GrX/TBLgPw8Moax9HCzMZsMw5JrRJQCFo/m1O05S+Pk6uOmeqcCXouXjfxWHRsUlHAg NJHfXG88Sl2AhVhk6eEo2MX7WghzvUAclegYs= MIME-Version: 1.0 Received: by 10.220.130.135 with SMTP id t7mr2757896vcs.81.1309261739655; Tue, 28 Jun 2011 04:48:59 -0700 (PDT) Received: by 10.220.179.72 with HTTP; Tue, 28 Jun 2011 04:48:59 -0700 (PDT) Date: Tue, 28 Jun 2011 17:18:59 +0530 Message-ID: From: Rahul Goel To: manet@ietf.org Content-Type: multipart/alternative; boundary=e0cb4e887b57e9029e04a6c4403a X-Mailman-Approved-At: Tue, 28 Jun 2011 07:02:02 -0700 Subject: [manet] (no subject) 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, 28 Jun 2011 12:51:53 -0000 --e0cb4e887b57e9029e04a6c4403a Content-Type: text/plain; charset=ISO-8859-1 Hi, How is the TTL value of a RREQ in AODV decided and what decides the threshold value beyond which a RREQ is broadcast over the complete network? Regards, Rahul Goel --e0cb4e887b57e9029e04a6c4403a Content-Type: text/html; charset=ISO-8859-1 
Hi,
How is the TTL value of a RREQ in AODV decided and what decides the
threshold value beyond which a RREQ is broadcast over the complete
network?
Regards,
Rahul Goel
--e0cb4e887b57e9029e04a6c4403a-- From abdussalambaryun@gmail.com Tue Jun 28 09:02: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 D848421F85EA for ; Tue, 28 Jun 2011 09:02:23 -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 aTZJ29HapUDJ for ; Tue, 28 Jun 2011 09:02:23 -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 E007821F85E1 for ; Tue, 28 Jun 2011 09:02:22 -0700 (PDT) Received: by qwc23 with SMTP id 23so292334qwc.31 for ; Tue, 28 Jun 2011 09:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=RslbFqIx+29eLtuIW6hTltpnHomyBCU1lc9s9gYybLU=; b=fJouOO9zeOdQzyDuGeSEEOl4aaq4ydIyvAzfjFTw5R1EHFuLofT0Bb9MhzpBTS0q/k J0yyeQ7pAXZw8mjlAiJ7jdSagHD9Myiea8803y1DxaGBOjkq28CLF98aRqNWOj7N4MVY iVrveYFB8Se8u+zeQrdf77IbnArEiFpHlSO8U= MIME-Version: 1.0 Received: by 10.229.17.134 with SMTP id s6mr5515185qca.278.1309276942120; Tue, 28 Jun 2011 09:02:22 -0700 (PDT) Received: by 10.229.50.143 with HTTP; Tue, 28 Jun 2011 09:02:22 -0700 (PDT) Date: Tue, 28 Jun 2011 17:02:22 +0100 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: multipart/alternative; boundary=0015175cdf4e0c362a04a6c7cb91 X-Mailman-Approved-At: Tue, 28 Jun 2011 09:21:44 -0700 Subject: Re: [manet] DLEP 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, 28 Jun 2011 16:02:23 -0000 --0015175cdf4e0c362a04a6c7cb91 Content-Type: text/plain; charset=ISO-8859-1 *Hi Stan,* I have some comments, as below to some sections until 7.4 , I read so far Abdussalam ------------------------ In Abstract +++++++++++++ > in order to make forwarding decisions (recommend replace : decisions, to: and routing decisions) neighbour discover usually are updated at the routing, recommend to specify options: In mobile or fixed environments, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. (not clear because I think routers only decisions, they process the adaptive routing algorithm; maybe change to: accurate adaptive decisions) A bidirectional, event-driven communication channel between the router and the modem is necessary. (the reasons are not clear, why necessary this method only) recommend change to: necessary for correct adaptive routing...because of unpredicted events +++++++++++++++++++++++++++++++++++++++++++ In Introduction: >DLEP utilizes a session paradigm between the modem device and its >associated router. If multiple modem devices are attached to a >router, a separate DLEP session MUST exist for each modem. If a modem >device supports multiple connections to a router (via multiple >interfaces), or supports connections to multiple routers, a separate >DLEP session MUST exist for each connection. if there is only one channel DLEP for each peer why do we need two ID (client and router) as in 7.1 (not sure!) +++++++++++++++++++++++++++++++++++++++++++++ *In Assumption* ++++++++++++ *should* be the MAC address of the next-hop router or end- device, and not the MAC address of any of the intervening modem devices. (SHOULD) Some issues are not specified as the link assumptions and link's connectivity, as was mentioned in introduction different events of link, or environment, network size, etc. In 7.1 ++++++++++ "Peer Discovery" and "Peer Offer" messages described *below*. (please specify where, page or section). While reading through the messages format and packet it was difficult to relate them to their functionality, within the big picture, +++++++++++++++++++++++++++++++++++++++++++++ Thanking you Abdussalam --0015175cdf4e0c362a04a6c7cb91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stan,
=A0
I ha= ve some comments,=A0as below to some sections until 7.4 , I read so far
=A0
Abdu= ssalam
----= --------------------
=A0
In A= bstract
++++= +++++++++
>= in order to make forwarding decisions
(rec= ommend replace : decisions, to: and routing decisions)
neighbour discover usually are updated at the routing,
=A0
recommend to specify options: In mobile or fixed environments,=A0
=A0

manu= al configurations or the=A0 infere= nce of state through routing or transport protocols does not allow the rout= er to make the best decisions.

(not= clear because I think routers=A0only decisions, they process the adaptive = routing algorithm;=A0maybe change to: accurate adaptive decisions)

=A0

A bi= directional, event-driven communication channel between the router and the = modem is necessary. (the reasons are not clear, why necessary this method o= nly)
reco= mmend change to: necessary for correct adaptive routing...because of unpred= icted events
++++= +++++++++++++++++++++++++++++++++++++++
In I= ntroduction:

>= DLEP=A0utilizes a session paradigm between the modem device and its

>= associated router. If multiple modem devices are attached to a

>= router, a separate DLEP session MUST exist for each modem. If a modem

>= device supports multiple connections to a router (via multiple

>= interfaces), or supports connections to multiple routers, a separate=

>D= LEP session MUST exist for each connection.
=A0
if th= ere is only one channel DLEP for each peer why do we need two ID (client an= d router) as in 7.1 (not sure!)
+++++= ++++++++++++++++++++++++++++++++++++++++

In Assumption

++++++++++++=A0=

should<= /u> = be the MAC address of the next-hop router or end-

device, and not= the MAC address of any of the intervening modem

devices.=A0 (SH= OULD)

=A0

=A0Some issues are not specified as the link assumptions and link&#= 39;s connectivity, as was mentioned in introduction different events of lin= k, or environment, network size, etc.

=A0

In 7.1

++++++++++

"Peer Disc= overy" and "Peer Offer" messages described below. (pl= ease specify where, page or section).

=A0

While reading t= hrough the messages format and packet it was difficult to relate them to th= eir functionality, within the big picture,

=A0

+++++++++++++++= ++++++++++++++++++++++++++++++

Thanking you

Abdussalam

 --0015175cdf4e0c362a04a6c7cb91-- From sratliff@cisco.com Tue Jun 28 09:40:43 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 9060D11E8105 for ; Tue, 28 Jun 2011 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nkULeW-5fq7k for ; Tue, 28 Jun 2011 09:40:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id A608E11E8103 for ; Tue, 28 Jun 2011 09:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=26160; q=dns/txt; s=iport; t=1309279242; x=1310488842; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=PWEl/eDWFaScZzIkXwSfnbL0ojaafZ0AMfbdKAoOPYs=; b=LX73oONafGxa345hwNTzYGoKqJNPCIHEKapPkIZyH6k28+LOwTEbqrHP k8zZ1Q1OKiwDQyq2n5t68Scp8JcOiPwj6d+XUHfPeUq454J0ur1X6uEQA VSWASq9EuEKrWNssnq9p4+I+t3HZM+6cmphyzJXuSwW5SatV3xef61dAb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMYDCk6tJXG+/2dsb2JhbABSglGkb3eId6I8nimGMASSEJA9 X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208,217";a="471395950" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2011 16:40:41 +0000 Received: from dhcp-64-102-54-112.cisco.com (dhcp-64-102-54-112.cisco.com [64.102.54.112]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5SGeeOJ026378; Tue, 28 Jun 2011 16:40:41 GMT Message-Id: <69031682-3193-4793-895B-393AEFA94740@cisco.com> From: Stan Ratliff To: Abdussalam Baryun In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-74-259559347 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 28 Jun 2011 12:40:40 -0400 References: X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP 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, 28 Jun 2011 16:40:43 -0000 --Apple-Mail-74-259559347 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks for your comments. I'm working on an update to the draft. No ETA yet. Regards, Stan On Jun 28, 2011, at 12:02 PM, Abdussalam Baryun wrote: > Hi Stan, > > I have some comments, as below to some sections until 7.4 , I read > so far > > Abdussalam > ------------------------ > > In Abstract > +++++++++++++ > > in order to make forwarding decisions > (recommend replace : decisions, to: and routing decisions) > neighbour discover usually are updated at the routing, > > recommend to specify options: In mobile or fixed environments, > > manual configurations or the inference of state through routing or > transport protocols does not allow the router to make the best > decisions. > (not clear because I think routers only decisions, they process the > adaptive routing algorithm; maybe change to: accurate adaptive > decisions) > > A bidirectional, event-driven communication channel between the > router and the modem is necessary. (the reasons are not clear, why > necessary this method only) > recommend change to: necessary for correct adaptive > routing...because of unpredicted events > +++++++++++++++++++++++++++++++++++++++++++ > In Introduction: > >DLEP utilizes a session paradigm between the modem device and its > >associated router. If multiple modem devices are attached to a > >router, a separate DLEP session MUST exist for each modem. If a modem > >device supports multiple connections to a router (via multiple > >interfaces), or supports connections to multiple routers, a separate > >DLEP session MUST exist for each connection. > > if there is only one channel DLEP for each peer why do we need two > ID (client and router) as in 7.1 (not sure!) > +++++++++++++++++++++++++++++++++++++++++++++ > In Assumption > ++++++++++++ > should be the MAC address of the next-hop router or end- > device, and not the MAC address of any of the intervening modem > devices. (SHOULD) > > Some issues are not specified as the link assumptions and link's > connectivity, as was mentioned in introduction different events of > link, or environment, network size, etc. > > In 7.1 > ++++++++++ > "Peer Discovery" and "Peer Offer" messages described below. (please > specify where, page or section). > > While reading through the messages format and packet it was > difficult to relate them to their functionality, within the big > picture, > > +++++++++++++++++++++++++++++++++++++++++++++ > Thanking you > Abdussalam > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-74-259559347 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks for your comments. I'm = working on an update to the draft. No ETA = yet. 

Regards,
Stan

=

On Jun 28, 2011, at 12:02 PM, Abdussalam Baryun = wrote:

Hi Stan,
=
 
I = have some comments, as below to some sections until 7.4 , I read so = far
 
Abdussalam
------------------------
 
In = Abstract
+++++++++++++
> in order to make forwarding = decisions
(recommend replace : decisions, to: = and routing decisions)
neighbour discover usually are updated at the = routing,
 
recommend to specify options: In mobile = or fixed environments, 
 

manual configurations or the  inference of state through routing or transport = protocols does not allow the router to make the best = decisions.
(not clear because I think routers only decisions, they = process the adaptive routing algorithm; maybe change to: accurate = adaptive decisions)

 

A = bidirectional, event-driven communication channel between the router and = the modem is necessary. (the reasons are not clear, why necessary this = method only)
recommend change to: necessary for = correct adaptive routing...because of unpredicted events
=
+++++++++++++++++++++++++++++++++++++++++++
In Introduction:
>DLEP utilizes a session paradigm between the modem = device and its
>associated router. If multiple modem devices are attached to = a
>router, a separate DLEP session MUST exist for each modem. If = a modem
>device supports multiple connections to a router (via = multiple
>interfaces), or supports connections to multiple routers, a = separate
>DLEP session MUST exist for each = connection.
 
if there is only = one channel DLEP for each peer why do we need two ID (client and router) = as in 7.1 (not sure!)
+++++++++++++++++++++++++++++++++++++++++++++
In Assumption
++++++++++++ 
should = be the MAC address of the next-hop router or end-
device, and not the MAC address of any = of the intervening modem
devices.  (SHOULD)

 

 Some issues are not specified as the link assumptions and link's = connectivity, as was mentioned in introduction different events of link, = or environment, network size, etc.

 

In 7.1
++++++++++
"Peer Discovery" and "Peer Offer" = messages described below. (please specify where, page or = section).

 

While reading through the messages format and = packet it was difficult to relate them to their functionality, within = the big picture,

 

+++++++++++++++++++++++++++++++++++++++++++++
Thanking you
Abdussalam
=
= _______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail-74-259559347-- From reller@cococorp.com Tue Jun 28 11:04:52 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 F40D911E80F4 for ; Tue, 28 Jun 2011 11:04:51 -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 epq+X48YFX+V for ; Tue, 28 Jun 2011 11:04:49 -0700 (PDT) Received: from im2.namehub.com (im2.namehub.com [64.70.94.14]) by ietfa.amsl.com (Postfix) with ESMTP id D122611E808C for ; Tue, 28 Jun 2011 11:04:49 -0700 (PDT) Received: from ([64.70.67.188]) by im2.namehub.com with ESMTP with TLS id DZY0FN1.137523041; Tue, 28 Jun 2011 11:01:45 -0700 Received: from EXCASUM03.exchhosting.com (192.168.11.203) by exhub04.exchhosting.com (192.168.11.100) with Microsoft SMTP Server (TLS) id 8.2.213.0; Tue, 28 Jun 2011 11:01:46 -0700 Received: from EXMBX13.exchhosting.com ([fe80:0000:0000:0000:0034:7540:105.137.123.141]) by EXCASUM03.exchhosting.com ([192.168.11.203]) with mapi; Tue, 28 Jun 2011 11:01:44 -0700 From: "A. Riley Eller" To: Stan Ratliff , MANET IETF Date: Tue, 28 Jun 2011 11:01:44 -0700 Thread-Topic: [manet] DLEP Thread-Index: AcwiCwx/cRy4I+n3QFKe6yWIFsr/jwTsHVWA Message-ID: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP 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, 28 Jun 2011 18:04:52 -0000 Hello, I've been on the list for a while and mostly tried to learn from what is be= ing said but, based on increasing experience with military radios, I wonder= : is there time to ask for an EFT Sub-TLV for DLEP? This question has been = bouncing around MIT/LL and associated technology development labs. I apolog= ize in advance if my query is in poor form. My reasoning: 1. DLEP aims to make standard radio to router interfaces (R2RI), a primary = value proposition for multi-radio platforms. Even in single-radio platforms= , it is the interface standard that would permit component and vendor repla= cement or upgrade. 2. 7.11 Relative Link Quality value is under-specified and cannot be tested= except for nonzero value. 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. 4. 7.9 does not mandate the latency computation. 5. The EFT method is effective at answering all of these problems, and has = been tested by members of this list. Thank you for your consideration, A Riley Eller CoCo Communications=20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: Friday, June 03, 2011 9:25 AM To: MANET IETF Subject: [manet] DLEP Hello everyone. The latest version of the DLEP draft - http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ was posted on May 2. As of this writing, there has been no discussion =20 on the mailing list about the 01 version of the draft. Taking the =20 optimistic viewpoint that there are no objections, I'll ask the group =20 - Can we proceed to WGLC on this document? Regards, Stan _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Jun 28 19:21: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 84F0B9E8010 for ; Tue, 28 Jun 2011 19:21:58 -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 c+W3egmq8PFc for ; Tue, 28 Jun 2011 19:21:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id DA5819E8004 for ; Tue, 28 Jun 2011 19:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2103; q=dns/txt; s=iport; t=1309314117; x=1310523717; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=RaZt80XDRvBZbp6dG9cR39QSOwL7i8KXO9wKj0CBmhM=; b=YP+0Gvvp1xNWwoer1XTs98c9tnbaryZ++7pVALYTrWq36wF76GlUeX/4 qSwOoYP5zyNlDN05dtI6YUdzITHRb9of2+iV+0umewOFxAEJwXjLZNAnX ls9fKFBLW1r/icn2+FwgEn3LdMCeE75lYEVvGVVgC4IM3aoCMHl3JNmvL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAALSLCk6tJV2d/2dsb2JhbABSmBGPOXeIeKIUnX+GMASSF5BF X-IronPort-AV: E=Sophos;i="4.65,441,1304294400"; d="scan'208";a="471704292" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2011 02:21:57 +0000 Received: from rtp-sratliff-8712.cisco.com (rtp-sratliff-8712.cisco.com [10.116.179.211]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5T2LuLL012118; Wed, 29 Jun 2011 02:21:56 GMT Message-Id: From: Stan Ratliff To: "A. Riley Eller" In-Reply-To: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 28 Jun 2011 22:21:55 -0400 References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> X-Mailer: Apple Mail (2.936) Cc: MANET IETF Subject: Re: [manet] DLEP 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, 29 Jun 2011 02:21:58 -0000 Is there time? Yes, of course. I'm going to show my ignorance here; I haven't heard about the EFT method. Can you please give me some explanation/background? Regards, Stan On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: > Hello, > > I've been on the list for a while and mostly tried to learn from > what is being said but, based on increasing experience with military > radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? > This question has been bouncing around MIT/LL and associated > technology development labs. I apologize in advance if my query is > in poor form. > > My reasoning: > 1. DLEP aims to make standard radio to router interfaces (R2RI), a > primary value proposition for multi-radio platforms. Even in single- > radio platforms, it is the interface standard that would permit > component and vendor replacement or upgrade. > 2. 7.11 Relative Link Quality value is under-specified and cannot be > tested except for nonzero value. > 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. > 4. 7.9 does not mandate the latency computation. > 5. The EFT method is effective at answering all of these problems, > and has been tested by members of this list. > > > Thank you for your consideration, > > A Riley Eller > CoCo Communications > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf Of Stan Ratliff > Sent: Friday, June 03, 2011 9:25 AM > To: MANET IETF > Subject: [manet] DLEP > > Hello everyone. > > The latest version of the DLEP draft - > http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > was posted on May 2. As of this writing, there has been no discussion > on the mailing list about the 01 version of the draft. Taking the > optimistic viewpoint that there are no objections, I'll ask the group > - Can we proceed to WGLC on this document? > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From reller@cococorp.com Wed Jun 29 10:52: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 30B649E8052 for ; Wed, 29 Jun 2011 10:52:34 -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 WCkkzy4W3eDM for ; Wed, 29 Jun 2011 10:52:33 -0700 (PDT) Received: from namehub.com (im9.namehub.com [64.70.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4F89E804F for ; Wed, 29 Jun 2011 10:52:32 -0700 (PDT) Received: from ([64.70.67.188]) by im9.namehub.com with ESMTP with TLS id 96C1JJ1.278573066; Wed, 29 Jun 2011 10:52:26 -0700 Received: from EXCASUM03.exchhosting.com (192.168.11.203) by exhub08.exchhosting.com (192.168.11.106) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 29 Jun 2011 10:52:27 -0700 Received: from EXMBX13.exchhosting.com ([fe80:0000:0000:0000:0034:7540:105.137.123.141]) by EXCASUM03.exchhosting.com ([192.168.11.203]) with mapi; Wed, 29 Jun 2011 10:52:26 -0700 From: "A. Riley Eller" To: Stan Ratliff Date: Wed, 29 Jun 2011 10:52:24 -0700 Thread-Topic: [manet] DLEP Thread-Index: Acw2A1SymwYFRJZVRnGrqxuZmcJWdwAf7T5Q Message-ID: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MANET IETF Subject: Re: [manet] DLEP 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, 29 Jun 2011 17:52:34 -0000 Thank you for the consideration. Expected Forwarding Time (EFT)[1] represents what I believe to be the state= of the art in generating a meaningful cost function for links. The value r= epresents "typical latency between the arrival of a given packet at the tra= nsmitting device and that packet's reception at the other end of the link" = and so it combines transmission time, idle time, waiting time, freezing tim= e, and queuing time to the degree that those values are meaningful for a gi= ven medium. By encompassing the entire packet lifetime, it describes the in= teraction of transmission rate, packet delivery ratio (in acknowledged, ret= ransmitting links), contention in the local area, router load, and potentia= lly traffic priority. The last of those depends upon whether the metric is = computed distinctly for different traffic classes, of course. It is not panacea, but it is a discrete unit of measure that aggregates wel= l across multiple media. This strength is in opposition to the inutility to= software developers of dimensionless RLQ. I have been using a scheme of my= own design (which amounts to nothing more than an integer approximation of= air time) to good effect for six years, but EFT is better. EFT represents = a milestone in both its efficacy and its comprehensibility. Regards, Riley [1] EFT: a high throughput routing metric for IEEE 802.11s wireless mesh ne= tworks, Islam et al., 13 March 2009, Institut TELECOM and Springer-Verlag 2009 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: Tuesday, June 28, 2011 7:22 PM To: A. Riley Eller Cc: MANET IETF Subject: Re: [manet] DLEP Is there time? Yes, of course. I'm going to show my ignorance here; I =20 haven't heard about the EFT method. Can you please give me some =20 explanation/background? Regards, Stan On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: > Hello, > > I've been on the list for a while and mostly tried to learn from =20 > what is being said but, based on increasing experience with military =20 > radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? =20 > This question has been bouncing around MIT/LL and associated =20 > technology development labs. I apologize in advance if my query is =20 > in poor form. > > My reasoning: > 1. DLEP aims to make standard radio to router interfaces (R2RI), a =20 > primary value proposition for multi-radio platforms. Even in single-=20 > radio platforms, it is the interface standard that would permit =20 > component and vendor replacement or upgrade. > 2. 7.11 Relative Link Quality value is under-specified and cannot be =20 > tested except for nonzero value. > 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. > 4. 7.9 does not mandate the latency computation. > 5. The EFT method is effective at answering all of these problems, =20 > and has been tested by members of this list. > > > Thank you for your consideration, > > A Riley Eller > CoCo Communications > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =20 > Behalf Of Stan Ratliff > Sent: Friday, June 03, 2011 9:25 AM > To: MANET IETF > Subject: [manet] DLEP > > Hello everyone. > > The latest version of the DLEP draft - > http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > was posted on May 2. As of this writing, there has been no discussion > on the mailing list about the 01 version of the draft. Taking the > optimistic viewpoint that there are no objections, I'll ask the group > - Can we proceed to WGLC on this document? > > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Wed Jun 29 13:05:07 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 CC8891F0C37 for ; Wed, 29 Jun 2011 13:05:07 -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 grDI6Y0nOqXh for ; Wed, 29 Jun 2011 13:05:07 -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 2868E1F0C3D for ; Wed, 29 Jun 2011 13:05:06 -0700 (PDT) Received: by ewy19 with SMTP id 19so659535ewy.31 for ; Wed, 29 Jun 2011 13:05:06 -0700 (PDT) Received: by 10.213.4.15 with SMTP id 15mr506220ebp.41.1309377905834; Wed, 29 Jun 2011 13:05:05 -0700 (PDT) Received: from [192.168.178.16] (524A158D.cm-4-3a.dynamic.ziggo.nl [82.74.21.141]) by mx.google.com with ESMTPS id f6sm1177667eef.14.2011.06.29.13.05.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 13:05:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Teco Boot In-Reply-To: Date: Wed, 29 Jun 2011 22:05:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: MANET IETF X-Mailer: Apple Mail (2.1084) Subject: [manet] Progress ??? 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, 29 Jun 2011 20:05:07 -0000 May I ask authors of WG documents to submit? I-D cut-off is July 11th. It would be nice if we have something on the table to read and discuss. If not, IMHO we don't need to meet f2f to make excuses. Nor discuss security and mibs for parked (dead?) protocols. Teco From abdussalambaryun@gmail.com Wed Jun 29 05:09:12 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 1988D21F8551 for ; Wed, 29 Jun 2011 05:09:12 -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=[AWL=0.001, 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 FNKkJFwdRvbz for ; Wed, 29 Jun 2011 05:09:11 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E79521F8550 for ; Wed, 29 Jun 2011 05:09:11 -0700 (PDT) Received: by qyk9 with SMTP id 9so3280392qyk.10 for ; Wed, 29 Jun 2011 05:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=efsD8Go6Y0g7XkxNiIQQ2qnuWxe8oCLEq/qGiVNTFHM=; b=uIXFSyDcs9ofWPCM08BoVP5jN1/XcBqqlqb58XyvChoCSBN79CB0N9vwn4sOiY35x+ 5+EJ1JGHfYIT1ihiPSNHxnkHvKa6TJbl0n3Qi8FF/HRIr+Vug01Ph/+yUXyYaqoyPsC+ GGee2hnFSzN7sYaHAWmUtwvG3yK7XHVZTwbnA= MIME-Version: 1.0 Received: by 10.229.14.194 with SMTP id h2mr469552qca.240.1309349350398; Wed, 29 Jun 2011 05:09:10 -0700 (PDT) Received: by 10.229.50.143 with HTTP; Wed, 29 Jun 2011 05:09:10 -0700 (PDT) Date: Wed, 29 Jun 2011 14:09:10 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 29 Jun 2011 15:02:31 -0700 Subject: Re: [manet] (no subject) 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, 29 Jun 2011 12:09:12 -0000 Hi Rahul >How is the TTL value of a RREQ in AODV decided and what decides >the threshold value beyond which a RREQ is broadcast over the completenetwork? Please read RFC3561 sections: 6.4, 6.12, and 10, the question answers are clear, Abdussalam From sratliff@cisco.com Thu Jun 30 09:40: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 E9A9011E8080 for ; Thu, 30 Jun 2011 09:40:57 -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=[AWL=0.000, 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 pGfgzz3m4reX for ; Thu, 30 Jun 2011 09:40:57 -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 50B3E11E807F for ; Thu, 30 Jun 2011 09:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4165; q=dns/txt; s=iport; t=1309452057; x=1310661657; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=3wxL+rTKqxT/39slsaZT4SECCysnaZiKpTaSdqCjDhg=; b=BrBM7fdYnpmh6XRa7VgwrIUbmZmwL/0ci7dRq30ptgtxhXRPHhjGuncj fPPHWd6sxvfVMegp6s0iI7tgQr1Zk99JpA0pyoOd8iAC8/1r8YEBYG5H8 nA/P3RrioxxnSYEkG41PDRS5v7Q72bx+t14LgXxqcUFbHIU4iQlvGseaN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAD6mDE6tJV2d/2dsb2JhbABSmCSPMneIeKFFnXyGMQSSL5BK X-IronPort-AV: E=Sophos;i="4.65,451,1304294400"; d="scan'208";a="288638963" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-4.cisco.com with ESMTP; 30 Jun 2011 16:40:56 +0000 Received: from dhcp-64-102-54-112.cisco.com (dhcp-64-102-54-112.cisco.com [64.102.54.112]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5UGeugG026312; Thu, 30 Jun 2011 16:40:56 GMT Message-Id: <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> From: Stan Ratliff To: "A. Riley Eller" In-Reply-To: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 30 Jun 2011 12:40:56 -0400 References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> X-Mailer: Apple Mail (2.936) Cc: MANET IETF Subject: Re: [manet] DLEP 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, 30 Jun 2011 16:40:58 -0000 Riley, Thank you for the explanation. Just playing devil's advocate here - couldn't EFT be expressed as a better, more accurate definition of latency? Regards, Stan On Jun 29, 2011, at 1:52 PM, A. Riley Eller wrote: > Thank you for the consideration. > > Expected Forwarding Time (EFT)[1] represents what I believe to be > the state of the art in generating a meaningful cost function for > links. The value represents "typical latency between the arrival of > a given packet at the transmitting device and that packet's > reception at the other end of the link" and so it combines > transmission time, idle time, waiting time, freezing time, and > queuing time to the degree that those values are meaningful for a > given medium. By encompassing the entire packet lifetime, it > describes the interaction of transmission rate, packet delivery > ratio (in acknowledged, retransmitting links), contention in the > local area, router load, and potentially traffic priority. The last > of those depends upon whether the metric is computed distinctly for > different traffic classes, of course. > > It is not panacea, but it is a discrete unit of measure that > aggregates well across multiple media. This strength is in > opposition to the inutility to software developers of dimensionless > RLQ. I have been using a scheme of my own design (which amounts to > nothing more than an integer approximation of air time) to good > effect for six years, but EFT is better. EFT represents a milestone > in both its efficacy and its comprehensibility. > > Regards, > > Riley > > > [1] EFT: a high throughput routing metric for IEEE 802.11s wireless > mesh networks, Islam et al., 13 March 2009, > Institut TELECOM and Springer-Verlag 2009 > > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: Tuesday, June 28, 2011 7:22 PM > To: A. Riley Eller > Cc: MANET IETF > Subject: Re: [manet] DLEP > > Is there time? Yes, of course. I'm going to show my ignorance here; I > haven't heard about the EFT method. Can you please give me some > explanation/background? > > Regards, > Stan > > > On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: > >> Hello, >> >> I've been on the list for a while and mostly tried to learn from >> what is being said but, based on increasing experience with military >> radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? >> This question has been bouncing around MIT/LL and associated >> technology development labs. I apologize in advance if my query is >> in poor form. >> >> My reasoning: >> 1. DLEP aims to make standard radio to router interfaces (R2RI), a >> primary value proposition for multi-radio platforms. Even in single- >> radio platforms, it is the interface standard that would permit >> component and vendor replacement or upgrade. >> 2. 7.11 Relative Link Quality value is under-specified and cannot be >> tested except for nonzero value. >> 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. >> 4. 7.9 does not mandate the latency computation. >> 5. The EFT method is effective at answering all of these problems, >> and has been tested by members of this list. >> >> >> Thank you for your consideration, >> >> A Riley Eller >> CoCo Communications >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf Of Stan Ratliff >> Sent: Friday, June 03, 2011 9:25 AM >> To: MANET IETF >> Subject: [manet] DLEP >> >> Hello everyone. >> >> The latest version of the DLEP draft - >> http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ >> was posted on May 2. As of this writing, there has been no discussion >> on the mailing list about the 01 version of the draft. Taking the >> optimistic viewpoint that there are no objections, I'll ask the group >> - Can we proceed to WGLC on this document? >> >> Regards, >> Stan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From reller@cococorp.com Thu Jun 30 10:18: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 E335F11E8276 for ; Thu, 30 Jun 2011 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW5blWn7-DqJ for ; Thu, 30 Jun 2011 10:18:58 -0700 (PDT) Received: from im1.namehub.com (im1.namehub.com [64.70.94.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0B55E11E8229 for ; Thu, 30 Jun 2011 10:18:58 -0700 (PDT) Received: from ([64.70.67.188]) by im1.namehub.com with ESMTP with TLS id 2YL2FN1.140429796; Thu, 30 Jun 2011 10:14:26 -0700 Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub04.exchhosting.com (192.168.11.100) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 30 Jun 2011 10:14:26 -0700 Received: from EXMBX13.exchhosting.com ([fe80::34:7540:6989:7b8d]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Thu, 30 Jun 2011 10:14:26 -0700 From: "A. Riley Eller" To: Stan Ratliff Date: Thu, 30 Jun 2011 10:14:25 -0700 Thread-Topic: [manet] DLEP Thread-Index: Acw3RKgeMs8QdEUwRfq+V57CVLdVwwAArR2Q Message-ID: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18B0F@EXMBX13.exchhosting.com> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> In-Reply-To: <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MANET IETF Subject: Re: [manet] DLEP 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, 30 Jun 2011 17:18:59 -0000 Stan, "You can call me anything, just don't call me late for dinner." -- my pops I'm not much of a semanticist, so I'll defer to the group's ideas about nam= ing, but in the spirit of advocacy: "Latency" is easy to understand and has= a lot of background context that EFT does not share. The latter is, at bes= t, comprehensible only if you sound it out. That suggests to me that a read= er would pay better attention to the more specific term and not be tempted = to "plug in" an existing one- or two-way link latency metric. So by virtue = of being precise, my hunch is that EFT is a better name. I must admit that my scientific training is weak in temporal matters, so I = cannot be an arbiter of whether a "queuing delay" and "transmission delay" = should be expressed in the same terms as a "congestion back-off timer". It = seems to me, though, that latency should be used in tightly-coupled process= es (like phase-lock loops latent by the distance over the speed of light) a= nd duration should be used in loosely-coupled processes like timer events. = So in some senses, I might say, forwarding time is latencies plus durations= . In the pursuit of standardization, also, EFT is a formulation that might be= better specified rather than left to implementers. In the exchange of mess= ages across a component architecture, I believe that Latency might lose suf= ficient context to be mistaken for one- or two-way link latency or any simi= lar term. My preference sort would be: 1) Specify EFT instead of Latency in 7.9 2) Specify EFT as 7.x in addition to 7.9 3) Specify EFT as the MUST for 7.9 4) Suggest EFT as a MAY for 7.9 Do those ideas make sense? Again thank you for the consideration, Riley -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: Thursday, June 30, 2011 9:41 AM To: A. Riley Eller Cc: MANET IETF Subject: Re: [manet] DLEP Riley, Thank you for the explanation. Just playing devil's advocate here - =20 couldn't EFT be expressed as a better, more accurate definition of =20 latency? Regards, Stan On Jun 29, 2011, at 1:52 PM, A. Riley Eller wrote: > Thank you for the consideration. > > Expected Forwarding Time (EFT)[1] represents what I believe to be =20 > the state of the art in generating a meaningful cost function for =20 > links. The value represents "typical latency between the arrival of =20 > a given packet at the transmitting device and that packet's =20 > reception at the other end of the link" and so it combines =20 > transmission time, idle time, waiting time, freezing time, and =20 > queuing time to the degree that those values are meaningful for a =20 > given medium. By encompassing the entire packet lifetime, it =20 > describes the interaction of transmission rate, packet delivery =20 > ratio (in acknowledged, retransmitting links), contention in the =20 > local area, router load, and potentially traffic priority. The last =20 > of those depends upon whether the metric is computed distinctly for =20 > different traffic classes, of course. > > It is not panacea, but it is a discrete unit of measure that =20 > aggregates well across multiple media. This strength is in =20 > opposition to the inutility to software developers of dimensionless =20 > RLQ. I have been using a scheme of my own design (which amounts to =20 > nothing more than an integer approximation of air time) to good =20 > effect for six years, but EFT is better. EFT represents a milestone =20 > in both its efficacy and its comprehensibility. > > Regards, > > Riley > > > [1] EFT: a high throughput routing metric for IEEE 802.11s wireless =20 > mesh networks, Islam et al., 13 March 2009, > Institut TELECOM and Springer-Verlag 2009 > > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: Tuesday, June 28, 2011 7:22 PM > To: A. Riley Eller > Cc: MANET IETF > Subject: Re: [manet] DLEP > > Is there time? Yes, of course. I'm going to show my ignorance here; I > haven't heard about the EFT method. Can you please give me some > explanation/background? > > Regards, > Stan > > > On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: > >> Hello, >> >> I've been on the list for a while and mostly tried to learn from >> what is being said but, based on increasing experience with military >> radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? >> This question has been bouncing around MIT/LL and associated >> technology development labs. I apologize in advance if my query is >> in poor form. >> >> My reasoning: >> 1. DLEP aims to make standard radio to router interfaces (R2RI), a >> primary value proposition for multi-radio platforms. Even in single- >> radio platforms, it is the interface standard that would permit >> component and vendor replacement or upgrade. >> 2. 7.11 Relative Link Quality value is under-specified and cannot be >> tested except for nonzero value. >> 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. >> 4. 7.9 does not mandate the latency computation. >> 5. The EFT method is effective at answering all of these problems, >> and has been tested by members of this list. >> >> >> Thank you for your consideration, >> >> A Riley Eller >> CoCo Communications >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf Of Stan Ratliff >> Sent: Friday, June 03, 2011 9:25 AM >> To: MANET IETF >> Subject: [manet] DLEP >> >> Hello everyone. >> >> The latest version of the DLEP draft - >> http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ >> was posted on May 2. As of this writing, there has been no discussion >> on the mailing list about the 01 version of the draft. Taking the >> optimistic viewpoint that there are no objections, I'll ask the group >> - Can we proceed to WGLC on this document? >> >> Regards, >> Stan >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From joseph.macker@nrl.navy.mil Thu Jun 30 10:53:56 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 1BD4111E8204 for ; Thu, 30 Jun 2011 10:53:55 -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 tAUMAWxJO0yh for ; Thu, 30 Jun 2011 10:53:54 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfa.amsl.com (Postfix) with ESMTP id 30B5F11E81B3 for ; Thu, 30 Jun 2011 10:53:54 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p5UHrBq7029712; Thu, 30 Jun 2011 13:53:11 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011063013531102629 ; Thu, 30 Jun 2011 13:53:11 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> Date: Thu, 30 Jun 2011 13:53:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C9BFD3C-0BB7-45C2-B9A1-C2EEAA7053BE@nrl.navy.mil> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Cc: MANET IETF Subject: Re: [manet] DLEP 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, 30 Jun 2011 17:53:56 -0000 At first glance its seems like some sort of stochastic measure of = expected latency.=20 Is that essential what it is? Can you sketch out the TLV content desires and post it? On Jun 30, 2011, at 12:40 PM, Stan Ratliff wrote: > Riley, >=20 > Thank you for the explanation. Just playing devil's advocate here - = couldn't EFT be expressed as a better, more accurate definition of = latency? >=20 > Regards, > Stan >=20 >=20 > On Jun 29, 2011, at 1:52 PM, A. Riley Eller wrote: >=20 >> Thank you for the consideration. >>=20 >> Expected Forwarding Time (EFT)[1] represents what I believe to be the = state of the art in generating a meaningful cost function for links. The = value represents "typical latency between the arrival of a given packet = at the transmitting device and that packet's reception at the other end = of the link" and so it combines transmission time, idle time, waiting = time, freezing time, and queuing time to the degree that those values = are meaningful for a given medium. By encompassing the entire packet = lifetime, it describes the interaction of transmission rate, packet = delivery ratio (in acknowledged, retransmitting links), contention in = the local area, router load, and potentially traffic priority. The last = of those depends upon whether the metric is computed distinctly for = different traffic classes, of course. >>=20 >> It is not panacea, but it is a discrete unit of measure that = aggregates well across multiple media. This strength is in opposition to = the inutility to software developers of dimensionless RLQ. I have been = using a scheme of my own design (which amounts to nothing more than an = integer approximation of air time) to good effect for six years, but EFT = is better. EFT represents a milestone in both its efficacy and its = comprehensibility. >>=20 >> Regards, >>=20 >> Riley >>=20 >>=20 >> [1] EFT: a high throughput routing metric for IEEE 802.11s wireless = mesh networks, Islam et al., 13 March 2009, >> Institut TELECOM and Springer-Verlag 2009 >>=20 >>=20 >> -----Original Message----- >> From: Stan Ratliff [mailto:sratliff@cisco.com] >> Sent: Tuesday, June 28, 2011 7:22 PM >> To: A. Riley Eller >> Cc: MANET IETF >> Subject: Re: [manet] DLEP >>=20 >> Is there time? Yes, of course. I'm going to show my ignorance here; I >> haven't heard about the EFT method. Can you please give me some >> explanation/background? >>=20 >> Regards, >> Stan >>=20 >>=20 >> On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: >>=20 >>> Hello, >>>=20 >>> I've been on the list for a while and mostly tried to learn from >>> what is being said but, based on increasing experience with military >>> radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? >>> This question has been bouncing around MIT/LL and associated >>> technology development labs. I apologize in advance if my query is >>> in poor form. >>>=20 >>> My reasoning: >>> 1. DLEP aims to make standard radio to router interfaces (R2RI), a >>> primary value proposition for multi-radio platforms. Even in single- >>> radio platforms, it is the interface standard that would permit >>> component and vendor replacement or upgrade. >>> 2. 7.11 Relative Link Quality value is under-specified and cannot be >>> tested except for nonzero value. >>> 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. >>> 4. 7.9 does not mandate the latency computation. >>> 5. The EFT method is effective at answering all of these problems, >>> and has been tested by members of this list. >>>=20 >>>=20 >>> Thank you for your consideration, >>>=20 >>> A Riley Eller >>> CoCo Communications >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >>> Behalf Of Stan Ratliff >>> Sent: Friday, June 03, 2011 9:25 AM >>> To: MANET IETF >>> Subject: [manet] DLEP >>>=20 >>> Hello everyone. >>>=20 >>> The latest version of the DLEP draft - >>> http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ >>> was posted on May 2. As of this writing, there has been no = discussion >>> on the mailing list about the 01 version of the draft. Taking the >>> optimistic viewpoint that there are no objections, I'll ask the = group >>> - Can we proceed to WGLC on this document? >>>=20 >>> Regards, >>> Stan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Thu Jun 30 12:09:00 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 BD71C11E80AC for ; Thu, 30 Jun 2011 12:09:00 -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=[AWL=0.000, 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 yqPlmXYWE+Zy for ; Thu, 30 Jun 2011 12:08:59 -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 E7C9011E807A for ; Thu, 30 Jun 2011 12:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6639; q=dns/txt; s=iport; t=1309460939; x=1310670539; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=xOZSa4kQ2WUAKrNGm/VOfr3fbJUfcHYcqedQTecDmT4=; b=PPq4OCtE8+i1xBxCUb6AwBCPrAJcj5d1Rb/zBO7PU3nIIc2B3ejzQANz Ln7DKKwPLfMfkmNPzrulVEzE6+9vgXg/RnXFI4DT2k9YUFQjmcjgqntL/ dyOQnWblYQvpIzXvEQ5LwE8b/OTECy/wU6ugPRFEPa6E3eJx66Xd2c3Sb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAEzJDE6tJV2d/2dsb2JhbABSmCmPMXeIeKEHnXSGMQSSL5BK X-IronPort-AV: E=Sophos;i="4.65,453,1304294400"; d="scan'208";a="288653602" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-4.cisco.com with ESMTP; 30 Jun 2011 19:08:57 +0000 Received: from dhcp-64-102-54-112.cisco.com (dhcp-64-102-54-112.cisco.com [64.102.54.112]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5UJ8vtY017564; Thu, 30 Jun 2011 19:08:57 GMT Message-Id: <8F9E98F9-E84F-4080-A890-F4F606F50CFC@cisco.com> From: Stan Ratliff To: "A. Riley Eller" In-Reply-To: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18B0F@EXMBX13.exchhosting.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 30 Jun 2011 15:08:57 -0400 References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18B0F@EXMBX13.exchhosting.com> X-Mailer: Apple Mail (2.936) Cc: MANET IETF Subject: Re: [manet] DLEP 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, 30 Jun 2011 19:09:00 -0000 Riley, :-) Your father & mine share the same sayings... Your point makes sense. I'll try to lift the ETF description from the reference and include it in the next rev of the DLEP document. If you have some suggested text to describe EFT, that would be great. Regards, Stan On Jun 30, 2011, at 1:14 PM, A. Riley Eller wrote: > Stan, > > "You can call me anything, just don't call me late for dinner." -- > my pops > > I'm not much of a semanticist, so I'll defer to the group's ideas > about naming, but in the spirit of advocacy: "Latency" is easy to > understand and has a lot of background context that EFT does not > share. The latter is, at best, comprehensible only if you sound it > out. That suggests to me that a reader would pay better attention to > the more specific term and not be tempted to "plug in" an existing > one- or two-way link latency metric. So by virtue of being precise, > my hunch is that EFT is a better name. > > I must admit that my scientific training is weak in temporal > matters, so I cannot be an arbiter of whether a "queuing delay" and > "transmission delay" should be expressed in the same terms as a > "congestion back-off timer". It seems to me, though, that latency > should be used in tightly-coupled processes (like phase-lock loops > latent by the distance over the speed of light) and duration should > be used in loosely-coupled processes like timer events. So in some > senses, I might say, forwarding time is latencies plus durations. > > In the pursuit of standardization, also, EFT is a formulation that > might be better specified rather than left to implementers. In the > exchange of messages across a component architecture, I believe that > Latency might lose sufficient context to be mistaken for one- or two- > way link latency or any similar term. > > My preference sort would be: > 1) Specify EFT instead of Latency in 7.9 > 2) Specify EFT as 7.x in addition to 7.9 > 3) Specify EFT as the MUST for 7.9 > 4) Suggest EFT as a MAY for 7.9 > > Do those ideas make sense? > > > Again thank you for the consideration, > > Riley > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: Thursday, June 30, 2011 9:41 AM > To: A. Riley Eller > Cc: MANET IETF > Subject: Re: [manet] DLEP > > Riley, > > Thank you for the explanation. Just playing devil's advocate here - > couldn't EFT be expressed as a better, more accurate definition of > latency? > > Regards, > Stan > > > On Jun 29, 2011, at 1:52 PM, A. Riley Eller wrote: > >> Thank you for the consideration. >> >> Expected Forwarding Time (EFT)[1] represents what I believe to be >> the state of the art in generating a meaningful cost function for >> links. The value represents "typical latency between the arrival of >> a given packet at the transmitting device and that packet's >> reception at the other end of the link" and so it combines >> transmission time, idle time, waiting time, freezing time, and >> queuing time to the degree that those values are meaningful for a >> given medium. By encompassing the entire packet lifetime, it >> describes the interaction of transmission rate, packet delivery >> ratio (in acknowledged, retransmitting links), contention in the >> local area, router load, and potentially traffic priority. The last >> of those depends upon whether the metric is computed distinctly for >> different traffic classes, of course. >> >> It is not panacea, but it is a discrete unit of measure that >> aggregates well across multiple media. This strength is in >> opposition to the inutility to software developers of dimensionless >> RLQ. I have been using a scheme of my own design (which amounts to >> nothing more than an integer approximation of air time) to good >> effect for six years, but EFT is better. EFT represents a milestone >> in both its efficacy and its comprehensibility. >> >> Regards, >> >> Riley >> >> >> [1] EFT: a high throughput routing metric for IEEE 802.11s wireless >> mesh networks, Islam et al., 13 March 2009, >> Institut TELECOM and Springer-Verlag 2009 >> >> >> -----Original Message----- >> From: Stan Ratliff [mailto:sratliff@cisco.com] >> Sent: Tuesday, June 28, 2011 7:22 PM >> To: A. Riley Eller >> Cc: MANET IETF >> Subject: Re: [manet] DLEP >> >> Is there time? Yes, of course. I'm going to show my ignorance here; I >> haven't heard about the EFT method. Can you please give me some >> explanation/background? >> >> Regards, >> Stan >> >> >> On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: >> >>> Hello, >>> >>> I've been on the list for a while and mostly tried to learn from >>> what is being said but, based on increasing experience with military >>> radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? >>> This question has been bouncing around MIT/LL and associated >>> technology development labs. I apologize in advance if my query is >>> in poor form. >>> >>> My reasoning: >>> 1. DLEP aims to make standard radio to router interfaces (R2RI), a >>> primary value proposition for multi-radio platforms. Even in single- >>> radio platforms, it is the interface standard that would permit >>> component and vendor replacement or upgrade. >>> 2. 7.11 Relative Link Quality value is under-specified and cannot be >>> tested except for nonzero value. >>> 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. >>> 4. 7.9 does not mandate the latency computation. >>> 5. The EFT method is effective at answering all of these problems, >>> and has been tested by members of this list. >>> >>> >>> Thank you for your consideration, >>> >>> A Riley Eller >>> CoCo Communications >>> >>> >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >>> Behalf Of Stan Ratliff >>> Sent: Friday, June 03, 2011 9:25 AM >>> To: MANET IETF >>> Subject: [manet] DLEP >>> >>> Hello everyone. >>> >>> The latest version of the DLEP draft - >>> http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ >>> was posted on May 2. As of this writing, there has been no >>> discussion >>> on the mailing list about the 01 version of the draft. Taking the >>> optimistic viewpoint that there are no objections, I'll ask the >>> group >>> - Can we proceed to WGLC on this document? >>> >>> Regards, >>> Stan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> > From reller@cococorp.com Thu Jun 30 13:20: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 7C67B21F85A3 for ; Thu, 30 Jun 2011 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] 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 wpcL4hNQIn-y for ; Thu, 30 Jun 2011 13:20:08 -0700 (PDT) Received: from namehub.com (im10.namehub.com [64.70.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5153521F8511 for ; Thu, 30 Jun 2011 13:20:06 -0700 (PDT) Received: from ([64.70.67.188]) by im10.namehub.com with ESMTP with TLS id 17C1JJ1.194280263; Thu, 30 Jun 2011 13:17:26 -0700 Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub05.exchhosting.com (192.168.11.101) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 30 Jun 2011 13:17:26 -0700 Received: from EXMBX13.exchhosting.com ([fe80::34:7540:6989:7b8d]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Thu, 30 Jun 2011 13:17:23 -0700 From: "A. Riley Eller" To: Joe Macker , Stan Ratliff Date: Thu, 30 Jun 2011 13:17:22 -0700 Thread-Topic: [manet] DLEP Thread-Index: Acw3TsO/h4XBpkXTSL+/SnSJEvqgvQABa1xQ Message-ID: <3D05610F3AC2E047AACAA68F63DF908D1DF4F18B21@EXMBX13.exchhosting.com> References: <201105111113.35299.henning.rogge@fkie.fraunhofer.de> <69CF2839-A101-4D22-A16F-85E9F0CD2169@inf-net.nl> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18A35@EXMBX13.exchhosting.com> <3D05610F3AC2E047AACAA68F63DF908D1DF4F18AA5@EXMBX13.exchhosting.com> <7A64218E-C70F-4D49-A8B9-B1583F28DE53@cisco.com> <9C9BFD3C-0BB7-45C2-B9A1-C2EEAA7053BE@nrl.navy.mil> In-Reply-To: <9C9BFD3C-0BB7-45C2-B9A1-C2EEAA7053BE@nrl.navy.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MANET IETF Subject: Re: [manet] DLEP 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, 30 Jun 2011 20:20:09 -0000 Dennis Edwards, the co-author of the Air Time metric I mentioned, reminds m= e that all we're talking about is using the best available mechanism to mea= sure latency. So with his admonishment in mind, here's my attempt at a draf= t text. Stan will surely note that it resembles the Latency Sub-TLV, althou= gh I took the liberty of pushing toward a microsecond based representation.= Millisecond accuracy is technically sufficient, but I believe that the add= itional bits can be used to improve mobility in CSMA-style media. Please fe= el free to replace (us) with (ms) if the group prefers, and in that case sh= rink the encoding to 2 octets. 7.X Expected Forwarding Time (EFT) Sub-TLV The EFT Sub-TLV is used in Neighbor Up, Neighbor Update, Link=20 Characteristics Request, and Link Characteristics ACK messages to=20 indicate the expected forwarding time on the link, or in the case=20 of the Link Characteristics Request, to indicate the maximum=20 packet holding time (e.g. a should-not-exeed value) on the link.=20 The EFT Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =3DTBD |TLV Flags=3D0x10 |Length =3D 4 |EFT (us) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Expected Forwarding Time (us) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not used and MUST be set to '0'. Length - 2 Expected Forwarding - the transmission delay that a packet Time encounters as it is transmitted over the link. In Neighbor Up, Neighbor Update,=20 and Link Characteristics ACK, this value is reported in expected delay, in=20 microseconds. The calculation of=20 forwarding time is modem-device dependent,=20 but SHOULD represent the sum of all=20 latencies due to queuing, transmission, retransmission, idle, and freezing times. For example, the queuing time may be a=20 running average calculated from the=20 internal queuing and the freezing time may be a running average of media acquisition time. If the modem device cannot calculate=20 expected forwarding time it MUST be=20 reported as 0. In the Link Characteristics=20 Request Message, this value represents the=20 maximum acceptance holding time, in=20 microseconds, expected on the link. -----Original Message----- From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 Sent: Thursday, June 30, 2011 10:54 AM To: Stan Ratliff Cc: A. Riley Eller; MANET IETF Subject: Re: [manet] DLEP At first glance its seems like some sort of stochastic measure of expected = latency.=20 Is that essential what it is? Can you sketch out the TLV content desires and post it? On Jun 30, 2011, at 12:40 PM, Stan Ratliff wrote: > Riley, >=20 > Thank you for the explanation. Just playing devil's advocate here - could= n't EFT be expressed as a better, more accurate definition of latency? >=20 > Regards, > Stan >=20 >=20 > On Jun 29, 2011, at 1:52 PM, A. Riley Eller wrote: >=20 >> Thank you for the consideration. >>=20 >> Expected Forwarding Time (EFT)[1] represents what I believe to be the st= ate of the art in generating a meaningful cost function for links. The valu= e represents "typical latency between the arrival of a given packet at the = transmitting device and that packet's reception at the other end of the lin= k" and so it combines transmission time, idle time, waiting time, freezing = time, and queuing time to the degree that those values are meaningful for a= given medium. By encompassing the entire packet lifetime, it describes the= interaction of transmission rate, packet delivery ratio (in acknowledged, = retransmitting links), contention in the local area, router load, and poten= tially traffic priority. The last of those depends upon whether the metric = is computed distinctly for different traffic classes, of course. >>=20 >> It is not panacea, but it is a discrete unit of measure that aggregates = well across multiple media. This strength is in opposition to the inutility= to software developers of dimensionless RLQ. I have been using a scheme of= my own design (which amounts to nothing more than an integer approximation= of air time) to good effect for six years, but EFT is better. EFT represen= ts a milestone in both its efficacy and its comprehensibility. >>=20 >> Regards, >>=20 >> Riley >>=20 >>=20 >> [1] EFT: a high throughput routing metric for IEEE 802.11s wireless mesh= networks, Islam et al., 13 March 2009, >> Institut TELECOM and Springer-Verlag 2009 >>=20 >>=20 >> -----Original Message----- >> From: Stan Ratliff [mailto:sratliff@cisco.com] >> Sent: Tuesday, June 28, 2011 7:22 PM >> To: A. Riley Eller >> Cc: MANET IETF >> Subject: Re: [manet] DLEP >>=20 >> Is there time? Yes, of course. I'm going to show my ignorance here; I >> haven't heard about the EFT method. Can you please give me some >> explanation/background? >>=20 >> Regards, >> Stan >>=20 >>=20 >> On Jun 28, 2011, at 2:01 PM, A. Riley Eller wrote: >>=20 >>> Hello, >>>=20 >>> I've been on the list for a while and mostly tried to learn from >>> what is being said but, based on increasing experience with military >>> radios, I wonder: is there time to ask for an EFT Sub-TLV for DLEP? >>> This question has been bouncing around MIT/LL and associated >>> technology development labs. I apologize in advance if my query is >>> in poor form. >>>=20 >>> My reasoning: >>> 1. DLEP aims to make standard radio to router interfaces (R2RI), a >>> primary value proposition for multi-radio platforms. Even in single- >>> radio platforms, it is the interface standard that would permit >>> component and vendor replacement or upgrade. >>> 2. 7.11 Relative Link Quality value is under-specified and cannot be >>> tested except for nonzero value. >>> 3. 7.9 Latency Sub-TLV is too short to bear deep queuing times. >>> 4. 7.9 does not mandate the latency computation. >>> 5. The EFT method is effective at answering all of these problems, >>> and has been tested by members of this list. >>>=20 >>>=20 >>> Thank you for your consideration, >>>=20 >>> A Riley Eller >>> CoCo Communications >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >>> Behalf Of Stan Ratliff >>> Sent: Friday, June 03, 2011 9:25 AM >>> To: MANET IETF >>> Subject: [manet] DLEP >>>=20 >>> Hello everyone. >>>=20 >>> The latest version of the DLEP draft - >>> http://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ >>> was posted on May 2. As of this writing, there has been no discussion >>> on the mailing list about the 01 version of the draft. Taking the >>> optimistic viewpoint that there are no objections, I'll ask the group >>> - Can we proceed to WGLC on this document? >>>=20 >>> Regards, >>> Stan >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20