From mailnull@www1.ietf.org Tue Apr 1 16:48:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16938 for ; Tue, 1 Apr 2003 16:48:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31MCZI24849 for ans-research-archive@odin.ietf.org; Tue, 1 Apr 2003 17:12:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MCZK24846 for ; Tue, 1 Apr 2003 17:12:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16907 for ; Tue, 1 Apr 2003 16:48:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MCRK24835; Tue, 1 Apr 2003 17:12:27 -0500 Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MBnK24785 for ; Tue, 1 Apr 2003 17:11:49 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <2C24RFM1>; Tue, 1 Apr 2003 16:49:42 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0117877A@ftmail.lab.flarion.com> From: Scott Corson To: "'Xiaoyan Hong'" , "'Joe Macker'" , "'ans-research@www1.ietf.org'" Cc: "'Dr Mario Gerla'" Subject: RE: [Ans-research] (no subject) Date: Tue, 1 Apr 2003 16:49:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Xiaoyan, I would characterize most of what you mention as 'scenario criteria', e.g.: * number of nodes/connectivity of nodes/mobility pattern * traffic pattern/application mixture/traffic intensity * node energy storage constaints/CPU cycles bound * bandwidth constraints/link layer type(s) in use etc... Common definitions of the above are needed to specify 'standard' scenario test cases that can be considered during evaluations. As regards 'black box' performance metrics, I'm thinking more of *protocol-independent performance measures* as seen by higher layer applications/protocols, e.g.: * 1st and 2nd-order latency measures (delay/jitter) * 1st and 2nd-order throughput measures (goodput/variation) etc... Common definitions of these metrics are also desired. These can be broken down per traffic aggregate (in DiffServ terms) if QoS routing is considered. These measures apply equally to reactive, proactive or hybrid algorithms. We are looking for contributions (Internet Drafts) on both these topics and others by interested parties. -Scott > -----Original Message----- > From: Xiaoyan Hong [mailto:hxy@CS.UCLA.EDU] > Sent: Monday, March 31, 2003 9:32 PM > To: Joe Macker; ans-research@www1.ietf.org > Cc: Xiaoyan Hong; Dr Mario Gerla > Subject: Re: [Ans-research] (no subject) > > > Joe, > > Thank you, and I agree with you on those points. Please see below. > > On Mon, 31 Mar 2003, Joe Macker wrote: > > Xiaoyan: > > > > First off, I think you are describing "the black box". > > Is that what was meant by the black box criteria.? > > Yes. Thank you for clarifing this. > > > (I was thinking more normalized performance metrics and evaluation > > criteria for use on black boxes) > > ..perhaps its both... > > > > I added some comments below on your scenario items. > > > > >In terms of the "black box criteria" to be defined by the > > >group for routing scalability, I want to share the measures > > >that we have used in our research with LANMAR and FSR. > > > > > >(1) Number of active nodes. This is the classic measure. > As the # of > > >nodes becomes large, some routing schemes suffer > increasing o/h due to > > >the computing, storage and communication of the routing info. > > > > Just a thought. > > > > A combination of number of nodes and average density, gives one a > > notion of the diameter of the network. We needed such a > distinguishing > > model in a recent study of several scalability mechanisms. Some o/h > > reduction mechanisms (scalability related) are targeted at handling > > neighborhood density conditions, while other perhaps tackle network > > diameter issues better. In the case where a network approach > > automatically adjusts network density (e.g., power control) > and hence > > diameter, perhaps number of nodes is enough to specify here. > > > Yes. I agree. Though increasing in density and network diameter both > involve number of nodes, the number of nodes itself is not enough to > distinguish different o/h reduction mechanisms. A combination with > average density makes things clear. > > > It may be even more complicated (non-homogenous graph densities)... > > this can have a signficant effect on any findings? > > > Depending on what mechanism is in using, I think. If a mechanism works > only good in terms of network diameter, the non-homogenous graph > densities will affect the performance. But may not on ANY findings. > > > >(2) Traffic pattern. The nature of traffic pattern (say, number of > > >active source/destination pairs; source destination near > each other vs > > >far away from each other) will have major impact on the O/H of some > > >routing protocols. Localized traffic patterns, for example, may not > > >require as much routing O/H as fully distributed patterns. > > > > Also, the type of traffic, highly bursty vs. more uniform > ,etc...can affect on-demand techniques, cacheing techniques, > overhead vs. data delivered, etc. > > > > >(3) Mobility. The norm is that the higher the mobility > (relative to a > > >certain transmission range) the more routing effort is needed to > > >maintain a path. > > > > True, there are specifics here that need further > discussion, like the > > mobile (or dynamics) model. > > > I'd prefer models that reflect topology changes. But if we can model > some real scenarios... Are there any real world > mobility and connection data for MANET? > > > > > Regards, > > Xiaoyan > > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research > _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Sat Apr 5 09:41:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06873 for ; Sat, 5 Apr 2003 09:41:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35EihD32139 for ans-research-archive@odin.ietf.org; Sat, 5 Apr 2003 09:44:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Eih832136 for ; Sat, 5 Apr 2003 09:44:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06861 for ; Sat, 5 Apr 2003 09:40:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35EhS832117; Sat, 5 Apr 2003 09:43:28 -0500 Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Ee2832047 for ; Sat, 5 Apr 2003 09:40:03 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <2KQJ9GM7>; Sat, 5 Apr 2003 09:38:38 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> From: Scott Corson To: "'Joe Macker'" , "'A. Bruce McDonald'" Cc: "'ankur.j@media.mit.edu'" , "'manet@ietf.org'" , "'ans-research@www1.ietf.org'" Date: Sat, 5 Apr 2003 09:38:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [Ans-research] RE: [manet] Interlayer Interactions Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , This is a *very* old discussion. ;-) In the absence of standardized mechanisms, I also agree with Joe that we need code that does not require standard interlayer interaction mechanisms. > The ANS IRTF list may want to comment and may be an > appropriate venue for > broadening the knowledge base further over time. As to whether the ANS group will explore this issue, I would be very much in favor of it (note the cross posting), but the issue is *broader* than ad hoc networking. It pertains to IP-based cellular systems, WLAN and ad hoc schemes. In short any link layer where intermittent and dynamic connectivity may be a typical event. Of all the *trigger* and related IETF work I've seen proposed to date, IMO, the most sensible and general approach was articulated by Phil Neumiller in an interesting way. The proposal is that the IETF standardize IP's *underbelly*. I interpret what Phil meant as a general interface definition that would be built into the bottomhalf of standard IP kernels. Link layers could then be defined or extended to operate in accordance with this interface as desired. Most generally IP kernels understand 'point-to-point' and 'broadcast' link layers. What is necessary is *another* type of interface that blends and generalizes aspects of point-to-point and broadcast link layers to accomodate link *dynamics*. As such I refer to it as a *triggered* or *dynamic* interface for lack of a better name. In wireless, link layer broadcast communication (one-to-many) is the general case and must be supported as in Ethernet. At the same time, point-to-point 'peer-to-peer' associations (neighbors in an ad hoc sense) arise *dynamically* as a consequence of movement, power up, fading, etc. Many link layers efficiently detect the existence/non-existence and quality of these associations. This association information can be conveyed to an IP stack via the triggered interface construct, and the IP stack is free to use this information as desired (and it may ignore it as well). This mechanism is applicable to Ad hoc, WLAN and Cellular technologies. For those interested, this topic is explored a bit further in http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt Cheers, -Scott _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Sat Apr 5 10:48:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09522 for ; Sat, 5 Apr 2003 10:48:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35Fq7R04007 for ans-research-archive@odin.ietf.org; Sat, 5 Apr 2003 10:52:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Fq7804004 for ; Sat, 5 Apr 2003 10:52:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09504 for ; Sat, 5 Apr 2003 10:48:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Fps803937; Sat, 5 Apr 2003 10:51:54 -0500 Received: from gandalf.icr.a-star.edu.sg (gandalf.icr.a-star.edu.sg [137.132.31.244]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35FdF803543 for ; Sat, 5 Apr 2003 10:39:15 -0500 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h35FcKGi022892 for ; Sat, 5 Apr 2003 23:38:20 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Sat, 05 Apr 2003 23:30:00 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 0179A30948; Sat, 5 Apr 2003 23:37:24 +0800 (SGT) Date: Sat, 5 Apr 2003 23:37:24 +0800 From: Sukanta Kumar Hazra To: Scott Corson Cc: "'Joe Macker'" , "'A. Bruce McDonald'" , "'ankur.j@media.mit.edu'" , "'manet@ietf.org'" , "'ans-research@www1.ietf.org'" Subject: Re: [Ans-research] RE: [manet] Interlayer Interactions Message-ID: <20030405153724.GA12200@localhost> Mail-Followup-To: Scott Corson , 'Joe Macker' , "'A. Bruce McDonald'" , "'ankur.j@media.mit.edu'" , "'manet@ietf.org'" , "'ans-research@www1.ietf.org'" References: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A011789CA@ftmail.lab.flarion.com> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , > This is a *very* old discussion. ;-) Indeed it is a *very* old discussion. But it resurfaces ever so often that it is imperative that something be done about it (IMHO). All the arguments that I have come across point to the need for a standardized interface for IP<->L2 interaction. Anyone remembers the arguments against it (as were discussed in the IP triggers BOF). - Sukanta > > In the absence of standardized mechanisms, I also agree with Joe that we > need code that does not require standard interlayer interaction mechanisms. > > > The ANS IRTF list may want to comment and may be an > > appropriate venue for > > broadening the knowledge base further over time. > > As to whether the ANS group will explore this issue, I would be very much in > favor of it (note the cross posting), but the issue is *broader* than ad hoc > networking. It pertains to IP-based cellular systems, WLAN and ad hoc > schemes. In short any link layer where intermittent and dynamic > connectivity may be a typical event. > > Of all the *trigger* and related IETF work I've seen proposed to date, IMO, > the most sensible and general approach was articulated by Phil Neumiller in > an interesting way. The proposal is that the IETF standardize IP's > *underbelly*. > > I interpret what Phil meant as a general interface definition that would be > built into the bottomhalf of standard IP kernels. Link layers could then be > defined or extended to operate in accordance with this interface as desired. > > Most generally IP kernels understand 'point-to-point' and 'broadcast' link > layers. What is necessary is *another* type of interface that blends and > generalizes aspects of point-to-point and broadcast link layers to > accomodate link *dynamics*. As such I refer to it as a *triggered* or > *dynamic* interface for lack of a better name. > > In wireless, link layer broadcast communication (one-to-many) is the general > case and must be supported as in Ethernet. At the same time, point-to-point > 'peer-to-peer' associations (neighbors in an ad hoc sense) arise > *dynamically* as a consequence of movement, power up, fading, etc. Many > link layers efficiently detect the existence/non-existence and quality of > these associations. This association information can be conveyed to an IP > stack via the triggered interface construct, and the IP stack is free to use > this information as desired (and it may ignore it as well). This mechanism > is applicable to Ad hoc, WLAN and Cellular technologies. > > For those interested, this topic is explored a bit further in > > http://www.ietf.org/internet-drafts/draft-corson-triggered-00.txt > > Cheers, > > -Scott > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research -- _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Sat Apr 5 10:49:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09539 for ; Sat, 5 Apr 2003 10:49:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h35FqWL04032 for ans-research-archive@odin.ietf.org; Sat, 5 Apr 2003 10:52:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35FqV804029 for ; Sat, 5 Apr 2003 10:52:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09513 for ; Sat, 5 Apr 2003 10:48:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Fq1803964; Sat, 5 Apr 2003 10:52:01 -0500 Received: from gandalf.icr.a-star.edu.sg (gandalf.icr.a-star.edu.sg [137.132.31.244]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Fh2803705 for ; Sat, 5 Apr 2003 10:43:03 -0500 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h35FgJGi022928 for ; Sat, 5 Apr 2003 23:42:19 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Sat, 05 Apr 2003 23:34:04 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 6DA4130948; Sat, 5 Apr 2003 23:41:31 +0800 (SGT) Date: Sat, 5 Apr 2003 23:41:31 +0800 From: Sukanta Kumar Hazra To: Scott Corson Cc: "'Xiaoyan Hong'" , "'Joe Macker'" , "'ans-research@www1.ietf.org'" , "'Dr Mario Gerla'" Subject: Re: [Ans-research] (no subject) Message-ID: <20030405154131.GA12252@localhost> Mail-Followup-To: Scott Corson , 'Xiaoyan Hong' , 'Joe Macker' , "'ans-research@www1.ietf.org'" , 'Dr Mario Gerla' References: <748C6D0A58C0F94CA63C198B6674697A0117877A@ftmail.lab.flarion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0117877A@ftmail.lab.flarion.com> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Comments Inline. > As regards 'black box' performance metrics, I'm thinking more of > *protocol-independent performance measures* as seen by higher layer > applications/protocols, e.g.: > * 1st and 2nd-order latency measures (delay/jitter) > * 1st and 2nd-order throughput measures (goodput/variation) > etc... > > Common definitions of these metrics are also desired. These can be broken > down per traffic aggregate (in DiffServ terms) if QoS routing is considered. > These measures apply equally to reactive, proactive or hybrid algorithms. > How will the definition of the above be any different from the ones used in traditional networks? - Sukanta _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Mon Apr 7 15:06:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01303 for ; Mon, 7 Apr 2003 15:06:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37JAwI04417 for ans-research-archive@odin.ietf.org; Mon, 7 Apr 2003 15:10:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37JAw804414 for ; Mon, 7 Apr 2003 15:10:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01244 for ; Mon, 7 Apr 2003 15:06:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37J2P803196; Mon, 7 Apr 2003 15:02:25 -0400 Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Iws803017 for ; Mon, 7 Apr 2003 14:58:55 -0400 Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with SMTP id h37IuZC11845 for ; Mon, 7 Apr 2003 11:56:35 -0700 (PDT) Message-Id: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> Date: Mon, 7 Apr 2003 11:56:35 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: ans-research@www1.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Q/7umrEu8W4VtBoRrBzZmQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [Ans-research] Direction of ANS RG Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Hi, There are a number of you on the mailing list now so I think we should start discussing the direction and emphasis of this research group. At the Bar BOF at the IETF meeting, we talked about a number of potential directions for the group. The over-riding point that became evident as we continued our discussion was that we need a clear definition of what scalability is. Since the group's focus is scalability in ad hoc networks, we need to first define the problem we are working on before we can begin to propose solutions. This topic has been discussed in a different flavor on the MANET mailing list in terms of trying to define the type of network the MANET group should focus on. It has become evident from these discussions that there are a number of dimensions to defining a network. Likewise, there will be multiple dimensions to consider when defining scalability. These are likely to include number of nodes, network size, traffic model, mobility, and others. One of the first things that could be a product of this research group is an information document defining scalability along all of the different possible axes. This will enable us to focus more clearly on the type of networks we are researching. It will also most likely benefit the MANET group as well. Does anyone have thoughts either on this as our future direction or on how to begin undertaking this task? Elizabeth _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Mon Apr 7 16:32:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05182 for ; Mon, 7 Apr 2003 16:32:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37KbMY10960 for ans-research-archive@odin.ietf.org; Mon, 7 Apr 2003 16:37:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KbL810949 for ; Mon, 7 Apr 2003 16:37:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05171 for ; Mon, 7 Apr 2003 16:32:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KSi810077; Mon, 7 Apr 2003 16:28:44 -0400 Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KPc809957 for ; Mon, 7 Apr 2003 16:25:38 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h37KN7cX017787; Mon, 7 Apr 2003 16:23:07 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h37KMxWg009675; Mon, 7 Apr 2003 16:23:02 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040716230102510 ; Mon, 07 Apr 2003 16:23:01 -0400 Message-Id: <5.1.1.5.2.20030407162028.032dc5a0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 07 Apr 2003 16:22:35 -0400 To: "Elizabeth M. Belding-Royer" From: Joe Macker Subject: Re: [Ans-research] Direction of ANS RG Cc: ans-research@www1.ietf.org In-Reply-To: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Although slightly different in scope and intent you could look at RFC 2357 for some ideas. I think a short information document talking about issues and scope might be relevant. Doesn't have to be perfect. -Joe At 11:56 AM 4/7/2003 -0700, Elizabeth M. Belding-Royer wrote: >Hi, > >There are a number of you on the mailing list now so I think we >should start discussing the direction and emphasis of this research >group. > >At the Bar BOF at the IETF meeting, we talked about a number of >potential directions for the group. The over-riding point that >became evident as we continued our discussion was that we need >a clear definition of what scalability is. Since the group's >focus is scalability in ad hoc networks, we need to first define >the problem we are working on before we can begin to propose >solutions. This topic has been discussed in a different flavor >on the MANET mailing list in terms of trying to define the type >of network the MANET group should focus on. It has become evident >from these discussions that there are a number of dimensions >to defining a network. Likewise, there will be multiple dimensions >to consider when defining scalability. These are likely to include >number of nodes, network size, traffic model, mobility, and others. > >One of the first things that could be a product of this research >group is an information document defining scalability along all >of the different possible axes. This will enable us to focus more >clearly on the type of networks we are researching. It will also >most likely benefit the MANET group as well. > >Does anyone have thoughts either on this as our future direction or >on how to begin undertaking this task? > >Elizabeth > >_______________________________________________ >Ans-research mailing list >Ans-research@www1.ietf.org >https://www1.ietf.org/mailman/listinfo/ans-research _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Mon Apr 7 16:52:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05637 for ; Mon, 7 Apr 2003 16:52:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37Kukr12268 for ans-research-archive@odin.ietf.org; Mon, 7 Apr 2003 16:56:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Kuk812265 for ; Mon, 7 Apr 2003 16:56:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05627 for ; Mon, 7 Apr 2003 16:51:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Kj9811717; Mon, 7 Apr 2003 16:45:09 -0400 Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Khd811614 for ; Mon, 7 Apr 2003 16:43:39 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h37KfCcX018425; Mon, 7 Apr 2003 16:41:12 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h37Kf7Wg009790; Mon, 7 Apr 2003 16:41:07 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040716410602558 ; Mon, 07 Apr 2003 16:41:07 -0400 Message-Id: <5.1.1.5.2.20030407163745.03370c80@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 07 Apr 2003 16:40:40 -0400 To: "Elizabeth M. Belding-Royer" From: Joe Macker Subject: Re: [Ans-research] Direction of ANS RG Cc: ans-research@www1.ietf.org In-Reply-To: <5.1.1.5.2.20030407162028.032dc5a0@pop.itd.nrl.navy.mil> References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , At 04:22 PM 4/7/2003 -0400, Joe Macker wrote: >Although slightly different in scope and intent you could look at RFC 2357 for some ideas. >I think a short information document talking about issues and scope might be relevant. >Doesn't have to be perfect. Before the threads start, by the above, I meant it could be a short discussion layouting some basic ANS tradeoffs and problem space issues without getting into solution sets right away. >-Joe _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Mon Apr 7 17:40:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05651 for ; Mon, 7 Apr 2003 16:52:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37Kuk512284 for ans-research-archive@odin.ietf.org; Mon, 7 Apr 2003 16:56:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Kuk812281 for ; Mon, 7 Apr 2003 16:56:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05628 for ; Mon, 7 Apr 2003 16:51:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37KjA811733; Mon, 7 Apr 2003 16:45:10 -0400 Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75] (may be forged)) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Khg811618 for ; Mon, 7 Apr 2003 16:43:42 -0400 Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.12.9/8.12.8) with ESMTP id h37KfJ2t011460; Mon, 7 Apr 2003 16:41:19 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.12.9/8.12.8) with ESMTP id h37KfHCg002733; Mon, 7 Apr 2003 16:41:17 -0400 (EDT) Received: from m29103-pc.mitre.org (128.29.55.52) by mailhub2.mitre.org with SMTP id 1850679; Mon, 07 Apr 2003 16:41:08 -0400 Message-ID: <3E91E265.693AA23B@mitre.org> Date: Mon, 07 Apr 2003 16:41:09 -0400 From: John Stine Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Elizabeth M. Belding-Royer" CC: ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Elizabeth, I was looking forward to a new mailing list that would have a more research oriented nature but must admit that I am a bit disappointed that we have chosen scalability as our focus. This appears to be an effort to create the environments in which to compare the IETF MANET routing protocol solutions rather than an effort to find new and better solutions for all aspects of ad hoc networking. There is a very rich design space at the physical layer but the IETF MANET charter to focus on IP routing solutions has separated this design space from potential solutions. The recent discussions on the MANET mailing list on interlayer communication and dependence is far more interesting and would be the direction I would want a new group to follow. Would it be possible to allow the discussion to go in this direction? Some topics I would like to see discussed is an articulation of the pros and cons of implementing routing above and below IP. Can functionality be divided? Can routing be integrated with an access protocol? How can such integration be exploited to improve networking performance? What functionality has to be above IP to give layers 4+ an interface that remains quinessentially IP? What capability should higher layer protocols have to affect the operation of lower layer protocols for purposes of QoS, security, or some other goal? Is the 802.11 layer 1 and 2 solution the best we can do? Say an access protocol provides a QoS capability, how should a higher layer protocol communicate its selection? What are the mechanisms for interlayer communication (read this as IP and above to and from below IP)? I know positions on these topics border on being religious beliefs but it seems silly to me to limit our design space. John "Elizabeth M. Belding-Royer" wrote: > Hi, > > There are a number of you on the mailing list now so I think we > should start discussing the direction and emphasis of this research > group. > > At the Bar BOF at the IETF meeting, we talked about a number of > potential directions for the group. The over-riding point that > became evident as we continued our discussion was that we need > a clear definition of what scalability is. Since the group's > focus is scalability in ad hoc networks, we need to first define > the problem we are working on before we can begin to propose > solutions. This topic has been discussed in a different flavor > on the MANET mailing list in terms of trying to define the type > of network the MANET group should focus on. It has become evident > from these discussions that there are a number of dimensions > to defining a network. Likewise, there will be multiple dimensions > to consider when defining scalability. These are likely to include > number of nodes, network size, traffic model, mobility, and others. > > One of the first things that could be a product of this research > group is an information document defining scalability along all > of the different possible axes. This will enable us to focus more > clearly on the type of networks we are researching. It will also > most likely benefit the MANET group as well. > > Does anyone have thoughts either on this as our future direction or > on how to begin undertaking this task? > > Elizabeth > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Mon Apr 7 19:41:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10747 for ; Mon, 7 Apr 2003 19:41:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37Njhl23802 for ans-research-archive@odin.ietf.org; Mon, 7 Apr 2003 19:45:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Njg823799 for ; Mon, 7 Apr 2003 19:45:42 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10726 for ; Mon, 7 Apr 2003 19:40:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37NbA822934; Mon, 7 Apr 2003 19:37:10 -0400 Received: from barrichello.cs.ucr.edu (barrichello.cs.ucr.edu [138.23.169.5]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37NaK822740 for ; Mon, 7 Apr 2003 19:36:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 5B179AB56AF5 for ; Mon, 7 Apr 2003 16:32:49 -0700 (PDT) Mailbox-Line: From jeriksson@cs.ucr.edu Mon Apr 7 16:32:44 2003 Received: from cs.ucr.edu (posidon.cs.ucr.edu [138.23.174.164]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 18383AB56ADE for ; Mon, 7 Apr 2003 16:32:43 -0700 (PDT) Date: Mon, 7 Apr 2003 16:34:06 -0700 Subject: Re: [Ans-research] Direction of ANS RG Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jakob Eriksson To: ans-research@www1.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> Message-Id: <6CD1FA3A-6951-11D7-8E6D-000393B4A8C0@cs.ucr.edu> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 X-Virus-Scanned: by AMaViS perl-11 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi there, The topics outlined by Elisabeth earlier deal with how to recognize scalability when we see it. I would like to see some discussion on known facts/absolute truths on how to achieve scalability, to see if there are any such beasts. Of course, since scalability has yet to be defined, this will have to be a rather informal discussion. Nevertheless, it would be good to hear people's opinions in these matters. To stir up some discussion, I'd like to volunteer some candidates for known facts/absolute truths. These are the "known facts" that I'm using as guidelines in my own work. Feel free to rip them apart, and please elaborate on specific problems you see. 7 Candidates for "Known Facts" concerning MANETS ========================================= 1. Protocols that rely on flooding do not scale to large networks. To some extent, this could mean that reactive protocols aren't likely to scale, unless someone comes up with a non-flooding reactive scheme. Limited flooding may still have some merit. 2. Protocols that use a flat namespace for addresses do not scale to large networks. In essence, in order to scale to thousands of nodes or even millions of nodes, some kind of hierarchy is needed. ZRP, for example, takes a small step in that direction, but in the limit, a two-level hierarchy is almost flat anyway. 3. For scalability, the address of a node should reflect its current position in the network topology. This is similar to the previous point. If addresses indicate a position in the network, routing is very much simplified. However, it means that addresses must change as nodes change position in the network, so there may be a trade-off here. 4. Centralized services do not scale. In the optimal routing protocol, there can be no reliance on centralized services. 5. Wireless omnidirectional does not scale. In order to scale to very large networks, we have to support wires and directional antennas. That is, we cannot depend on particular characteristics of omnidirectional transmission, although we can very well use them when available. 6. How a mac/network protocol interacts with TCP is irrelevant. TCP was not made for lossy channels. Design for mac/network layer scalability and a natural transport layer will follow. 7. Last, but not least, routing protocols that rely on geographical location information are undesirable for many reasons. Beside the obvious problems (energy, bulk, cost, precision, indoor operation etc.), a geographic location does not reliably correspond to a location in a network topology. Two disjoint domains could very well coexist in the same geographical location, with an intersection in some other part of the world. Thus, relying on GPS or equiv. even for rough guidance, may be very harmful for large networks. Note that the above is not criticism against anyone's earlier, current or future work, but simply a controversial starting point for discussion. I'd love to see more candidates for absolute truths, and arguments for and against those mentioned above. Flame away, =) Jakob Eriksson U.C. Riverside * The opinions expressed above are mine and not necessarily the policy of my school, department, research group or advisor =) * _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 05:17:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03170 for ; Tue, 8 Apr 2003 05:17:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h389LiH06032 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 05:21:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h389Lh806029 for ; Tue, 8 Apr 2003 05:21:43 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03167 for ; Tue, 8 Apr 2003 05:16:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h389A4805563; Tue, 8 Apr 2003 05:10:04 -0400 Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3899o805529 for ; Tue, 8 Apr 2003 05:09:50 -0400 Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id LAA16074; Tue, 8 Apr 2003 11:07:07 +0200 (MET DST) Message-ID: <3E92912A.5090306@telecom.lth.se> Date: Tue, 08 Apr 2003 11:06:50 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Eriksson , ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG References: <6CD1FA3A-6951-11D7-8E6D-000393B4A8C0@cs.ucr.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, I think the first aim of this group should be to produce a document like RFC 2501, but for large and scalable ad hoc networks. As Elzabeth says, this document should discuss the problems we are facing, known issues, various performance and evaluation criterias etc. Although larger ad hoc networks have many similarities with smaller or moderate networks, the design considerations are different. We still consider the same issues and problems, but some of the existing problems tend to grow with the size of the network. As already mentioned, we must consider the number of nodes, network size, traffic model, rate of mobility. We should try to visualize the properties future applications will have. Will these produce bursty traffic or more smooth traffic. In some cases, the type of expected applications and their expected traffic and mobility patterns, might have a vital impact on the performance of the network. An other very important part is the density of the network. This is important both in terms of congestion and overload, and in terms of connectivity. A sparse network might have low connectivity while a dense network might have a very high connectivity. But the dense network also has higher congestion and traffic/routing load. It would be nice if we could have a common set of performance metrics, that reflect the scalability of the network. > 1. Protocols that rely on flooding do not scale to large networks. > To some extent, this could mean that reactive protocols aren't > likely to scale, unless someone comes up with a non-flooding > reactive scheme. Limited flooding may still have some merit. I agree, but this also depends on the amount traffic in the network. S.J. Lee et al. showed that AODV could scale to very larger network. When the amount of traffic was fairly low. Pure proactive schemes, except maybe LANMAR, all tend to scale poorly. > > 2. Protocols that use a flat namespace for addresses do not > scale to large networks. In essence, in order to scale to thousands > of nodes or even millions of nodes, some kind of hierarchy is > needed. ZRP, for example, takes a small step in that direction, but > in the limit, a two-level hierarchy is almost flat anyway. I agree that we probably need some kind of hierarchy when the network becomes very large. But this is not the same thing as having a hierarchical namespace. I think it is possible to come with solutions that use a flat addressing scheme, but that still relies on a hierarchy. > > 3. For scalability, the address of a node should reflect its current > position in the network topology. This is similar to the previous > point. If addresses indicate a position in the network, routing is very > much simplified. However, it means that addresses must change > as nodes change position in the network, so there may be a > trade-off here. Yes, the problem here becomes a mobile IP sort of problem. For this to work we need some kind of handover sheme and/or lookup scheme. When a node receives a new address, the old one will no longer be available, e.g. hard handover. If the network is a hybrid one, we can probably use existing solutions. But if it is a pure ad hoc network, the problem becomes more difficult to solve, at least for ongoing sessions and proactive schemes > 4. Centralized services do not scale. In the optimal routing protocol, > there can be no reliance on centralized services. Why not? I am not saying having centralized services is optimal, but I do think centralized services can help scalability. Say we a special node in the network providing a special service such as DNS. If all nodes in the network know of this node, or neighboring nodes know of it, a node doesn't need to first serach for it. The node could then unicast/mulicast/anycast packets to the intended service node. This might not be optimal, and it do make the network more vulnerable, but I think it will improve scalability. By the way, I don't think there will ever be an optimal routing protocol, a one size fits all. > > 5. Wireless omnidirectional does not scale. In order to scale to very > large networks, we have to support wires and directional antennas. > That is, we cannot depend on particular characteristics of > omnidirectional transmission, although we can very well use them > when available. Right. Directional antennas will surely improve performance, but we shouldn't have to rely on them either. > > 6. How a mac/network protocol interacts with TCP is irrelevant. > TCP was not made for lossy channels. Design for mac/network > layer scalability and a natural transport layer will follow. I think what you say here is a contradiction. I think a TCP version that handle large network with lossy channels will developed, but only through interaction with the mac and network levels. So the mac/network and transport layer interaction is very much relevant, and is an area that I think should receive more attention. > > 7. Last, but not least, routing protocols that rely on geographical > location information are undesirable for many reasons. Beside > the obvious problems (energy, bulk, cost, precision, indoor > operation etc.), a geographic location does not reliably correspond > to a location in a network topology. Two disjoint domains could > very well coexist in the same geographical location, with an > intersection in some other part of the world. Thus, relying on GPS > or equiv. even for rough guidance, may be very harmful for large > networks. > I can't say I agree with you here at all. The obvious problems you mentioned are so obvious at all. The GPS technology is developing all the time, and the devices themselves becomes smaller and more power conservative. In future there is a possibility that all network equipped devices will also include GPS or similiar devices. And what is the problem of having two disjoint domains coexisting in the same geographical area? Maybe, if you force the addressing scheme to stricly reflect your position, will you have problems with this. But that is an addressing problem, not a routing problem. The problem is how to determine the position of a node. There are numerous solutions to how this problem can be solved, and some of them work quite well. But there are reason for taking advantage of GPS information. There are many applications that could benefit from having an exact geographical position, not the least military applications, but also many civilian ones. regards, Anders Nilsson _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 06:35:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05221 for ; Tue, 8 Apr 2003 06:35:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38AduY11850 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 06:39:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ade811836 for ; Tue, 8 Apr 2003 06:39:40 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05195 for ; Tue, 8 Apr 2003 06:34:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38AVA810627; Tue, 8 Apr 2003 06:31:10 -0400 Received: from cheviot3.ncl.ac.uk (IDENT:root@cheviot3.ncl.ac.uk [128.240.233.117]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38AUs810576 for ; Tue, 8 Apr 2003 06:30:54 -0400 Received: from ncl.ac.uk (deerbook.ncl.ac.uk [128.240.149.114]) by cheviot3.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id h38ASCO13174; Tue, 8 Apr 2003 11:28:13 +0100 Date: Tue, 8 Apr 2003 11:28:11 +0100 Subject: Re: [Ans-research] Direction of ANS RG Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Elizabeth M. Belding-Royer" , ans-research@www1.ietf.org To: John Stine From: Einar Vollset In-Reply-To: <3E91E265.693AA23B@mitre.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Newcastle-MailScanner: Found to be clean Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > All, > I was looking forward to a new mailing list that would have a more > research oriented nature but must admit that I am a bit disappointed > that we have chosen scalability as our focus. This appears to be an > effort to create the environments in which to compare the IETF MANET > routing protocol solutions rather than an effort to find new and better > solutions for all aspects of ad hoc networking. I must say I agree with John here. On the MANET list, we were urged to stop discussing research topics in order to focus more on the engineering aspects and getting protocols to Experimental RFC status, and setting up an IRTF list was hailed as the answer. Not that I don't think scalability is important, quite the contrary, but it does mean that research on MANETs in other areas such as reliability, QoS, services++ are left in the lurk. I suppose the answer to this is setting up another mailing list.. Cheers, Einar _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 06:51:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05789 for ; Tue, 8 Apr 2003 06:51:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38AuQe13145 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 06:56:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38AuQ813142 for ; Tue, 8 Apr 2003 06:56:26 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05783 for ; Tue, 8 Apr 2003 06:51:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Am1812271; Tue, 8 Apr 2003 06:48:01 -0400 Received: from cheviot3.ncl.ac.uk (IDENT:root@cheviot3.ncl.ac.uk [128.240.233.117]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38AlW812219 for ; Tue, 8 Apr 2003 06:47:32 -0400 Received: from ncl.ac.uk (deerbook.ncl.ac.uk [128.240.149.114]) by cheviot3.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id h38AirO17995; Tue, 8 Apr 2003 11:44:53 +0100 Date: Tue, 8 Apr 2003 11:44:52 +0100 Subject: Re: [Ans-research] Direction of ANS RG Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ans-research@www1.ietf.org To: Jakob Eriksson From: Einar Vollset In-Reply-To: <6CD1FA3A-6951-11D7-8E6D-000393B4A8C0@cs.ucr.edu> Message-Id: <20E55256-69AF-11D7-BD1F-000A9575BD30@ncl.ac.uk> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Newcastle-MailScanner: Found to be clean Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > 4. Centralized services do not scale. In the optimal routing protocol, > there can be no reliance on centralized services. On the routing level I definately agree with this. To me, this is one of the key characteristics and benefits of MANETs. > > 5. Wireless omnidirectional does not scale. In order to scale to very > large networks, we have to support wires and directional antennas. > That is, we cannot depend on particular characteristics of > omnidirectional transmission, although we can very well use them > when available. I'll have to disagree on this point. I think what is required is a fundamental shift in thinking about routing as something which happens in one-dimensional space to two-dimensional space. My belief is that the omnidirectional property of 99.99% of packet radios can be utilized to the benefit of the routing protocol. (A very simple example is the use of passive acknowledgments as hinted at in the original ODMRP paper). (At least this is my own personal crusade at the moment.. ) > > > 7. Last, but not least, routing protocols that rely on geographical > location information are undesirable for many reasons. Beside > the obvious problems (energy, bulk, cost, precision, indoor > operation etc.), a geographic location does not reliably correspond > to a location in a network topology. Two disjoint domains could > very well coexist in the same geographical location, with an > intersection in some other part of the world. Thus, relying on GPS > or equiv. even for rough guidance, may be very harmful for large > networks. I agree with Anders on this, I think location information will become more and more common (it is, after all one of the key points in the current push for pervasive/ubiquitous computing), and I think not making use of it would be rather silly :-) Cheers, Einar _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 07:26:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06719 for ; Tue, 8 Apr 2003 07:26:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38BVAe16144 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 07:31:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38BUt816125 for ; Tue, 8 Apr 2003 07:30:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06701 for ; Tue, 8 Apr 2003 07:25:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38BMH815871; Tue, 8 Apr 2003 07:22:17 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38BLL815826 for ; Tue, 8 Apr 2003 07:21:21 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HD000201VF1L1@mailout3.samsung.com> for ans-research@www1.ietf.org; Tue, 08 Apr 2003 20:18:37 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HD000H7PVF06M@mailout3.samsung.com> for ans-research@www1.ietf.org; Tue, 08 Apr 2003 20:18:37 +0900 (KST) Received: from Shubhranshu ([75.2.47.220]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HD0008S4VF00A@mmp2.samsung.com> for ans-research@www1.ietf.org; Tue, 08 Apr 2003 20:18:36 +0900 (KST) Date: Tue, 08 Apr 2003 20:16:42 -0800 From: Shubhranshu Subject: Re: [Ans-research] Direction of ANS RG To: John Stine , "Elizabeth M. Belding-Royer" Cc: ans-research@www1.ietf.org Reply-to: Shubhranshu Message-id: <022001c2fe4e$d3dee6a0$dc2f024b@Shubhranshu> Organization: Samsung MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> <3E91E265.693AA23B@mitre.org> Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT hello, > I was looking forward to a new mailing list that would have a more > research oriented nature but must admit that I am a bit disappointed > that we have chosen scalability as our focus. This appears to be an > effort to create the environments in which to compare the IETF MANET > routing protocol solutions rather than an effort to find new and better > solutions for all aspects of ad hoc networking. I feel ( and wish) that most members won't go for creating environments to compare MANET protocol solutions. As most of the MANET protocols doesn't scale well. AODV has been shown to be a better SCALABLE candidate, but then here SCALABLE means millions of nodes not just hundreds. > There is a very rich > design space at the physical layer but the IETF MANET charter to focus > on IP routing solutions has separated this design space from potential > solutions. The recent discussions on the MANET mailing list on > interlayer communication and dependence is far more interesting and > would be the direction I would want a new group to follow. Would it be > possible to allow the discussion to go in this direction? I favour considering discussion about interlayer communication and dependence but its my feeling that by itself, it won't give us the real Scalable network that we are looking for. For that we need to focus on ADDRESSING MECHANISM. > > Some topics I would like to see discussed is an articulation of the > pros and cons of implementing routing above and below IP. Can > functionality be divided? Can routing be integrated with an access > protocol? How can such integration be exploited to improve networking > performance? What functionality has to be above IP to give layers 4+ an > interface that remains quinessentially IP? What capability should > higher layer protocols have to affect the operation of lower layer > protocols for purposes of QoS, security, or some other goal? Is the > 802.11 layer 1 and 2 solution the best we can do? Say an access > protocol provides a QoS capability, how should a higher layer protocol > communicate its selection? What are the mechanisms for interlayer > communication (read this as IP and above to and from below IP)? I know > positions on these topics border on being religious beliefs but it seems > silly to me to limit our design space. Any discussion which may lead to better scalable network are welcome. > John > > > > "Elizabeth M. Belding-Royer" wrote: > > > Hi, > > > > There are a number of you on the mailing list now so I think we > > should start discussing the direction and emphasis of this research > > group. > > > > At the Bar BOF at the IETF meeting, we talked about a number of > > potential directions for the group. The over-riding point that > > became evident as we continued our discussion was that we need > > a clear definition of what scalability is. Since the group's > > focus is scalability in ad hoc networks, we need to first define > > the problem we are working on before we can begin to propose > > solutions. This topic has been discussed in a different flavor > > on the MANET mailing list in terms of trying to define the type > > of network the MANET group should focus on. It has become evident > > from these discussions that there are a number of dimensions > > to defining a network. Likewise, there will be multiple dimensions > > to consider when defining scalability. These are likely to include > > number of nodes, network size, traffic model, mobility, and others. > > > > One of the first things that could be a product of this research > > group is an information document defining scalability along all > > of the different possible axes. This will enable us to focus more > > clearly on the type of networks we are researching. It will also > > most likely benefit the MANET group as well. > > > > Does anyone have thoughts either on this as our future direction or > > on how to begin undertaking this task? > > > > Elizabeth > > > > _______________________________________________ > > Ans-research mailing list > > Ans-research@www1.ietf.org > > https://www1.ietf.org/mailman/listinfo/ans-research > > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research > _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 07:32:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06977 for ; Tue, 8 Apr 2003 07:32:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38BbCK16866 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 07:37:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38BbC816863 for ; Tue, 8 Apr 2003 07:37:12 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06946 for ; Tue, 8 Apr 2003 07:32:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Bb3816517; Tue, 8 Apr 2003 07:37:03 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Bag816395 for ; Tue, 8 Apr 2003 07:36:42 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HD000301W4M1M@mailout3.samsung.com> for ans-research@www1.ietf.org; Tue, 08 Apr 2003 20:33:58 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HD000IMPW4MBI@mailout3.samsung.com> for ans-research@www1.ietf.org; Tue, 08 Apr 2003 20:33:58 +0900 (KST) Received: from Shubhranshu ([75.2.47.220]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HD00081YW4M0A@mmp2.samsung.com> for ans-research@www1.ietf.org; Tue, 08 Apr 2003 20:33:58 +0900 (KST) Date: Tue, 08 Apr 2003 20:32:04 -0800 From: Shubhranshu Subject: Re: [Ans-research] Direction of ANS RG To: Anders Nilsson , Jakob Eriksson , ans-research@www1.ietf.org Reply-to: Shubhranshu Message-id: <024201c2fe50$f8fb1b00$dc2f024b@Shubhranshu> Organization: Samsung MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6CD1FA3A-6951-11D7-8E6D-000393B4A8C0@cs.ucr.edu> <3E92912A.5090306@telecom.lth.se> Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, > > I think the first aim of this group should be to produce a document like > RFC 2501, but for large and scalable ad hoc networks. As Elzabeth says, > this document should discuss the problems we are > facing, known issues, various performance and evaluation criterias etc. > Although larger ad hoc networks have many similarities with smaller or > moderate networks, the design considerations are different. We still > consider the same issues and problems, but some of the existing problems > tend to grow with the size of the network. > > As already mentioned, we must consider the number of nodes, network > size, traffic model, rate of mobility. We should try to visualize the > properties future applications will have. Will these produce bursty > traffic or more smooth traffic. In some cases, the type of expected > applications and their expected traffic and mobility patterns, might > have a vital impact on the performance of the network. > An other very important part is the density of the network. This is > important both in terms of congestion and overload, and in terms of > connectivity. A sparse network might have low connectivity while a dense > network might have a very high connectivity. But the dense network also > has higher congestion and traffic/routing load. > It would be nice if we could have a common set of performance metrics, > that reflect the scalability of the network. > > > 1. Protocols that rely on flooding do not scale to large networks. > > To some extent, this could mean that reactive protocols aren't > > likely to scale, unless someone comes up with a non-flooding > > reactive scheme. Limited flooding may still have some merit. > > I agree, but this also depends on the amount traffic in the network. > S.J. Lee et al. showed that AODV could scale to very larger network. > When the amount of traffic was fairly low. Pure proactive schemes, > except maybe LANMAR, all tend to scale poorly. Yes, AODV does scale to very large network but I feel this scalabality should not be our concern here. Scalabality here should IDEALLY mean scaling to the size of the internet !!!! And to achieve this we have to start AFRESH !!!! > > 2. Protocols that use a flat namespace for addresses do not > > scale to large networks. In essence, in order to scale to thousands > > of nodes or even millions of nodes, some kind of hierarchy is > > needed. ZRP, for example, takes a small step in that direction, but > > in the limit, a two-level hierarchy is almost flat anyway. > > I agree that we probably need some kind of hierarchy when the network > becomes very large. But this is not the same thing as having a > hierarchical namespace. I think it is possible to come with solutions > that use a flat addressing scheme, but that still relies on a hierarchy. So far I feel hierarchical based addressing is the path that may lead us to a real scalable network !!!!! Warm Regards Shubhranshu Singh _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 08:11:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08049 for ; Tue, 8 Apr 2003 08:11:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38CGK919611 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 08:16:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CGK819608 for ; Tue, 8 Apr 2003 08:16:20 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08009 for ; Tue, 8 Apr 2003 08:11:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CG1819600; Tue, 8 Apr 2003 08:16:01 -0400 Received: from gandalf.icr.a-star.edu.sg (gandalf.icr.a-star.edu.sg [137.132.31.244]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CFk819561 for ; Tue, 8 Apr 2003 08:15:46 -0400 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h38CDbGi003688 for ; Tue, 8 Apr 2003 20:13:37 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Tue, 08 Apr 2003 20:05:26 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 8AB7A30536; Tue, 8 Apr 2003 20:12:54 +0800 (SGT) Date: Tue, 8 Apr 2003 20:12:54 +0800 From: Sukanta Kumar Hazra To: ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG Message-ID: <20030408121254.GA12240@localhost> Mail-Followup-To: ans-research@www1.ietf.org References: <3E91E265.693AA23B@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Einar, > I must say I agree with John here. On the MANET list, we were urged to > stop discussing research topics in order to focus more on the > engineering > aspects and getting protocols to Experimental RFC status, and setting > up an IRTF list was hailed as the answer. > Not that I don't think scalability is important, > quite the contrary, but it does mean that research on MANETs in other > areas such as reliability, QoS, services++ are left in the lurk. > > I suppose the answer to this is setting up another mailing list.. You have issues with the term "scalability", which I can appreciate. However if I recall correctly then most of the issues that you mentioned were discussed in the BAR BOF. Except for security, I can't remember any other topic being shown a red flag. Maybe we should not take "scalability" in a narrow sense, and instead look at research that enable scalable ad hoc networks, which include reliability etc. And I haven't encountered any opposition to discussion on QoS etc. on this list, so why is there a need for new list? - Sukanta > > Cheers, > > Einar > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research -- _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 08:14:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08105 for ; Tue, 8 Apr 2003 08:14:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38CJ9R19715 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 08:19:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CJ9819712 for ; Tue, 8 Apr 2003 08:19:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08102 for ; Tue, 8 Apr 2003 08:13:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CJ0819702; Tue, 8 Apr 2003 08:19:00 -0400 Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CIl819682 for ; Tue, 8 Apr 2003 08:18:47 -0400 Received: from verdi.ece.cornell.edu (verdi.ece.cornell.edu [128.84.210.27]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id h38CG8R21590; Tue, 8 Apr 2003 08:16:08 -0400 Date: Tue, 8 Apr 2003 08:15:11 -0400 (EDT) From: To: ans-research@www1.ietf.org cc: Zygmunt Haas Subject: [Ans-research] Direction of ANS RG In-Reply-To: <20E55256-69AF-11D7-BD1F-000A9575BD30@ncl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Dear All, With regards to scalability .... I think that before we jump into any conclusions and set up "universal truths," we need to make sure that we are comparing apples with apples ... In my understanding, "scalability" is a complex issue and I am not even sure that we all mean the same thing .... I think that we all understand that scalability means that we increase SOMETHING#1 and that this increase has an effect on SOMETHING#2. But what these SOMETHING#1 and SOMETHING#2 are may not be universally agreed upon. To be more specific, we can talk about SOMETHING#1 as the number of nodes in the network (probably the common conception), but it can also be the coverage area of the network (i.e., the size of the network), the density of nodes, etc. Similarly, SOMETHING#2 could be the delay or throughput (again, probably the common conception), but it could also be the processing (computational) load, the increase in the amount of control traffic (i.e., network management cost, the energy usage (i.e., network lifetime), etc. Therefore, maybe the right approach would be to set up a set of independent parameters (the SOMETHING#1's) and the set of matrics (the SOMETHING#2's). I.e., both SOMETHING#1 and SOMETHING#2 are *vectors*. Not to even mention the issue of what we define as "scalable." Gupta and Kumar in their paper discussed scalability of the end-to-end throughput of wireless ad hoc networks and concluded that it behaves as O(1/sqrt(N)), where N is the number of nodes in the network. Is this scalable? Probably not. So what could we define as scalable? Maybe the right thing is to talk about relative scalability, rather than in absolute terms; i.e., to compare the scalability of one protocol vs. another. With this approach, we could say, for example, that protocol#1 is more scalable than protocol#2, when scalability is defined as the increase in the end-to-end delay with the increase in the node density. And further, all this would be meaningless, if we do not state the conditions of such an evaluation. For example, what is the mobility model (some protocols will behave differently in stationary environment, vs. highly mobile environment), or what is the transmission/propagation models, etc, etc, etc. In other words, I think that the first step would be for us to precisely define what is it that we want to evaluate and to "synchronize" our terms. With regards to the "charter" of the group ... I think that we should expand it to more than just the scalability issue. I, for one, would like to see some discussion about QoS, security, etc. Zygmunt. ===--==-==== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 08:43:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08511 for ; Tue, 8 Apr 2003 08:43:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Clwu21668 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 08:47:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Clw821665 for ; Tue, 8 Apr 2003 08:47:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08495 for ; Tue, 8 Apr 2003 08:42:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Cll821646; Tue, 8 Apr 2003 08:47:47 -0400 Received: from gandalf.icr.a-star.edu.sg (gandalf.icr.a-star.edu.sg [137.132.31.244]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Cja821495 for ; Tue, 8 Apr 2003 08:45:37 -0400 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h38ChUGi003897 for ; Tue, 8 Apr 2003 20:43:31 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Tue, 08 Apr 2003 20:35:17 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id B3C4F2EE1; Tue, 8 Apr 2003 20:42:48 +0800 (SGT) Date: Tue, 8 Apr 2003 20:42:48 +0800 From: Sukanta Kumar Hazra To: ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG Message-ID: <20030408124248.GC12240@localhost> Mail-Followup-To: ans-research@www1.ietf.org References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> <6CD1FA3A-6951-11D7-8E6D-000393B4A8C0@cs.ucr.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CD1FA3A-6951-11D7-8E6D-000393B4A8C0@cs.ucr.edu> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Jakob, > 7 Candidates for "Known Facts" concerning MANETS > ========================================= > > 1. Protocols that rely on flooding do not scale to large networks. > To some extent, this could mean that reactive protocols aren't > likely to scale, unless someone comes up with a non-flooding > reactive scheme. Limited flooding may still have some merit. You obviously mean global flooding right. > > 2. Protocols that use a flat namespace for addresses do not > scale to large networks. In essence, in order to scale to thousands > of nodes or even millions of nodes, some kind of hierarchy is > needed. ZRP, for example, takes a small step in that direction, but > in the limit, a two-level hierarchy is almost flat anyway. I couldn't agree more. > > 3. For scalability, the address of a node should reflect its current > position in the network topology. This is similar to the previous > point. If addresses indicate a position in the network, routing is very > much simplified. However, it means that addresses must change > as nodes change position in the network, so there may be a > trade-off here. Its a strong SHOULD. If addresses change frequently, then we could have a lot of issues there. Maintaining TCP session comes to mind. > > 4. Centralized services do not scale. In the optimal routing protocol, > there can be no reliance on centralized services. Agree. > > 5. Wireless omnidirectional does not scale. In order to scale to very > large networks, we have to support wires and directional antennas. > That is, we cannot depend on particular characteristics of > omnidirectional transmission, although we can very well use them > when available. > > 6. How a mac/network protocol interacts with TCP is irrelevant. > TCP was not made for lossy channels. Design for mac/network > layer scalability and a natural transport layer will follow. "irrelevant"! > > 7. Last, but not least, routing protocols that rely on geographical > location information are undesirable for many reasons. Beside > the obvious problems (energy, bulk, cost, precision, indoor > operation etc.), a geographic location does not reliably correspond > to a location in a network topology. Two disjoint domains could > very well coexist in the same geographical location, with an > intersection in some other part of the world. Thus, relying on GPS > or equiv. even for rough guidance, may be very harmful for large > networks. But it may be less complex. > > Note that the above is not criticism against anyone's earlier, current > or future work, but simply a controversial starting point for > discussion. > I'd love to see more candidates for absolute truths, and arguments > for and against those mentioned above. Flame away, =) Another "absolute truth" is that the network (ad hoc or otherwise) is there for applications. Most applications at present are based on the client-server model (not distributed). Some application frameworks such as peer-to-peer are more suited to ad hoc networks, since they localize the communication. It is something that we must keep in mind, though this group is not working on application frameworks. Yet another "absolute truth" is that there should be mechanisms to take into account node capabilities (power, willingness to route, cpu cycles), in essence some policy based routing. - Sukanta _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 08:57:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08902 for ; Tue, 8 Apr 2003 08:57:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38D1wV22360 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 09:01:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38D1v822357 for ; Tue, 8 Apr 2003 09:01:58 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08873 for ; Tue, 8 Apr 2003 08:56:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38D1m822336; Tue, 8 Apr 2003 09:01:48 -0400 Received: from gandalf.icr.a-star.edu.sg (gandalf.icr.a-star.edu.sg [137.132.31.244]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Cuv822117 for ; Tue, 8 Apr 2003 08:56:58 -0400 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h38CsmGi003950 for ; Tue, 8 Apr 2003 20:54:48 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Tue, 08 Apr 2003 20:46:40 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 1CD4F30536; Tue, 8 Apr 2003 20:22:34 +0800 (SGT) Date: Tue, 8 Apr 2003 20:22:34 +0800 From: Sukanta Kumar Hazra To: ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG Message-ID: <20030408122234.GB12240@localhost> Mail-Followup-To: ans-research@www1.ietf.org References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> <3E91E265.693AA23B@mitre.org> <022001c2fe4e$d3dee6a0$dc2f024b@Shubhranshu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022001c2fe4e$d3dee6a0$dc2f024b@Shubhranshu> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , A PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Shubhranshu, > I feel ( and wish) that most members won't go for > creating environments to compare MANET protocol solutions. As most of > the MANET protocols doesn't scale well. AODV has been shown to be > a better SCALABLE candidate, but then here SCALABLE means millions of > nodes not just hundreds. Hmm... that is where the argument starts. "AODV has been shown to be a better SCALABLE candidate", using which metric? I am not against having a metric which I could refer to when making those statements. A standard metric and scenarios are most welcome. > > > There is a very rich > > design space at the physical layer but the IETF MANET charter to focus > > on IP routing solutions has separated this design space from potential > > solutions. The recent discussions on the MANET mailing list on > > interlayer communication and dependence is far more interesting and > > would be the direction I would want a new group to follow. Would it be > > possible to allow the discussion to go in this direction? I wouldn't mind any discussion as long as it is related to MANET on this list. Whether that is the direction (main focus?) that this research group should take is debatable (as is most things). > > I favour considering discussion about interlayer communication and > dependence > but its my feeling that by itself, it won't give us the real Scalable > network that we are looking for. For that we need to > focus on ADDRESSING MECHANISM. Another focus. > > > > > > Some topics I would like to see discussed is an articulation of the > > pros and cons of implementing routing above and below IP. Can > > functionality be divided? Can routing be integrated with an access > > protocol? How can such integration be exploited to improve networking > > performance? What functionality has to be above IP to give layers 4+ an > > interface that remains quinessentially IP? What capability should > > higher layer protocols have to affect the operation of lower layer > > protocols for purposes of QoS, security, or some other goal? Is the > > 802.11 layer 1 and 2 solution the best we can do? Say an access > > protocol provides a QoS capability, how should a higher layer protocol > > communicate its selection? What are the mechanisms for interlayer > > communication (read this as IP and above to and from below IP)? I know > > positions on these topics border on being religious beliefs but it seems > > silly to me to limit our design space. > > > Any discussion which may lead to better scalable network are welcome. The punch line. - Sukanta _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 08:58:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08965 for ; Tue, 8 Apr 2003 08:58:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38D3Al22481 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 09:03:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38D39822478 for ; Tue, 8 Apr 2003 09:03:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08938 for ; Tue, 8 Apr 2003 08:57:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38D30822464; Tue, 8 Apr 2003 09:03:00 -0400 Received: from cheviot3.ncl.ac.uk (IDENT:root@cheviot3.ncl.ac.uk [128.240.233.117]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38D25822393 for ; Tue, 8 Apr 2003 09:02:05 -0400 Received: from ncl.ac.uk (deerbook.ncl.ac.uk [128.240.149.114]) by cheviot3.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id h38CxJO22179; Tue, 8 Apr 2003 13:59:20 +0100 Date: Tue, 8 Apr 2003 13:59:19 +0100 Subject: Re: [Ans-research] Direction of ANS RG Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ans-research@www1.ietf.org To: Sukanta Kumar Hazra From: Einar Vollset In-Reply-To: <20030408121254.GA12240@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Newcastle-MailScanner: Found to be clean Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sukanta, On Tuesday, Apr 8, 2003, at 13:12 Europe/London, Sukanta Kumar Hazra wrote: > > You have issues with the term "scalability", which I can appreciate. > However if I recall correctly then most of the issues that you > mentioned > were discussed in the BAR BOF. Unfortunately I was unable to attend the BOF, and have been unable to find any description of what was discussed. I base most of my assumptions about the subgroup's research goals from the charter: http://www.flarion.com/ans-research > Except for security, I can't remember any > other topic being shown a red flag. Forgive my ignorance, but do you mean red flag as in: Not in scope of ANS? > Maybe we should not take > "scalability" in a narrow sense, and instead look at research that > enable scalable ad hoc networks, which include reliability etc. > And I > haven't encountered any opposition to discussion on QoS etc. on this > list, so why is there a need for new list? If this is the case, then you're right, there isn't a need for another forum, however reliability and scalability in my limited experience tends to (at least initially) be orthogonal issues, so providing reliability doesn't necessarily enhance scalability, quite the contrary. I think the same might be the case with security,etc. It would at the very least be constraining if the only research into reliability, Qos, security, etc that can be discussed is that which enhances scalability. I'd like to hear the chairs' opinions on this? Cheers, Einar _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 09:42:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09816 for ; Tue, 8 Apr 2003 09:42:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38DlHm26009 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 09:47:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38DlH826006 for ; Tue, 8 Apr 2003 09:47:17 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09802 for ; Tue, 8 Apr 2003 09:42:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Dl2825995; Tue, 8 Apr 2003 09:47:02 -0400 Received: from gandalf.icr.a-star.edu.sg (gandalf.icr.a-star.edu.sg [137.132.31.244]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Dki825973 for ; Tue, 8 Apr 2003 09:46:45 -0400 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h38DiZGi004306 for ; Tue, 8 Apr 2003 21:44:35 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Tue, 08 Apr 2003 21:36:24 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id BCE0E30947; Tue, 8 Apr 2003 21:43:53 +0800 (SGT) Date: Tue, 8 Apr 2003 21:43:53 +0800 From: Sukanta Kumar Hazra To: ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG Message-ID: <20030408134353.GA12552@localhost> Mail-Followup-To: ans-research@www1.ietf.org References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304071856.h37IuZC11845@letters.cs.ucsb.edu> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , I support any work that would define scalability and provide a scalability metric along with a set of scenarios to evaluate scalability of MANET routing protocols. I see that as the first step towards scalability research. - Sukanta ----- Original Message ----- From: ""Elizabeth M. Belding-Royer" " Date: Tue, 08 Apr, 2003 02:56 SGT Subject: [Ans-research] Direction of ANS RG > Hi, > > There are a number of you on the mailing list now so I think we > should start discussing the direction and emphasis of this research > group. > > At the Bar BOF at the IETF meeting, we talked about a number of > potential directions for the group. The over-riding point that > became evident as we continued our discussion was that we need > a clear definition of what scalability is. Since the group's > focus is scalability in ad hoc networks, we need to first define > the problem we are working on before we can begin to propose > solutions. This topic has been discussed in a different flavor > on the MANET mailing list in terms of trying to define the type > of network the MANET group should focus on. It has become evident > from these discussions that there are a number of dimensions > to defining a network. Likewise, there will be multiple dimensions > to consider when defining scalability. These are likely to include > number of nodes, network size, traffic model, mobility, and others. > > One of the first things that could be a product of this research > group is an information document defining scalability along all > of the different possible axes. This will enable us to focus more > clearly on the type of networks we are researching. It will also > most likely benefit the MANET group as well. > > Does anyone have thoughts either on this as our future direction or > on how to begin undertaking this task? > > Elizabeth > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research -- _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 12:06:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20279 for ; Tue, 8 Apr 2003 12:06:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38GBJ007008 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 12:11:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GBJ807005 for ; Tue, 8 Apr 2003 12:11:19 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20261 for ; Tue, 8 Apr 2003 12:06:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GB5806953; Tue, 8 Apr 2003 12:11:05 -0400 Received: from eigen.ee.ualberta.ca (eigen.ee.ualberta.ca [129.128.68.7]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38G3R805528 for ; Tue, 8 Apr 2003 12:03:27 -0400 Received: from webmail.ualberta.ca (webmail.srv.ualberta.ca [129.128.5.105]) by eigen.ee.ualberta.ca (8.9.3 (PHNE_24419+JAGae58098)/8.9.3) with ESMTP id JAA25074; Tue, 8 Apr 2003 09:55:09 -0600 (MDT) X-WebMail-UserID: snagaraj@ee.ualberta.ca Date: Tue, 8 Apr 2003 10:02:37 -0600 From: Sumeeth Nagaraj To: , ans-research X-EXP32-SerialNo: 00003228 Subject: RE: [Ans-research] Direction of ANS RG Message-ID: <3E94098E@webmail.ualberta.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.61.08 Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, Well, I agree with your point that there should be some common platform to compare the protocols inorder to use the term relative scalability. And its a non trivial issue. With scalability, Interlayer Interaction and to a certain level considering the MAC layer issues looks pretty promising to me. The results in the Gupta and Kumar paper considers each packet to travel an "Avg distance" which may not be the case in practical situation. Another aspect that needs to be stressed here is the underlying MAC and the Physical layer model that put those constraints and hence the throughput being O(Sqrt(N)) for the entire network. Best Regards, Sumeeth >Not to even mention the issue of what we define as "scalable." >Gupta and Kumar in their paper discussed scalability of the end-to-end >throughput of wireless ad hoc networks and concluded that it behaves as >O(1/sqrt(N)), where N is the number of nodes in the network. Is this >scalable? Probably not. So what could we define as scalable? Maybe the >right thing is to talk about relative scalability, rather than in absolute >terms; i.e., to compare the scalability of one protocol vs. another. With >this approach, we could say, for example, that protocol#1 is more scalable >than protocol#2, when scalability is defined as the increase in the >end-to-end delay with the increase in the node density. _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 12:10:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20476 for ; Tue, 8 Apr 2003 12:10:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38GF8r07301 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 12:15:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GF8807294 for ; Tue, 8 Apr 2003 12:15:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20462 for ; Tue, 8 Apr 2003 12:09:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GF1807259; Tue, 8 Apr 2003 12:15:01 -0400 Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GEO807219 for ; Tue, 8 Apr 2003 12:14:24 -0400 Received: from sdn-ar-014casfrmp028.dialsprint.net ([158.252.218.30] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 192vh9-0007eC-00; Tue, 08 Apr 2003 09:11:36 -0700 Message-ID: <3E92F496.6175DEFE@earthlink.net> Date: Tue, 08 Apr 2003 09:11:02 -0700 From: Richard Ogier X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: haas@ece.cornell.edu CC: ans-research@www1.ietf.org Subject: Re: [Ans-research] Direction of ANS RG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Not to even mention the issue of what we define as "scalable." > Gupta and Kumar in their paper discussed scalability of the end-to-end > throughput of wireless ad hoc networks and concluded that it behaves as > O(1/sqrt(N)), where N is the number of nodes in the network. Is this > scalable? Probably not. So what could we define as scalable? Maybe the > right thing is to talk about relative scalability, rather than in absolute > terms; i.e., to compare the scalability of one protocol vs. another. With > this approach, we could say, for example, that protocol#1 is more scalable > than protocol#2, when scalability is defined as the increase in the > end-to-end delay with the increase in the node density. Or we could define a protocol to be scalable if it achieves (on the order of) the theoretically best achievable scalability. For example, to achieve scalability with hierarchical routing, we would need O(log N) levels. A 2-level hierarchy is "more scalable" than a 1-level hierarchy but is not scalable in the above sense. On another topic, I don't think that the total amount of traffic (or the number of streams) is an independent scalability parameter. For example, maybe it should be assumed to be proportional to the number of nodes in the network (to simplify the definition). Someone mentioned that AODV has been shown to be scalable with light traffic. If that means keeping the number of streams constant while increasing the number of nodes, then I would not call that scalable. Richard _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 12:10:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20477 for ; Tue, 8 Apr 2003 12:10:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38GF8W07311 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 12:15:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GF8807296 for ; Tue, 8 Apr 2003 12:15:08 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20464 for ; Tue, 8 Apr 2003 12:09:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GF1807276; Tue, 8 Apr 2003 12:15:01 -0400 Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GEP807223 for ; Tue, 8 Apr 2003 12:14:25 -0400 Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with SMTP id h38GBeC06370 for ; Tue, 8 Apr 2003 09:11:40 -0700 (PDT) Message-Id: <200304081611.h38GBeC06370@letters.cs.ucsb.edu> Date: Tue, 8 Apr 2003 09:11:40 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: ans-research@www1.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cIVcRmhA4RORzRwxb5Q74A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [Ans-research] The Charter Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , It is my understanding that IRTF group charters do not have to be "strictly" adhered to in the sense that IETF charters do. In that sense, you can take the charter goal of scalable ad hoc networks rather loosely. So then, any ideas that will help improve the scalability of ad hoc networks are welcome. Hence, cross-layer interactions, addressing mechanisms, protocols (new or rehashed), etc. are all welcome ideas if the end goal is to improve the scalability of the network (of course, what scalable means is what we are still working on). Another point to note is that scalability can be looked at in a number of different areas. Routing, QoS, reliability, etc. are all important topics because they can also affect the scalability of the network. So Sukanta was right when he said no topics have really received a red flag, except for security. As long as the focus of the group remains narrow enough that we are still able to make progress then I think we are headed in the right direction. Elizabeth _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 14:57:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26566 for ; Tue, 8 Apr 2003 14:57:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38J1xx19882 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 15:01:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38J1x819879 for ; Tue, 8 Apr 2003 15:01:59 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26541 for ; Tue, 8 Apr 2003 14:56:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IrX819240; Tue, 8 Apr 2003 14:53:33 -0400 Received: from hermes.sc.intel.com (fmr03.intel.com [143.183.121.5]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ijh818912 for ; Tue, 8 Apr 2003 14:45:43 -0400 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by hermes.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h38Idrh10808 for ; Tue, 8 Apr 2003 18:39:53 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h38Ifj113213 for ; Tue, 8 Apr 2003 18:41:46 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040811404517758 ; Tue, 08 Apr 2003 11:40:45 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 11:42:50 -0700 Message-ID: From: "Yang, Lily L" To: "'Elizabeth M. Belding-Royer'" , ans-research@www1.ietf.org Cc: manet@ietf.org Subject: RE: [Ans-research] The Charter Date: Tue, 8 Apr 2003 11:42:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , I wasn't able to attend the BAR BOF -- personally I would like to understand how, among many interesting topics, scalability was chosen to be the one focus for this research group. Is that because people perceive the difficulty to scale ad hoc network into thousands or millions of nodes as the next biggest obstacle we face today in deploying such network? I would think there are many other challenges like QoS, self-configuration, seamless integration with the wired network, etc. -- even just for small to medium size networks -- that are more urgent but have not been adequately addressed in the research community. I was certainly hoping to see this group as a forum to discuss all these challenges in addition to scalability. Elizabeth suggested these topics can be discussed from the angle of how these interact with scalability issue. But my concern is that it is premature to discuss these issues for large networks while we don't even have good handle on them for small to medium size networks. Another concern I have on focusing on scalability is how this overlap with the current charter of the IETF MANET group. At the San Francisco MANET meeting, there was quite a heated disucssion without much resolution on how the MANET group proceed on standardizing one or two routing protocols for ad hoc networks. One of the suggestion is to come up with a set of network scenarios and evaluation metric so that fair evalution can be done on the existing protocols. This sounds a bit similar to what the ANS group is about to do as the first step, but of course with a focus on scalability. However, it wasn't clear to me whether scalability is one of the concern when evalauting the existing protocols produced by the MANET group in its effort to standardize one or two. So maybe the chairs of these two groups can explain exactly how the line is divided here between the work done by two groups? Overall I believe it is a good thing for the IETF MANET group to become very focus and engineering-oriented, but on the same time, I hope the ANS group can be more open in accomodating the research needs that are clearly outside of MANET but have been actively purseud by many people in the community. I post this to both groups because of the nature of my questions. Lily > -----Original Message----- > From: Elizabeth M. Belding-Royer [mailto:ebelding@cs.ucsb.edu] > Sent: Tuesday, April 08, 2003 9:12 AM > To: ans-research@www1.ietf.org > Subject: [Ans-research] The Charter > > > It is my understanding that IRTF group charters do not have > to be "strictly" adhered to in the sense that IETF charters > do. In that sense, you can take the charter goal of scalable > ad hoc networks rather loosely. So then, any ideas that will > help improve the scalability of ad hoc networks are welcome. > Hence, cross-layer interactions, addressing mechanisms, protocols > (new or rehashed), etc. are all welcome ideas if the end goal > is to improve the scalability of the network (of course, what > scalable means is what we are still working on). > > Another point to note is that scalability can be looked at > in a number of different areas. Routing, QoS, reliability, > etc. are all important topics because they can also affect the > scalability of the network. So Sukanta was right when he said > no topics have really received a red flag, except for security. > As long as the focus of the group remains narrow enough that > we are still able to make progress then I think we are headed > in the right direction. > > Elizabeth > > _______________________________________________ > Ans-research mailing list > Ans-research@www1.ietf.org > https://www1.ietf.org/mailman/listinfo/ans-research > _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 16:26:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00737 for ; Tue, 8 Apr 2003 16:26:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38KVco26910 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 16:31:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KVb826907 for ; Tue, 8 Apr 2003 16:31:37 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00667 for ; Tue, 8 Apr 2003 16:26:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KN7826444; Tue, 8 Apr 2003 16:23:07 -0400 Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38KMY826414 for ; Tue, 8 Apr 2003 16:22:34 -0400 Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with SMTP id h38KJdC28602; Tue, 8 Apr 2003 13:19:39 -0700 (PDT) Message-Id: <200304082019.h38KJdC28602@letters.cs.ucsb.edu> Date: Tue, 8 Apr 2003 13:19:39 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" Subject: RE: [Ans-research] The Charter To: ebelding@cs.ucsb.edu, ans-research@www1.ietf.org, lily.l.yang@intel.com Cc: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iD8PxYK8P4jA7evdDdemKw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , ~> ~> I wasn't able to attend the BAR BOF -- personally I would like to understand ~> how, among many interesting topics, scalability was chosen to be the one ~> focus for this research group. Is that because people perceive the ~> difficulty to scale ad hoc network into thousands or millions of nodes as ~> the next biggest obstacle we face today in deploying such network? I would ~> think there are many other challenges like QoS, self-configuration, seamless ~> integration with the wired network, etc. -- even just for small to medium ~> size networks -- that are more urgent but have not been adequately addressed ~> in the research community. I was certainly hoping to see this group as a ~> forum to discuss all these challenges in addition to scalability. Elizabeth ~> suggested these topics can be discussed from the angle of how these interact ~> with scalability issue. But my concern is that it is premature to discuss ~> these issues for large networks while we don't even have good handle on them ~> for small to medium size networks. ~> My understanding is that scalability was chosen in part to handle some of the research that had previously been submitted to MANET but was now out of scope because of the new MANET charter. The other part was because scalability has been far less researched than many other topics. There are already some reasonable ideas about what works and doesn't work in many areas of ad hoc networking, but little work has been done in the area of scalability. I don't know that IRTF groups are supposed to handle urgent topics. I'm speaking from my understanding of how the group was chartered. I actually became co-chair after the charter was already in place. Hopefuuly Scott can correct anything I said that it inaccurate. ~> Another concern I have on focusing on scalability is how this overlap with ~> the current charter of the IETF MANET group. At the San Francisco MANET ~> meeting, there was quite a heated disucssion without much resolution on how ~> the MANET group proceed on standardizing one or two routing protocols for ad ~> hoc networks. One of the suggestion is to come up with a set of network ~> scenarios and evaluation metric so that fair evalution can be done on the ~> existing protocols. This sounds a bit similar to what the ANS group is about ~> to do as the first step, but of course with a focus on scalability. However, ~> it wasn't clear to me whether scalability is one of the concern when ~> evalauting the existing protocols produced by the MANET group in its effort ~> to standardize one or two. So maybe the chairs of these two groups can ~> explain exactly how the line is divided here between the work done by two ~> groups? ~> In defining scalability, we are basically determining the dimensions on which an ad hoc network can be defined. I think this directly relates to what MANET is trying to do. They are trying to determine what metrics should be used to define a network, which is what we will determine when defining scalability. One of the goals of the ANS RG is to produce knowledge that is usable by other groups, such as MANET. ~> Overall I believe it is a good thing for the IETF MANET group to become very ~> focus and engineering-oriented, but on the same time, I hope the ANS group ~> can be more open in accomodating the research needs that are clearly outside ~> of MANET but have been actively purseud by many people in the community. ~> I hope I gave the impression in my prior email that the group was going to be accommodating in many areas. That was my intention. At the same time, I think its important to be realistic about how many topics a single group can incorporate while still being productive and reasonably focussed. If you look at the topics of the other IRTF research groups, I think you will find that we are headed in the direction of a much broader scope than the other previously chartered groups. I don't think you will find any single wired networking group that focuses on all of Scalability, Qos, Reliability, Multicast, etc. Each topic is typically the focus of a single group. In that sense, I think our focus is very broad (but hopefully not too broad if we keep scalability in mind). Elizabeth ~> I post this to both groups because of the nature of my questions. ~> ~> Lily ~> ~> > -----Original Message----- ~> > From: Elizabeth M. Belding-Royer [mailto:ebelding@cs.ucsb.edu] ~> > Sent: Tuesday, April 08, 2003 9:12 AM ~> > To: ans-research@www1.ietf.org ~> > Subject: [Ans-research] The Charter ~> > ~> > ~> > It is my understanding that IRTF group charters do not have ~> > to be "strictly" adhered to in the sense that IETF charters ~> > do. In that sense, you can take the charter goal of scalable ~> > ad hoc networks rather loosely. So then, any ideas that will ~> > help improve the scalability of ad hoc networks are welcome. ~> > Hence, cross-layer interactions, addressing mechanisms, protocols ~> > (new or rehashed), etc. are all welcome ideas if the end goal ~> > is to improve the scalability of the network (of course, what ~> > scalable means is what we are still working on). ~> > ~> > Another point to note is that scalability can be looked at ~> > in a number of different areas. Routing, QoS, reliability, ~> > etc. are all important topics because they can also affect the ~> > scalability of the network. So Sukanta was right when he said ~> > no topics have really received a red flag, except for security. ~> > As long as the focus of the group remains narrow enough that ~> > we are still able to make progress then I think we are headed ~> > in the right direction. ~> > ~> > Elizabeth ~> > ~> > _______________________________________________ ~> > Ans-research mailing list ~> > Ans-research@www1.ietf.org ~> > https://www1.ietf.org/mailman/listinfo/ans-research ~> > ~> _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 17:30:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03150 for ; Tue, 8 Apr 2003 17:30:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38LZlK00439 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 17:35:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LZl800436 for ; Tue, 8 Apr 2003 17:35:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03145 for ; Tue, 8 Apr 2003 17:30:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LO0832163; Tue, 8 Apr 2003 17:24:00 -0400 Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38LH3831867 for ; Tue, 8 Apr 2003 17:17:03 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h38LE2ap014498; Tue, 8 Apr 2003 17:14:02 -0400 (EDT) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h38LDvWe020579; Tue, 8 Apr 2003 17:13:57 -0400 (EDT) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040817135607231 ; Tue, 08 Apr 2003 17:13:56 -0400 Message-Id: <5.1.1.5.2.20030408165258.0294ac28@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 08 Apr 2003 17:13:52 -0400 To: "Elizabeth M. Belding-Royer" , ebelding@cs.ucsb.edu, ans-research@www1.ietf.org, lily.l.yang@intel.com From: Joe Macker Subject: RE: [Ans-research] The Charter Cc: manet@ietf.org In-Reply-To: <200304082019.h38KJdC28602@letters.cs.ucsb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , At 01:19 PM 4/8/2003 -0700, Elizabeth M. Belding-Royer wrote: >~> >~> I wasn't able to attend the BAR BOF -- personally I would like to understand >~> how, among many interesting topics, scalability was chosen to be the one >~> focus for this research group. Is that because people perceive the >~> difficulty to scale ad hoc network into thousands or millions of nodes as >~> the next biggest obstacle we face today in deploying such network? I would >~> think there are many other challenges like QoS, self-configuration, seamless >~> integration with the wired network, etc. -- even just for small to medium >~> size networks -- that are more urgent but have not been adequately addressed >~> in the research community. I was certainly hoping to see this group as a >~> forum to discuss all these challenges in addition to scalability. Elizabeth >~> suggested these topics can be discussed from the angle of how these interact >~> with scalability issue. But my concern is that it is premature to discuss >~> these issues for large networks while we don't even have good handle on them >~> for small to medium size networks. >~> > >My understanding is that scalability was chosen in part to handle some >of the research that had previously been submitted to MANET but was >now out of scope because of the new MANET charter. The other part was >because scalability has been far less researched than many other topics. >There are already some reasonable ideas about what works and doesn't >work in many areas of ad hoc networking, but little work has been done >in the area of scalability. I don't know that IRTF groups are supposed >to handle urgent topics. I took back from the discussions that the IRTF effort would be flexible and more open in topic coverage. I think we can address some more basic configuration and integration issues for small to medium networks at the IETF level. There are more complex autoconfiguration scenarios and they may be appropriate for the IRTF what is your particular scenario of interest? I am also hoping the IRTF is reasonable flexible and open to new thoughts and ideas. BTW, I (and others) have setup quite a few networks operating this way today (Internet stub area operation and some basic autoconfiguration).. >I hope I gave the impression in my prior email that the group was >going to be accommodating in many areas. That was my intention. >At the same time, I think its important to be realistic about how >many topics a single group can incorporate while still being >productive and reasonably focussed. If you look at the topics of >the other IRTF research groups, I think you will find that we are >headed in the direction of a much broader scope than the other >previously chartered groups. I don't think you will find any single >wired networking group that focuses on all of Scalability, Qos, >Reliability, Multicast, etc. Each topic is typically the focus >of a single group. In that sense, I think our focus is very broad >(but hopefully not too broad if we keep scalability in mind). I think an IRTF is intended to be very flexible and open but it does need to direct its efforts over time to what seems suitable and useful. _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Tue Apr 8 19:23:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08039 for ; Tue, 8 Apr 2003 19:23:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38NSac09802 for ans-research-archive@odin.ietf.org; Tue, 8 Apr 2003 19:28:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38NSa809799 for ; Tue, 8 Apr 2003 19:28:36 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08022 for ; Tue, 8 Apr 2003 19:23:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38NK5809384; Tue, 8 Apr 2003 19:20:05 -0400 Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38NGx809221 for ; Tue, 8 Apr 2003 19:16:59 -0400 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <2R3NNSZ0>; Tue, 8 Apr 2003 19:13:59 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01178B67@ftmail.lab.flarion.com> From: Scott Corson To: "'Elizabeth M. Belding-Royer'" , "'ans-research@www1.ietf.org'" , "'lily.l.yang@intel.com'" Cc: "'manet@ietf.org'" Subject: RE: [Ans-research] The Charter Date: Tue, 8 Apr 2003 19:13:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , > My understanding is that scalability was chosen in part to handle some > of the research that had previously been submitted to MANET but was > now out of scope because of the new MANET charter. The other part was > because scalability has been far less researched than many > other topics. > There are already some reasonable ideas about what works and doesn't > work in many areas of ad hoc networking, but little work has been done > in the area of scalability. I don't know that IRTF groups > are supposed > to handle urgent topics. > > I'm speaking from my understanding of how the group was chartered. > I actually became co-chair after the charter was already in place. > Hopefuuly Scott can correct anything I said that it inaccurate. What Elizabeth says is basically correct. Scalability as a general topic is fairly immature as a research area, and was also the principle goal of many of the algorithms no longer in scope of the MANET charter. That said, IMO related areas such as QoS, auto-conf, addressing and interlayer interactions are all part of the unicast puzzle. For purposes of keeping a (somewhat) more narrowed scope, I believe we should avoid both multicast and security for the time being. > > > ~> Another concern I have on focusing on scalability is how > this overlap with > ~> the current charter of the IETF MANET group. At the San > Francisco MANET > ~> meeting, there was quite a heated disucssion without much > resolution on how > ~> the MANET group proceed on standardizing one or two > routing protocols for ad > ~> hoc networks. One of the suggestion is to come up with a > set of network > ~> scenarios and evaluation metric so that fair evalution can > be done on the > ~> existing protocols. This sounds a bit similar to what the > ANS group is about > ~> to do as the first step, but of course with a focus on > scalability. However, > ~> it wasn't clear to me whether scalability is one of the > concern when > ~> evalauting the existing protocols produced by the MANET > group in its effort > ~> to standardize one or two. So maybe the chairs of these > two groups can > ~> explain exactly how the line is divided here between the > work done by two > ~> groups? The MANET WG already took the path of quantitative protocol bakeoff in its early years (research-like phase). Things were learned, but the approach led to little engineering consensus. That type of work is now in the ANS scope of activities. The MANET WG future (if it has one) is focused work on two unified protocols: reactive and proactive. If the WG cannot come to consensus on these, then it will cease to exist. -Scott _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Wed Apr 9 02:56:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16440 for ; Wed, 9 Apr 2003 02:56:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3971KE17230 for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 03:01:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3971K817227 for ; Wed, 9 Apr 2003 03:01:20 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16432 for ; Wed, 9 Apr 2003 02:55:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3971D817217; Wed, 9 Apr 2003 03:01:13 -0400 Received: from remt22.cluster1.charter.net (remt22.cluster1.charter.net [209.225.8.32]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3970P817174 for ; Wed, 9 Apr 2003 03:00:26 -0400 Received: from [66.215.207.46] (HELO cs.ucr.edu) by remt22.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9b) with ESMTP id 9242744 for ans-research@www1.ietf.org; Wed, 09 Apr 2003 02:57:19 -0400 Date: Tue, 8 Apr 2003 23:57:41 -0700 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Jakob Eriksson To: ans-research@www1.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <8EABE7E2-6A58-11D7-BC43-000393B4A8C0@cs.ucr.edu> X-Mailer: Apple Mail (2.551) Subject: [Ans-research] On the use of GPS for routing in heterogenous networks Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello again, Not feeling adequately informed to take part in the charter / directions discussion, I'll just forge ahead and bring up some subjects I find interesting. I would like to continue the discussion on the use of GPS for routing in MANETs. Assuming that we aren't talking about a homogenous network of omnidirectional transceivers of equal power, I think the use of GPS would add more problems than it solves. At the bottom of this email, there's a quick recap of the action so far. First a disclaimer: There is not a doubt in my mind that GPS information will become increasingly available to consumer products as miniaturization and technological advances continue. This will most certainly have important implications for all kinds of applications, and bring unbounded joy to the general populous. :-) However, I have serious doubts about the validity of using GPS for _routing_ in a heterogenous network, consisting of omnidirectional transceivers, directional transceivers, free-space optical links, satellites(?) and wires, among others. Beside the previously stated "obvious" problems, using geographical location information to guide routing may have disastrous effects on routing performance. For example, consider this simple network topology*: A ------ B ------ C ------ D ------ E ------ F ------ G ------ H | | ------------------------------------------------------------------- The link A-H is a fiber, whereas all the other links are 802.11 wireless links. Now B wants to send a message to H. With a routing protocol based on geographical location, C is the proper next hop, and so on. While this is certainly very cheap in terms of routing overhead, it isn't a good route. A protocol based on network distance (hop count, delay, available bandwidth or whatever) would instead "back track" to A, and then use the available fiber link. This is a simplified example, but I'm sure the point gets through. Things get even worse for geo-routing when the G-H link breaks. I can come up with any number of examples of where geographical location has little or nothing to do with the node's position in the network topology, which is what actually matters when routing packets. Any degree of dependence on such an unreliable guide seems very undesirable, (Einar: even silly *wink*), although I would very much like to be convinced otherwise. Given the above problem, how do the geo-routing advocates in the audience propose to make use of GPS in routing? Yours truly, Jakob Eriksson * just in case the "picture" gets garbled, it's supposed to be 8 nodes in a string, connected by wireless links, and an additional optical link going from the head of the string to the tail of the string. --- RECAP --- I started out stating a candidate "Known Fact": 7. Last, but not least, routing protocols that rely on geographical location information are undesirable for many reasons. Beside the obvious problems (energy, bulk, cost, precision, indoor operation etc.), a geographic location does not reliably correspond to a location in a network topology. Two disjoint domains could very well coexist in the same geographical location, with an intersection in some other part of the world. Thus, relying on GPS or equiv. even for rough guidance, may be very harmful for large networks. Anders Nilsson says: "I can't say I agree with you here at all. The obvious problems you mentioned are so obvious at all. The GPS technology is developing all the time, and the devices themselves becomes smaller and more power conservative. In future there is a possibility that all network equipped devices will also include GPS or similiar devices. And what is the problem of having two disjoint domains coexisting in the same geographical area? Maybe, if you force the addressing scheme to stricly reflect your position, will you have problems with this. But that is an addressing problem, not a routing problem. The problem is how to determine the position of a node. There are numerous solutions to how this problem can be solved, and some of them work quite well. But there are reason for taking advantage of GPS information. There are many applications that could benefit from having an exact geographical position, not the least military applications, but also many civilian ones." Einar Vollset agrees: "I agree with Anders on this, I think location information will become more and more common (it is, after all one of the key points in the current push for pervasive/ubiquitous computing), and I think not making use of it would be rather silly :-)" Sukantha Kumar Hazra says: "But it may be less complex." _______________________________________________ Ans-research mailing list Ans-research@www1.ietf.org https://www1.ietf.org/mailman/listinfo/ans-research From mailnull@www1.ietf.org Wed Apr 9 03:23:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16859 for ; Wed, 9 Apr 2003 03:23:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h397T3O19098 for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 03:29:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h397T3819095 for ; Wed, 9 Apr 2003 03:29:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16856 for ; Wed, 9 Apr 2003 03:23:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h397T2819085; Wed, 9 Apr 2003 03:29:02 -0400 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h397SG819056 for ; Wed, 9 Apr 2003 03:28:16 -0400 Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h397Owo26174; Wed, 9 Apr 2003 09:24:58 +0200 (MEST) Message-ID: <3E93CAC9.2BB821A@inrialpes.fr> Date: Wed, 09 Apr 2003 09:24:57 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott Corson CC: "'Elizabeth M. Belding-Royer'" , "'ans-research@www1.ietf.org'" , "'lily.l.yang@intel.com'" , "'manet@ietf.org'" Subject: Re: [Ans-research] The Charter References: <748C6D0A58C0F94CA63C198B6674697A01178B67@ftmail.lab.flarion.com> Content-Type: multipart/alternative; boundary="------------C09AD2D3EBDC735CFE82BD2E" Sender: ans-research-admin@www1.ietf.org Errors-To: ans-research-admin@www1.ietf.org X-BeenThere: ans-research@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Ad hoc Network Scaling Research List-Post: List-Help: List-Subscribe: , --------------C09AD2D3EBDC735CFE82BD2E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott Corson wrote: > > For purposes of keeping a (somewhat) more narrowed scope, I believe we > should avoid both multicast and security for the time being. > Hello Scott, Do you mean that work on MANET's security should be postponed or should be the subject of another WG?... cheers, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------C09AD2D3EBDC735CFE82BD2E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Scott Corson wrote:
 
For purposes of keeping a (somewhat) more narrowed scope, I believe we
should avoid both multicast and security for the time being.
 
Hello Scott,

Do you mean that work on MANET's security should be postponed or should be the subject
of another WG?...
cheers,

Claude.
  




-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

 

--------------C09AD2D3EBDC735CFE82BD2E--

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 06:32:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20452
	for ; Wed, 9 Apr 2003 06:32:32 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39AbfW00685
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 06:37:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Abf800682
	for ; Wed, 9 Apr 2003 06:37:41 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20449
	for ; Wed, 9 Apr 2003 06:32:00 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39AbU800548;
	Wed, 9 Apr 2003 06:37:30 -0400
Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39AaP832274
	for ; Wed, 9 Apr 2003 06:36:25 -0400
Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83])
	by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id MAA20620;
	Wed, 9 Apr 2003 12:33:15 +0200 (MET DST)
Message-ID: <3E93F6D9.3080302@telecom.lth.se>
Date: Wed, 09 Apr 2003 12:32:57 +0200
From: Anders Nilsson 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jakob Eriksson ,
        ANS research
 
Subject: Re: [Ans-research] On the use of GPS for routing in heterogenous
 networks
References: <8EABE7E2-6A58-11D7-BC43-000393B4A8C0@cs.ucr.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,

This thread is starting to become interesting! :-)
First of all I would like to say that we should all be aware that what 
we say here is not the truth at all. It is only a good and healthy 
discussion on a particular subject. Research as I see it is to stretch 
the limits,  "To boldly go where no man has gone before". As such, I 
think we should investigate all the possibilities of using such a 
promising technology as GPS before throwing it away. Sure, there are 
some difficulties, but that is what makes things interesting.
 
For example, say we have a VERY large network of wireless nodes. 
Existing routing solutions today either depend on a reactive, proactive 
or hybrid (e.g. ZRP) routing scheme. All these schemes have commonly 
known problems with scalability because of flooding based searches, 
large overhead etc. For a geographic based scheme to work in such a 
network, basicly all that is needed is the GPS location of the 
destination. We can then use geographic forwarding when routing the 
packet to its destination. Of course, it is not as simple as that. Not 
at all. For example, how do we determine the location? How do we handle 
routing around "holes" etc. But it is a good start, and I don't think we 
should through it away untill it has proved to be totally useless, or at 
least very inadequate.

A heterogenous or hybrid network as the one you describe is a different 
case. I don't think future routing schemes will solely be based on one 
routing metric. That is, to not only rely on hop count, delay, 
bandwidth, signal strength or GPS information, but maybe a combination 
of all of them. They all have their strength' and weaknesses, including 
geographic forwarding. A hybrid network is as I see it, a special case, 
and not a "pure" ad hoc network as much of the research so far has been 
focused on. A node equipped with two network interfaces where one is 
fiberbased, is a strong indication that this node have special 
capabilities, maybe it is some kind of gateway,  or basestation etc. You 
don't just setup heterogenous nodes "ad hoc" just like that. They are 
proably there for a special reason, and are probably not very mobile. In 
that case, hybrid routing must be used. In your case, node B might be 
using node A as a default gateway, and could choose to forward the 
packet to A because the route to A is shorter, more cost effective, 
whatever, than the route through C.  What I mean is that you need a 
different scheme for routing in hybrid networks, than for "pure" ad hoc 
networks. We could in your case use GPS routing towards the 
heterogenerous/hybrid nodes, if those routes are shorter, and then 
normal GPS routing if the heterogenerous nodes are more distant or 
unavailable. The geographic forwarding is only the method we use to get 
packet to their waypoint, or even final destination.
If the link G-H breaks, we have a "hole", and how such problems can be 
solved have been studied in several papers.

>
>
> However, I have serious doubts about the validity of using GPS for 
> _routing_ in a heterogenous network, consisting of omnidirectional 
> transceivers, directional transceivers, free-space optical links, 
> satellites(?) and wires, among others. Beside the previously stated 
> "obvious" problems, using geographical location information to guide 
> routing may have disastrous
> effects on routing performance. For example, consider this simple 
> network topology*:
>
> A ------ B ------ C ------ D ------ E ------ F ------ G ------ H
>  |                                                                      
>                   |
>  -------------------------------------------------------------------
>
> The link A-H is a fiber, whereas all the other links are 802.11 
> wireless links. Now B wants to send a message to H. With a routing 
> protocol based on geographical location, C is the proper next hop, and 
> so on. While this is certainly very cheap in terms of routing 
> overhead, it isn't a good route. A protocol based on network distance 
> (hop count, delay, available bandwidth or whatever) would instead 
> "back track" to A, and then use the available fiber link. This is a 
> simplified example, but I'm sure the point gets through. Things get 
> even worse for geo-routing when the G-H link breaks.

Hetergenous networks consisting of many types of links and radios, 
produces challenges for all type of routing schemes, including GPS 
routing. These are challenges that should be challenged, and before any 
final judgements are made, especially about specific routing scheme, 
they should be investigated thoroughly.

>
> I can come up with any number of examples of where geographical 
> location has little or nothing to do with the node's position in the 
> network topology, which is what actually matters when routing packets. 
> Any degree of dependence on such an unreliable guide seems very 
> undesirable, (Einar: even silly *wink*), although I would very much 
> like to be convinced otherwise.

I can't really understand why you think this is such a big problem. 
Routing deals with the problem of getting packets to their intended 
destination. How is the network topology preventing us from using GPS 
routing? So, a nodes geographical position has nothing to do with its 
position in the topology, why should that prevent us from using GPS 
information in routing? If you use a hierarchical scheme, you can still 
use GPS routing within the hierarchy.

regards,

Anders





_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 07:01:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20984
	for ; Wed, 9 Apr 2003 07:01:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39B6AL01809
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 07:06:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39B6A801804
	for ; Wed, 9 Apr 2003 07:06:10 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20964
	for ; Wed, 9 Apr 2003 07:00:28 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39B63801792;
	Wed, 9 Apr 2003 07:06:03 -0400
Received: from mailout3.samsung.com ([203.254.224.33])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39B5Y801758
	for ; Wed, 9 Apr 2003 07:05:34 -0400
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
 (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002))
 id <0HD200401PBYN7@mailout3.samsung.com> for ans-research@www1.ietf.org; Wed,
 09 Apr 2003 20:02:22 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1])
 by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6
 2002)) with ESMTP id <0HD200A1APBXE9@mailout3.samsung.com> for
 ans-research@www1.ietf.org; Wed, 09 Apr 2003 20:02:21 +0900 (KST)
Received: from Shubhranshu ([75.2.47.220])
 by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6
 2002)) with ESMTPA id <0HD2007W6PBWXF@mmp2.samsung.com> for
 ans-research@www1.ietf.org; Wed, 09 Apr 2003 20:02:21 +0900 (KST)
Date: Wed, 09 Apr 2003 20:00:27 -0800
From: Shubhranshu 
Subject: Re: [Ans-research] Direction of ANS RG
To: Sukanta Kumar Hazra ,
        ans-research@www1.ietf.org
Reply-to: Shubhranshu 
Message-id: <00de01c2ff15$b8f5d570$dc2f024b@Shubhranshu>
Organization: Samsung
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <200304071856.h37IuZC11845@letters.cs.ucsb.edu>
 <3E91E265.693AA23B@mitre.org> <022001c2fe4e$d3dee6a0$dc2f024b@Shubhranshu>
 <20030408122234.GB12240@localhost>
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7BIT
Content-Transfer-Encoding: 7BIT

Dear Mr. Sukanta


> >      I feel ( and wish)  that most members won't go for
> > creating environments  to compare MANET protocol solutions. As most of
> > the MANET protocols doesn't scale well. AODV has been shown to be
> > a better SCALABLE candidate,  but then here SCALABLE means millions of
> >  nodes not just hundreds.
> 
> Hmm... that is where the argument starts. "AODV has been shown to be a
> better SCALABLE candidate", using which metric? I am not against having
> a metric which I could refer to when making those statements. A standard
> metric and scenarios are most welcome.


You may like to check "S.J. Lee et al" paper.
As pointed out by Mr. Anders Nilsson  on 8th April ----
" S.J. Lee et al. showed that AODV could scale to very larger network. 
When the amount of traffic was fairly low. Pure proactive schemes, 
except maybe LANMAR,  all tend to scale poorly."


Warm Regards
Shubhranshu Singh

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 08:30:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25645
	for ; Wed, 9 Apr 2003 08:30:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39Ca8P08470
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 08:36:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Ca7808461
	for ; Wed, 9 Apr 2003 08:36:07 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25623
	for ; Wed, 9 Apr 2003 08:30:26 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Ca6808452;
	Wed, 9 Apr 2003 08:36:06 -0400
Received: from cheviot3.ncl.ac.uk (IDENT:root@cheviot3.ncl.ac.uk [128.240.233.117])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CZl808353
	for ; Wed, 9 Apr 2003 08:35:47 -0400
Received: from ncl.ac.uk (deerbook.ncl.ac.uk [128.240.149.114])
	by cheviot3.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id h39CWYO15915;
	Wed, 9 Apr 2003 13:32:35 +0100
Date: Wed, 9 Apr 2003 13:32:34 +0100
Subject: Re: [Ans-research] On the use of GPS for routing in heterogenous networks
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: ANS research 
To: Jakob Eriksson 
From: Einar Vollset 
In-Reply-To: <3E93F6D9.3080302@telecom.lth.se>
Message-Id: <573D45B4-6A87-11D7-BD1F-000A9575BD30@ncl.ac.uk>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-Newcastle-MailScanner: Found to be clean
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hello indeed :-)

Ok, in a heterogenous network, things are a little more complex, 
however, routing is essentially
about attempting to create a global view using local information.
Previously, when there were no or few wireless links in a network, 
knowing where a node is
physically made little sense, as it was the logical position of the 
node in the network which
mattered.
In a MANET, the position of a node determines it's connectivity (most 
of the time) and thus
recursively determines the global view.
It just seems to me that discarding the validity of location 
information in routing is like throwing
away perfectly good information. And that is what one craves, right? :-)



Cheers,


Einar

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 12:47:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05805
	for ; Wed, 9 Apr 2003 12:47:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39FQ7j22795
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 11:26:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39FQ7822792
	for ; Wed, 9 Apr 2003 11:26:07 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02546
	for ; Wed, 9 Apr 2003 11:20:21 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39FOX822609;
	Wed, 9 Apr 2003 11:25:35 -0400
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39FNK822538
	for ; Wed, 9 Apr 2003 11:23:20 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])
	by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h39FIrap017513;
	Wed, 9 Apr 2003 11:18:53 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1])
	by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h39FIjWe027538;
	Wed, 9 Apr 2003 11:18:45 -0400 (EDT)
Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22])
 by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040911184510196
 ; Wed, 09 Apr 2003 11:18:45 -0400
Message-Id: <5.1.1.5.2.20030409110951.02d07a38@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 09 Apr 2003 11:18:41 -0400
To: Einar Vollset ,
        Jakob Eriksson 
From: Joe Macker 
Subject: Re: [Ans-research] On the use of GPS for routing in
  heterogenous networks
Cc: ANS research 
In-Reply-To: <573D45B4-6A87-11D7-BD1F-000A9575BD30@ncl.ac.uk>
References: <3E93F6D9.3080302@telecom.lth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	

GPS is not receivable everywhere or reliable.  Building are problems as are many other real environments. Also, location doesn't necessarily reflect network topology (it may hint at it). 

Allowing location information to potentially help scaling may not be a bad idea but I think relying on it is a bad idea...its no magic bullet in a real RF and topographical environment.

-Joe

At 01:32 PM 4/9/2003 +0100, Einar Vollset wrote:

>Hello indeed :-)
>
>Ok, in a heterogenous network, things are a little more complex, however, routing is essentially
>about attempting to create a global view using local information.
>Previously, when there were no or few wireless links in a network, knowing where a node is
>physically made little sense, as it was the logical position of the node in the network which
>mattered.
>In a MANET, the position of a node determines it's connectivity (most of the time) and thus
>recursively determines the global view.
>It just seems to me that discarding the validity of location information in routing is like throwing
>away perfectly good information. And that is what one craves, right? :-)
>
>
>
>Cheers,
>
>
>Einar
>
>_______________________________________________
>Ans-research mailing list
>Ans-research@www1.ietf.org
>https://www1.ietf.org/mailman/listinfo/ans-research


_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 16:41:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13616
	for ; Wed, 9 Apr 2003 16:41:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39KlFE26960
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 16:47:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39KlF826957
	for ; Wed, 9 Apr 2003 16:47:15 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13610
	for ; Wed, 9 Apr 2003 16:41:23 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39KlE826949;
	Wed, 9 Apr 2003 16:47:14 -0400
Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Kke826915
	for ; Wed, 9 Apr 2003 16:46:40 -0400
Received: from yahoo.com ([65.93.180.25]) by tomts5-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP
          id <20030409204322.FSJC1594.tomts5-srv.bellnexxia.net@yahoo.com>
          for ; Wed, 9 Apr 2003 16:43:22 -0400
Date: Wed, 9 Apr 2003 16:43:21 -0400
Subject: Re: [Ans-research] On the use of GPS for routing in heterogenous networks
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: S Woodside 
To: ANS research 
Content-Transfer-Encoding: 7bit
In-Reply-To: <5.1.1.5.2.20030409110951.02d07a38@pop.itd.nrl.navy.mil>
Message-Id: 
X-Mailer: Apple Mail (2.551)
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, April 9, 2003, at 11:18  AM, Joe Macker wrote:

> GPS is not receivable everywhere or reliable.  Building are problems 
> as are many other real environments.

True, but there are other ways to get position. Just look up your 
address in mapquest is one ;-) Also, there's no need to build a GPS 
into a node, simply visiting and programming it in once is enough 
(assuming fixed nodes).

However it might be nice if the geographical scheme would allow a 
transition to a locally determined scheme once it reaches a certain 
precision. That might use building codes, room numbers etc.

> Also, location doesn't necessarily reflect network topology (it may 
> hint at it).

In a wireless environment it does especially in the case of a 
mesh-style network where the topology is determined in large part by 
the range of the radios.

> Allowing location information to potentially help scaling may not be a 
> bad idea but I think relying on it is a bad idea...its no magic bullet 
> in a real RF and topographical environment.

It certainly should be a component, because of the massive aggregation 
benefits it offers where it is useful.

> -Joe
>
>
>
> _______________________________________________
> Ans-research mailing list
> Ans-research@www1.ietf.org
> https://www1.ietf.org/mailman/listinfo/ans-research
>
>

--
      anti-spam: do not post this address publicly
www.simonwoodside.com -- 99% Devil, 1% Angel

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 17:55:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16102
	for ; Wed, 9 Apr 2003 17:55:49 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39M1CW32461
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 18:01:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39M1B832458
	for ; Wed, 9 Apr 2003 18:01:11 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16086
	for ; Wed, 9 Apr 2003 17:55:17 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39M14832442;
	Wed, 9 Apr 2003 18:01:04 -0400
Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [192.160.51.75] (may be forged))
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39M07832381
	for ; Wed, 9 Apr 2003 18:00:07 -0400
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58])
	by smtpproxy1.mitre.org (8.12.9/8.12.8) with ESMTP id h39Lun2t013859;
	Wed, 9 Apr 2003 17:56:49 -0400 (EDT)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31])
	by smtpsrv1.mitre.org (8.12.9/8.12.8) with ESMTP id h39LulCg016968;
	Wed, 9 Apr 2003 17:56:47 -0400 (EDT)
Received: from m29103-pc.mitre.org (128.29.55.52) by mailhub1.mitre.org with SMTP
        id 1919368; Wed, 09 Apr 2003 17:56:45 -0400
Message-ID: <3E94971C.EDDB051E@mitre.org>
Date: Wed, 09 Apr 2003 17:56:44 -0400
From: John Stine 
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.79 [en]C-20020130M  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: S Woodside 
CC: ANS research 
Subject: Re: [Ans-research] On the use of GPS for routing in heterogenous 
 networks
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



S Woodside wrote:

> On Wednesday, April 9, 2003, at 11:18  AM, Joe Macker wrote:
>
> > GPS is not receivable everywhere or reliable.  Building are problems
> > as are many other real environments.
>
> True, but there are other ways to get position. Just look up your
> address in mapquest is one ;-) Also, there's no need to build a GPS
> into a node, simply visiting and programming it in once is enough
> (assuming fixed nodes).

Also, since we are talking about RF signals with ad hoc networks, we have
the perfect environment to develop location awareness by using the radio
itself.  Some systems that generate location awareness using RF signals
include  GPS, the U.S. Army's Enhanced Position Location Reporting System
(EPLRS), and from what I understand, ultrawideband radio systems.  For
EPLRS, two nodes are surveyed into a location and then the network
identifies all the locations of the hundreds of nodes that may be part of
the network using time of arrival of signals and a collateration algorithm.
When I worked at the U.S. Army's Test and Experimentation Command, those who
were testing this system said it only got better as the number of nodes
increased.  Location accuracy is advertised as being better than within 30
meters.  This also implies the clock accuracies are on the order of 100
nsecs.   This is not something that can be built easily on top of an 802.11
device but an inexpensive AH MAC/Radio could be developed that provides this
service.  In an indirect sense, it is a requirement for many military
systems since there is a need for timing synchronization for TRANSEC
implementation and synchronization and location awareness go hand-in-glove.

Don't forget that at least in military systems the "killer application" of
the ad hoc network is to develop situational awareness.  In other words,
where is everybody?

>
>
> However it might be nice if the geographical scheme would allow a
> transition to a locally determined scheme once it reaches a certain
> precision. That might use building codes, room numbers etc.
>
> > Also, location doesn't necessarily reflect network topology (it may
> > hint at it).
>
> In a wireless environment it does especially in the case of a
> mesh-style network where the topology is determined in large part by
> the range of the radios.
>
> > Allowing location information to potentially help scaling may not be a
> > bad idea but I think relying on it is a bad idea...its no magic bullet
> > in a real RF and topographical environment.
>
> It certainly should be a component, because of the massive aggregation
> benefits it offers where it is useful.
>
> > -Joe
> >
> >
> >
> > _______________________________________________
> > Ans-research mailing list
> > Ans-research@www1.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ans-research
> >
> >
>
> --
>       anti-spam: do not post this address publicly
> www.simonwoodside.com -- 99% Devil, 1% Angel
>
> _______________________________________________
> Ans-research mailing list
> Ans-research@www1.ietf.org
> https://www1.ietf.org/mailman/listinfo/ans-research


_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Wed Apr  9 18:43:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19006
	for ; Wed, 9 Apr 2003 18:43:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h39MnC604091
	for ans-research-archive@odin.ietf.org; Wed, 9 Apr 2003 18:49:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MnB804088
	for ; Wed, 9 Apr 2003 18:49:11 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18994
	for ; Wed, 9 Apr 2003 18:43:16 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Mn5804079;
	Wed, 9 Apr 2003 18:49:05 -0400
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MmW804061
	for ; Wed, 9 Apr 2003 18:48:32 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])
	by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h39Mj5ap009098;
	Wed, 9 Apr 2003 18:45:05 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1])
	by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h39Mj0Wg002235;
	Wed, 9 Apr 2003 18:45:00 -0400 (EDT)
Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22])
 by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003040918450012233
 ; Wed, 09 Apr 2003 18:45:00 -0400
Message-Id: <5.1.1.5.2.20030409183154.014df620@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Wed, 09 Apr 2003 18:44:55 -0400
To: S Woodside ,
        ANS research 
From: Joe Macker 
Subject: Re: [Ans-research] On the use of GPS for routing in
  heterogenous networks
In-Reply-To: 
References: <5.1.1.5.2.20030409110951.02d07a38@pop.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	

At 04:43 PM 4/9/2003 -0400, S Woodside wrote:

>On Wednesday, April 9, 2003, at 11:18  AM, Joe Macker wrote:
>
>>GPS is not receivable everywhere or reliable.  Building are problems as are many other real environments.
>
>True, but there are other ways to get position. Just look up your address in mapquest is one ;-) Also, there's no need to build a GPS into a node, simply visiting and programming it in once is enough (assuming fixed nodes).
>
>However it might be nice if the geographical scheme would allow a transition to a locally determined scheme once it reaches a certain precision. That might use building codes, room numbers etc.
>
>>Also, location doesn't necessarily reflect network topology (it may hint at it).
>
>In a wireless environment it does especially in the case of a mesh-style network where the topology is determined in large part by the range of the radios.

No way...

If I learned anything from grad school and plenty of years designing wireless systems at many different freq bands its the inevitable time-varying and environmental sensitive nature of wireless channels...take a typical campus at the 2G band...I can likely communicate very far down an open road and not very far around a particular building,etc.. (I am one who has actually measured this effect quite frequently and I am talking orders of magnitude)...sometimes ~/r**2, sometimes ~/r**4 its not a euclidean space in many cases.. Granted it might be in some ....In another case...take a set of nodes in a valley and one on a hill.  These are simple cases.


>>Allowing location information to potentially help scaling may not be a bad idea but I think relying on it is a bad idea...its no magic bullet in a real RF and topographical environment.
>
>It certainly should be a component, because of the massive aggregation benefits it offers where it is useful.

I think it can be a useful tool in the bag...

Einstein said "Make everything as simple as possible but not simpler"

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Thu Apr 10 04:33:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11878
	for ; Thu, 10 Apr 2003 04:33:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3A8d7v21921
	for ans-research-archive@odin.ietf.org; Thu, 10 Apr 2003 04:39:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8d6821918
	for ; Thu, 10 Apr 2003 04:39:06 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11865
	for ; Thu, 10 Apr 2003 04:33:00 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8d5821909;
	Thu, 10 Apr 2003 04:39:05 -0400
Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A8c4821865
	for ; Thu, 10 Apr 2003 04:38:04 -0400
Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83])
	by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id KAA24053;
	Thu, 10 Apr 2003 10:34:26 +0200 (MET DST)
Message-ID: <3E952C80.4010106@telecom.lth.se>
Date: Thu, 10 Apr 2003 10:34:08 +0200
From: Anders Nilsson 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Corson ,
        ANS research
 
Subject: Re: [Ans-research] The Charter
References: <748C6D0A58C0F94CA63C198B6674697A01178B67@ftmail.lab.flarion.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,

Scott Corson wrote

>The MANET WG already took the path of quantitative protocol bakeoff in its
>early years (research-like phase).  Things were learned, but the approach
>led to little engineering consensus.  That type of work is now in the ANS
>scope of activities.
>
>  
>
Just a quick question about your last statement. Does this mean that 
research related questions about ad hoc networks is within the scope of 
ANS, even though they may not apply to scalability directly? That is, 
research realted issues that might relate to ad hoc networks of a 
smaller scale?

regards,

Anders

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Sun Apr 13 04:37:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25873
	for ; Sun, 13 Apr 2003 04:37:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3D8ioR10764
	for ans-research-archive@odin.ietf.org; Sun, 13 Apr 2003 04:44:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D8in810761
	for ; Sun, 13 Apr 2003 04:44:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25867
	for ; Sun, 13 Apr 2003 04:37:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194d1h-0004hM-00
	for ans-research-web-archive@ietf.org; Sun, 13 Apr 2003 04:39:49 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194d1h-0004hI-00
	for ans-research-web-archive@ietf.org; Sun, 13 Apr 2003 04:39:49 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D8ih810750;
	Sun, 13 Apr 2003 04:44:43 -0400
Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D8hh810714
	for ; Sun, 13 Apr 2003 04:43:43 -0400
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59)
	id <25785HQ5>; Sun, 13 Apr 2003 04:38:37 -0400
Message-ID: <748C6D0A58C0F94CA63C198B6674697A01178DAD@ftmail.lab.flarion.com>
From: Scott Corson 
To: "'Claude Castelluccia'" ,
        Scott Corson
	 
Cc: "'Elizabeth M. Belding-Royer'" ,
        "'ans-research@www1.ietf.org'" ,
        "'lily.l.yang@intel.com'" ,
        "'manet@ietf.org'"
	 
Subject: RE: [manet] Re: [Ans-research] The Charter
Date: Sun, 13 Apr 2003 04:38:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30198.0878FF30"
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C30198.0878FF30
Content-Type: text/plain

Claude,
 
I was referring to the ANS work... not MANET.  Sorry for the confusion that
cross-posting on two lists can create.
 
-Scott

-----Original Message-----
From: Claude Castelluccia [mailto:Claude.castelluccia@inrialpes.fr] 
Sent: Wednesday, April 09, 2003 3:25 AM
To: Scott Corson
Cc: 'Elizabeth M. Belding-Royer'; 'ans-research@www1.ietf.org';
'lily.l.yang@intel.com'; 'manet@ietf.org'
Subject: [manet] Re: [Ans-research] The Charter


Scott Corson wrote: 


For purposes of keeping a (somewhat) more narrowed scope, I believe we 
should avoid both multicast and security for the time being. 
   

Hello Scott, 

Do you mean that work on MANET's security should be postponed or should be
the subject 
of another WG?... 
cheers, 


Claude. 
  


-- 



----------------------------------------

Claude CASTELLUCCIA, INRIA Rhone-Alpes  

ph:  +33 4.76.61.52.15 (fax: 52.52)

http://www.inrialpes.fr/planete/  
  


------_=_NextPart_001_01C30198.0878FF30
Content-Type: text/html




Message




Claude,


 


I was 
referring to the ANS work... not MANET.  Sorry for the confusion that 
cross-posting on two lists can create.


 


-Scott



  

  
-----Original Message-----
From: Claude 
  Castelluccia [mailto:Claude.castelluccia@inrialpes.fr] 
Sent: 
  Wednesday, April 09, 2003 3:25 AM
To: Scott Corson
Cc: 
  'Elizabeth M. Belding-Royer'; 'ans-research@www1.ietf.org'; 
  'lily.l.yang@intel.com'; 'manet@ietf.org'
Subject: [manet] Re: 
  [Ans-research] The Charter

Scott Corson wrote: 
  
 
For purposes of keeping a (somewhat) more 
    narrowed scope, I believe we 
should avoid both multicast and security 
    for the time being. 
 
Hello 
  Scott, 
  
Do you mean that work on MANET's security should be postponed or should be 
  the subject 
of another WG?... 
cheers, 
  
Claude. 
  
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  



------_=_NextPart_001_01C30198.0878FF30--
_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Sun Apr 13 04:58:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26115
	for ; Sun, 13 Apr 2003 04:58:04 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3D959l11391
	for ans-research-archive@odin.ietf.org; Sun, 13 Apr 2003 05:05:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D959811388
	for ; Sun, 13 Apr 2003 05:05:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26105
	for ; Sun, 13 Apr 2003 04:57:34 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194dLM-0004ll-00
	for ans-research-web-archive@ietf.org; Sun, 13 Apr 2003 05:00:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194dLM-0004li-00
	for ans-research-web-archive@ietf.org; Sun, 13 Apr 2003 05:00:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D952811380;
	Sun, 13 Apr 2003 05:05:02 -0400
Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D946811350
	for ; Sun, 13 Apr 2003 05:04:06 -0400
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59)
	id <25785HRF>; Sun, 13 Apr 2003 04:59:02 -0400
Message-ID: <748C6D0A58C0F94CA63C198B6674697A01178DAF@ftmail.lab.flarion.com>
From: Scott Corson 
To: "'Anders Nilsson'" ,
        "'ANS research'"
	 
Subject: RE: [Ans-research] The Charter
Date: Sun, 13 Apr 2003 04:58:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	

Well... in my view most of the *quantitative* types of simulation
studies/work that was underway within MANET should be moved here...
regardless of network size. 

MANET should really focus on engineering-oriented packet header/protocol
option-type discussions... the nuts and bolts required to get some basic
proactive and reactive functionality into IETF standards.  Once that is
done, other MANET protocol work can be considered (mcast, etc).  But the
group has thus far shown little ability to get to consensus, and that needs
to be remedied, and I don't believe further simulation studies will help
MANET make progress there.

-Scott

> -----Original Message-----
> From: Anders Nilsson [mailto:andersn@telecom.lth.se] 
> Sent: Thursday, April 10, 2003 4:34 AM
> To: Scott Corson; ANS research
> Subject: Re: [Ans-research] The Charter
> 
> 
> Hello,
> 
> Scott Corson wrote
> 
> >The MANET WG already took the path of quantitative protocol 
> bakeoff in its
> >early years (research-like phase).  Things were learned, but 
> the approach
> >led to little engineering consensus.  That type of work is 
> now in the ANS
> >scope of activities.
> >
> >  
> >
> Just a quick question about your last statement. Does this mean that 
> research related questions about ad hoc networks is within 
> the scope of 
> ANS, even though they may not apply to scalability directly? That is, 
> research realted issues that might relate to ad hoc networks of a 
> smaller scale?
> 
> regards,
> 
> Anders
> 
_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Mon Apr 14 01:04:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12549
	for ; Mon, 14 Apr 2003 01:04:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E5CB109833
	for ans-research-archive@odin.ietf.org; Mon, 14 Apr 2003 01:12:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5CB809830
	for ; Mon, 14 Apr 2003 01:12:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12508
	for ; Mon, 14 Apr 2003 01:04:11 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194wB3-0007PF-00
	for ans-research-web-archive@ietf.org; Mon, 14 Apr 2003 01:06:45 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194wB3-0007PC-00
	for ans-research-web-archive@ietf.org; Mon, 14 Apr 2003 01:06:45 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5C5809821;
	Mon, 14 Apr 2003 01:12:05 -0400
Received: from tomts22-srv.bellnexxia.net (tomts22-srv.bellnexxia.net [209.226.175.184])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E57D809332
	for ; Mon, 14 Apr 2003 01:07:13 -0400
Received: from yahoo.com ([65.93.186.225]) by tomts22-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP
          id <20030414050152.RRQS25567.tomts22-srv.bellnexxia.net@yahoo.com>
          for ; Mon, 14 Apr 2003 01:01:52 -0400
Date: Mon, 14 Apr 2003 01:01:51 -0400
Subject: Re: [Ans-research] On the use of GPS for routing in heterogenous networks
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: S Woodside 
To: ANS research 
Content-Transfer-Encoding: 7bit
In-Reply-To: <5.1.1.5.2.20030409183154.014df620@pop.itd.nrl.navy.mil>
Message-Id: <341C4BC4-6E36-11D7-BA8C-000393414368@yahoo.com>
X-Mailer: Apple Mail (2.551)
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, April 9, 2003, at 06:44  PM, Joe Macker wrote:

>>> Also, location doesn't necessarily reflect network topology (it may 
>>> hint at it).
>> In a wireless environment it does especially in the case of a 
>> mesh-style network where the topology is determined in large part by 
>> the range of the radios.
> No way...
>
> If I learned anything from grad school and plenty of years designing 
> wireless systems at many different freq bands its the inevitable 
> time-varying and environmental sensitive nature of wireless 
> channels...take a typical campus at the 2G band...I can likely 
> communicate very far down an open road and not very far around a 
> particular building,etc.. (I am one who has actually measured this 
> effect quite frequently and I am talking orders of 
> magnitude)...sometimes ~/r**2, sometimes ~/r**4 its not a euclidean 
> space in many cases.. Granted it might be in some ....In another 
> case...take a set of nodes in a valley and one on a hill.  These are 
> simple cases.

I'll give you that there's variability, maybe even lots. But very few 
microwave connections are going to be more than something like 50 km (I 
can't remember the exact number) due to the curvature of the earth and 
a certain reasonable limit on the height of towers. Practically 
speaking the current wisdom puts Wifi links at about 25-30km max before 
you really start to have trouble. Whereas, if you start putting bits 
down a wire, who knows where it's going to go? The circuit could be 
local or go to the other side of the world.

So that, at certain scales, the network and real-world topology are 
definitely going to be related.

simon


--
www.simonwoodside.com -- 99% Devil, 1% Angel

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research



From mailnull@www1.ietf.org  Mon Apr 14 01:34:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13043
	for ; Mon, 14 Apr 2003 01:34:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3E5g8g11647
	for ans-research-archive@odin.ietf.org; Mon, 14 Apr 2003 01:42:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5g8811644
	for ; Mon, 14 Apr 2003 01:42:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13023
	for ; Mon, 14 Apr 2003 01:34:08 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194we2-0007Vy-00
	for ans-research-web-archive@ietf.org; Mon, 14 Apr 2003 01:36:42 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194we1-0007Vv-00
	for ans-research-web-archive@ietf.org; Mon, 14 Apr 2003 01:36:41 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5g2811635;
	Mon, 14 Apr 2003 01:42:02 -0400
Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E5fl811615
	for ; Mon, 14 Apr 2003 01:41:47 -0400
Received: from yahoo.com ([65.93.186.225]) by tomts10-srv.bellnexxia.net
          (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP
          id <20030414053625.LDML11777.tomts10-srv.bellnexxia.net@yahoo.com>
          for ; Mon, 14 Apr 2003 01:36:25 -0400
Date: Mon, 14 Apr 2003 01:36:23 -0400
Subject: Re: [Ans-research] On the use of GPS for routing in heterogenous networks
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: S Woodside 
To: ANS research 
Content-Transfer-Encoding: 7bit
In-Reply-To: <8EABE7E2-6A58-11D7-BC43-000393B4A8C0@cs.ucr.edu>
Message-Id: <07116D61-6E3B-11D7-BA8C-000393414368@yahoo.com>
X-Mailer: Apple Mail (2.551)
Sender: ans-research-admin@www1.ietf.org
Errors-To: ans-research-admin@www1.ietf.org
X-BeenThere: ans-research@www1.ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Ad hoc Network Scaling Research 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On Wednesday, April 9, 2003, at 02:57  AM, Jakob Eriksson wrote:

>  I would like to continue the discussion on the use of GPS for routing 
> in MANETs.

A quick assumption check. Does this list require an assumption of 
"mobile" ... ad hoc networks don't necessarily have to be mobile, and I 
think it makes a difference in terms of routing because a fixed ad hoc 
network has a lot more time to decide on good routing pathways. The 
kind of network I'm interested in -- a community wireless-style 
network, would also have much higher link stability. Ad hoc can mean 
"for the purpose of" but also it is often used to indicate 
improvisation, in this context, perhaps, self-configuration.

> For example, consider this simple network topology*:
>
> A ------ B ------ C ------ D ------ E ------ F ------ G ------ H
>  |                                                                     
>                    |
>  -------------------------------------------------------------------
>
> The link A-H is a fiber, whereas all the other links are 802.11 
> wireless links.

Using a naive geographic scheme, I agree this topology would present 
problems for all nodes but A and H. So that, a naive geographic scheme, 
which simply forwards packets in the correct cardinal direction, would 
work ... non-optimally.

Two possible points of opportunity to optimize upon:
- the network isn't mobile (my assumption) therefore time is available 
to create better routing paths
- some kind of dual routing scheme could act to detect such situations 
and change the routing for them

to repeat your diagram:
> A ------ B ------ C ------ D ------ E ------ F ------ G ------ H
>  |                                                                     
>                    |
>  -------------------------------------------------------------------

It would be interesting to get some idea of how far away from A and H a 
node has to be before it's more efficient to route over the fibre vs. 
geographically. There would be a critical point where the decision 
flips. What does that look like? Is there any kind of mathematical 
analysis that can be made about the function. For example if it's 
exponential then it might be worthwhile for A to tell B to send packets 
headed beyond a certain distance east to A instead of to C. That's a 
highly specific example but if such a scheme can be devised that sends 
these instructions out to a certain limited distance, so as to have a 
very low routing-table-size overhead, along with some scheme to resolve 
conflicts.

> Things get even worse for geo-routing when the G-H link breaks.

There are existing protocols that can circumnavigate around holes, 
e.g., Greedy Perimeter Stateless Routing.

> Any degree of dependence on such an unreliable guide seems very 
> undesirable, (Einar: even silly *wink*), although I would very much 
> like to be convinced otherwise.

It depends on what undesirable means. The geographic scheme will still 
/work/ even if in a very sub-optimal way. And that's a Good Thing since 
it scales so nicely.

Simon

> * just in case the "picture" gets garbled, it's supposed to be 8 nodes 
> in a string, connected by wireless links, and an
> additional optical link going from the head of the string to the tail 
> of the string.
>

--
www.simonwoodside.com -- 99% Devil, 1% Angel

_______________________________________________
Ans-research mailing list
Ans-research@www1.ietf.org
https://www1.ietf.org/mailman/listinfo/ans-research