From manet-admin@ietf.org Mon Jul 1 03:18:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02728 for ; Mon, 1 Jul 2002 03:18:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12487; Mon, 1 Jul 2002 02:57:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12462 for ; Mon, 1 Jul 2002 02:57:21 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02919 for ; Mon, 1 Jul 2002 02:56:33 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id IAA28855 for ; Mon, 1 Jul 2002 08:55:24 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 09:00:49 +0200 X-Mailer: KMail [version 1.2] References: <3D1D746E.000001.02228@bjapp1> <001701c22054$460d65a0$390a640a@Transient> <20020630142638.A31696@che.onthejob.net> In-Reply-To: <20020630142638.A31696@che.onthejob.net> MIME-Version: 1.0 Message-Id: <02070108413300.00485@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > I do not know any 802.11 radio that supports per-packet power level > adjustments, but there are a few with "master" TX power controls. > Power for the Cisco Aironet 35x is adjustable in 1mW increments. Power > levels in the Prism chipset, too, are adjustable, but it is not known > yet the mapping between register values and levels. It's possible to adjust power with 802.11 Cisco Aironet... and It's also possible to force roaming... it's an interesting feature within MANETs, isn't it? regards dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 03:18:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02735 for ; Mon, 1 Jul 2002 03:18:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA14038 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 03:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12487; Mon, 1 Jul 2002 02:57:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12462 for ; Mon, 1 Jul 2002 02:57:21 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02919 for ; Mon, 1 Jul 2002 02:56:33 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id IAA28855 for ; Mon, 1 Jul 2002 08:55:24 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 09:00:49 +0200 X-Mailer: KMail [version 1.2] References: <3D1D746E.000001.02228@bjapp1> <001701c22054$460d65a0$390a640a@Transient> <20020630142638.A31696@che.onthejob.net> In-Reply-To: <20020630142638.A31696@che.onthejob.net> MIME-Version: 1.0 Message-Id: <02070108413300.00485@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit > I do not know any 802.11 radio that supports per-packet power level > adjustments, but there are a few with "master" TX power controls. > Power for the Cisco Aironet 35x is adjustable in 1mW increments. Power > levels in the Prism chipset, too, are adjustable, but it is not known > yet the mapping between register values and levels. It's possible to adjust power with 802.11 Cisco Aironet... and It's also possible to force roaming... it's an interesting feature within MANETs, isn't it? regards dario _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 03:53:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09554 for ; Mon, 1 Jul 2002 03:53:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14286; Mon, 1 Jul 2002 03:26:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14258 for ; Mon, 1 Jul 2002 03:26:43 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04333 for ; Mon, 1 Jul 2002 03:25:55 -0400 (EDT) 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 JAA09178; Mon, 1 Jul 2002 09:26:24 +0200 (MET DST) Message-ID: <3D200469.30401@telecom.lth.se> Date: Mon, 01 Jul 2002 09:27:37 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Scott C. Lemon" , MANET mailing list Subject: Re: [manet] Gateway address resolution References: <3D1CDA22.628904DE@sun.com> <014101c21efa$6afb8140$390a640a@Transient> Content-Type: multipart/alternative; boundary="------------050302010105080808080205" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------050302010105080808080205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! There is a few groups out there working on these questions, and two drafts: draft-wakikawa-manet-globalv6-00.txt draft-royet-manet-globalv4-00.txt regards, Anders N Scott C. Lemon wrote: >Yes! > >I agree 100% ... think of the MANETs as roaming flat networks ... and each >node becomes a possible router with NAT using a second interface - wireless >*or* wired - to provide connectivity from the MANET to the Internet. > >This is the direction that we are working right now ... > > >Scott C. Lemon >HumanXtensions L.L.C. >http://www.HumanXtensions.com >http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" > >----- Original Message ----- >From: "kuldip Singh pabla" >To: ; >Sent: Friday, June 28, 2002 3:50 PM >Subject: Re: [manet] Gateway address resolution > > >>Yasser, >> >>How about treating the ad-hoc network as a NATed community in this case! >> >>-Kuldip >> >>"Yasser A. Lotfy" wrote: >> >>>Hi, >>> >>>Seems like many have agreed on the general ideas in my original e-mail. >>> >However, one point yet need further discussion: > >>>Gateway address resolution; >>>Since ad-hoc IP addresses don't represent a pool of addresses, the idea >>> >of subnet mask can not be used. Hince, distinguishing intranet traffic from >internet traaffic becomes a critical challenge. > >>>For example ad-hoc gateways can read distination address and check >>> >againest table of all ad-hoc IP addresses. This can raise scalability >issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed >structure nodes? Any other ideas? > >>>Yasser >>>Carleton U >>>Ottawa, Canada >>> >>>____________________________________________________________ >>>Win a first-class trip to New Orleans and vacation Elvis Style!. >>>Enter NOW! >>>http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ >>> >>>_______________________________________________ >>>manet mailing list >>>manet@ietf.org >>>https://www1.ietf.org/mailman/listinfo/manet >>> >>-- >>Kuldip Singh Pabla >>Peer-2-Peer Networking >>External: 408.276.6118 Internal: x16118 >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > --------------050302010105080808080205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi!

There is a few groups out there working on these questions, and two drafts:
draft-wakikawa-manet-globalv6-00.txt
draft-royet-manet-globalv4-00.txt

regards,

Anders N

Scott C. Lemon wrote:
Yes!

I agree 100% ... think of the MANETs as roaming flat networks ... and each
node becomes a possible router with NAT using a second interface - wireless
*or* wired - to provide connectivity from the MANET to the Internet.

This is the direction that we are working right now ...


Scott C. Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com
http://the.Inevitable.Org/anism

   "People often talk about it being the journey, not the destination.
        Consider the possibility that there is no destination ...
                    that in life there is only journey!"

----- Original Message -----
From: "kuldip Singh pabla" <Kuldipsingh.Pabla@sun.com>
To: <yasser.lotfy@lycos.com>; <manet@ietf.org>
Sent: Friday, June 28, 2002 3:50 PM
Subject: Re: [manet] Gateway address resolution


Yasser,

How about treating the ad-hoc network as a NATed community in this case!

-Kuldip

"Yasser A. Lotfy" wrote:
Hi,

Seems like many have agreed on the general ideas in my original e-mail.
However, one point yet need further discussion:
Gateway address resolution;
Since ad-hoc IP addresses don't represent a pool of addresses, the idea
of subnet mask can not be used. Hince, distinguishing intranet traffic from
internet traaffic becomes a critical challenge.
For example ad-hoc gateways can read distination address and check
againest table of all ad-hoc IP addresses. This can raise scalability
issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed
structure nodes? Any other ideas?
Yasser
Carleton U
Ottawa, Canada

____________________________________________________________
Win a first-class trip to New Orleans and vacation Elvis Style!.
Enter NOW!
http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet
--
Kuldip Singh Pabla
Peer-2-Peer Networking
External: 408.276.6118 Internal: x16118

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


--------------050302010105080808080205-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 03:53:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09562 for ; Mon, 1 Jul 2002 03:53:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15975 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 03:53:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14286; Mon, 1 Jul 2002 03:26:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14258 for ; Mon, 1 Jul 2002 03:26:43 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04333 for ; Mon, 1 Jul 2002 03:25:55 -0400 (EDT) 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 JAA09178; Mon, 1 Jul 2002 09:26:24 +0200 (MET DST) Message-ID: <3D200469.30401@telecom.lth.se> Date: Mon, 01 Jul 2002 09:27:37 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Scott C. Lemon" , MANET mailing list Subject: Re: [manet] Gateway address resolution References: <3D1CDA22.628904DE@sun.com> <014101c21efa$6afb8140$390a640a@Transient> Content-Type: multipart/alternative; boundary="------------050302010105080808080205" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------050302010105080808080205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! There is a few groups out there working on these questions, and two drafts: draft-wakikawa-manet-globalv6-00.txt draft-royet-manet-globalv4-00.txt regards, Anders N Scott C. Lemon wrote: >Yes! > >I agree 100% ... think of the MANETs as roaming flat networks ... and each >node becomes a possible router with NAT using a second interface - wireless >*or* wired - to provide connectivity from the MANET to the Internet. > >This is the direction that we are working right now ... > > >Scott C. Lemon >HumanXtensions L.L.C. >http://www.HumanXtensions.com >http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" > >----- Original Message ----- >From: "kuldip Singh pabla" >To: ; >Sent: Friday, June 28, 2002 3:50 PM >Subject: Re: [manet] Gateway address resolution > > >>Yasser, >> >>How about treating the ad-hoc network as a NATed community in this case! >> >>-Kuldip >> >>"Yasser A. Lotfy" wrote: >> >>>Hi, >>> >>>Seems like many have agreed on the general ideas in my original e-mail. >>> >However, one point yet need further discussion: > >>>Gateway address resolution; >>>Since ad-hoc IP addresses don't represent a pool of addresses, the idea >>> >of subnet mask can not be used. Hince, distinguishing intranet traffic from >internet traaffic becomes a critical challenge. > >>>For example ad-hoc gateways can read distination address and check >>> >againest table of all ad-hoc IP addresses. This can raise scalability >issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed >structure nodes? Any other ideas? > >>>Yasser >>>Carleton U >>>Ottawa, Canada >>> >>>____________________________________________________________ >>>Win a first-class trip to New Orleans and vacation Elvis Style!. >>>Enter NOW! >>>http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ >>> >>>_______________________________________________ >>>manet mailing list >>>manet@ietf.org >>>https://www1.ietf.org/mailman/listinfo/manet >>> >>-- >>Kuldip Singh Pabla >>Peer-2-Peer Networking >>External: 408.276.6118 Internal: x16118 >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > --------------050302010105080808080205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi!

There is a few groups out there working on these questions, and two drafts:
draft-wakikawa-manet-globalv6-00.txt
draft-royet-manet-globalv4-00.txt

regards,

Anders N

Scott C. Lemon wrote:
Yes!

I agree 100% ... think of the MANETs as roaming flat networks ... and each
node becomes a possible router with NAT using a second interface - wireless
*or* wired - to provide connectivity from the MANET to the Internet.

This is the direction that we are working right now ...


Scott C. Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com
http://the.Inevitable.Org/anism

   "People often talk about it being the journey, not the destination.
        Consider the possibility that there is no destination ...
                    that in life there is only journey!"

----- Original Message -----
From: "kuldip Singh pabla" <Kuldipsingh.Pabla@sun.com>
To: <yasser.lotfy@lycos.com>; <manet@ietf.org>
Sent: Friday, June 28, 2002 3:50 PM
Subject: Re: [manet] Gateway address resolution


Yasser,

How about treating the ad-hoc network as a NATed community in this case!

-Kuldip

"Yasser A. Lotfy" wrote:
Hi,

Seems like many have agreed on the general ideas in my original e-mail.
However, one point yet need further discussion:
Gateway address resolution;
Since ad-hoc IP addresses don't represent a pool of addresses, the idea
of subnet mask can not be used. Hince, distinguishing intranet traffic from
internet traaffic becomes a critical challenge.
For example ad-hoc gateways can read distination address and check
againest table of all ad-hoc IP addresses. This can raise scalability
issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed
structure nodes? Any other ideas?
Yasser
Carleton U
Ottawa, Canada

____________________________________________________________
Win a first-class trip to New Orleans and vacation Elvis Style!.
Enter NOW!
http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet
--
Kuldip Singh Pabla
Peer-2-Peer Networking
External: 408.276.6118 Internal: x16118

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


--------------050302010105080808080205-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 04:13:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10004 for ; Mon, 1 Jul 2002 04:13:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15803; Mon, 1 Jul 2002 03:52:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15772 for ; Mon, 1 Jul 2002 03:52:23 -0400 (EDT) Received: from bjapp1.163.net ([202.108.255.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09503 for ; Mon, 1 Jul 2002 03:51:36 -0400 (EDT) Received: by bjapp1.163.net (Postfix, from userid 1005) id 93F611D12A694; Mon, 1 Jul 2002 15:52:18 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D200A32.000017.04379@bjapp1> Date: Mon, 1 Jul 2002 15:52:18 +0800 (CST) From: "Íõº£" To: Scott.Lemon@HumanXtensions.com Cc: manet@ietf.org, dyoung@ojctech.com X-Priority: 3 X-Originating-IP: [218.2.150.198] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Content-Type: Multipart/Alternative; boundary="Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS" Subject: [manet] =?gb2312?B?UkU6IFttYW5ldF0gSVAgYWRkcmVzc2VzIGluIE1BTkVU?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello Scott: As David Young says, Using power control to increase MANET performance is an active research area in MANET. It sure will increase MANET¡¯s throughput. However, firstly, because of practical reason, transmitting power can not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very small, In such network, the mobility of nodes will become a big problem:) Practically speaking, if MANET can serve more than 10000 nodes freely, I think it is enough for real implementation. I see no case which needs more nodes than that:) Hai Wang > Hello Hai Wang, > > I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say: > > > No matter what structure, what algorithm you use, when the number of nodes increases, > > the routing OH or clustering OH will increase steadily(except we use autonomous region > > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when > > there is some point where the link quality is bad, the OH will choke the traffic too, make the > > performance unacceptable. So, I think that the size limit of a MANET may depend on > > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links > > among cluster heads will be of great concern. > > I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail. > > What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate. > > In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem? > > > Scott C. Lemon > HumanXtensions L.L.C. > http://www.HumanXtensions.com > http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" > --Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hello Scott:
As David Young says, Using power control to increase MANET performance is an active research area in MANET. It sure will increase MANET¡¯s throughput. However, firstly, because of practical reason, transmitting power can not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very small, In such network, the mobility of nodes will become a big problem:)
Practically speaking, if MANET can serve more than 10000 nodes freely, I think it is enough for real implementation. I see no case which needs more nodes than that:)

Hai Wang

> Hello Hai Wang,
>
> I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say:
>
> > No matter what structure, what algorithm you use, when the number of nodes increases,
>! ; > the routing OH or clustering OH will increase steadily(except we use autonomous region
> > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when
> > there is some point where the link quality is bad, the OH will choke the traffic too, make the
> > performance unacceptable. So, I think that the size limit of a MANET may depend on
> > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links
> > among cluster heads will be of great concern.
>
> I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail.
>
> What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as! I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate.
>
> In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem?
>
>
> Scott C. Lemon
> HumanXtensions L.L.C.
> http://www.HumanXtensions.com
> http://the.Inevitable.Org/anism
>
> "People often talk about it being the journey, not the destination.
> Consider the possibility that there is no destination ...
> that in life there is only journey!"
>
--Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 04:13:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10012 for ; Mon, 1 Jul 2002 04:13:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17677 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 04:13:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15803; Mon, 1 Jul 2002 03:52:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15772 for ; Mon, 1 Jul 2002 03:52:23 -0400 (EDT) Received: from bjapp1.163.net ([202.108.255.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09503 for ; Mon, 1 Jul 2002 03:51:36 -0400 (EDT) Received: by bjapp1.163.net (Postfix, from userid 1005) id 93F611D12A694; Mon, 1 Jul 2002 15:52:18 +0800 (CST) MIME-Version: 1.0 Message-ID: <3D200A32.000017.04379@bjapp1> Date: Mon, 1 Jul 2002 15:52:18 +0800 (CST) From: "Íõº£" To: Scott.Lemon@HumanXtensions.com Cc: manet@ietf.org, dyoung@ojctech.com X-Priority: 3 X-Originating-IP: [218.2.150.198] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Content-Type: Multipart/Alternative; boundary="Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS" Subject: [manet] =?gb2312?B?UkU6IFttYW5ldF0gSVAgYWRkcmVzc2VzIGluIE1BTkVU?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello Scott: As David Young says, Using power control to increase MANET performance is an active research area in MANET. It sure will increase MANET¡¯s throughput. However, firstly, because of practical reason, transmitting power can not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very small, In such network, the mobility of nodes will become a big problem:) Practically speaking, if MANET can serve more than 10000 nodes freely, I think it is enough for real implementation. I see no case which needs more nodes than that:) Hai Wang > Hello Hai Wang, > > I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say: > > > No matter what structure, what algorithm you use, when the number of nodes increases, > > the routing OH or clustering OH will increase steadily(except we use autonomous region > > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when > > there is some point where the link quality is bad, the OH will choke the traffic too, make the > > performance unacceptable. So, I think that the size limit of a MANET may depend on > > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links > > among cluster heads will be of great concern. > > I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail. > > What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate. > > In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem? > > > Scott C. Lemon > HumanXtensions L.L.C. > http://www.HumanXtensions.com > http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" > --Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hello Scott:
As David Young says, Using power control to increase MANET performance is an active research area in MANET. It sure will increase MANET¡¯s throughput. However, firstly, because of practical reason, transmitting power can not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very small, In such network, the mobility of nodes will become a big problem:)
Practically speaking, if MANET can serve more than 10000 nodes freely, I think it is enough for real implementation. I see no case which needs more nodes than that:)

Hai Wang

> Hello Hai Wang,
>
> I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say:
>
> > No matter what structure, what algorithm you use, when the number of nodes increases,
>! ; > the routing OH or clustering OH will increase steadily(except we use autonomous region
> > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when
> > there is some point where the link quality is bad, the OH will choke the traffic too, make the
> > performance unacceptable. So, I think that the size limit of a MANET may depend on
> > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links
> > among cluster heads will be of great concern.
>
> I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail.
>
> What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as! I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate.
>
> In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem?
>
>
> Scott C. Lemon
> HumanXtensions L.L.C.
> http://www.HumanXtensions.com
> http://the.Inevitable.Org/anism
>
> "People often talk about it being the journey, not the destination.
> Consider the possibility that there is no destination ...
> that in life there is only journey!"
>
--Boundary-=_gexAoZBhdLTxouMKVAAmBbieXgDS-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 04:32:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10529 for ; Mon, 1 Jul 2002 04:32:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16019; Mon, 1 Jul 2002 03:54:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15989 for ; Mon, 1 Jul 2002 03:54:00 -0400 (EDT) Received: from smtp2.yaonline.es ([62.151.11.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09579 for ; Mon, 1 Jul 2002 03:53:13 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp2.yaonline.es with esmtp id 17Ovzy-0003O6-00; Mon, 01 Jul 2002 09:53:26 +0200 Message-ID: <3D200B2C.3040506@ieee.org> Date: Mon, 01 Jul 2002 09:56:28 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dario Bottazzi CC: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET References: <3D1D746E.000001.02228@bjapp1> <001701c22054$460d65a0$390a640a@Transient> <20020630142638.A31696@che.onthejob.net> <02070108413300.00485@manson> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Cisco Aironet 35x only allow user to choose among six power levels (log scale): 100 mW (20 dBm) 50 mW (17 dBm) 30 mW (15 dBm) 20 mW (13 dBm) 5 mW (7 dBm) 1 mW (0 dBm) However the units we bought in Europe only allow up to 50mW. Regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain Dario Bottazzi wrote: >>I do not know any 802.11 radio that supports per-packet power level >>adjustments, but there are a few with "master" TX power controls. >>Power for the Cisco Aironet 35x is adjustable in 1mW increments. Power >>levels in the Prism chipset, too, are adjustable, but it is not known >>yet the mapping between register values and levels. >> >> > > >It's possible to adjust power with 802.11 Cisco Aironet... and It's also >possible to force roaming... it's an interesting feature within MANETs, isn't >it? > >regards > dario > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 04:32:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10537 for ; Mon, 1 Jul 2002 04:32:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18899 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 04:33:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16019; Mon, 1 Jul 2002 03:54:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15989 for ; Mon, 1 Jul 2002 03:54:00 -0400 (EDT) Received: from smtp2.yaonline.es ([62.151.11.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09579 for ; Mon, 1 Jul 2002 03:53:13 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp2.yaonline.es with esmtp id 17Ovzy-0003O6-00; Mon, 01 Jul 2002 09:53:26 +0200 Message-ID: <3D200B2C.3040506@ieee.org> Date: Mon, 01 Jul 2002 09:56:28 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dario Bottazzi CC: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET References: <3D1D746E.000001.02228@bjapp1> <001701c22054$460d65a0$390a640a@Transient> <20020630142638.A31696@che.onthejob.net> <02070108413300.00485@manson> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Cisco Aironet 35x only allow user to choose among six power levels (log scale): 100 mW (20 dBm) 50 mW (17 dBm) 30 mW (15 dBm) 20 mW (13 dBm) 5 mW (7 dBm) 1 mW (0 dBm) However the units we bought in Europe only allow up to 50mW. Regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain Dario Bottazzi wrote: >>I do not know any 802.11 radio that supports per-packet power level >>adjustments, but there are a few with "master" TX power controls. >>Power for the Cisco Aironet 35x is adjustable in 1mW increments. Power >>levels in the Prism chipset, too, are adjustable, but it is not known >>yet the mapping between register values and levels. >> >> > > >It's possible to adjust power with 802.11 Cisco Aironet... and It's also >possible to force roaming... it's an interesting feature within MANETs, isn't >it? > >regards > dario > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 05:09:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13143 for ; Mon, 1 Jul 2002 05:09:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19376; Mon, 1 Jul 2002 04:46:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19348 for ; Mon, 1 Jul 2002 04:46:26 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10834 for ; Mon, 1 Jul 2002 04:45:38 -0400 (EDT) Received: (qmail 17034 invoked from network); 1 Jul 2002 08:46:15 -0000 Received: from pc-025.diku.dk (130.225.97.25) by hugin.diku.dk with QMQP; 1 Jul 2002 08:46:15 -0000 To: manet@ietf.org From: Jonas Nielsen Date: 01 Jul 2002 10:46:15 +0200 Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] How do you compute normalized routing load? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org In most articles "Normalized routing load" is computed as sent (and forwarded) DSR control packets divided by number of data packets received. I use the following perl script to compute the normalized routing load but the numbers i get are wrong compared to the results from articles I compare the results with. I also use a similar script to compute the packet delivery ratio and her i get the right results on the same trace files. Here is the perl script: #/usr/bin/perl $file = 'wireless1-out.tr'; $DSRSent = 0; $cbrReceived = 0; open(TRACEFILE, "<$file" ) || die "\n" ; while() { if ($_ =~/^(s|f).*\-It DSR/) { $DSRSent++; #print $_; } if ($_ =~/^r.*\-It cbr/) { $cbrReceived++; #print $_; } } print "DSR control packets sent\t$DSRSent\n"; print "Data (cbr) packets received\t$cbrReceived\n"; $load = 1.0*$DSRSent /$cbrReceived; print "Normalized routing load:\t$load\n"; _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 05:09:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13156 for ; Mon, 1 Jul 2002 05:09:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00683 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 05:10:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19376; Mon, 1 Jul 2002 04:46:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19348 for ; Mon, 1 Jul 2002 04:46:26 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10834 for ; Mon, 1 Jul 2002 04:45:38 -0400 (EDT) Received: (qmail 17034 invoked from network); 1 Jul 2002 08:46:15 -0000 Received: from pc-025.diku.dk (130.225.97.25) by hugin.diku.dk with QMQP; 1 Jul 2002 08:46:15 -0000 To: manet@ietf.org From: Jonas Nielsen Date: 01 Jul 2002 10:46:15 +0200 Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] How do you compute normalized routing load? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org In most articles "Normalized routing load" is computed as sent (and forwarded) DSR control packets divided by number of data packets received. I use the following perl script to compute the normalized routing load but the numbers i get are wrong compared to the results from articles I compare the results with. I also use a similar script to compute the packet delivery ratio and her i get the right results on the same trace files. Here is the perl script: #/usr/bin/perl $file = 'wireless1-out.tr'; $DSRSent = 0; $cbrReceived = 0; open(TRACEFILE, "<$file" ) || die "\n" ; while() { if ($_ =~/^(s|f).*\-It DSR/) { $DSRSent++; #print $_; } if ($_ =~/^r.*\-It cbr/) { $cbrReceived++; #print $_; } } print "DSR control packets sent\t$DSRSent\n"; print "Data (cbr) packets received\t$cbrReceived\n"; $load = 1.0*$DSRSent /$cbrReceived; print "Normalized routing load:\t$load\n"; _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 05:25:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15010 for ; Mon, 1 Jul 2002 05:25:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24811; Mon, 1 Jul 2002 05:04:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24731 for ; Mon, 1 Jul 2002 05:04:51 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12002 for ; Mon, 1 Jul 2002 05:04:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA16768 for ; Mon, 1 Jul 2002 02:04:20 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6194JS13030 for ; Mon, 1 Jul 2002 02:04:19 -0700 X-mProtect: <200207010904> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd72PlKb; Mon, 01 Jul 2002 02:03:43 PDT Message-ID: <3D201AEF.FD731278@iprg.nokia.com> Date: Mon, 01 Jul 2002 02:03:43 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile Ad Hoc IETF working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] New AODV draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello folks, A new revision for AODV has been submitted to the Internet Drafts directorate, and is also available at the URL: http://people.nokia.net/charliep/txt/aodvid/aodvid.txt Regards. Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 05:25:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15020 for ; Mon, 1 Jul 2002 05:25:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10364 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 05:25:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24811; Mon, 1 Jul 2002 05:04:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24731 for ; Mon, 1 Jul 2002 05:04:51 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12002 for ; Mon, 1 Jul 2002 05:04:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA16768 for ; Mon, 1 Jul 2002 02:04:20 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6194JS13030 for ; Mon, 1 Jul 2002 02:04:19 -0700 X-mProtect: <200207010904> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd72PlKb; Mon, 01 Jul 2002 02:03:43 PDT Message-ID: <3D201AEF.FD731278@iprg.nokia.com> Date: Mon, 01 Jul 2002 02:03:43 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile Ad Hoc IETF working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] New AODV draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello folks, A new revision for AODV has been submitted to the Internet Drafts directorate, and is also available at the URL: http://people.nokia.net/charliep/txt/aodvid/aodvid.txt Regards. Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailman-owner@ietf.org Mon Jul 1 06:26:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20506 for ; Mon, 1 Jul 2002 06:26:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13940 for ; Mon, 1 Jul 2002 06:27:17 -0400 (EDT) Date: Mon, 1 Jul 2002 06:27:17 -0400 (EDT) Message-Id: <200207011027.GAA13940@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: manet-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, manet-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for manet-archive@lists.ietf.org: List Password // URL ---- -------- manet@ietf.org FtOz https://www1.ietf.org/mailman/options/manet/manet-archive@lists.ietf.org From manet-admin@ietf.org Mon Jul 1 09:30:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04285 for ; Mon, 1 Jul 2002 09:30:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23614; Mon, 1 Jul 2002 09:08:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23507 for ; Mon, 1 Jul 2002 09:08:01 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02894 for ; Mon, 1 Jul 2002 09:07:10 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117122>; Mon, 1 Jul 2002 07:07:49 -0600 Message-Id: <02Jul1.070749mdt.117122@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Scott C. Lemon" Cc: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 07:07:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Scott, I think reducing transmitter power is a good tactic to control cluster size. It is also a good idea from the perspective of conserving limited power. However, I'm not sure reducing receiver sensitivity is a good idea. By reducing output power, you will reduce the area over which the transmitter will interfere with other transmissions. However, reducing sensitivity will only add to the problem of data collisions. In addition, reduced sensitivity will require higher transmit power and will offer less protection against Raleigh fading, multipath, etc. It would be better to focus on the output power reduction and allow the receiver to make the most of the received signal. This will reduce the probability of two adjacent clusters interfering with one another while maintaining good chances of a successful packet transfer. It will also lead to a simpler control problem, since only one element will be modified instead of two. John Mullen Hello Hai Wang, I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say: > No matter what structure, what algorithm you use, when the number of nodes increases, > the routing OH or clustering OH will increase steadily(except we use autonomous region > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when > there is some point where the link quality is bad, the OH will choke the traffic too, make the > performance unacceptable. So, I think that the size limit of a MANET may depend on > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links > among cluster heads will be of great concern. I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail. What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate. In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem? Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" John P. Mullen, Contractor Mail to: Director USATRAC-WSMR Attn: ATRC-WBC (John Mullen) White Sands Missile Range, NM 88002-5502 Phone: (505) 678-5275 DSN 258-5275 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 09:30:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04295 for ; Mon, 1 Jul 2002 09:30:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25843 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 09:31:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23614; Mon, 1 Jul 2002 09:08:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23507 for ; Mon, 1 Jul 2002 09:08:01 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02894 for ; Mon, 1 Jul 2002 09:07:10 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117122>; Mon, 1 Jul 2002 07:07:49 -0600 Message-Id: <02Jul1.070749mdt.117122@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Scott C. Lemon" Cc: manet@ietf.org Subject: Re: [manet] Re: RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 07:07:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Scott, I think reducing transmitter power is a good tactic to control cluster size. It is also a good idea from the perspective of conserving limited power. However, I'm not sure reducing receiver sensitivity is a good idea. By reducing output power, you will reduce the area over which the transmitter will interfere with other transmissions. However, reducing sensitivity will only add to the problem of data collisions. In addition, reduced sensitivity will require higher transmit power and will offer less protection against Raleigh fading, multipath, etc. It would be better to focus on the output power reduction and allow the receiver to make the most of the received signal. This will reduce the probability of two adjacent clusters interfering with one another while maintaining good chances of a successful packet transfer. It will also lead to a simpler control problem, since only one element will be modified instead of two. John Mullen Hello Hai Wang, I have been thinking about the characteristics that I want in a radio ... and working with a local company to develop one that might be well oriented towards MANETs. When you say: > No matter what structure, what algorithm you use, when the number of nodes increases, > the routing OH or clustering OH will increase steadily(except we use autonomous region > concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when > there is some point where the link quality is bad, the OH will choke the traffic too, make the > performance unacceptable. So, I think that the size limit of a MANET may depend on > smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links > among cluster heads will be of great concern. I have thought about one way to possibly deal with this, although I will not claim to have thought this through with a lot of detail. What if I were able to use software to alter the output power and sensitivity of my radio? When I found myself in a situation where I have too many "peers" or the cluster size is getting very large (I am not sure that this is accurate language as I am still coming up to speed!) then I would issue software commands to the radio to decrease my output power, and sensitivity so that I would decrease the radius that I can effectively communicate. In a sense, what if I could decrease and increase my effective "cell" size through software? Would that assist in this problem? Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" John P. Mullen, Contractor Mail to: Director USATRAC-WSMR Attn: ATRC-WBC (John Mullen) White Sands Missile Range, NM 88002-5502 Phone: (505) 678-5275 DSN 258-5275 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 10:00:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06375 for ; Mon, 1 Jul 2002 10:00:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26245; Mon, 1 Jul 2002 09:35:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26214 for ; Mon, 1 Jul 2002 09:35:23 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04423 for ; Mon, 1 Jul 2002 09:34:34 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Mon, 1 Jul 2002 07:35:16 -0600 Message-Id: <02Jul1.073516mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: ?? Cc: manet@ietf.org Subject: RE: [manet] Re: RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 07:35:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22104.21362EA0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C22104.21362EA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Hai Wang, =20 Certainly, minimal routing update control, together with bandwidth, = would be a limiting factor, but it is not possible to say in general where that = is. The volume of update traffic is related to the rate of change within = the net. The effectiveness of a protocol may also be related to traffic patterns. For example, in AODV, the need to update depends only on the = rate of change among links involved with active routes. If those links = consist of only 10% of the total possible links, then a ten fold increase in topology change would, in theory, be possible, compared to a MANET in = which 100% of the links are involved in active paths or a protocol that = attempts to keep all kink information updated, regardless of whether or not it = is involved in an active route. =20 10,000 sounds like a very large number, but it is just the maximum size = of a telephone exchange in the US. At New Mexico State University, we have = a need for two such exchanges. If there is a need for such a MANET, = somebody will come up with something to provide at least some management of the situation. Also, bandwidth is relative. Thirty or forty years ago, = the bandwidth in wired nets was about the same as bandwidth in MANETs. = People found ways to cope with that then and they will now. =20 I remember, in 1978, a technician patiently explaining to me why the = data rate on a conditioned telephone line could never exceed 3kb. According = to the theory in use at the time, it was an insurmountable barrier. Well, = some bright guy figured a way around the theory and now I've got a cheap 56 = kb modem at home. There is no telling what the future has in store for = us. =20 Although we can safely assume that whatever technology is out there, = the BW in MANETs will be significantly less than in wired nets, it is hard for = me to say with any confidence that a particular limit on that BW, and = hence MANET size, exists. =20 John Mullen =20 -----Original Message----- From: hai_wang@163.net [mailto:hai_wang@163.net] Sent: Saturday, June 29, 2002 2:49 AM To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org Subject: [manet] Re: RE: [manet] IP addresses in MANET Hi John: Thanks for your detailed explaining. I agree with you in most part, = except: [John M] =A1=ADGiven a "nice" situation, there would be no practical = limit to the MANET,.... I think there is a limit to the MANET. Wireless is different from = wired, its bandwidth is limited, and it can hardly to make a breakthrough. No = matter what structure, what algorithm you use, when the number of nodes = increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up = the bandwidth. Just before that, when there is some point where the link = quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the = bandwidth of links among cluster heads will be of great concern. Perkins has = shown that there is a 10000 nodes network under test, however,! he did not = show us the bandwidth he use. 10000 is a rather astonishing number to me :)=20 BR. Hai Wang ------_=_NextPart_001_01C22104.21362EA0 Content-Type: text/html; charset="gb2312"
Hi Hai Wang,
 
Certainly, minimal routing update control, together with bandwidth, would be a limiting factor, but it is not possible to say in general where that is.  The volume of update traffic is related to the rate of change within the net.  The effectiveness of a protocol may also be related to traffic patterns.  For example, in AODV, the need to update depends only on the rate of change among links involved with active routes.  If those links consist of only 10% of the total possible links, then a ten fold increase in topology change would, in theory, be possible, compared to a MANET in which 100% of the links are involved in active paths or a protocol that attempts to keep all kink information updated, regardless of whether or not it is involved in an active route.
 
10,000 sounds like a very large number, but it is just the maximum size of a telephone exchange in the US.  At New Mexico State University, we have a need for two such exchanges.  If there is a need for such a MANET, somebody will come up with something to provide at least some management of the situation.  Also, bandwidth is relative.  Thirty or forty years ago, the bandwidth in wired nets was about the same as bandwidth in MANETs.  People found ways to cope with that then and they will now.
 
I remember, in 1978, a technician patiently explaining to me why the data rate on a conditioned telephone line could never exceed 3kb.  According to the theory in use at the time, it was an insurmountable barrier.  Well, some bright guy figured a way around the theory and now I've got a cheap 56 kb modem at home.  There is no telling what the future has in store for us.
 
Although we can safely assume that whatever technology is out there, the BW in MANETs will be significantly less than in wired nets, it is hard for me to say with any confidence that a particular limit on that BW, and hence MANET size, exists.
 
John Mullen
 
-----Original Message-----
From: hai_wang@163.net [mailto:hai_wang@163.net]
Sent: Saturday, June 29, 2002 2:49 AM
To: mullenjp.contractor@trac.wsmr.army.mil
Cc: manet@ietf.org
Subject: [manet] Re: RE: [manet] IP addresses in MANET

Hi John:
Thanks for your detailed explaining. I agree with you in most part, except:
[John M] ¡­Given a "nice" situation, there would be no practical limit to the MANET,....

I think there is a limit to the MANET. Wireless is different from wired, its bandwidth is limited, and it can hardly to make a breakthrough. No matter what structure, what algorithm you use, when the number of nodes increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when there is some point where the link quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links among cluster heads will be of great concern. Perkins has shown that there is a 10000 nodes network under test, however,! he did not show us the bandwidth he use. 10000 is a rather astonishing number to me :)

BR.
Hai Wang
------_=_NextPart_001_01C22104.21362EA0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 10:00:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06384 for ; Mon, 1 Jul 2002 10:00:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00033 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 10:01:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26245; Mon, 1 Jul 2002 09:35:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26214 for ; Mon, 1 Jul 2002 09:35:23 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04423 for ; Mon, 1 Jul 2002 09:34:34 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Mon, 1 Jul 2002 07:35:16 -0600 Message-Id: <02Jul1.073516mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: ?? Cc: manet@ietf.org Subject: RE: [manet] Re: RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 07:35:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22104.21362EA0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C22104.21362EA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Hai Wang, =20 Certainly, minimal routing update control, together with bandwidth, = would be a limiting factor, but it is not possible to say in general where that = is. The volume of update traffic is related to the rate of change within = the net. The effectiveness of a protocol may also be related to traffic patterns. For example, in AODV, the need to update depends only on the = rate of change among links involved with active routes. If those links = consist of only 10% of the total possible links, then a ten fold increase in topology change would, in theory, be possible, compared to a MANET in = which 100% of the links are involved in active paths or a protocol that = attempts to keep all kink information updated, regardless of whether or not it = is involved in an active route. =20 10,000 sounds like a very large number, but it is just the maximum size = of a telephone exchange in the US. At New Mexico State University, we have = a need for two such exchanges. If there is a need for such a MANET, = somebody will come up with something to provide at least some management of the situation. Also, bandwidth is relative. Thirty or forty years ago, = the bandwidth in wired nets was about the same as bandwidth in MANETs. = People found ways to cope with that then and they will now. =20 I remember, in 1978, a technician patiently explaining to me why the = data rate on a conditioned telephone line could never exceed 3kb. According = to the theory in use at the time, it was an insurmountable barrier. Well, = some bright guy figured a way around the theory and now I've got a cheap 56 = kb modem at home. There is no telling what the future has in store for = us. =20 Although we can safely assume that whatever technology is out there, = the BW in MANETs will be significantly less than in wired nets, it is hard for = me to say with any confidence that a particular limit on that BW, and = hence MANET size, exists. =20 John Mullen =20 -----Original Message----- From: hai_wang@163.net [mailto:hai_wang@163.net] Sent: Saturday, June 29, 2002 2:49 AM To: mullenjp.contractor@trac.wsmr.army.mil Cc: manet@ietf.org Subject: [manet] Re: RE: [manet] IP addresses in MANET Hi John: Thanks for your detailed explaining. I agree with you in most part, = except: [John M] =A1=ADGiven a "nice" situation, there would be no practical = limit to the MANET,.... I think there is a limit to the MANET. Wireless is different from = wired, its bandwidth is limited, and it can hardly to make a breakthrough. No = matter what structure, what algorithm you use, when the number of nodes = increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up = the bandwidth. Just before that, when there is some point where the link = quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the = bandwidth of links among cluster heads will be of great concern. Perkins has = shown that there is a 10000 nodes network under test, however,! he did not = show us the bandwidth he use. 10000 is a rather astonishing number to me :)=20 BR. Hai Wang ------_=_NextPart_001_01C22104.21362EA0 Content-Type: text/html; charset="gb2312"
Hi Hai Wang,
 
Certainly, minimal routing update control, together with bandwidth, would be a limiting factor, but it is not possible to say in general where that is.  The volume of update traffic is related to the rate of change within the net.  The effectiveness of a protocol may also be related to traffic patterns.  For example, in AODV, the need to update depends only on the rate of change among links involved with active routes.  If those links consist of only 10% of the total possible links, then a ten fold increase in topology change would, in theory, be possible, compared to a MANET in which 100% of the links are involved in active paths or a protocol that attempts to keep all kink information updated, regardless of whether or not it is involved in an active route.
 
10,000 sounds like a very large number, but it is just the maximum size of a telephone exchange in the US.  At New Mexico State University, we have a need for two such exchanges.  If there is a need for such a MANET, somebody will come up with something to provide at least some management of the situation.  Also, bandwidth is relative.  Thirty or forty years ago, the bandwidth in wired nets was about the same as bandwidth in MANETs.  People found ways to cope with that then and they will now.
 
I remember, in 1978, a technician patiently explaining to me why the data rate on a conditioned telephone line could never exceed 3kb.  According to the theory in use at the time, it was an insurmountable barrier.  Well, some bright guy figured a way around the theory and now I've got a cheap 56 kb modem at home.  There is no telling what the future has in store for us.
 
Although we can safely assume that whatever technology is out there, the BW in MANETs will be significantly less than in wired nets, it is hard for me to say with any confidence that a particular limit on that BW, and hence MANET size, exists.
 
John Mullen
 
-----Original Message-----
From: hai_wang@163.net [mailto:hai_wang@163.net]
Sent: Saturday, June 29, 2002 2:49 AM
To: mullenjp.contractor@trac.wsmr.army.mil
Cc: manet@ietf.org
Subject: [manet] Re: RE: [manet] IP addresses in MANET

Hi John:
Thanks for your detailed explaining. I agree with you in most part, except:
[John M] ¡­Given a "nice" situation, there would be no practical limit to the MANET,....

I think there is a limit to the MANET. Wireless is different from wired, its bandwidth is limited, and it can hardly to make a breakthrough. No matter what structure, what algorithm you use, when the number of nodes increases, the routing OH or clustering OH will increase steadily(except we use autonomous region concept in MANET :) ). At last, the OH will eat up the bandwidth. Just before that, when there is some point where the link quality is bad, the OH will choke the traffic too, make the performance unacceptable. So, I think that the size limit of a MANET may depend on smallest link bandwidth in a network. For hierarchical scheme, the bandwidth of links among cluster heads will be of great concern. Perkins has shown that there is a 10000 nodes network under test, however,! he did not show us the bandwidth he use. 10000 is a rather astonishing number to me :)

BR.
Hai Wang
------_=_NextPart_001_01C22104.21362EA0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 10:17:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07902 for ; Mon, 1 Jul 2002 10:17:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27637; Mon, 1 Jul 2002 09:47:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27588 for ; Mon, 1 Jul 2002 09:47:48 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05102 for ; Mon, 1 Jul 2002 09:47:00 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117122>; Mon, 1 Jul 2002 07:47:37 -0600 Message-Id: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 07:47:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, I know I'm missing something here. Why can't the MANET be treated as a local intranet with each of its nodes having a common Internet subnet mask (augmented by whatever is needed to affect routing within the MANET, of course.) When a gateway sees a packet bearing an IP with the MANET subnet mask, it knows it is intended for a node within the MANET, while one with a different pattern would be clearly intended for the Internet. John Mullen -----Original Message----- From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] Sent: Friday, June 28, 2002 3:40 PM To: yasser.lotfy@lycos.com; Kuldip Singh Pabla; Charles E. Perkins; Rex Buddenberg Cc: manet@ietf.org Subject: [manet] Gateway address resolution Hi, Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: Gateway address resolution; Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? Yasser Carleton U Ottawa, Canada ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 10:29:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08964 for ; Mon, 1 Jul 2002 10:29:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00768; Mon, 1 Jul 2002 10:07:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00734 for ; Mon, 1 Jul 2002 10:06:57 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06688 for ; Mon, 1 Jul 2002 10:06:07 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA28505; Mon, 1 Jul 2002 07:06:50 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA13975; Mon, 1 Jul 2002 07:06:45 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61E6m005949; Mon, 1 Jul 2002 07:06:48 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 10:06:48 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39D7@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 10:06:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Mullen, John P. wrote: > Hi, > > I know I'm missing something here. > > Why can't the MANET be treated as a local intranet with each > of its nodes > having a common Internet subnet mask (augmented by whatever > is needed to > affect routing within the MANET, of course.) When a gateway > sees a packet > bearing an IP with the MANET subnet mask, it knows it is > intended for a node > within the MANET, while one with a different pattern would be clearly > intended for the Internet. Because that wouldn't be the general solution. Seems that many want to be able to turn on their MANET host anywhere and have it join the MANET, without needing DHCP or other server, and without having to enter a MANET-specific IP address and mask manually. And the host must be capable of roaming freely. If you expect the MANET hosts to belong to a particular IP subnet, that mandates some sort of manual or automatic IP address/mask configuration, with the requisite changes as the host roams. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 10:29:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08974 for ; Mon, 1 Jul 2002 10:29:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03904 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 10:30:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00768; Mon, 1 Jul 2002 10:07:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00734 for ; Mon, 1 Jul 2002 10:06:57 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06688 for ; Mon, 1 Jul 2002 10:06:07 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA28505; Mon, 1 Jul 2002 07:06:50 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA13975; Mon, 1 Jul 2002 07:06:45 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61E6m005949; Mon, 1 Jul 2002 07:06:48 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 10:06:48 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39D7@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 10:06:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Mullen, John P. wrote: > Hi, > > I know I'm missing something here. > > Why can't the MANET be treated as a local intranet with each > of its nodes > having a common Internet subnet mask (augmented by whatever > is needed to > affect routing within the MANET, of course.) When a gateway > sees a packet > bearing an IP with the MANET subnet mask, it knows it is > intended for a node > within the MANET, while one with a different pattern would be clearly > intended for the Internet. Because that wouldn't be the general solution. Seems that many want to be able to turn on their MANET host anywhere and have it join the MANET, without needing DHCP or other server, and without having to enter a MANET-specific IP address and mask manually. And the host must be capable of roaming freely. If you expect the MANET hosts to belong to a particular IP subnet, that mandates some sort of manual or automatic IP address/mask configuration, with the requisite changes as the host roams. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 10:36:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09330 for ; Mon, 1 Jul 2002 10:36:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02071; Mon, 1 Jul 2002 10:18:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02045 for ; Mon, 1 Jul 2002 10:17:59 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07815 for ; Mon, 1 Jul 2002 10:17:11 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA11404; Mon, 1 Jul 2002 07:17:50 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA23306; Mon, 1 Jul 2002 07:17:47 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61EHp020412; Mon, 1 Jul 2002 07:17:51 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 10:17:48 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39D8@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'??'" Cc: manet@ietf.org Subject: RE: [manet] RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 10:17:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2210A.10A2F5E0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C2210A.10A2F5E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Some miscellaneous rambling: =20 Decreasing power is useful to decrease the size of cells, to make more = efficient use of RF spectrum. In a system with base stations or access = points, the advantages seem obvious. The wired infrastructure will have = to be upgraded for a greater traffic load, but the individual wireless = cells will support the same number of hosts in a smaller area, = resulting in greater density of mobile hosts. =20 In an ad-hoc network, the advantage doesn't seem so obvious (to me). = Since ad-hoc networks depend on mobile hosts for all their intra-MANET = routing, decreasing power means increasing the number of hops required, = which means that there will be more choke points in the network and = more hosts involved in the average data path. I suppose that if one = introduces faster mobile hosts while reducing the power, same as one = had to upgrade the wired infrastructure in the cell-based network with = base stations, then maybe I can understand how you'd expect better = performance. =20 Bert =20 -----Original Message----- From: hai_wang@163.net [mailto:hai_wang@163.net] Sent: Monday, July 01, 2002 3:52 AM To: Scott.Lemon@HumanXtensions.com Cc: manet@ietf.org; dyoung@ojctech.com Subject: [manet] RE: [manet] IP addresses in MANET Hello Scott: As David Young says, Using power control to increase MANET performance = is an active research area in MANET. It sure will increase = MANET?=A1=A5s throughput. However, firstly, because of practical = reason, transmitting power can not be decreasing without limit; = secondly, when the transmitting power is low enough, it means that the = talking area or clustering area is very small, In such network, the = mobility of nodes will become a big problem:)=20 Practically speaking, if MANET can serve more than 10000 nodes freely, = I think it is enough for real implementation. I see no case which needs = more nodes than that:) Hai Wang ------_=_NextPart_001_01C2210A.10A2F5E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Some = miscellaneous=20 rambling:
 
Decreasing = power is=20 useful to decrease the size of cells, to make more efficient use of RF = spectrum.=20 In a system with base stations or access points, the advantages seem = obvious.=20 The wired infrastructure will have to be upgraded for a greater traffic = load,=20 but the individual wireless cells will support the same number of hosts = in a=20 smaller area, resulting in greater density of mobile = hosts.
 
In an = ad-hoc network,=20 the advantage doesn't seem so obvious (to me). Since ad-hoc networks = depend on=20 mobile hosts for all their intra-MANET routing, decreasing power means=20 increasing the number of hops required, which means that there will be = more=20 choke points in the network and more hosts involved in the average data = path. I=20 suppose that if one introduces faster mobile hosts while reducing the = power,=20 same as one had to upgrade the wired infrastructure in the cell-based = network=20 with base stations, then maybe I can understand how you'd expect = better=20 performance.
 
Bert
 
-----Original Message-----
From: hai_wang@163.net=20 [mailto:hai_wang@163.net]
Sent: Monday, July 01, 2002 3:52=20 AM
To: Scott.Lemon@HumanXtensions.com
Cc: = manet@ietf.org;=20 dyoung@ojctech.com
Subject: [manet] RE: [manet] IP = addresses in=20 MANET

Hello Scott:
As David Young says, Using = power=20 control to increase MANET performance is an active research area in = MANET. It=20 sure will increase MANET¡=A1=A5s throughput. However, firstly, = because of practical=20 reason, transmitting power can not be decreasing without limit; = secondly, when=20 the transmitting power is low enough, it means that the talking area = or=20 clustering area is very small, In such network, the mobility of nodes = will=20 become a big problem:)
Practically speaking, if MANET can serve = more than=20 10000 nodes freely, I think it is enough for real implementation. I = see no=20 case which needs more nodes than that:)

Hai=20 Wang
------_=_NextPart_001_01C2210A.10A2F5E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 10:36:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09338 for ; Mon, 1 Jul 2002 10:36:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04579 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 10:36:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02071; Mon, 1 Jul 2002 10:18:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02045 for ; Mon, 1 Jul 2002 10:17:59 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07815 for ; Mon, 1 Jul 2002 10:17:11 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA11404; Mon, 1 Jul 2002 07:17:50 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA23306; Mon, 1 Jul 2002 07:17:47 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61EHp020412; Mon, 1 Jul 2002 07:17:51 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 10:17:48 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39D8@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'??'" Cc: manet@ietf.org Subject: RE: [manet] RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 10:17:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2210A.10A2F5E0" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C2210A.10A2F5E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Some miscellaneous rambling: =20 Decreasing power is useful to decrease the size of cells, to make more = efficient use of RF spectrum. In a system with base stations or access = points, the advantages seem obvious. The wired infrastructure will have = to be upgraded for a greater traffic load, but the individual wireless = cells will support the same number of hosts in a smaller area, = resulting in greater density of mobile hosts. =20 In an ad-hoc network, the advantage doesn't seem so obvious (to me). = Since ad-hoc networks depend on mobile hosts for all their intra-MANET = routing, decreasing power means increasing the number of hops required, = which means that there will be more choke points in the network and = more hosts involved in the average data path. I suppose that if one = introduces faster mobile hosts while reducing the power, same as one = had to upgrade the wired infrastructure in the cell-based network with = base stations, then maybe I can understand how you'd expect better = performance. =20 Bert =20 -----Original Message----- From: hai_wang@163.net [mailto:hai_wang@163.net] Sent: Monday, July 01, 2002 3:52 AM To: Scott.Lemon@HumanXtensions.com Cc: manet@ietf.org; dyoung@ojctech.com Subject: [manet] RE: [manet] IP addresses in MANET Hello Scott: As David Young says, Using power control to increase MANET performance = is an active research area in MANET. It sure will increase = MANET?=A1=A5s throughput. However, firstly, because of practical = reason, transmitting power can not be decreasing without limit; = secondly, when the transmitting power is low enough, it means that the = talking area or clustering area is very small, In such network, the = mobility of nodes will become a big problem:)=20 Practically speaking, if MANET can serve more than 10000 nodes freely, = I think it is enough for real implementation. I see no case which needs = more nodes than that:) Hai Wang ------_=_NextPart_001_01C2210A.10A2F5E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Some = miscellaneous=20 rambling:
 
Decreasing = power is=20 useful to decrease the size of cells, to make more efficient use of RF = spectrum.=20 In a system with base stations or access points, the advantages seem = obvious.=20 The wired infrastructure will have to be upgraded for a greater traffic = load,=20 but the individual wireless cells will support the same number of hosts = in a=20 smaller area, resulting in greater density of mobile = hosts.
 
In an = ad-hoc network,=20 the advantage doesn't seem so obvious (to me). Since ad-hoc networks = depend on=20 mobile hosts for all their intra-MANET routing, decreasing power means=20 increasing the number of hops required, which means that there will be = more=20 choke points in the network and more hosts involved in the average data = path. I=20 suppose that if one introduces faster mobile hosts while reducing the = power,=20 same as one had to upgrade the wired infrastructure in the cell-based = network=20 with base stations, then maybe I can understand how you'd expect = better=20 performance.
 
Bert
 
-----Original Message-----
From: hai_wang@163.net=20 [mailto:hai_wang@163.net]
Sent: Monday, July 01, 2002 3:52=20 AM
To: Scott.Lemon@HumanXtensions.com
Cc: = manet@ietf.org;=20 dyoung@ojctech.com
Subject: [manet] RE: [manet] IP = addresses in=20 MANET

Hello Scott:
As David Young says, Using = power=20 control to increase MANET performance is an active research area in = MANET. It=20 sure will increase MANET¡=A1=A5s throughput. However, firstly, = because of practical=20 reason, transmitting power can not be decreasing without limit; = secondly, when=20 the transmitting power is low enough, it means that the talking area = or=20 clustering area is very small, In such network, the mobility of nodes = will=20 become a big problem:)
Practically speaking, if MANET can serve = more than=20 10000 nodes freely, I think it is enough for real implementation. I = see no=20 case which needs more nodes than that:)

Hai=20 Wang
------_=_NextPart_001_01C2210A.10A2F5E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 10:36:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09395 for ; Mon, 1 Jul 2002 10:36:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00932; Mon, 1 Jul 2002 10:08:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00860 for ; Mon, 1 Jul 2002 10:08:01 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06786 for ; Mon, 1 Jul 2002 10:07:13 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g61E5Ga16522 for ; Mon, 1 Jul 2002 10:05:16 -0400 Date: Mon, 1 Jul 2002 10:07:52 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ZRP Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear All, Although we have submitted the revised ZRP drafts, I am afraid that we may not have met the deadline. For your information, here is the link to the new drafts: http://wnl.ece.cornell.edu/wnlother.html The ZRP contains three drafts: draft-ietf-manet-zone-zrp-04.txt draft-ietf-manet-zone-brp-02.txt draft-ietf-manet-zone-ierp-02.txt draft-ietf-manet-zone-iarp-02.txt Best, 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 ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 10:37:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09402 for ; Mon, 1 Jul 2002 10:36:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04635 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 10:37:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00932; Mon, 1 Jul 2002 10:08:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00860 for ; Mon, 1 Jul 2002 10:08:01 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06786 for ; Mon, 1 Jul 2002 10:07:13 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g61E5Ga16522 for ; Mon, 1 Jul 2002 10:05:16 -0400 Date: Mon, 1 Jul 2002 10:07:52 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ZRP Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear All, Although we have submitted the revised ZRP drafts, I am afraid that we may not have met the deadline. For your information, here is the link to the new drafts: http://wnl.ece.cornell.edu/wnlother.html The ZRP contains three drafts: draft-ietf-manet-zone-zrp-04.txt draft-ietf-manet-zone-brp-02.txt draft-ietf-manet-zone-ierp-02.txt draft-ietf-manet-zone-iarp-02.txt Best, 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 ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 11:04:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07910 for ; Mon, 1 Jul 2002 10:17:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02177 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 10:18:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27637; Mon, 1 Jul 2002 09:47:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27588 for ; Mon, 1 Jul 2002 09:47:48 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05102 for ; Mon, 1 Jul 2002 09:47:00 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117122>; Mon, 1 Jul 2002 07:47:37 -0600 Message-Id: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 07:47:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, I know I'm missing something here. Why can't the MANET be treated as a local intranet with each of its nodes having a common Internet subnet mask (augmented by whatever is needed to affect routing within the MANET, of course.) When a gateway sees a packet bearing an IP with the MANET subnet mask, it knows it is intended for a node within the MANET, while one with a different pattern would be clearly intended for the Internet. John Mullen -----Original Message----- From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] Sent: Friday, June 28, 2002 3:40 PM To: yasser.lotfy@lycos.com; Kuldip Singh Pabla; Charles E. Perkins; Rex Buddenberg Cc: manet@ietf.org Subject: [manet] Gateway address resolution Hi, Seems like many have agreed on the general ideas in my original e-mail. However, one point yet need further discussion: Gateway address resolution; Since ad-hoc IP addresses don't represent a pool of addresses, the idea of subnet mask can not be used. Hince, distinguishing intranet traffic from internet traaffic becomes a critical challenge. For example ad-hoc gateways can read distination address and check againest table of all ad-hoc IP addresses. This can raise scalability issues. Can IPv6 provide a way to distinguish local ad-hoc nodes from fixed structure nodes? Any other ideas? Yasser Carleton U Ottawa, Canada ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 11:31:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12479 for ; Mon, 1 Jul 2002 11:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06461; Mon, 1 Jul 2002 11:00:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06406 for ; Mon, 1 Jul 2002 11:00:42 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10475 for ; Mon, 1 Jul 2002 10:59:53 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Mon, 1 Jul 2002 09:00:32 -0600 Message-Id: <02Jul1.090032mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 09:00:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Well, at least in some MANETs, there is an attempt to introduce hierarchical routing through dynamic clustering. These are the organization-related MANETs (military, public services, etc.) though, rather than the open-ended ones that are more general. The proliferation of the Internet and local networks may eventually lead to a reform of the whole IP approach. For example, we may end up with 40 or 48-bit IP addresses in a few years, something like the move from five-digit to nine-digit zip codes. The demand is very great and, with today's technology, the extra bits are relatively cheap. Another technological fix on the horizon is the use of GPS data. Rental cars now routinely come with GPS receivers. The ability to receive and decode GPS could become a standard MANET feature. Someone will probably come up with routing and clustering schemes based on that GPS info. That could really help routing in those wide-open general MANETs. On the other side, I hear that someone has invented a RF-blocking paint that many theater and restaurant operators are interested in. (I wonder how that will fly the first time someone needs to dial 911 from within a structure coated with this paint). I suspect there will be sociological, as well as technological, aspects to the eventual use of MANETs. After all, Jazz musicians manage, why not MANETs? :-) As for the hop-by-hop, that is not really unusual. It just appears that way because of the differences in clustering and channel availability and usage in MANETs, as opposed to wired nets. In both cases, nodes are not smart enough to figure out what to do with a packet on their own, so each packet is either constrained, through selection of a point-to-point channel, or addressed so that the recipient is not in doubt. This is usually managed at the lower levels, so IP can seem less messy, but the hop-by-hop routing is still there. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Monday, July 01, 2002 8:25 AM To: 'Mullen, John P. (Contractor)' Subject: RE: [manet] Gateway address resolution You're most welcome, John. Actually, I don't see much similarity between a MANET and anything IP-related, as we have known IP to be until now. MANET seems to operate a lot more like a Layer 2 catenet, i.e. a big, multi-hop infrastructure with no attempt at hierarchical addressing and routing. It's quite chaotic. And no one seems to worry too much about scaling. For example, routes have to be described hop by hop. Not exactly the way IP is supposed to work. Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, July 01, 2002 10:17 AM > To: Manfredi, Albert E > Subject: RE: [manet] Gateway address resolution > > > Thanks Bert, > > I was thinking of a situation in which all MANET nodes would have an > association with a common organization, such as in area > emergency relief. I > can see, however, the problem in the more general case you describe. > > JPM > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Monday, July 01, 2002 8:07 AM > To: 'Mullen, John P. (Contractor)'; manet@ietf.org > Subject: RE: [manet] Gateway address resolution > > > Mullen, John P. wrote: > > > Hi, > > > > I know I'm missing something here. > > > > Why can't the MANET be treated as a local intranet with each > > of its nodes > > having a common Internet subnet mask (augmented by whatever > > is needed to > > affect routing within the MANET, of course.) When a gateway > > sees a packet > > bearing an IP with the MANET subnet mask, it knows it is > > intended for a node > > within the MANET, while one with a different pattern would > be clearly > > intended for the Internet. > > Because that wouldn't be the general solution. Seems that > many want to be > able to turn on their MANET host anywhere and have it join the MANET, > without needing DHCP or other server, and without having to enter a > MANET-specific IP address and mask manually. And the host > must be capable of > roaming freely. > > If you expect the MANET hosts to belong to a particular IP > subnet, that > mandates some sort of manual or automatic IP address/mask > configuration, > with the requisite changes as the host roams. > > Bert > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 11:31:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12489 for ; Mon, 1 Jul 2002 11:31:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09264 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 11:32:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06461; Mon, 1 Jul 2002 11:00:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06406 for ; Mon, 1 Jul 2002 11:00:42 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10475 for ; Mon, 1 Jul 2002 10:59:53 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Mon, 1 Jul 2002 09:00:32 -0600 Message-Id: <02Jul1.090032mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 09:00:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Well, at least in some MANETs, there is an attempt to introduce hierarchical routing through dynamic clustering. These are the organization-related MANETs (military, public services, etc.) though, rather than the open-ended ones that are more general. The proliferation of the Internet and local networks may eventually lead to a reform of the whole IP approach. For example, we may end up with 40 or 48-bit IP addresses in a few years, something like the move from five-digit to nine-digit zip codes. The demand is very great and, with today's technology, the extra bits are relatively cheap. Another technological fix on the horizon is the use of GPS data. Rental cars now routinely come with GPS receivers. The ability to receive and decode GPS could become a standard MANET feature. Someone will probably come up with routing and clustering schemes based on that GPS info. That could really help routing in those wide-open general MANETs. On the other side, I hear that someone has invented a RF-blocking paint that many theater and restaurant operators are interested in. (I wonder how that will fly the first time someone needs to dial 911 from within a structure coated with this paint). I suspect there will be sociological, as well as technological, aspects to the eventual use of MANETs. After all, Jazz musicians manage, why not MANETs? :-) As for the hop-by-hop, that is not really unusual. It just appears that way because of the differences in clustering and channel availability and usage in MANETs, as opposed to wired nets. In both cases, nodes are not smart enough to figure out what to do with a packet on their own, so each packet is either constrained, through selection of a point-to-point channel, or addressed so that the recipient is not in doubt. This is usually managed at the lower levels, so IP can seem less messy, but the hop-by-hop routing is still there. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Monday, July 01, 2002 8:25 AM To: 'Mullen, John P. (Contractor)' Subject: RE: [manet] Gateway address resolution You're most welcome, John. Actually, I don't see much similarity between a MANET and anything IP-related, as we have known IP to be until now. MANET seems to operate a lot more like a Layer 2 catenet, i.e. a big, multi-hop infrastructure with no attempt at hierarchical addressing and routing. It's quite chaotic. And no one seems to worry too much about scaling. For example, routes have to be described hop by hop. Not exactly the way IP is supposed to work. Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, July 01, 2002 10:17 AM > To: Manfredi, Albert E > Subject: RE: [manet] Gateway address resolution > > > Thanks Bert, > > I was thinking of a situation in which all MANET nodes would have an > association with a common organization, such as in area > emergency relief. I > can see, however, the problem in the more general case you describe. > > JPM > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Monday, July 01, 2002 8:07 AM > To: 'Mullen, John P. (Contractor)'; manet@ietf.org > Subject: RE: [manet] Gateway address resolution > > > Mullen, John P. wrote: > > > Hi, > > > > I know I'm missing something here. > > > > Why can't the MANET be treated as a local intranet with each > > of its nodes > > having a common Internet subnet mask (augmented by whatever > > is needed to > > affect routing within the MANET, of course.) When a gateway > > sees a packet > > bearing an IP with the MANET subnet mask, it knows it is > > intended for a node > > within the MANET, while one with a different pattern would > be clearly > > intended for the Internet. > > Because that wouldn't be the general solution. Seems that > many want to be > able to turn on their MANET host anywhere and have it join the MANET, > without needing DHCP or other server, and without having to enter a > MANET-specific IP address and mask manually. And the host > must be capable of > roaming freely. > > If you expect the MANET hosts to belong to a particular IP > subnet, that > mandates some sort of manual or automatic IP address/mask > configuration, > with the requisite changes as the host roams. > > Bert > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 11:41:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12984 for ; Mon, 1 Jul 2002 11:41:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08102; Mon, 1 Jul 2002 11:21:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08000 for ; Mon, 1 Jul 2002 11:21:04 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11720 for ; Mon, 1 Jul 2002 11:20:16 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Mon, 1 Jul 2002 09:20:49 -0600 Message-Id: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" , "'??'" Cc: manet@ietf.org Subject: RE: [manet] RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 09:20:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22112.DC702460" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C22112.DC702460 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Bert, =20 It all turns on the density of your hosts and the patterns of communications. If you have a very large number of hosts in a rather = small geographical area, you will have increased contention for the RF = channel. By reducing power, you reduce the potential for interference among = hosts attempting unrelated communications on the same channel, but in significantly different geographical locations. If, on the other hand, those conversations are of interest to all nodes, then reducing power = will increase the number of hops and channel utilization. =20 =20 For example, suppose your MANET consists of clusters of hosts that are = about 1 km apart. However, within a cluster, each node is within a few = meters of at least one other node. When communications is within a cluster, it = would be prudent, to limit transmit power to that level necessary to carry = out communications within that cluster, but not high enough to cause interference between clusters. On the other hand, if you need to communicate from one cluster to another, a higher power level would be needed. =20 Also, if we agree that the MANET hosts are likely to be portable battery-powered units, then managing transmitter power is also = important from the perspective of conserving network resources. =20 =20 I would say that the ability to change transmitter power has potential = for more efficient MANET management, but its success will turn on the = ability of the protocol to detect situations in which the different power levels = are appropriate. =20 John Mullen =20 -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Monday, July 01, 2002 8:18 AM To: '??' Cc: manet@ietf.org Subject: RE: [manet] RE: [manet] IP addresses in MANET Some miscellaneous rambling: =20 Decreasing power is useful to decrease the size of cells, to make more efficient use of RF spectrum. In a system with base stations or access points, the advantages seem obvious. The wired infrastructure will have = to be upgraded for a greater traffic load, but the individual wireless = cells will support the same number of hosts in a smaller area, resulting in greater density of mobile hosts. =20 In an ad-hoc network, the advantage doesn't seem so obvious (to me). = Since ad-hoc networks depend on mobile hosts for all their intra-MANET = routing, decreasing power means increasing the number of hops required, which = means that there will be more choke points in the network and more hosts = involved in the average data path. I suppose that if one introduces faster = mobile hosts while reducing the power, same as one had to upgrade the wired infrastructure in the cell-based network with base stations, then maybe = I can understand how you'd expect better performance. =20 Bert =20 -----Original Message----- From: hai_wang@163.net [mailto:hai_wang@163.net] Sent: Monday, July 01, 2002 3:52 AM To: Scott.Lemon@HumanXtensions.com Cc: manet@ietf.org; dyoung@ojctech.com Subject: [manet] RE: [manet] IP addresses in MANET Hello Scott: As David Young says, Using power control to increase MANET performance = is an active research area in MANET. It sure will increase MANET?=A1=A5s = throughput. However, firstly, because of practical reason, transmitting power can = not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very = small, In such network, the mobility of nodes will become a big problem:)=20 Practically speaking, if MANET can serve more than 10000 nodes freely, = I think it is enough for real implementation. I see no case which needs = more nodes than that:) Hai Wang ------_=_NextPart_001_01C22112.DC702460 Content-Type: text/html; charset="gb2312"
Hi Bert,
 
It all turns on the density of your hosts and the patterns of communications.  If you have a very large number of hosts in a rather small geographical area, you will have increased contention for the RF channel.  By reducing power, you reduce the potential for interference among hosts attempting unrelated communications on the same channel, but in significantly different geographical locations.  If, on the other hand, those conversations are of interest to all nodes, then reducing power will increase the number of hops and channel utilization. 
 
For example, suppose your MANET consists of clusters of hosts that are about 1 km apart.  However, within a cluster, each node is within a few meters of at least one other node.  When communications is within a cluster, it would be prudent, to limit transmit power to that level necessary to carry out communications within that cluster, but not high enough to cause interference between clusters.  On the other hand, if you need to communicate from one cluster to another, a higher power level would be needed.
 
Also, if we agree that the MANET hosts are likely to be portable battery-powered units, then managing transmitter power is also important from the perspective of conserving network resources. 
 
I would say that the ability to change transmitter power has potential for more efficient MANET management, but its success will turn on the ability of the protocol to detect situations in which the different power levels are appropriate.
 
John Mullen
 
-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Monday, July 01, 2002 8:18 AM
To: '??'
Cc: manet@ietf.org
Subject: RE: [manet] RE: [manet] IP addresses in MANET

Some miscellaneous rambling:
 
Decreasing power is useful to decrease the size of cells, to make more efficient use of RF spectrum. In a system with base stations or access points, the advantages seem obvious. The wired infrastructure will have to be upgraded for a greater traffic load, but the individual wireless cells will support the same number of hosts in a smaller area, resulting in greater density of mobile hosts.
 
In an ad-hoc network, the advantage doesn't seem so obvious (to me). Since ad-hoc networks depend on mobile hosts for all their intra-MANET routing, decreasing power means increasing the number of hops required, which means that there will be more choke points in the network and more hosts involved in the average data path. I suppose that if one introduces faster mobile hosts while reducing the power, same as one had to upgrade the wired infrastructure in the cell-based network with base stations, then maybe I can understand how you'd expect better performance.
 
Bert
 
-----Original Message-----
From: hai_wang@163.net [mailto:hai_wang@163.net]
Sent: Monday, July 01, 2002 3:52 AM
To: Scott.Lemon@HumanXtensions.com
Cc: manet@ietf.org; dyoung@ojctech.com
Subject: [manet] RE: [manet] IP addresses in MANET

Hello Scott:
As David Young says, Using power control to increase MANET performance is an active research area in MANET. It sure will increase MANET¡¡¥s throughput. However, firstly, because of practical reason, transmitting power can not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very small, In such network, the mobility of nodes will become a big problem:)
Practically speaking, if MANET can serve more than 10000 nodes freely, I think it is enough for real implementation. I see no case which needs more nodes than that:)

Hai Wang
------_=_NextPart_001_01C22112.DC702460-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 11:41:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12993 for ; Mon, 1 Jul 2002 11:41:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09895 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 11:41:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08102; Mon, 1 Jul 2002 11:21:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08000 for ; Mon, 1 Jul 2002 11:21:04 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11720 for ; Mon, 1 Jul 2002 11:20:16 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Mon, 1 Jul 2002 09:20:49 -0600 Message-Id: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" , "'??'" Cc: manet@ietf.org Subject: RE: [manet] RE: [manet] IP addresses in MANET Date: Mon, 1 Jul 2002 09:20:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22112.DC702460" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C22112.DC702460 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Bert, =20 It all turns on the density of your hosts and the patterns of communications. If you have a very large number of hosts in a rather = small geographical area, you will have increased contention for the RF = channel. By reducing power, you reduce the potential for interference among = hosts attempting unrelated communications on the same channel, but in significantly different geographical locations. If, on the other hand, those conversations are of interest to all nodes, then reducing power = will increase the number of hops and channel utilization. =20 =20 For example, suppose your MANET consists of clusters of hosts that are = about 1 km apart. However, within a cluster, each node is within a few = meters of at least one other node. When communications is within a cluster, it = would be prudent, to limit transmit power to that level necessary to carry = out communications within that cluster, but not high enough to cause interference between clusters. On the other hand, if you need to communicate from one cluster to another, a higher power level would be needed. =20 Also, if we agree that the MANET hosts are likely to be portable battery-powered units, then managing transmitter power is also = important from the perspective of conserving network resources. =20 =20 I would say that the ability to change transmitter power has potential = for more efficient MANET management, but its success will turn on the = ability of the protocol to detect situations in which the different power levels = are appropriate. =20 John Mullen =20 -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Monday, July 01, 2002 8:18 AM To: '??' Cc: manet@ietf.org Subject: RE: [manet] RE: [manet] IP addresses in MANET Some miscellaneous rambling: =20 Decreasing power is useful to decrease the size of cells, to make more efficient use of RF spectrum. In a system with base stations or access points, the advantages seem obvious. The wired infrastructure will have = to be upgraded for a greater traffic load, but the individual wireless = cells will support the same number of hosts in a smaller area, resulting in greater density of mobile hosts. =20 In an ad-hoc network, the advantage doesn't seem so obvious (to me). = Since ad-hoc networks depend on mobile hosts for all their intra-MANET = routing, decreasing power means increasing the number of hops required, which = means that there will be more choke points in the network and more hosts = involved in the average data path. I suppose that if one introduces faster = mobile hosts while reducing the power, same as one had to upgrade the wired infrastructure in the cell-based network with base stations, then maybe = I can understand how you'd expect better performance. =20 Bert =20 -----Original Message----- From: hai_wang@163.net [mailto:hai_wang@163.net] Sent: Monday, July 01, 2002 3:52 AM To: Scott.Lemon@HumanXtensions.com Cc: manet@ietf.org; dyoung@ojctech.com Subject: [manet] RE: [manet] IP addresses in MANET Hello Scott: As David Young says, Using power control to increase MANET performance = is an active research area in MANET. It sure will increase MANET?=A1=A5s = throughput. However, firstly, because of practical reason, transmitting power can = not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very = small, In such network, the mobility of nodes will become a big problem:)=20 Practically speaking, if MANET can serve more than 10000 nodes freely, = I think it is enough for real implementation. I see no case which needs = more nodes than that:) Hai Wang ------_=_NextPart_001_01C22112.DC702460 Content-Type: text/html; charset="gb2312"
Hi Bert,
 
It all turns on the density of your hosts and the patterns of communications.  If you have a very large number of hosts in a rather small geographical area, you will have increased contention for the RF channel.  By reducing power, you reduce the potential for interference among hosts attempting unrelated communications on the same channel, but in significantly different geographical locations.  If, on the other hand, those conversations are of interest to all nodes, then reducing power will increase the number of hops and channel utilization. 
 
For example, suppose your MANET consists of clusters of hosts that are about 1 km apart.  However, within a cluster, each node is within a few meters of at least one other node.  When communications is within a cluster, it would be prudent, to limit transmit power to that level necessary to carry out communications within that cluster, but not high enough to cause interference between clusters.  On the other hand, if you need to communicate from one cluster to another, a higher power level would be needed.
 
Also, if we agree that the MANET hosts are likely to be portable battery-powered units, then managing transmitter power is also important from the perspective of conserving network resources. 
 
I would say that the ability to change transmitter power has potential for more efficient MANET management, but its success will turn on the ability of the protocol to detect situations in which the different power levels are appropriate.
 
John Mullen
 
-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Monday, July 01, 2002 8:18 AM
To: '??'
Cc: manet@ietf.org
Subject: RE: [manet] RE: [manet] IP addresses in MANET

Some miscellaneous rambling:
 
Decreasing power is useful to decrease the size of cells, to make more efficient use of RF spectrum. In a system with base stations or access points, the advantages seem obvious. The wired infrastructure will have to be upgraded for a greater traffic load, but the individual wireless cells will support the same number of hosts in a smaller area, resulting in greater density of mobile hosts.
 
In an ad-hoc network, the advantage doesn't seem so obvious (to me). Since ad-hoc networks depend on mobile hosts for all their intra-MANET routing, decreasing power means increasing the number of hops required, which means that there will be more choke points in the network and more hosts involved in the average data path. I suppose that if one introduces faster mobile hosts while reducing the power, same as one had to upgrade the wired infrastructure in the cell-based network with base stations, then maybe I can understand how you'd expect better performance.
 
Bert
 
-----Original Message-----
From: hai_wang@163.net [mailto:hai_wang@163.net]
Sent: Monday, July 01, 2002 3:52 AM
To: Scott.Lemon@HumanXtensions.com
Cc: manet@ietf.org; dyoung@ojctech.com
Subject: [manet] RE: [manet] IP addresses in MANET

Hello Scott:
As David Young says, Using power control to increase MANET performance is an active research area in MANET. It sure will increase MANET¡¡¥s throughput. However, firstly, because of practical reason, transmitting power can not be decreasing without limit; secondly, when the transmitting power is low enough, it means that the talking area or clustering area is very small, In such network, the mobility of nodes will become a big problem:)
Practically speaking, if MANET can serve more than 10000 nodes freely, I think it is enough for real implementation. I see no case which needs more nodes than that:)

Hai Wang
------_=_NextPart_001_01C22112.DC702460-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 12:25:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16404 for ; Mon, 1 Jul 2002 12:25:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13397; Mon, 1 Jul 2002 12:03:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13362 for ; Mon, 1 Jul 2002 12:03:04 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14652 for ; Mon, 1 Jul 2002 12:02:05 -0400 (EDT) Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id RAA09674; Mon, 1 Jul 2002 17:02:50 +0100 (BST) Received: (from tapselj0@localhost) by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g61G2Tg02157; Mon, 1 Jul 2002 17:02:29 +0100 Date: Mon, 1 Jul 2002 17:02:29 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_2153_1025539349_1@ug003> Content-ID: <18137_2153_1025539349_2@ug003> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] diff-serv + RSVP Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable Really stupid question... but has anyone given the idea of the diff-serv stuff with RSVP over the same network any thought? I was thinking you could have the per-node routing until that breaks down, then switching to RSVP... = Thoughts? John Tapsell _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 12:25:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16414 for ; Mon, 1 Jul 2002 12:25:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15523 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 12:26:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13397; Mon, 1 Jul 2002 12:03:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13362 for ; Mon, 1 Jul 2002 12:03:04 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14652 for ; Mon, 1 Jul 2002 12:02:05 -0400 (EDT) Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id RAA09674; Mon, 1 Jul 2002 17:02:50 +0100 (BST) Received: (from tapselj0@localhost) by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g61G2Tg02157; Mon, 1 Jul 2002 17:02:29 +0100 Date: Mon, 1 Jul 2002 17:02:29 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_2153_1025539349_1@ug003> Content-ID: <18137_2153_1025539349_2@ug003> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] diff-serv + RSVP Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable Really stupid question... but has anyone given the idea of the diff-serv stuff with RSVP over the same network any thought? I was thinking you could have the per-node routing until that breaks down, then switching to RSVP... = Thoughts? John Tapsell _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 13:05:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18860 for ; Mon, 1 Jul 2002 13:05:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17372; Mon, 1 Jul 2002 12:41:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17335 for ; Mon, 1 Jul 2002 12:40:57 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17355 for ; Mon, 1 Jul 2002 12:40:09 -0400 (EDT) Received: from miller (miller [128.111.49.136]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id g61Ge5E05194; Mon, 1 Jul 2002 09:40:15 -0700 (PDT) Date: Mon, 1 Jul 2002 09:40:05 -0700 (PDT) From: "Elizabeth M. Belding-Royer" X-Sender: eroyer@miller To: Zhenqiang Ye cc: "Charles E. Perkins" , manet@ietf.org Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org The paper should appear later this year in the International Journal on Network Management. We don't yet know in which issue it will appear. Title: Scalability Study of the Ad hoc On-Demand Distance Vector Routing Protocol. Authors: Sung-Ju Lee, Elizabeth M. Belding-Royer, and Charles E. Perkins. > Hi, Charles: > Did you publish your experiment results? Where can I find it? I am very > interested in it. > > Regards, > > Zhenqiang(Frank) Ye > > On Fri, 28 Jun 2002, Charles E. Perkins wrote: > > > > > Hello Vijay, > > > > We did experiments with 10,000 nodes running AODV which > > indicated the need and beneficial directions for study. > > I think that recent advances in understanding for AODV > > would yield substantial performance improvements. > > > > I don't know of any other experiments of similar scale, > > and I don't know of any experiments at all with 100,000 > > nodes. That would be one of our next milestones with AODV, > > though... > > > > Regards, > > Charlie P. > > > > > > > > Vijay Kumar wrote: > > > > > > hi! > > > > > > I am basicaly new to this list . > > > Has any work been done on routing in Large Scale MANETS (RWNs as > > > mentioned below? Whcih are the protocols which have been tested / > > > developed for such routing and where can i find them? > > > > > > thanks, > > > Vijay > > > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > > > Hi Hai Wang, > > > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > > Protocol (ZRP). > > > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > > hoc networks by rapidly changing network topologies, influenced by network > > > > size and node mobility. Typically, such networks have a large span and > > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > > emphasis). > > > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > > protocol works under those conditions, it will probably work anywhere and > > > > anytime. (Though it could be overkill in simpler cases). > > > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > > other MANET protocols, too :-) > > > > > > > > All I know is what I'm reading in books and papers. > > > > > > > > John Mullen > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 13:05:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18869 for ; Mon, 1 Jul 2002 13:05:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19406 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 13:06:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17372; Mon, 1 Jul 2002 12:41:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17335 for ; Mon, 1 Jul 2002 12:40:57 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17355 for ; Mon, 1 Jul 2002 12:40:09 -0400 (EDT) Received: from miller (miller [128.111.49.136]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id g61Ge5E05194; Mon, 1 Jul 2002 09:40:15 -0700 (PDT) Date: Mon, 1 Jul 2002 09:40:05 -0700 (PDT) From: "Elizabeth M. Belding-Royer" X-Sender: eroyer@miller To: Zhenqiang Ye cc: "Charles E. Perkins" , manet@ietf.org Subject: Re: [manet] RE: Maximum MANET size In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org The paper should appear later this year in the International Journal on Network Management. We don't yet know in which issue it will appear. Title: Scalability Study of the Ad hoc On-Demand Distance Vector Routing Protocol. Authors: Sung-Ju Lee, Elizabeth M. Belding-Royer, and Charles E. Perkins. > Hi, Charles: > Did you publish your experiment results? Where can I find it? I am very > interested in it. > > Regards, > > Zhenqiang(Frank) Ye > > On Fri, 28 Jun 2002, Charles E. Perkins wrote: > > > > > Hello Vijay, > > > > We did experiments with 10,000 nodes running AODV which > > indicated the need and beneficial directions for study. > > I think that recent advances in understanding for AODV > > would yield substantial performance improvements. > > > > I don't know of any other experiments of similar scale, > > and I don't know of any experiments at all with 100,000 > > nodes. That would be one of our next milestones with AODV, > > though... > > > > Regards, > > Charlie P. > > > > > > > > Vijay Kumar wrote: > > > > > > hi! > > > > > > I am basicaly new to this list . > > > Has any work been done on routing in Large Scale MANETS (RWNs as > > > mentioned below? Whcih are the protocols which have been tested / > > > developed for such routing and where can i find them? > > > > > > thanks, > > > Vijay > > > > > > On Fri, 28 Jun 2002, Mullen, John P. (Contractor) wrote: > > > > > > > Hi Hai Wang, > > > > > > > > I just came across this in Hass and Pearlman's description of Zone Routing > > > > Protocol (ZRP). > > > > > > > > "RWNs (Reconfigurable Wireless Networks) are distinguishable from other ad > > > > hoc networks by rapidly changing network topologies, influenced by network > > > > size and node mobility. Typically, such networks have a large span and > > > > contain hundreds to thousands of nodes." [Ad Hoc Networking, p. 222]. (my > > > > emphasis). > > > > > > > > I'd say "hundreds to thousands" qualifies as "large" in my book! > > > > > > > > As to what a RWN is, as far as I can tell, it is simply a very large, very > > > > dynamic MANET that has to be ready to go as soon as it is deployed. If a > > > > protocol works under those conditions, it will probably work anywhere and > > > > anytime. (Though it could be overkill in simpler cases). > > > > > > > > Incidentally, I think Zygmunt Hass is on this working group, so if you want > > > > to learn more about ZRP, this is the place to ask. (Also the place for > > > > other MANET protocols, too :-) > > > > > > > > All I know is what I'm reading in books and papers. > > > > > > > > John Mullen > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 13:44:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21550 for ; Mon, 1 Jul 2002 13:44:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19629; Mon, 1 Jul 2002 13:09:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19597 for ; Mon, 1 Jul 2002 13:09:43 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19108 for ; Mon, 1 Jul 2002 13:08:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04579; Mon, 1 Jul 2002 10:09:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61H9AA24780; Mon, 1 Jul 2002 10:09:10 -0700 X-mProtect: <200207011709> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2KAiAb; Mon, 01 Jul 2002 10:09:08 PDT Message-ID: <3D208C6E.CFEFA825@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:07:59 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mullen, John P. (Contractor)" CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello John, "Mullen, John P. (Contractor)" wrote: > Hi, > > I know I'm missing something here. > > Why can't the MANET be treated as a local intranet with each of its nodes > having a common Internet subnet mask (augmented by whatever is needed to > affect routing within the MANET, of course.) When a gateway sees a packet > bearing an IP with the MANET subnet mask, it knows it is intended for a node > within the MANET, while one with a different pattern would be clearly > intended for the Internet. This can be done, yes. And yet, it should at the same time be possible for nodes to join the MANET without having to conform to the subnet addressability that is offered. Those nodes, however, may be unable to make use of the bidirectional Internet connectivity offered by the gateway. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 13:44:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21557 for ; Mon, 1 Jul 2002 13:44:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23839 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 13:45:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19629; Mon, 1 Jul 2002 13:09:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19597 for ; Mon, 1 Jul 2002 13:09:43 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19108 for ; Mon, 1 Jul 2002 13:08:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04579; Mon, 1 Jul 2002 10:09:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61H9AA24780; Mon, 1 Jul 2002 10:09:10 -0700 X-mProtect: <200207011709> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2KAiAb; Mon, 01 Jul 2002 10:09:08 PDT Message-ID: <3D208C6E.CFEFA825@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:07:59 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mullen, John P. (Contractor)" CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello John, "Mullen, John P. (Contractor)" wrote: > Hi, > > I know I'm missing something here. > > Why can't the MANET be treated as a local intranet with each of its nodes > having a common Internet subnet mask (augmented by whatever is needed to > affect routing within the MANET, of course.) When a gateway sees a packet > bearing an IP with the MANET subnet mask, it knows it is intended for a node > within the MANET, while one with a different pattern would be clearly > intended for the Internet. This can be done, yes. And yet, it should at the same time be possible for nodes to join the MANET without having to conform to the subnet addressability that is offered. Those nodes, however, may be unable to make use of the bidirectional Internet connectivity offered by the gateway. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 13:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21957 for ; Mon, 1 Jul 2002 13:50:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22368; Mon, 1 Jul 2002 13:35:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22340 for ; Mon, 1 Jul 2002 13:35:51 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20913 for ; Mon, 1 Jul 2002 13:35:03 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA03275; Mon, 1 Jul 2002 10:35:49 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA19371; Mon, 1 Jul 2002 12:35:45 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61HZk002457; Mon, 1 Jul 2002 10:35:46 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 13:35:45 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DA@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 13:35:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Charlie Perkins wrote: > Finally, > the node can use its pre-existing IP address (not topologically > correct) for bidirectional Internet communications, but in > that case it has to use Mobile IP. Charlie, I think that even this limitation is not mandatory, as we discussed last week. In principle, if the Internet gateways to the MANET and the MANET hosts conduct ICMP Router Discovery (RFC 1256), and if the gateways maintain a complete list of all MANET hosts, as if the MANET host IP addresses were just arbitrary flat addresses, then MANET hosts should be able to conduct bidirectional Internet communications without going to Mobile IP. The gateways would sort of operate like NATs, except that the MANET side is a flat address space. That's why the gateways need the exhaustive list of all MANET hosts. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 13:50:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21970 for ; Mon, 1 Jul 2002 13:50:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24668 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 13:51:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22368; Mon, 1 Jul 2002 13:35:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22340 for ; Mon, 1 Jul 2002 13:35:51 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20913 for ; Mon, 1 Jul 2002 13:35:03 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA03275; Mon, 1 Jul 2002 10:35:49 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA19371; Mon, 1 Jul 2002 12:35:45 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61HZk002457; Mon, 1 Jul 2002 10:35:46 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 13:35:45 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DA@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 13:35:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Charlie Perkins wrote: > Finally, > the node can use its pre-existing IP address (not topologically > correct) for bidirectional Internet communications, but in > that case it has to use Mobile IP. Charlie, I think that even this limitation is not mandatory, as we discussed last week. In principle, if the Internet gateways to the MANET and the MANET hosts conduct ICMP Router Discovery (RFC 1256), and if the gateways maintain a complete list of all MANET hosts, as if the MANET host IP addresses were just arbitrary flat addresses, then MANET hosts should be able to conduct bidirectional Internet communications without going to Mobile IP. The gateways would sort of operate like NATs, except that the MANET side is a flat address space. That's why the gateways need the exhaustive list of all MANET hosts. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 13:52:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22143 for ; Mon, 1 Jul 2002 13:52:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21253; Mon, 1 Jul 2002 13:30:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21199 for ; Mon, 1 Jul 2002 13:30:02 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20594 for ; Mon, 1 Jul 2002 13:29:14 -0400 (EDT) Received: (qmail 32569 invoked from network); 1 Jul 2002 17:29:59 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 1 Jul 2002 17:29:59 -0000 To: manet@ietf.org, ns-users@isi.edu From: Jonas Nielsen Date: 01 Jul 2002 19:29:59 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] The size of hdr_sr in the DSR implementation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I'm trying to expand the DSR protocol by caching the routes from cancelled route requests on each node as the route request is moving to its destination. I will then piggyback these routes on a route reply. Therefore I have tried to expand the hdr_sr struct by a c-array of additional routes. This works fine if the number of additional routes are not above 5. However if there is allocated space for over 5 routes in the hdr_sr structure the packets aren't transferred correctly. (which normally results in segmentation faults in various places). Are there a maximum limit of header size in ns and how do I change it ? (I know it has nothing to do with the value computed in the Size function). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 13:52:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22151 for ; Mon, 1 Jul 2002 13:52:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24937 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 13:52:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21253; Mon, 1 Jul 2002 13:30:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21199 for ; Mon, 1 Jul 2002 13:30:02 -0400 (EDT) Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20594 for ; Mon, 1 Jul 2002 13:29:14 -0400 (EDT) Received: (qmail 32569 invoked from network); 1 Jul 2002 17:29:59 -0000 Received: from pc-026.diku.dk (130.225.97.26) by hugin.diku.dk with QMQP; 1 Jul 2002 17:29:59 -0000 To: manet@ietf.org, ns-users@isi.edu From: Jonas Nielsen Date: 01 Jul 2002 19:29:59 +0200 Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] The size of hdr_sr in the DSR implementation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I'm trying to expand the DSR protocol by caching the routes from cancelled route requests on each node as the route request is moving to its destination. I will then piggyback these routes on a route reply. Therefore I have tried to expand the hdr_sr struct by a c-array of additional routes. This works fine if the number of additional routes are not above 5. However if there is allocated space for over 5 routes in the hdr_sr structure the packets aren't transferred correctly. (which normally results in segmentation faults in various places). Are there a maximum limit of header size in ns and how do I change it ? (I know it has nothing to do with the value computed in the Size function). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 14:03:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22780 for ; Mon, 1 Jul 2002 14:03:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22265; Mon, 1 Jul 2002 13:34:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22232 for ; Mon, 1 Jul 2002 13:34:33 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20837 for ; Mon, 1 Jul 2002 13:33:44 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Jul 1 10:33:44 2002 To: "Manfredi, Albert E" , "Mullen, John P. (Contractor)" Date: Mon, 01 Jul 2002 13:33:44 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] Gateway address resolution X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Your e-mail holds many interesting ideas. It clearly raises the need to understand why MANET should not rely on a pool of contiguous IP addresses. 1) Nodes should be able to roam freely in the network. If a cellular node connected to the cellular network via address xxxx came into accessable range of a bluetooth MANET based network, it might decide to join. Obviously, the node prefer to keep its xxxx address. 2) Imagine the situation when you have many MANET networks scaterd in somewhat geographically limited area. Every network will be able to adminstrate itself (ie assign contiguous IP addresses, and subnet mask). Those MANET networks will have occasional interference in shared areas (areas that may belong to more than one MANET). Shared areas obviously have dynamic nature. Nodes roaming from one MANET network to the next should be able to do so without giving up it's IP address. 3) The use of anytype of DHCP requires adminstration both at the node level, and centralized level. In addition, centralized management of MANET contradicts it's charter. 4) Users are entitled to have thier own IP addresses. Assume my PDA address is yyyy, and it is a static IP that is recognizable throughout the internet. Part of the IPv6 effort is to allow personal IP addresses. Overiding this address contradicts with IPv6 directions. However, I understand that having a pool of contiguous addresses may be the common case. Yet, building the network should be based on the more general case. Comments? Yasser ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 14:03:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22787 for ; Mon, 1 Jul 2002 14:03:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26407 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 14:04:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22265; Mon, 1 Jul 2002 13:34:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22232 for ; Mon, 1 Jul 2002 13:34:33 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20837 for ; Mon, 1 Jul 2002 13:33:44 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Jul 1 10:33:44 2002 To: "Manfredi, Albert E" , "Mullen, John P. (Contractor)" Date: Mon, 01 Jul 2002 13:33:44 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] Gateway address resolution X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Your e-mail holds many interesting ideas. It clearly raises the need to understand why MANET should not rely on a pool of contiguous IP addresses. 1) Nodes should be able to roam freely in the network. If a cellular node connected to the cellular network via address xxxx came into accessable range of a bluetooth MANET based network, it might decide to join. Obviously, the node prefer to keep its xxxx address. 2) Imagine the situation when you have many MANET networks scaterd in somewhat geographically limited area. Every network will be able to adminstrate itself (ie assign contiguous IP addresses, and subnet mask). Those MANET networks will have occasional interference in shared areas (areas that may belong to more than one MANET). Shared areas obviously have dynamic nature. Nodes roaming from one MANET network to the next should be able to do so without giving up it's IP address. 3) The use of anytype of DHCP requires adminstration both at the node level, and centralized level. In addition, centralized management of MANET contradicts it's charter. 4) Users are entitled to have thier own IP addresses. Assume my PDA address is yyyy, and it is a static IP that is recognizable throughout the internet. Part of the IPv6 effort is to allow personal IP addresses. Overiding this address contradicts with IPv6 directions. However, I understand that having a pool of contiguous addresses may be the common case. Yet, building the network should be based on the more general case. Comments? Yasser ____________________________________________________________ Win a first-class trip to New Orleans and vacation Elvis Style!. Enter NOW! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 14:07:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23059 for ; Mon, 1 Jul 2002 14:07:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23266; Mon, 1 Jul 2002 13:40:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23235 for ; Mon, 1 Jul 2002 13:40:53 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21252 for ; Mon, 1 Jul 2002 13:40:04 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06915; Mon, 1 Jul 2002 10:40:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61HeKj05984; Mon, 1 Jul 2002 10:40:20 -0700 X-mProtect: <200207011740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1BCf3y; Mon, 01 Jul 2002 10:40:18 PDT Message-ID: <3D2093C0.FD72ECAB@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:39:14 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DA@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Bert, In the case you describe, what address does a host in the Internet use as the destination address, to connect with the manet node? "Manfredi, Albert E" wrote: > Charlie Perkins wrote: > > > Finally, > > the node can use its pre-existing IP address (not topologically > > correct) for bidirectional Internet communications, but in > > that case it has to use Mobile IP. > > Charlie, > > I think that even this limitation is not mandatory, as we discussed last week. In principle, if the Internet gateways to the MANET and the MANET hosts conduct ICMP Router Discovery (RFC 1256), and if the gateways maintain a complete list of all MANET hosts, as if the MANET host IP addresses were just arbitrary flat addresses, then MANET hosts should be able to conduct bidirectional Internet communications without going to Mobile IP. > > The gateways would sort of operate like NATs, except that the MANET side is a flat address space. That's why the gateways need the exhaustive list of all MANET hosts. > > Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 14:07:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23068 for ; Mon, 1 Jul 2002 14:07:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26591 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 14:08:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23266; Mon, 1 Jul 2002 13:40:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23235 for ; Mon, 1 Jul 2002 13:40:53 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21252 for ; Mon, 1 Jul 2002 13:40:04 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06915; Mon, 1 Jul 2002 10:40:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61HeKj05984; Mon, 1 Jul 2002 10:40:20 -0700 X-mProtect: <200207011740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1BCf3y; Mon, 01 Jul 2002 10:40:18 PDT Message-ID: <3D2093C0.FD72ECAB@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:39:14 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DA@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Bert, In the case you describe, what address does a host in the Internet use as the destination address, to connect with the manet node? "Manfredi, Albert E" wrote: > Charlie Perkins wrote: > > > Finally, > > the node can use its pre-existing IP address (not topologically > > correct) for bidirectional Internet communications, but in > > that case it has to use Mobile IP. > > Charlie, > > I think that even this limitation is not mandatory, as we discussed last week. In principle, if the Internet gateways to the MANET and the MANET hosts conduct ICMP Router Discovery (RFC 1256), and if the gateways maintain a complete list of all MANET hosts, as if the MANET host IP addresses were just arbitrary flat addresses, then MANET hosts should be able to conduct bidirectional Internet communications without going to Mobile IP. > > The gateways would sort of operate like NATs, except that the MANET side is a flat address space. That's why the gateways need the exhaustive list of all MANET hosts. > > Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 14:17:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23706 for ; Mon, 1 Jul 2002 14:17:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20334; Mon, 1 Jul 2002 13:16:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20275 for ; Mon, 1 Jul 2002 13:16:31 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19620 for ; Mon, 1 Jul 2002 13:15:39 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05388; Mon, 1 Jul 2002 10:15:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61HFrC00984; Mon, 1 Jul 2002 10:15:53 -0700 X-mProtect: <200207011715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM4V9Ck; Mon, 01 Jul 2002 10:15:51 PDT Message-ID: <3D208E05.B1FACF61@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:14:46 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39D7@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Bert, "Manfredi, Albert E" wrote: > If you expect the MANET hosts to belong to a particular IP subnet, that mandates some sort of manual or automatic IP address/mask configuration, with the requisite changes as the host roams. We have a draft: draft-wakikawa-manet-globalv6-01.txt also available at: http://people.nokia.net/charliep/txt/aodvid/globalv6.txt (but the formatting isn't perfect). that offers a solution for enabling Internet connectivity for manet nodes. In our solution, a node can keep its old address and work fine in the ad hoc network. However, if it wants Internet connectivity, then it has to configure an address that is topologically correct for the point of attachment of the MANET to the Internet. If the node has no address, it can stateless autoconfigure one for the manet, using a predefined site-local prefix. It can also stateless autoconfigue a topologically correct address if it gets information from the gateway. Finally, the node can use its pre-existing IP address (not topologically correct) for bidirectional Internet communications, but in that case it has to use Mobile IP. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 14:17:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23729 for ; Mon, 1 Jul 2002 14:17:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27310 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 14:18:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20334; Mon, 1 Jul 2002 13:16:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20275 for ; Mon, 1 Jul 2002 13:16:31 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19620 for ; Mon, 1 Jul 2002 13:15:39 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05388; Mon, 1 Jul 2002 10:15:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61HFrC00984; Mon, 1 Jul 2002 10:15:53 -0700 X-mProtect: <200207011715> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM4V9Ck; Mon, 01 Jul 2002 10:15:51 PDT Message-ID: <3D208E05.B1FACF61@iprg.nokia.com> Date: Mon, 01 Jul 2002 10:14:46 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39D7@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Bert, "Manfredi, Albert E" wrote: > If you expect the MANET hosts to belong to a particular IP subnet, that mandates some sort of manual or automatic IP address/mask configuration, with the requisite changes as the host roams. We have a draft: draft-wakikawa-manet-globalv6-01.txt also available at: http://people.nokia.net/charliep/txt/aodvid/globalv6.txt (but the formatting isn't perfect). that offers a solution for enabling Internet connectivity for manet nodes. In our solution, a node can keep its old address and work fine in the ad hoc network. However, if it wants Internet connectivity, then it has to configure an address that is topologically correct for the point of attachment of the MANET to the Internet. If the node has no address, it can stateless autoconfigure one for the manet, using a predefined site-local prefix. It can also stateless autoconfigue a topologically correct address if it gets information from the gateway. Finally, the node can use its pre-existing IP address (not topologically correct) for bidirectional Internet communications, but in that case it has to use Mobile IP. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 14:20:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23814 for ; Mon, 1 Jul 2002 14:20:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24685; Mon, 1 Jul 2002 13:51:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24643 for ; Mon, 1 Jul 2002 13:51:08 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21953 for ; Mon, 1 Jul 2002 13:50:18 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA08382; Mon, 1 Jul 2002 12:51:03 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA04935; Mon, 1 Jul 2002 12:51:00 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61Hp0028095; Mon, 1 Jul 2002 10:51:01 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 13:51:00 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DB@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 13:50:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Charlie, In the case I described, the MANET host would have to transmit first. Similar to the situation you have today with DHCP and IEEE 802.11 nets in "infrastructure mode." If the MANET host initiates the session, then the fixed Internet host will see the IP address assigned to the MANET host by the MANET gateway at that time. I agree that if you want Internet hosts to initiate the session with the MANET host, without any prior knowledge, then Mobile IP would be required. Bert Charlie Perkins wrote: > Hello Bert, > > In the case you describe, what address does a host in the Internet use > as the destination address, to connect with the manet node? > > "Manfredi, Albert E" wrote: > > > Charlie Perkins wrote: > > > > > Finally, > > > the node can use its pre-existing IP address (not topologically > > > correct) for bidirectional Internet communications, but in > > > that case it has to use Mobile IP. > > > > Charlie, > > > > I think that even this limitation is not mandatory, as we > discussed last week. In principle, if the Internet gateways > to the MANET and the MANET hosts conduct ICMP Router > Discovery (RFC 1256), and if the gateways maintain a complete > list of all MANET hosts, as if the MANET host IP addresses > were just arbitrary flat addresses, then MANET hosts should > be able to conduct bidirectional Internet communications > without going to Mobile IP. > > > > The gateways would sort of operate like NATs, except that > the MANET side is a flat address space. That's why the > gateways need the exhaustive list of all MANET hosts. > > > > Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 14:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23822 for ; Mon, 1 Jul 2002 14:20:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27348 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 14:21:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24685; Mon, 1 Jul 2002 13:51:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24643 for ; Mon, 1 Jul 2002 13:51:08 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21953 for ; Mon, 1 Jul 2002 13:50:18 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA08382; Mon, 1 Jul 2002 12:51:03 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA04935; Mon, 1 Jul 2002 12:51:00 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61Hp0028095; Mon, 1 Jul 2002 10:51:01 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 13:51:00 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DB@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 13:50:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Charlie, In the case I described, the MANET host would have to transmit first. Similar to the situation you have today with DHCP and IEEE 802.11 nets in "infrastructure mode." If the MANET host initiates the session, then the fixed Internet host will see the IP address assigned to the MANET host by the MANET gateway at that time. I agree that if you want Internet hosts to initiate the session with the MANET host, without any prior knowledge, then Mobile IP would be required. Bert Charlie Perkins wrote: > Hello Bert, > > In the case you describe, what address does a host in the Internet use > as the destination address, to connect with the manet node? > > "Manfredi, Albert E" wrote: > > > Charlie Perkins wrote: > > > > > Finally, > > > the node can use its pre-existing IP address (not topologically > > > correct) for bidirectional Internet communications, but in > > > that case it has to use Mobile IP. > > > > Charlie, > > > > I think that even this limitation is not mandatory, as we > discussed last week. In principle, if the Internet gateways > to the MANET and the MANET hosts conduct ICMP Router > Discovery (RFC 1256), and if the gateways maintain a complete > list of all MANET hosts, as if the MANET host IP addresses > were just arbitrary flat addresses, then MANET hosts should > be able to conduct bidirectional Internet communications > without going to Mobile IP. > > > > The gateways would sort of operate like NATs, except that > the MANET side is a flat address space. That's why the > gateways need the exhaustive list of all MANET hosts. > > > > Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 15:01:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26399 for ; Mon, 1 Jul 2002 15:01:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27643; Mon, 1 Jul 2002 14:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27604 for ; Mon, 1 Jul 2002 14:27:17 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24170 for ; Mon, 1 Jul 2002 14:26:27 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id NAA19492 for manet@ietf.org; Mon, 1 Jul 2002 13:26:43 -0500 Date: Mon, 1 Jul 2002 13:26:43 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] tx power adjustment Message-ID: <20020701132643.B22306@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil>; from mullenjp.contractor@trac.wsmr.army.mil on Mon, Jul 01, 2002 at 09:20:41AM -0600 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit In some research, a host transmits a beacon at each TX power level and listens for beacon-replies to discover its neighbors. Then the host labels each neighbor's route with the least TX power level necessary to reach that neighbor. Packets destined for a neighbor are transmitted with the power level labeling the neighbor's route. If a host discovers neighbors with beacons independently of discovering routes with an ad hoc routing protocol, then sometimes a neighbor will have two routes, one discovered by the beacon and one discovered by the routing protocol. Then the host will have a choice between shouting at a far away neighbor, or whispering to a nearer neighbor who will whisper to the far away neighbor. A strategy for choosing between one "loud" hop and several quiet ones could be quite complex, it seems. Suppose you tried to estimate and minimize the product of a packet's on-air time and the area silenced by its (re)transmission? Dave On Mon, Jul 01, 2002 at 09:20:41AM -0600, Mullen, John P. (Contractor) wrote: > Hi Bert, > > It all turns on the density of your hosts and the patterns of > communications. If you have a very large number of hosts in a rather small > geographical area, you will have increased contention for the RF channel. > By reducing power, you reduce the potential for interference among hosts > attempting unrelated communications on the same channel, but in > significantly different geographical locations. If, on the other hand, > those conversations are of interest to all nodes, then reducing power will > increase the number of hops and channel utilization. > > For example, suppose your MANET consists of clusters of hosts that are about > 1 km apart. However, within a cluster, each node is within a few meters of > at least one other node. When communications is within a cluster, it would > be prudent, to limit transmit power to that level necessary to carry out > communications within that cluster, but not high enough to cause > interference between clusters. On the other hand, if you need to > communicate from one cluster to another, a higher power level would be > needed. > > Also, if we agree that the MANET hosts are likely to be portable > battery-powered units, then managing transmitter power is also important > from the perspective of conserving network resources. > > I would say that the ability to change transmitter power has potential for > more efficient MANET management, but its success will turn on the ability of > the protocol to detect situations in which the different power levels are > appropriate. > > John Mullen > > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Monday, July 01, 2002 8:18 AM > To: '??' > Cc: manet@ietf.org > Subject: RE: [manet] RE: [manet] IP addresses in MANET > > > Some miscellaneous rambling: > > Decreasing power is useful to decrease the size of cells, to make more > efficient use of RF spectrum. In a system with base stations or access > points, the advantages seem obvious. The wired infrastructure will have to > be upgraded for a greater traffic load, but the individual wireless cells > will support the same number of hosts in a smaller area, resulting in > greater density of mobile hosts. > > In an ad-hoc network, the advantage doesn't seem so obvious (to me). Since > ad-hoc networks depend on mobile hosts for all their intra-MANET routing, > decreasing power means increasing the number of hops required, which means > that there will be more choke points in the network and more hosts involved > in the average data path. I suppose that if one introduces faster mobile > hosts while reducing the power, same as one had to upgrade the wired > infrastructure in the cell-based network with base stations, then maybe I > can understand how you'd expect better performance. > > Bert > > > -----Original Message----- > From: hai_wang@163.net [mailto:hai_wang@163.net] > Sent: Monday, July 01, 2002 3:52 AM > To: Scott.Lemon@HumanXtensions.com > Cc: manet@ietf.org; dyoung@ojctech.com > Subject: [manet] RE: [manet] IP addresses in MANET > > > Hello Scott: > As David Young says, Using power control to increase MANET performance is an > active research area in MANET. It sure will increase MANET?¡¥s throughput. > However, firstly, because of practical reason, transmitting power can not be > decreasing without limit; secondly, when the transmitting power is low > enough, it means that the talking area or clustering area is very small, In > such network, the mobility of nodes will become a big problem:) > Practically speaking, if MANET can serve more than 10000 nodes freely, I > think it is enough for real implementation. I see no case which needs more > nodes than that:) > > Hai Wang > > -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 15:01:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26408 for ; Mon, 1 Jul 2002 15:01:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01877 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 15:02:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27643; Mon, 1 Jul 2002 14:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27604 for ; Mon, 1 Jul 2002 14:27:17 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24170 for ; Mon, 1 Jul 2002 14:26:27 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id NAA19492 for manet@ietf.org; Mon, 1 Jul 2002 13:26:43 -0500 Date: Mon, 1 Jul 2002 13:26:43 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] tx power adjustment Message-ID: <20020701132643.B22306@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil>; from mullenjp.contractor@trac.wsmr.army.mil on Mon, Jul 01, 2002 at 09:20:41AM -0600 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit In some research, a host transmits a beacon at each TX power level and listens for beacon-replies to discover its neighbors. Then the host labels each neighbor's route with the least TX power level necessary to reach that neighbor. Packets destined for a neighbor are transmitted with the power level labeling the neighbor's route. If a host discovers neighbors with beacons independently of discovering routes with an ad hoc routing protocol, then sometimes a neighbor will have two routes, one discovered by the beacon and one discovered by the routing protocol. Then the host will have a choice between shouting at a far away neighbor, or whispering to a nearer neighbor who will whisper to the far away neighbor. A strategy for choosing between one "loud" hop and several quiet ones could be quite complex, it seems. Suppose you tried to estimate and minimize the product of a packet's on-air time and the area silenced by its (re)transmission? Dave On Mon, Jul 01, 2002 at 09:20:41AM -0600, Mullen, John P. (Contractor) wrote: > Hi Bert, > > It all turns on the density of your hosts and the patterns of > communications. If you have a very large number of hosts in a rather small > geographical area, you will have increased contention for the RF channel. > By reducing power, you reduce the potential for interference among hosts > attempting unrelated communications on the same channel, but in > significantly different geographical locations. If, on the other hand, > those conversations are of interest to all nodes, then reducing power will > increase the number of hops and channel utilization. > > For example, suppose your MANET consists of clusters of hosts that are about > 1 km apart. However, within a cluster, each node is within a few meters of > at least one other node. When communications is within a cluster, it would > be prudent, to limit transmit power to that level necessary to carry out > communications within that cluster, but not high enough to cause > interference between clusters. On the other hand, if you need to > communicate from one cluster to another, a higher power level would be > needed. > > Also, if we agree that the MANET hosts are likely to be portable > battery-powered units, then managing transmitter power is also important > from the perspective of conserving network resources. > > I would say that the ability to change transmitter power has potential for > more efficient MANET management, but its success will turn on the ability of > the protocol to detect situations in which the different power levels are > appropriate. > > John Mullen > > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Monday, July 01, 2002 8:18 AM > To: '??' > Cc: manet@ietf.org > Subject: RE: [manet] RE: [manet] IP addresses in MANET > > > Some miscellaneous rambling: > > Decreasing power is useful to decrease the size of cells, to make more > efficient use of RF spectrum. In a system with base stations or access > points, the advantages seem obvious. The wired infrastructure will have to > be upgraded for a greater traffic load, but the individual wireless cells > will support the same number of hosts in a smaller area, resulting in > greater density of mobile hosts. > > In an ad-hoc network, the advantage doesn't seem so obvious (to me). Since > ad-hoc networks depend on mobile hosts for all their intra-MANET routing, > decreasing power means increasing the number of hops required, which means > that there will be more choke points in the network and more hosts involved > in the average data path. I suppose that if one introduces faster mobile > hosts while reducing the power, same as one had to upgrade the wired > infrastructure in the cell-based network with base stations, then maybe I > can understand how you'd expect better performance. > > Bert > > > -----Original Message----- > From: hai_wang@163.net [mailto:hai_wang@163.net] > Sent: Monday, July 01, 2002 3:52 AM > To: Scott.Lemon@HumanXtensions.com > Cc: manet@ietf.org; dyoung@ojctech.com > Subject: [manet] RE: [manet] IP addresses in MANET > > > Hello Scott: > As David Young says, Using power control to increase MANET performance is an > active research area in MANET. It sure will increase MANET?¡¥s throughput. > However, firstly, because of practical reason, transmitting power can not be > decreasing without limit; secondly, when the transmitting power is low > enough, it means that the talking area or clustering area is very small, In > such network, the mobility of nodes will become a big problem:) > Practically speaking, if MANET can serve more than 10000 nodes freely, I > think it is enough for real implementation. I see no case which needs more > nodes than that:) > > Hai Wang > > -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 15:02:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26524 for ; Mon, 1 Jul 2002 15:02:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28792; Mon, 1 Jul 2002 14:35:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28749 for ; Mon, 1 Jul 2002 14:34:59 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24568 for ; Mon, 1 Jul 2002 14:34:09 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Mon, 1 Jul 2002 12:34:24 -0600 Message-Id: <02Jul1.123424mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" , "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 12:34:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Mulling on this, Suppose we had a MANET implementation of a "cellular" phone system, in which instead of a backbone of cellular antennas, routers, etc., there is just a few isolated antennas designed to act as gateways to the internet. Of course, the handsets would differ from the usual cellular handset in that it would be able to forward packets for other users and might also be strictly digital, with limited digital voice, to compensate for the limited bandwidth. The question is, how will a user entering the region of a local MANET be properly identified and make its location known to other hosts, including those access through the Internet. My thought is this: Suppose there were on the Internet a number of special servers whose function is to provide directory service for this class of users. Each mobile host would have a unique identifier (IP?) that would be easily associated with a subset of these servers, much like area code gives us an idea of what state the user is in. However, this is just to simplify the task of finding an entry and has nothing to do with the host's current association or location. Whenever a host comes within range of one of the associated MANETs, it recognizes, through Hello messages, the proximity of like hosts and broadcasts its own request to join. Once the local group accepts its membership, it unicasts a location packet to one of the Internet gateways, which keeps this information for its own use, but also forwards to the appropriate directory server the host's IP as well as the gateway's own IP. Then, any host accessing through the Internet, trying to find the mobile host in question, would request directory assistance, finding whatever information it needs to route packets to the gateway. Technically, I realize, this is a form of centralized information storage, but it is for the purpose of locating a particular host that may be on any one of hundreds of MANETs, or on none. The storage is on the Internet, not on the MANET. Local MANET routing information would not be forwarded, so the directory entry would be valid (and useful) as long as the host is in that particular MANET, even if the route to it within the MANET changes. John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 15:02:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26534 for ; Mon, 1 Jul 2002 15:02:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02006 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 15:03:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28792; Mon, 1 Jul 2002 14:35:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28749 for ; Mon, 1 Jul 2002 14:34:59 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24568 for ; Mon, 1 Jul 2002 14:34:09 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Mon, 1 Jul 2002 12:34:24 -0600 Message-Id: <02Jul1.123424mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" , "'Charlie Perkins'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 12:34:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Mulling on this, Suppose we had a MANET implementation of a "cellular" phone system, in which instead of a backbone of cellular antennas, routers, etc., there is just a few isolated antennas designed to act as gateways to the internet. Of course, the handsets would differ from the usual cellular handset in that it would be able to forward packets for other users and might also be strictly digital, with limited digital voice, to compensate for the limited bandwidth. The question is, how will a user entering the region of a local MANET be properly identified and make its location known to other hosts, including those access through the Internet. My thought is this: Suppose there were on the Internet a number of special servers whose function is to provide directory service for this class of users. Each mobile host would have a unique identifier (IP?) that would be easily associated with a subset of these servers, much like area code gives us an idea of what state the user is in. However, this is just to simplify the task of finding an entry and has nothing to do with the host's current association or location. Whenever a host comes within range of one of the associated MANETs, it recognizes, through Hello messages, the proximity of like hosts and broadcasts its own request to join. Once the local group accepts its membership, it unicasts a location packet to one of the Internet gateways, which keeps this information for its own use, but also forwards to the appropriate directory server the host's IP as well as the gateway's own IP. Then, any host accessing through the Internet, trying to find the mobile host in question, would request directory assistance, finding whatever information it needs to route packets to the gateway. Technically, I realize, this is a form of centralized information storage, but it is for the purpose of locating a particular host that may be on any one of hundreds of MANETs, or on none. The storage is on the Internet, not on the MANET. Local MANET routing information would not be forwarded, so the directory entry would be valid (and useful) as long as the host is in that particular MANET, even if the route to it within the MANET changes. John Mullen _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 15:24:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27965 for ; Mon, 1 Jul 2002 15:24:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29533; Mon, 1 Jul 2002 14:44:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29501 for ; Mon, 1 Jul 2002 14:44:55 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25191 for ; Mon, 1 Jul 2002 14:44:05 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA11186; Mon, 1 Jul 2002 11:44:42 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA13780; Mon, 1 Jul 2002 11:44:38 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61Iig026930; Mon, 1 Jul 2002 11:44:42 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 14:44:42 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DC@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 14:44:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John, How does what you describe differ from Mobile IP? In Mobile IP, the job of the home server is to keep track of where the mobile host pops up at any given time. In the basic version of Mobile IP, all packets to and from the mobile host are routed through the home server. In a newer elaboration, the actual current address of the mobile host is provided to the host wanting to communicate with the mobile host, so the home server can be bypassed. If I understand your proposal, doesn't this meet the same functionality? Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, July 01, 2002 2:34 PM > To: Manfredi, Albert E; 'Charlie Perkins' > Cc: manet@ietf.org > Subject: RE: [manet] Gateway address resolution > > > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone > system, in which > instead of a backbone of cellular antennas, routers, etc., > there is just a > few isolated antennas designed to act as gateways to the internet. > > Of course, the handsets would differ from the usual cellular > handset in that > it would be able to forward packets for other users and might also be > strictly digital, with limited digital voice, to compensate > for the limited > bandwidth. > > The question is, how will a user entering the region of a > local MANET be > properly identified and make its location known to other > hosts, including > those access through the Internet. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of > users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area > code gives us an > idea of what state the user is in. However, this is just to > simplify the > task of finding an entry and has nothing to do with the host's current > association or location. > > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the > Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the > gateway's own IP. > Then, any host accessing through the Internet, trying to find > the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. > > Technically, I realize, this is a form of centralized > information storage, > but it is for the purpose of locating a particular host that > may be on any > one of hundreds of MANETs, or on none. The storage is on the > Internet, not > on the MANET. Local MANET routing information would not be > forwarded, so > the directory entry would be valid (and useful) as long as > the host is in > that particular MANET, even if the route to it within the > MANET changes. > > John Mullen > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 15:24:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27970 for ; Mon, 1 Jul 2002 15:24:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04003 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 15:25:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29533; Mon, 1 Jul 2002 14:44:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29501 for ; Mon, 1 Jul 2002 14:44:55 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25191 for ; Mon, 1 Jul 2002 14:44:05 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA11186; Mon, 1 Jul 2002 11:44:42 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA13780; Mon, 1 Jul 2002 11:44:38 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g61Iig026930; Mon, 1 Jul 2002 11:44:42 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Jul 2002 14:44:42 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DC@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 14:44:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John, How does what you describe differ from Mobile IP? In Mobile IP, the job of the home server is to keep track of where the mobile host pops up at any given time. In the basic version of Mobile IP, all packets to and from the mobile host are routed through the home server. In a newer elaboration, the actual current address of the mobile host is provided to the host wanting to communicate with the mobile host, so the home server can be bypassed. If I understand your proposal, doesn't this meet the same functionality? Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, July 01, 2002 2:34 PM > To: Manfredi, Albert E; 'Charlie Perkins' > Cc: manet@ietf.org > Subject: RE: [manet] Gateway address resolution > > > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone > system, in which > instead of a backbone of cellular antennas, routers, etc., > there is just a > few isolated antennas designed to act as gateways to the internet. > > Of course, the handsets would differ from the usual cellular > handset in that > it would be able to forward packets for other users and might also be > strictly digital, with limited digital voice, to compensate > for the limited > bandwidth. > > The question is, how will a user entering the region of a > local MANET be > properly identified and make its location known to other > hosts, including > those access through the Internet. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of > users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area > code gives us an > idea of what state the user is in. However, this is just to > simplify the > task of finding an entry and has nothing to do with the host's current > association or location. > > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the > Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the > gateway's own IP. > Then, any host accessing through the Internet, trying to find > the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. > > Technically, I realize, this is a form of centralized > information storage, > but it is for the purpose of locating a particular host that > may be on any > one of hundreds of MANETs, or on none. The storage is on the > Internet, not > on the MANET. Local MANET routing information would not be > forwarded, so > the directory entry would be valid (and useful) as long as > the host is in > that particular MANET, even if the route to it within the > MANET changes. > > John Mullen > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 15:33:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28423 for ; Mon, 1 Jul 2002 15:33:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01029; Mon, 1 Jul 2002 14:58:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00926 for ; Mon, 1 Jul 2002 14:58:40 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26136 for ; Mon, 1 Jul 2002 14:57:50 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Mon, 1 Jul 2002 12:58:36 -0600 Message-Id: <02Jul1.125836mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: dyoung@pobox.com, manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Mon, 1 Jul 2002 12:58:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi David, In general, as the distance is doubled, the received power is quartered, or received S/N drops about 6 dB. (This is actually overly optimistic in some frequency bands). One factor is how this 6 dB drop affects bandwidth. The Shannon limit would predict about a 50% decrease in available BW, but that may not be critical. Usually, BER and other errors do you in first. Also, absolute levels count. If the original S/N is 20 dBm, there is probably not a problem, but if it were 8 dBm, ... Another factor is processing time. If 80% of the time required to move a packet from one node to the next is taken up in coding, decoding, etc., then a two-hop path would be doubly slow (added processing time plus lower transmission rate). Of course, multiple transmissions tie up the channel longer than a single one, but a "shout" ties up the channel over a greater geographic area. The effect on battery life is probably worth considering, too. Interesting problem. John Mullen -----Original Message----- From: David Young [mailto:dyoung@ojctech.com] Sent: Monday, July 01, 2002 12:27 PM To: manet@ietf.org Subject: Re: [manet] tx power adjustment In some research, a host transmits a beacon at each TX power level and listens for beacon-replies to discover its neighbors. Then the host labels each neighbor's route with the least TX power level necessary to reach that neighbor. Packets destined for a neighbor are transmitted with the power level labeling the neighbor's route. If a host discovers neighbors with beacons independently of discovering routes with an ad hoc routing protocol, then sometimes a neighbor will have two routes, one discovered by the beacon and one discovered by the routing protocol. Then the host will have a choice between shouting at a far away neighbor, or whispering to a nearer neighbor who will whisper to the far away neighbor. A strategy for choosing between one "loud" hop and several quiet ones could be quite complex, it seems. Suppose you tried to estimate and minimize the product of a packet's on-air time and the area silenced by its (re)transmission? Dave On Mon, Jul 01, 2002 at 09:20:41AM -0600, Mullen, John P. (Contractor) wrote: > Hi Bert, > > It all turns on the density of your hosts and the patterns of > communications. If you have a very large number of hosts in a rather small > geographical area, you will have increased contention for the RF channel. > By reducing power, you reduce the potential for interference among hosts > attempting unrelated communications on the same channel, but in > significantly different geographical locations. If, on the other hand, > those conversations are of interest to all nodes, then reducing power will > increase the number of hops and channel utilization. > > For example, suppose your MANET consists of clusters of hosts that are about > 1 km apart. However, within a cluster, each node is within a few meters of > at least one other node. When communications is within a cluster, it would > be prudent, to limit transmit power to that level necessary to carry out > communications within that cluster, but not high enough to cause > interference between clusters. On the other hand, if you need to > communicate from one cluster to another, a higher power level would be > needed. > > Also, if we agree that the MANET hosts are likely to be portable > battery-powered units, then managing transmitter power is also important > from the perspective of conserving network resources. > > I would say that the ability to change transmitter power has potential for > more efficient MANET management, but its success will turn on the ability of > the protocol to detect situations in which the different power levels are > appropriate. > > John Mullen > > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Monday, July 01, 2002 8:18 AM > To: '??' > Cc: manet@ietf.org > Subject: RE: [manet] RE: [manet] IP addresses in MANET > > > Some miscellaneous rambling: > > Decreasing power is useful to decrease the size of cells, to make more > efficient use of RF spectrum. In a system with base stations or access > points, the advantages seem obvious. The wired infrastructure will have to > be upgraded for a greater traffic load, but the individual wireless cells > will support the same number of hosts in a smaller area, resulting in > greater density of mobile hosts. > > In an ad-hoc network, the advantage doesn't seem so obvious (to me). Since > ad-hoc networks depend on mobile hosts for all their intra-MANET routing, > decreasing power means increasing the number of hops required, which means > that there will be more choke points in the network and more hosts involved > in the average data path. I suppose that if one introduces faster mobile > hosts while reducing the power, same as one had to upgrade the wired > infrastructure in the cell-based network with base stations, then maybe I > can understand how you'd expect better performance. > > Bert > > > -----Original Message----- > From: hai_wang@163.net [mailto:hai_wang@163.net] > Sent: Monday, July 01, 2002 3:52 AM > To: Scott.Lemon@HumanXtensions.com > Cc: manet@ietf.org; dyoung@ojctech.com > Subject: [manet] RE: [manet] IP addresses in MANET > > > Hello Scott: > As David Young says, Using power control to increase MANET performance is an > active research area in MANET. It sure will increase MANET?¡¥s throughput. > However, firstly, because of practical reason, transmitting power can not be > decreasing without limit; secondly, when the transmitting power is low > enough, it means that the talking area or clustering area is very small, In > such network, the mobility of nodes will become a big problem:) > Practically speaking, if MANET can serve more than 10000 nodes freely, I > think it is enough for real implementation. I see no case which needs more > nodes than that:) > > Hai Wang > > -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 15:33:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28431 for ; Mon, 1 Jul 2002 15:33:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05177 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 15:34:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01029; Mon, 1 Jul 2002 14:58:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00926 for ; Mon, 1 Jul 2002 14:58:40 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26136 for ; Mon, 1 Jul 2002 14:57:50 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Mon, 1 Jul 2002 12:58:36 -0600 Message-Id: <02Jul1.125836mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: dyoung@pobox.com, manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Mon, 1 Jul 2002 12:58:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi David, In general, as the distance is doubled, the received power is quartered, or received S/N drops about 6 dB. (This is actually overly optimistic in some frequency bands). One factor is how this 6 dB drop affects bandwidth. The Shannon limit would predict about a 50% decrease in available BW, but that may not be critical. Usually, BER and other errors do you in first. Also, absolute levels count. If the original S/N is 20 dBm, there is probably not a problem, but if it were 8 dBm, ... Another factor is processing time. If 80% of the time required to move a packet from one node to the next is taken up in coding, decoding, etc., then a two-hop path would be doubly slow (added processing time plus lower transmission rate). Of course, multiple transmissions tie up the channel longer than a single one, but a "shout" ties up the channel over a greater geographic area. The effect on battery life is probably worth considering, too. Interesting problem. John Mullen -----Original Message----- From: David Young [mailto:dyoung@ojctech.com] Sent: Monday, July 01, 2002 12:27 PM To: manet@ietf.org Subject: Re: [manet] tx power adjustment In some research, a host transmits a beacon at each TX power level and listens for beacon-replies to discover its neighbors. Then the host labels each neighbor's route with the least TX power level necessary to reach that neighbor. Packets destined for a neighbor are transmitted with the power level labeling the neighbor's route. If a host discovers neighbors with beacons independently of discovering routes with an ad hoc routing protocol, then sometimes a neighbor will have two routes, one discovered by the beacon and one discovered by the routing protocol. Then the host will have a choice between shouting at a far away neighbor, or whispering to a nearer neighbor who will whisper to the far away neighbor. A strategy for choosing between one "loud" hop and several quiet ones could be quite complex, it seems. Suppose you tried to estimate and minimize the product of a packet's on-air time and the area silenced by its (re)transmission? Dave On Mon, Jul 01, 2002 at 09:20:41AM -0600, Mullen, John P. (Contractor) wrote: > Hi Bert, > > It all turns on the density of your hosts and the patterns of > communications. If you have a very large number of hosts in a rather small > geographical area, you will have increased contention for the RF channel. > By reducing power, you reduce the potential for interference among hosts > attempting unrelated communications on the same channel, but in > significantly different geographical locations. If, on the other hand, > those conversations are of interest to all nodes, then reducing power will > increase the number of hops and channel utilization. > > For example, suppose your MANET consists of clusters of hosts that are about > 1 km apart. However, within a cluster, each node is within a few meters of > at least one other node. When communications is within a cluster, it would > be prudent, to limit transmit power to that level necessary to carry out > communications within that cluster, but not high enough to cause > interference between clusters. On the other hand, if you need to > communicate from one cluster to another, a higher power level would be > needed. > > Also, if we agree that the MANET hosts are likely to be portable > battery-powered units, then managing transmitter power is also important > from the perspective of conserving network resources. > > I would say that the ability to change transmitter power has potential for > more efficient MANET management, but its success will turn on the ability of > the protocol to detect situations in which the different power levels are > appropriate. > > John Mullen > > > -----Original Message----- > From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Sent: Monday, July 01, 2002 8:18 AM > To: '??' > Cc: manet@ietf.org > Subject: RE: [manet] RE: [manet] IP addresses in MANET > > > Some miscellaneous rambling: > > Decreasing power is useful to decrease the size of cells, to make more > efficient use of RF spectrum. In a system with base stations or access > points, the advantages seem obvious. The wired infrastructure will have to > be upgraded for a greater traffic load, but the individual wireless cells > will support the same number of hosts in a smaller area, resulting in > greater density of mobile hosts. > > In an ad-hoc network, the advantage doesn't seem so obvious (to me). Since > ad-hoc networks depend on mobile hosts for all their intra-MANET routing, > decreasing power means increasing the number of hops required, which means > that there will be more choke points in the network and more hosts involved > in the average data path. I suppose that if one introduces faster mobile > hosts while reducing the power, same as one had to upgrade the wired > infrastructure in the cell-based network with base stations, then maybe I > can understand how you'd expect better performance. > > Bert > > > -----Original Message----- > From: hai_wang@163.net [mailto:hai_wang@163.net] > Sent: Monday, July 01, 2002 3:52 AM > To: Scott.Lemon@HumanXtensions.com > Cc: manet@ietf.org; dyoung@ojctech.com > Subject: [manet] RE: [manet] IP addresses in MANET > > > Hello Scott: > As David Young says, Using power control to increase MANET performance is an > active research area in MANET. It sure will increase MANET?¡¥s throughput. > However, firstly, because of practical reason, transmitting power can not be > decreasing without limit; secondly, when the transmitting power is low > enough, it means that the talking area or clustering area is very small, In > such network, the mobility of nodes will become a big problem:) > Practically speaking, if MANET can serve more than 10000 nodes freely, I > think it is enough for real implementation. I see no case which needs more > nodes than that:) > > Hai Wang > > -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 15:41:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28821 for ; Mon, 1 Jul 2002 15:41:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03047; Mon, 1 Jul 2002 15:13:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03006 for ; Mon, 1 Jul 2002 15:13:53 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27242 for ; Mon, 1 Jul 2002 15:13:02 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Mon, 1 Jul 2002 13:13:44 -0600 Message-Id: <02Jul1.131344mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 13:13:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Well, my idea is similar to the newer elaboration of Mobile IP, except possibly that the information provided by the server is just a vector to one of the MANET's gateways, not the full address. In Mobile IP, as I understand it, the vector is to a fixed host that is in direct communications with the mobile host. However, in my idea, the vector is just to the MANET. All details of interconnection within the MANET are hidden from the Internet. This should decrease the volatility of the listing. Also, it could be possible to have the server operated as a stand-alone directory service, not affiliated with a particular MANET or type of host. Users wishing such connectivity could subscribe to the service, while others could forego the option, independently of which organization or MANETs they belong to. The one down side I see is that unless users insist on privacy from the beginning, there would be a new option open to telemarketers. :-/ John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Monday, July 01, 2002 12:45 PM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution John, How does what you describe differ from Mobile IP? In Mobile IP, the job of the home server is to keep track of where the mobile host pops up at any given time. In the basic version of Mobile IP, all packets to and from the mobile host are routed through the home server. In a newer elaboration, the actual current address of the mobile host is provided to the host wanting to communicate with the mobile host, so the home server can be bypassed. If I understand your proposal, doesn't this meet the same functionality? Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, July 01, 2002 2:34 PM > To: Manfredi, Albert E; 'Charlie Perkins' > Cc: manet@ietf.org > Subject: RE: [manet] Gateway address resolution > > > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone > system, in which > instead of a backbone of cellular antennas, routers, etc., > there is just a > few isolated antennas designed to act as gateways to the internet. > > Of course, the handsets would differ from the usual cellular > handset in that > it would be able to forward packets for other users and might also be > strictly digital, with limited digital voice, to compensate > for the limited > bandwidth. > > The question is, how will a user entering the region of a > local MANET be > properly identified and make its location known to other > hosts, including > those access through the Internet. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of > users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area > code gives us an > idea of what state the user is in. However, this is just to > simplify the > task of finding an entry and has nothing to do with the host's current > association or location. > > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the > Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the > gateway's own IP. > Then, any host accessing through the Internet, trying to find > the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. > > Technically, I realize, this is a form of centralized > information storage, > but it is for the purpose of locating a particular host that > may be on any > one of hundreds of MANETs, or on none. The storage is on the > Internet, not > on the MANET. Local MANET routing information would not be > forwarded, so > the directory entry would be valid (and useful) as long as > the host is in > that particular MANET, even if the route to it within the > MANET changes. > > John Mullen > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 15:41:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28828 for ; Mon, 1 Jul 2002 15:41:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05658 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 15:41:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03047; Mon, 1 Jul 2002 15:13:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03006 for ; Mon, 1 Jul 2002 15:13:53 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27242 for ; Mon, 1 Jul 2002 15:13:02 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Mon, 1 Jul 2002 13:13:44 -0600 Message-Id: <02Jul1.131344mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Mon, 1 Jul 2002 13:13:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Well, my idea is similar to the newer elaboration of Mobile IP, except possibly that the information provided by the server is just a vector to one of the MANET's gateways, not the full address. In Mobile IP, as I understand it, the vector is to a fixed host that is in direct communications with the mobile host. However, in my idea, the vector is just to the MANET. All details of interconnection within the MANET are hidden from the Internet. This should decrease the volatility of the listing. Also, it could be possible to have the server operated as a stand-alone directory service, not affiliated with a particular MANET or type of host. Users wishing such connectivity could subscribe to the service, while others could forego the option, independently of which organization or MANETs they belong to. The one down side I see is that unless users insist on privacy from the beginning, there would be a new option open to telemarketers. :-/ John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Monday, July 01, 2002 12:45 PM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution John, How does what you describe differ from Mobile IP? In Mobile IP, the job of the home server is to keep track of where the mobile host pops up at any given time. In the basic version of Mobile IP, all packets to and from the mobile host are routed through the home server. In a newer elaboration, the actual current address of the mobile host is provided to the host wanting to communicate with the mobile host, so the home server can be bypassed. If I understand your proposal, doesn't this meet the same functionality? Bert > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, July 01, 2002 2:34 PM > To: Manfredi, Albert E; 'Charlie Perkins' > Cc: manet@ietf.org > Subject: RE: [manet] Gateway address resolution > > > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone > system, in which > instead of a backbone of cellular antennas, routers, etc., > there is just a > few isolated antennas designed to act as gateways to the internet. > > Of course, the handsets would differ from the usual cellular > handset in that > it would be able to forward packets for other users and might also be > strictly digital, with limited digital voice, to compensate > for the limited > bandwidth. > > The question is, how will a user entering the region of a > local MANET be > properly identified and make its location known to other > hosts, including > those access through the Internet. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of > users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area > code gives us an > idea of what state the user is in. However, this is just to > simplify the > task of finding an entry and has nothing to do with the host's current > association or location. > > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the > Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the > gateway's own IP. > Then, any host accessing through the Internet, trying to find > the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. > > Technically, I realize, this is a form of centralized > information storage, > but it is for the purpose of locating a particular host that > may be on any > one of hundreds of MANETs, or on none. The storage is on the > Internet, not > on the MANET. Local MANET routing information would not be > forwarded, so > the directory entry would be valid (and useful) as long as > the host is in > that particular MANET, even if the route to it within the > MANET changes. > > John Mullen > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 16:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00528 for ; Mon, 1 Jul 2002 16:11:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05696; Mon, 1 Jul 2002 15:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05668 for ; Mon, 1 Jul 2002 15:41:55 -0400 (EDT) Received: from Eng.Auburn.EDU (dns.eng.auburn.edu [131.204.10.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28817 for ; Mon, 1 Jul 2002 15:41:03 -0400 (EDT) Received: from roadrunner.eng.auburn.edu (roadrunner.eng.auburn.edu [131.204.12.50]) by Eng.Auburn.EDU (8.11.6/8.11.6) with ESMTP id g61JfZ107275; Mon, 1 Jul 2002 14:41:35 -0500 (CDT) Received: from localhost (sbiaz@localhost) by roadrunner.eng.auburn.edu (8.9.3+Sun/8.6.4) with ESMTP id OAA12852; Mon, 1 Jul 2002 14:41:40 -0500 (CDT) X-Authentication-Warning: roadrunner.eng.auburn.edu: sbiaz owned process doing -bs Date: Mon, 1 Jul 2002 14:41:40 -0500 (CDT) From: Saad Biaz To: "Mullen, John P. (Contractor)" cc: dyoung@pobox.com, Subject: RE: [manet] tx power adjustment In-Reply-To: <02Jul1.125836mdt.117126@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 1 Jul 2002, Mullen, John P. (Contractor) wrote: > Hi David, > > In general, as the distance is doubled, the received power is quartered, or > received S/N drops about 6 dB. (This is actually overly optimistic in some > frequency bands). One factor is how this 6 dB drop affects bandwidth. The > Shannon limit would predict about a 50% decrease in available BW, but that > may not be critical. Usually, BER and other errors do you in first. Also, > absolute levels count. If the original S/N is 20 dBm, there is probably not > a problem, but if it were 8 dBm, ... > > Another factor is processing time. If 80% of the time required to move a > packet from one node to the next is taken up in coding, decoding, etc., then > a two-hop path would be doubly slow (added processing time plus lower > transmission rate). > > Of course, multiple transmissions tie up the channel longer than a single > one, but a "shout" ties up the channel over a greater geographic area. > > The effect on battery life is probably worth considering, too. > > > Interesting problem. > > John Mullen There has been some work on power-aware routing (PARO). J. Gomez, A.T. Campbell, M.Naghshineh, and C. Bisdikian, "Power-Aware Routing in Wireless Packet Networks". I believe they have a more recent version in ICPN 2001. ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 16:11:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00536 for ; Mon, 1 Jul 2002 16:11:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08237 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 16:11:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05696; Mon, 1 Jul 2002 15:41:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05668 for ; Mon, 1 Jul 2002 15:41:55 -0400 (EDT) Received: from Eng.Auburn.EDU (dns.eng.auburn.edu [131.204.10.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28817 for ; Mon, 1 Jul 2002 15:41:03 -0400 (EDT) Received: from roadrunner.eng.auburn.edu (roadrunner.eng.auburn.edu [131.204.12.50]) by Eng.Auburn.EDU (8.11.6/8.11.6) with ESMTP id g61JfZ107275; Mon, 1 Jul 2002 14:41:35 -0500 (CDT) Received: from localhost (sbiaz@localhost) by roadrunner.eng.auburn.edu (8.9.3+Sun/8.6.4) with ESMTP id OAA12852; Mon, 1 Jul 2002 14:41:40 -0500 (CDT) X-Authentication-Warning: roadrunner.eng.auburn.edu: sbiaz owned process doing -bs Date: Mon, 1 Jul 2002 14:41:40 -0500 (CDT) From: Saad Biaz To: "Mullen, John P. (Contractor)" cc: dyoung@pobox.com, Subject: RE: [manet] tx power adjustment In-Reply-To: <02Jul1.125836mdt.117126@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 1 Jul 2002, Mullen, John P. (Contractor) wrote: > Hi David, > > In general, as the distance is doubled, the received power is quartered, or > received S/N drops about 6 dB. (This is actually overly optimistic in some > frequency bands). One factor is how this 6 dB drop affects bandwidth. The > Shannon limit would predict about a 50% decrease in available BW, but that > may not be critical. Usually, BER and other errors do you in first. Also, > absolute levels count. If the original S/N is 20 dBm, there is probably not > a problem, but if it were 8 dBm, ... > > Another factor is processing time. If 80% of the time required to move a > packet from one node to the next is taken up in coding, decoding, etc., then > a two-hop path would be doubly slow (added processing time plus lower > transmission rate). > > Of course, multiple transmissions tie up the channel longer than a single > one, but a "shout" ties up the channel over a greater geographic area. > > The effect on battery life is probably worth considering, too. > > > Interesting problem. > > John Mullen There has been some work on power-aware routing (PARO). J. Gomez, A.T. Campbell, M.Naghshineh, and C. Bisdikian, "Power-Aware Routing in Wireless Packet Networks". I believe they have a more recent version in ICPN 2001. ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 18:47:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08245 for ; Mon, 1 Jul 2002 18:47:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15435; Mon, 1 Jul 2002 18:18:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15402 for ; Mon, 1 Jul 2002 18:18:12 -0400 (EDT) Received: from smtp2.yaonline.es ([62.151.11.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07039 for ; Mon, 1 Jul 2002 18:17:23 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp2.yaonline.es with esmtp id 17P9UB-000229-00; Tue, 02 Jul 2002 00:17:31 +0200 Message-ID: <3D20D5B7.5040301@ieee.org> Date: Tue, 02 Jul 2002 00:20:39 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dyoung@pobox.com CC: manet@ietf.org Subject: Re: [manet] tx power adjustment References: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil> <20020701132643.B22306@che.onthejob.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Dave, You wrote: >... a choice between shouting at a >far away neighbor, or whispering to a nearer neighbor who will whisper >to the far away neighbor. A strategy for choosing between one "loud" >hop and several quiet ones could be quite complex, it seems. Suppose >you tried to estimate and minimize the product of a packet's on-air time >and the area silenced by its (re)transmission? > >Dave > > As a rule of thumb if you look at the tx power only, it is more energy efficient to whisper the packet twice than to transmit it loud once (due to the power law on the atenuation). However if you take into account that receiving is not coming for free either, and if you assume that all neighbor nodes will receive a packet before they can check if it is addressed to them or not (and therefore they will draw reception energy) then whispering twice could be a worse choice than one loud transmission. Of course this analysis may be interesting when you are worried about network survivability (i.e. low power sensor networks). What it is more, the numbers of this observation will change a lot depending on the nodal density about these three involved nodes (i.e. sender, reciver and forwarder). I just wanted to add this thought to the discussion. Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 18:47:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08251 for ; Mon, 1 Jul 2002 18:47:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17697 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 18:47:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15435; Mon, 1 Jul 2002 18:18:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15402 for ; Mon, 1 Jul 2002 18:18:12 -0400 (EDT) Received: from smtp2.yaonline.es ([62.151.11.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07039 for ; Mon, 1 Jul 2002 18:17:23 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp2.yaonline.es with esmtp id 17P9UB-000229-00; Tue, 02 Jul 2002 00:17:31 +0200 Message-ID: <3D20D5B7.5040301@ieee.org> Date: Tue, 02 Jul 2002 00:20:39 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dyoung@pobox.com CC: manet@ietf.org Subject: Re: [manet] tx power adjustment References: <02Jul1.092049mdt.117126@gw.trac.wsmr.army.mil> <20020701132643.B22306@che.onthejob.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Dave, You wrote: >... a choice between shouting at a >far away neighbor, or whispering to a nearer neighbor who will whisper >to the far away neighbor. A strategy for choosing between one "loud" >hop and several quiet ones could be quite complex, it seems. Suppose >you tried to estimate and minimize the product of a packet's on-air time >and the area silenced by its (re)transmission? > >Dave > > As a rule of thumb if you look at the tx power only, it is more energy efficient to whisper the packet twice than to transmit it loud once (due to the power law on the atenuation). However if you take into account that receiving is not coming for free either, and if you assume that all neighbor nodes will receive a packet before they can check if it is addressed to them or not (and therefore they will draw reception energy) then whispering twice could be a worse choice than one loud transmission. Of course this analysis may be interesting when you are worried about network survivability (i.e. low power sensor networks). What it is more, the numbers of this observation will change a lot depending on the nodal density about these three involved nodes (i.e. sender, reciver and forwarder). I just wanted to add this thought to the discussion. Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 18:52:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08448 for ; Mon, 1 Jul 2002 18:52:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16244; Mon, 1 Jul 2002 18:25:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16181 for ; Mon, 1 Jul 2002 18:25:34 -0400 (EDT) Received: from smtp2.yaonline.es ([62.151.11.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07374 for ; Mon, 1 Jul 2002 18:24:45 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp2.yaonline.es with esmtp id 17P9bC-0002GC-00; Tue, 02 Jul 2002 00:24:47 +0200 Message-ID: <3D20D765.8040905@ieee.org> Date: Tue, 02 Jul 2002 00:27:49 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saad Biaz CC: "Mullen, John P. (Contractor)" , dyoung@pobox.com, manet@ietf.org Subject: Re: [manet] tx power adjustment References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Saad, COMPOW protocol is another TX power control protocol by P.R. Kumar et al from UIUC. Regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain Saad Biaz wrote: >On Mon, 1 Jul 2002, Mullen, John P. (Contractor) wrote: > > > >>Hi David, >> >>In general, as the distance is doubled, the received power is quartered, or >>received S/N drops about 6 dB. (This is actually overly optimistic in some >>frequency bands). One factor is how this 6 dB drop affects bandwidth. The >>Shannon limit would predict about a 50% decrease in available BW, but that >>may not be critical. Usually, BER and other errors do you in first. Also, >>absolute levels count. If the original S/N is 20 dBm, there is probably not >>a problem, but if it were 8 dBm, ... >> >>Another factor is processing time. If 80% of the time required to move a >>packet from one node to the next is taken up in coding, decoding, etc., then >>a two-hop path would be doubly slow (added processing time plus lower >>transmission rate). >> >>Of course, multiple transmissions tie up the channel longer than a single >>one, but a "shout" ties up the channel over a greater geographic area. >> >>The effect on battery life is probably worth considering, too. >> >> >>Interesting problem. >> >>John Mullen >> >> > > >There has been some work on power-aware routing (PARO). >J. Gomez, A.T. Campbell, M.Naghshineh, and C. Bisdikian, >"Power-Aware Routing in Wireless Packet Networks". > >I believe they have a more recent version in ICPN 2001. > > >---------------------------------------------------------------------- >Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 >114 Dunstan Hall Auburn University Fax : (334) 844 6329 >Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz >---------------------------------------------------------------------- > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 18:53:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08457 for ; Mon, 1 Jul 2002 18:53:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17866 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 18:53:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16244; Mon, 1 Jul 2002 18:25:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16181 for ; Mon, 1 Jul 2002 18:25:34 -0400 (EDT) Received: from smtp2.yaonline.es ([62.151.11.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07374 for ; Mon, 1 Jul 2002 18:24:45 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp2.yaonline.es with esmtp id 17P9bC-0002GC-00; Tue, 02 Jul 2002 00:24:47 +0200 Message-ID: <3D20D765.8040905@ieee.org> Date: Tue, 02 Jul 2002 00:27:49 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saad Biaz CC: "Mullen, John P. (Contractor)" , dyoung@pobox.com, manet@ietf.org Subject: Re: [manet] tx power adjustment References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Saad, COMPOW protocol is another TX power control protocol by P.R. Kumar et al from UIUC. Regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain Saad Biaz wrote: >On Mon, 1 Jul 2002, Mullen, John P. (Contractor) wrote: > > > >>Hi David, >> >>In general, as the distance is doubled, the received power is quartered, or >>received S/N drops about 6 dB. (This is actually overly optimistic in some >>frequency bands). One factor is how this 6 dB drop affects bandwidth. The >>Shannon limit would predict about a 50% decrease in available BW, but that >>may not be critical. Usually, BER and other errors do you in first. Also, >>absolute levels count. If the original S/N is 20 dBm, there is probably not >>a problem, but if it were 8 dBm, ... >> >>Another factor is processing time. If 80% of the time required to move a >>packet from one node to the next is taken up in coding, decoding, etc., then >>a two-hop path would be doubly slow (added processing time plus lower >>transmission rate). >> >>Of course, multiple transmissions tie up the channel longer than a single >>one, but a "shout" ties up the channel over a greater geographic area. >> >>The effect on battery life is probably worth considering, too. >> >> >>Interesting problem. >> >>John Mullen >> >> > > >There has been some work on power-aware routing (PARO). >J. Gomez, A.T. Campbell, M.Naghshineh, and C. Bisdikian, >"Power-Aware Routing in Wireless Packet Networks". > >I believe they have a more recent version in ICPN 2001. > > >---------------------------------------------------------------------- >Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 >114 Dunstan Hall Auburn University Fax : (334) 844 6329 >Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz >---------------------------------------------------------------------- > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 1 19:53:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10167 for ; Mon, 1 Jul 2002 19:53:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19378; Mon, 1 Jul 2002 19:27:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19351 for ; Mon, 1 Jul 2002 19:27:44 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09441 for ; Mon, 1 Jul 2002 19:26:54 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA29247; Mon, 1 Jul 2002 16:27:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61NRAp26268; Mon, 1 Jul 2002 16:27:10 -0700 X-mProtect: <200207012327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYcqrb3; Mon, 01 Jul 2002 16:27:08 PDT Message-ID: <3D20E6DF.4070309@iprg.nokia.com> Date: Mon, 01 Jul 2002 16:33:51 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DA@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Bert (and others), Several aspects of these discussions strike me as something of a rehash of some exchanges that took place in this mailing list in Mar-Apr 2001. Check the archives in that timeframe for topics entitled: "Challenges for the MANET addressing model" and "MANET and IP Layering". The draft Charlie Perkins referred to: draft-wakikawa-manet-globalv6-01.txt is for the most part consistent with the rough concensus that emerged from those earlier mailing list discussions, and takes advantage of the nice properties of IPv6 neighbor discovery and stateless address autoconfiguration for subnet convergence. I would find any solution that requires NAT at the MANET border gateways to be much less desireable. Regards, Fred Templin ftemplin@iprg.nokia.com Manfredi, Albert E wrote: > Charlie Perkins wrote: > > >>Finally, >>the node can use its pre-existing IP address (not topologically >>correct) for bidirectional Internet communications, but in >>that case it has to use Mobile IP. > > > Charlie, > > I think that even this limitation is not mandatory, as we discussed last week. In principle, if the Internet gateways to the MANET and the MANET hosts conduct ICMP Router Discovery (RFC 1256), and if the gateways maintain a complete list of all MANET hosts, as if the MANET host IP addresses were just arbitrary flat addresses, then MANET hosts should be able to conduct bidirectional Internet communications without going to Mobile IP. > > The gateways would sort of operate like NATs, except that the MANET side is a flat address space. That's why the gateways need the exhaustive list of all MANET hosts. > > Bert > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 1 19:53:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10177 for ; Mon, 1 Jul 2002 19:53:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA21073 for manet-archive@odin.ietf.org; Mon, 1 Jul 2002 19:54:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19378; Mon, 1 Jul 2002 19:27:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19351 for ; Mon, 1 Jul 2002 19:27:44 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09441 for ; Mon, 1 Jul 2002 19:26:54 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA29247; Mon, 1 Jul 2002 16:27:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g61NRAp26268; Mon, 1 Jul 2002 16:27:10 -0700 X-mProtect: <200207012327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYcqrb3; Mon, 01 Jul 2002 16:27:08 PDT Message-ID: <3D20E6DF.4070309@iprg.nokia.com> Date: Mon, 01 Jul 2002 16:33:51 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39DA@xch-ne-02.ne.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Bert (and others), Several aspects of these discussions strike me as something of a rehash of some exchanges that took place in this mailing list in Mar-Apr 2001. Check the archives in that timeframe for topics entitled: "Challenges for the MANET addressing model" and "MANET and IP Layering". The draft Charlie Perkins referred to: draft-wakikawa-manet-globalv6-01.txt is for the most part consistent with the rough concensus that emerged from those earlier mailing list discussions, and takes advantage of the nice properties of IPv6 neighbor discovery and stateless address autoconfiguration for subnet convergence. I would find any solution that requires NAT at the MANET border gateways to be much less desireable. Regards, Fred Templin ftemplin@iprg.nokia.com Manfredi, Albert E wrote: > Charlie Perkins wrote: > > >>Finally, >>the node can use its pre-existing IP address (not topologically >>correct) for bidirectional Internet communications, but in >>that case it has to use Mobile IP. > > > Charlie, > > I think that even this limitation is not mandatory, as we discussed last week. In principle, if the Internet gateways to the MANET and the MANET hosts conduct ICMP Router Discovery (RFC 1256), and if the gateways maintain a complete list of all MANET hosts, as if the MANET host IP addresses were just arbitrary flat addresses, then MANET hosts should be able to conduct bidirectional Internet communications without going to Mobile IP. > > The gateways would sort of operate like NATs, except that the MANET side is a flat address space. That's why the gateways need the exhaustive list of all MANET hosts. > > Bert > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 09:35:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08998 for ; Tue, 2 Jul 2002 09:35:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09778; Tue, 2 Jul 2002 09:10:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09750 for ; Tue, 2 Jul 2002 09:10:21 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07539 for ; Tue, 2 Jul 2002 09:09:30 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 2 Jul 2002 07:10:14 -0600 Message-Id: <02Jul2.071014mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Miguel Sanchez Cc: manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Tue, 2 Jul 2002 07:10:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Miguel, I follow your argument, but come to a different conclusion. If we assume that only nodes on the path from sender to receiver "whisper," then a repeated whisper will affect only nodes in the vicinity of the end-to-end path, whereas a loud shout will affect every node within the radius of the distance from the originator to the destination. For example, if the MANET consists of 100 nodes arranged in a 10 by 10 array with each at the limit of "whisper" range, a whisper path from the middle to the right edge will affect, maybe 10 or so nodes, but a shout from the center to one edge would involve about 80 nodes (pi r^2). Also, reception power, though significant, is usually a couple of orders of magnitude or more, less than transmission power and may actually be less than idle power. (A receiver searching for a signal may have its gain cranked much higher than one actually locked on a signal). I agree that circumstances could affect the analysis, which is why some sort of adaptive control will probably be the answer. John Mullen -----Original Message----- From: Miguel Sanchez [mailto:misan@ieee.org] Sent: Monday, July 01, 2002 4:21 PM To: dyoung@pobox.com Cc: manet@ietf.org Subject: Re: [manet] tx power adjustment Hi Dave, You wrote: >... a choice between shouting at a >far away neighbor, or whispering to a nearer neighbor who will whisper >to the far away neighbor. A strategy for choosing between one "loud" >hop and several quiet ones could be quite complex, it seems. Suppose >you tried to estimate and minimize the product of a packet's on-air time >and the area silenced by its (re)transmission? > >Dave > > As a rule of thumb if you look at the tx power only, it is more energy efficient to whisper the packet twice than to transmit it loud once (due to the power law on the atenuation). However if you take into account that receiving is not coming for free either, and if you assume that all neighbor nodes will receive a packet before they can check if it is addressed to them or not (and therefore they will draw reception energy) then whispering twice could be a worse choice than one loud transmission. Of course this analysis may be interesting when you are worried about network survivability (i.e. low power sensor networks). What it is more, the numbers of this observation will change a lot depending on the nodal density about these three involved nodes (i.e. sender, reciver and forwarder). I just wanted to add this thought to the discussion. Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 09:35:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09007 for ; Tue, 2 Jul 2002 09:35:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11731 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 09:36:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09778; Tue, 2 Jul 2002 09:10:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09750 for ; Tue, 2 Jul 2002 09:10:21 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07539 for ; Tue, 2 Jul 2002 09:09:30 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 2 Jul 2002 07:10:14 -0600 Message-Id: <02Jul2.071014mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Miguel Sanchez Cc: manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Tue, 2 Jul 2002 07:10:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Miguel, I follow your argument, but come to a different conclusion. If we assume that only nodes on the path from sender to receiver "whisper," then a repeated whisper will affect only nodes in the vicinity of the end-to-end path, whereas a loud shout will affect every node within the radius of the distance from the originator to the destination. For example, if the MANET consists of 100 nodes arranged in a 10 by 10 array with each at the limit of "whisper" range, a whisper path from the middle to the right edge will affect, maybe 10 or so nodes, but a shout from the center to one edge would involve about 80 nodes (pi r^2). Also, reception power, though significant, is usually a couple of orders of magnitude or more, less than transmission power and may actually be less than idle power. (A receiver searching for a signal may have its gain cranked much higher than one actually locked on a signal). I agree that circumstances could affect the analysis, which is why some sort of adaptive control will probably be the answer. John Mullen -----Original Message----- From: Miguel Sanchez [mailto:misan@ieee.org] Sent: Monday, July 01, 2002 4:21 PM To: dyoung@pobox.com Cc: manet@ietf.org Subject: Re: [manet] tx power adjustment Hi Dave, You wrote: >... a choice between shouting at a >far away neighbor, or whispering to a nearer neighbor who will whisper >to the far away neighbor. A strategy for choosing between one "loud" >hop and several quiet ones could be quite complex, it seems. Suppose >you tried to estimate and minimize the product of a packet's on-air time >and the area silenced by its (re)transmission? > >Dave > > As a rule of thumb if you look at the tx power only, it is more energy efficient to whisper the packet twice than to transmit it loud once (due to the power law on the atenuation). However if you take into account that receiving is not coming for free either, and if you assume that all neighbor nodes will receive a packet before they can check if it is addressed to them or not (and therefore they will draw reception energy) then whispering twice could be a worse choice than one loud transmission. Of course this analysis may be interesting when you are worried about network survivability (i.e. low power sensor networks). What it is more, the numbers of this observation will change a lot depending on the nodal density about these three involved nodes (i.e. sender, reciver and forwarder). I just wanted to add this thought to the discussion. Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 11:08:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17072 for ; Tue, 2 Jul 2002 11:08:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22515; Tue, 2 Jul 2002 10:16:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22479 for ; Tue, 2 Jul 2002 10:16:09 -0400 (EDT) Received: from smtp4.yaonline.es ([62.151.11.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10973 for ; Tue, 2 Jul 2002 10:15:22 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp4.yaonline.es with esmtp id 17POMp-0005gX-00; Tue, 02 Jul 2002 16:10:57 +0200 Message-ID: <3D21B640.6090204@ieee.org> Date: Tue, 02 Jul 2002 16:18:40 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mullen, John P. (Contractor)" CC: manet@ietf.org Subject: Re: [manet] tx power adjustment References: <02Jul2.071014mdt.117121@gw.trac.wsmr.army.mil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi John, See my comments below ... Mullen, John P. (Contractor) wrote: >Hi Miguel, > >I follow your argument, but come to a different conclusion. > That's the point of discussing things :-) >If we assume that only nodes on the path from sender to receiver "whisper," >then a repeated whisper will affect only nodes in the vicinity of the >end-to-end path, whereas a loud shout will affect every node within the >radius of the distance from the originator to the destination. > Hmm, I agree. But if you whisper twice some nodes will receive this packet twice too. Depending on where nodes are located this can be a large or small number of nodes ... >For example, if the MANET consists of 100 nodes arranged in a 10 by 10 array >with each at the limit of "whisper" range, a whisper path from the middle to >the right edge will affect, maybe 10 or so nodes, but a shout from the >center to one edge would involve about 80 nodes (pi r^2). > I agree. >Also, reception power, though significant, is usually a couple of orders of >magnitude or more, less than transmission power and may actually be less >than idle power. (A receiver searching for a signal may have its gain >cranked much higher than one actually locked on a signal). > As other folks on the list, my thinking is tightly coupled to 802.11 standards. Most of the available products require while receiving around 70% of the energy used when transmitting (so transmit and receive energy consumption is, for this particular technology now, withing the same magnitude order). Other technologies (or even the new generations of CMOS 802.11 chipsets could change this dramatically ...) >I agree that circumstances could affect the analysis, which is why some sort >of adaptive control will probably be the answer. > Several authors (and I think Broadcom too) have proposed different adaptive schemes to do so. Cell phones , although not an ad-hoc network, have been routinely using transmission power control to achieve higher cell usage and/or to improve link quality. Please note that I am not claiming that "whispering" twice is necessaryly better than one loud transmission, but I wanted to show that packet reception energy cost can be significant and can favor one or the other choice, again strongly tied to the network topology and traffic. Best regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 11:08:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17077 for ; Tue, 2 Jul 2002 11:08:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27965 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 11:09:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22515; Tue, 2 Jul 2002 10:16:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22479 for ; Tue, 2 Jul 2002 10:16:09 -0400 (EDT) Received: from smtp4.yaonline.es ([62.151.11.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10973 for ; Tue, 2 Jul 2002 10:15:22 -0400 (EDT) Received: from 217-125-50-240.uc.nombres.ttd.es ([217.125.50.240] helo=ieee.org) by smtp4.yaonline.es with esmtp id 17POMp-0005gX-00; Tue, 02 Jul 2002 16:10:57 +0200 Message-ID: <3D21B640.6090204@ieee.org> Date: Tue, 02 Jul 2002 16:18:40 +0200 From: Miguel Sanchez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mullen, John P. (Contractor)" CC: manet@ietf.org Subject: Re: [manet] tx power adjustment References: <02Jul2.071014mdt.117121@gw.trac.wsmr.army.mil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi John, See my comments below ... Mullen, John P. (Contractor) wrote: >Hi Miguel, > >I follow your argument, but come to a different conclusion. > That's the point of discussing things :-) >If we assume that only nodes on the path from sender to receiver "whisper," >then a repeated whisper will affect only nodes in the vicinity of the >end-to-end path, whereas a loud shout will affect every node within the >radius of the distance from the originator to the destination. > Hmm, I agree. But if you whisper twice some nodes will receive this packet twice too. Depending on where nodes are located this can be a large or small number of nodes ... >For example, if the MANET consists of 100 nodes arranged in a 10 by 10 array >with each at the limit of "whisper" range, a whisper path from the middle to >the right edge will affect, maybe 10 or so nodes, but a shout from the >center to one edge would involve about 80 nodes (pi r^2). > I agree. >Also, reception power, though significant, is usually a couple of orders of >magnitude or more, less than transmission power and may actually be less >than idle power. (A receiver searching for a signal may have its gain >cranked much higher than one actually locked on a signal). > As other folks on the list, my thinking is tightly coupled to 802.11 standards. Most of the available products require while receiving around 70% of the energy used when transmitting (so transmit and receive energy consumption is, for this particular technology now, withing the same magnitude order). Other technologies (or even the new generations of CMOS 802.11 chipsets could change this dramatically ...) >I agree that circumstances could affect the analysis, which is why some sort >of adaptive control will probably be the answer. > Several authors (and I think Broadcom too) have proposed different adaptive schemes to do so. Cell phones , although not an ad-hoc network, have been routinely using transmission power control to achieve higher cell usage and/or to improve link quality. Please note that I am not claiming that "whispering" twice is necessaryly better than one loud transmission, but I wanted to show that packet reception energy cost can be significant and can favor one or the other choice, again strongly tied to the network topology and traffic. Best regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 11:12:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17460 for ; Tue, 2 Jul 2002 11:12:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23445; Tue, 2 Jul 2002 10:25:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23418 for ; Tue, 2 Jul 2002 10:25:55 -0400 (EDT) Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11803 for ; Tue, 2 Jul 2002 10:25:08 -0400 (EDT) From: T.Clausen@computer.org Received: from localhost (voop@pico.cs.auc.dk [130.225.194.80]) by mailhost.cs.auc.dk (8.12.3/8.12.3) with ESMTP id g62EPsnT021553 for ; Tue, 2 Jul 2002 16:25:54 +0200 (MEST) Date: Tue, 2 Jul 2002 16:25:54 +0200 (CEST) X-Sender: voop@armada To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: 8BIT Subject: [manet] New OLSR draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8BIT Dear All, We've submitted the revised OLSR draft to the secretariat. However I am afraid that we missed the official deadline. Still, the revised draft is available from here: http://byzantium.inria.fr:8080/OLSR-draft/draft-ietf-manet-olsr-07.txt -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 11:16:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18305 for ; Tue, 2 Jul 2002 11:16:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25641; Tue, 2 Jul 2002 10:49:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25614 for ; Tue, 2 Jul 2002 10:49:44 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14521 for ; Tue, 2 Jul 2002 10:48:56 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 2 Jul 2002 08:49:34 -0600 Message-Id: <02Jul2.084934mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Miguel Sanchez Cc: manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Tue, 2 Jul 2002 08:49:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Miguel, 70% of transmit energy for receive!! Wow! I'm not sure if that means the equipment has terribly efficient transmitters or terribly inefficient receivers. :-) This boggles my mind. Assuming omnidirectional transmission (logical in a MANET), in a transmit operation, the receiver receives only a very small fraction of the transmitted power. Power is lost in the transmitter, the final output stage, in mismatches between the output stage and antenna, in the antenna, in all sorts of environmental nasties, and in the receive antenna. On top of this, you have the power law, which describes the effect of dispersion with distance and attenuation by the medium. Receivers employ energy in a more-or-less closed system that involves repeated amplification and transformation of the received signal. There is power lost between stages, but since the signal levels are so low, the amount of power involved is very low. Of course, there could be a considerable amount of processing involved with decoding and deciphering. Still .. You are implying a very advanced technology which sounds very interesting. I will sure check this out! In my example, I did take into account the twice-reception rule. Assuming a path of five, including end points, four of the nodes will receive the packet twice. This is not all a loss, since the receipt of a packet forwarded to the next node can function as an implicit ACK. Of course, if other nodes are in the vicinity, they too will get the double reception. The power consumed in the receiver would also be a function of how much processing is needed to determine what to do with the packet. I think we agree, however, that conditions can speak in favor of either a shout or whisper, so the protocol will have to be adaptive. John Mullen -----Original Message----- From: Miguel Sanchez [mailto:misan@ieee.org] Sent: Tuesday, July 02, 2002 8:19 AM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: Re: [manet] tx power adjustment Hi John, See my comments below ... Mullen, John P. (Contractor) wrote: >Hi Miguel, > >I follow your argument, but come to a different conclusion. > That's the point of discussing things :-) >If we assume that only nodes on the path from sender to receiver "whisper," >then a repeated whisper will affect only nodes in the vicinity of the >end-to-end path, whereas a loud shout will affect every node within the >radius of the distance from the originator to the destination. > Hmm, I agree. But if you whisper twice some nodes will receive this packet twice too. Depending on where nodes are located this can be a large or small number of nodes ... >For example, if the MANET consists of 100 nodes arranged in a 10 by 10 array >with each at the limit of "whisper" range, a whisper path from the middle to >the right edge will affect, maybe 10 or so nodes, but a shout from the >center to one edge would involve about 80 nodes (pi r^2). > I agree. >Also, reception power, though significant, is usually a couple of orders of >magnitude or more, less than transmission power and may actually be less >than idle power. (A receiver searching for a signal may have its gain >cranked much higher than one actually locked on a signal). > As other folks on the list, my thinking is tightly coupled to 802.11 standards. Most of the available products require while receiving around 70% of the energy used when transmitting (so transmit and receive energy consumption is, for this particular technology now, withing the same magnitude order). Other technologies (or even the new generations of CMOS 802.11 chipsets could change this dramatically ...) >I agree that circumstances could affect the analysis, which is why some sort >of adaptive control will probably be the answer. > Several authors (and I think Broadcom too) have proposed different adaptive schemes to do so. Cell phones , although not an ad-hoc network, have been routinely using transmission power control to achieve higher cell usage and/or to improve link quality. Please note that I am not claiming that "whispering" twice is necessaryly better than one loud transmission, but I wanted to show that packet reception energy cost can be significant and can favor one or the other choice, again strongly tied to the network topology and traffic. Best regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 11:16:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18314 for ; Tue, 2 Jul 2002 11:16:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28585 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 11:17:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25641; Tue, 2 Jul 2002 10:49:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25614 for ; Tue, 2 Jul 2002 10:49:44 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14521 for ; Tue, 2 Jul 2002 10:48:56 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 2 Jul 2002 08:49:34 -0600 Message-Id: <02Jul2.084934mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Miguel Sanchez Cc: manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Tue, 2 Jul 2002 08:49:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Miguel, 70% of transmit energy for receive!! Wow! I'm not sure if that means the equipment has terribly efficient transmitters or terribly inefficient receivers. :-) This boggles my mind. Assuming omnidirectional transmission (logical in a MANET), in a transmit operation, the receiver receives only a very small fraction of the transmitted power. Power is lost in the transmitter, the final output stage, in mismatches between the output stage and antenna, in the antenna, in all sorts of environmental nasties, and in the receive antenna. On top of this, you have the power law, which describes the effect of dispersion with distance and attenuation by the medium. Receivers employ energy in a more-or-less closed system that involves repeated amplification and transformation of the received signal. There is power lost between stages, but since the signal levels are so low, the amount of power involved is very low. Of course, there could be a considerable amount of processing involved with decoding and deciphering. Still .. You are implying a very advanced technology which sounds very interesting. I will sure check this out! In my example, I did take into account the twice-reception rule. Assuming a path of five, including end points, four of the nodes will receive the packet twice. This is not all a loss, since the receipt of a packet forwarded to the next node can function as an implicit ACK. Of course, if other nodes are in the vicinity, they too will get the double reception. The power consumed in the receiver would also be a function of how much processing is needed to determine what to do with the packet. I think we agree, however, that conditions can speak in favor of either a shout or whisper, so the protocol will have to be adaptive. John Mullen -----Original Message----- From: Miguel Sanchez [mailto:misan@ieee.org] Sent: Tuesday, July 02, 2002 8:19 AM To: Mullen, John P. (Contractor) Cc: manet@ietf.org Subject: Re: [manet] tx power adjustment Hi John, See my comments below ... Mullen, John P. (Contractor) wrote: >Hi Miguel, > >I follow your argument, but come to a different conclusion. > That's the point of discussing things :-) >If we assume that only nodes on the path from sender to receiver "whisper," >then a repeated whisper will affect only nodes in the vicinity of the >end-to-end path, whereas a loud shout will affect every node within the >radius of the distance from the originator to the destination. > Hmm, I agree. But if you whisper twice some nodes will receive this packet twice too. Depending on where nodes are located this can be a large or small number of nodes ... >For example, if the MANET consists of 100 nodes arranged in a 10 by 10 array >with each at the limit of "whisper" range, a whisper path from the middle to >the right edge will affect, maybe 10 or so nodes, but a shout from the >center to one edge would involve about 80 nodes (pi r^2). > I agree. >Also, reception power, though significant, is usually a couple of orders of >magnitude or more, less than transmission power and may actually be less >than idle power. (A receiver searching for a signal may have its gain >cranked much higher than one actually locked on a signal). > As other folks on the list, my thinking is tightly coupled to 802.11 standards. Most of the available products require while receiving around 70% of the energy used when transmitting (so transmit and receive energy consumption is, for this particular technology now, withing the same magnitude order). Other technologies (or even the new generations of CMOS 802.11 chipsets could change this dramatically ...) >I agree that circumstances could affect the analysis, which is why some sort >of adaptive control will probably be the answer. > Several authors (and I think Broadcom too) have proposed different adaptive schemes to do so. Cell phones , although not an ad-hoc network, have been routinely using transmission power control to achieve higher cell usage and/or to improve link quality. Please note that I am not claiming that "whispering" twice is necessaryly better than one loud transmission, but I wanted to show that packet reception energy cost can be significant and can favor one or the other choice, again strongly tied to the network topology and traffic. Best regards, Miguel Sanchez Universidad Politecnica de Valencia, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 12:01:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24679 for ; Tue, 2 Jul 2002 12:01:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29303; Tue, 2 Jul 2002 11:25:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29276 for ; Tue, 2 Jul 2002 11:25:43 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21919 for ; Tue, 2 Jul 2002 11:24:55 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Tue, 2 Jul 2002 09:25:36 -0600 Message-Id: <02Jul2.092536mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: =?iso-8859-1?Q?Miguel_S=E1nchez?= Cc: manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Tue, 2 Jul 2002 09:25:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA29277 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Miguel, You probably hit the key to the receiver power need when you mentioned speed. Decoding involves Fast Fourier Transforms, etc. If the clock speed is very high, so will be power consumption. This RTS/CTS idea is intriguing. Nodes outside the transmission range of the originator will not know that some of the nodes are shut down, but even so, if a distant node tried to transmit to one of the nodes that would be shut down, there would be a data collision, anyhow. Either way, the end result is the same. That could work. Another idea might be a two part packet. The first part is the packet's ID, source, etc. and the second is the data. They are sent as a single physical packet, but encoded in a way that the first part can be decoded prior to decoding the second. A receiver, upon decoding the first part would realize that the packet is not directed at it or a duplicate of a packet already received and simply discard the rest of the packet without decoding it. That could save on receiver power, too. John Mullen -----Original Message----- From: Miguel Sánchez [mailto:misan@ieee.org] Sent: Tuesday, July 02, 2002 9:01 AM To: Mullen, John P. (Contractor) Subject: Re: [manet] tx power adjustment Hi John, I think that most of the energy budget of an spread-spectrum radio has to do with the control logic. RF wideband amplfier will acount (I guess) a negligible amount of power, but correlator and decoding section (logic working at very high speeds) needs a considerable amount of enery. However, if you are using an RTS/CTS control dialog between sender/receiver then an easy optimization can shutdown any neighboring node while the transmission is taking place (signaled by the RTS/CTS exchange), thus zeroing the unneeded receptions on neighbor nodes that are not the intended receiver (sorry I have no info about what manufacturers are actually doing this thing). Best regards, Miguel Sanchez Mullen, John P. (Contractor) wrote: >Hi Miguel, > >70% of transmit energy for receive!! Wow! I'm not sure if that means the >equipment has terribly efficient transmitters or terribly inefficient >receivers. > >:-) > >This boggles my mind. Assuming omnidirectional transmission (logical in a >MANET), in a transmit operation, the receiver receives only a very small >fraction of the transmitted power. Power is lost in the transmitter, the >final output stage, in mismatches between the output stage and antenna, in >the antenna, in all sorts of environmental nasties, and in the receive >antenna. On top of this, you have the power law, which describes the effect >of dispersion with distance and attenuation by the medium. > >Receivers employ energy in a more-or-less closed system that involves >repeated amplification and transformation of the received signal. There is >power lost between stages, but since the signal levels are so low, the >amount of power involved is very low. Of course, there could be a >considerable amount of processing involved with decoding and deciphering. >Still .. > >You are implying a very advanced technology which sounds very interesting. >I will sure check this out! > >In my example, I did take into account the twice-reception rule. Assuming a >path of five, including end points, four of the nodes will receive the >packet twice. This is not all a loss, since the receipt of a packet >forwarded to the next node can function as an implicit ACK. Of course, if >other nodes are in the vicinity, they too will get the double reception. >The power consumed in the receiver would also be a function of how much >processing is needed to determine what to do with the packet. > >I think we agree, however, that conditions can speak in favor of either a >shout or whisper, so the protocol will have to be adaptive. > >John Mullen > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 12:01:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24688 for ; Tue, 2 Jul 2002 12:01:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05212 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 12:02:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29303; Tue, 2 Jul 2002 11:25:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29276 for ; Tue, 2 Jul 2002 11:25:43 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21919 for ; Tue, 2 Jul 2002 11:24:55 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117125>; Tue, 2 Jul 2002 09:25:36 -0600 Message-Id: <02Jul2.092536mdt.117125@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: =?iso-8859-1?Q?Miguel_S=E1nchez?= Cc: manet@ietf.org Subject: RE: [manet] tx power adjustment Date: Tue, 2 Jul 2002 09:25:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA29277 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Miguel, You probably hit the key to the receiver power need when you mentioned speed. Decoding involves Fast Fourier Transforms, etc. If the clock speed is very high, so will be power consumption. This RTS/CTS idea is intriguing. Nodes outside the transmission range of the originator will not know that some of the nodes are shut down, but even so, if a distant node tried to transmit to one of the nodes that would be shut down, there would be a data collision, anyhow. Either way, the end result is the same. That could work. Another idea might be a two part packet. The first part is the packet's ID, source, etc. and the second is the data. They are sent as a single physical packet, but encoded in a way that the first part can be decoded prior to decoding the second. A receiver, upon decoding the first part would realize that the packet is not directed at it or a duplicate of a packet already received and simply discard the rest of the packet without decoding it. That could save on receiver power, too. John Mullen -----Original Message----- From: Miguel Sánchez [mailto:misan@ieee.org] Sent: Tuesday, July 02, 2002 9:01 AM To: Mullen, John P. (Contractor) Subject: Re: [manet] tx power adjustment Hi John, I think that most of the energy budget of an spread-spectrum radio has to do with the control logic. RF wideband amplfier will acount (I guess) a negligible amount of power, but correlator and decoding section (logic working at very high speeds) needs a considerable amount of enery. However, if you are using an RTS/CTS control dialog between sender/receiver then an easy optimization can shutdown any neighboring node while the transmission is taking place (signaled by the RTS/CTS exchange), thus zeroing the unneeded receptions on neighbor nodes that are not the intended receiver (sorry I have no info about what manufacturers are actually doing this thing). Best regards, Miguel Sanchez Mullen, John P. (Contractor) wrote: >Hi Miguel, > >70% of transmit energy for receive!! Wow! I'm not sure if that means the >equipment has terribly efficient transmitters or terribly inefficient >receivers. > >:-) > >This boggles my mind. Assuming omnidirectional transmission (logical in a >MANET), in a transmit operation, the receiver receives only a very small >fraction of the transmitted power. Power is lost in the transmitter, the >final output stage, in mismatches between the output stage and antenna, in >the antenna, in all sorts of environmental nasties, and in the receive >antenna. On top of this, you have the power law, which describes the effect >of dispersion with distance and attenuation by the medium. > >Receivers employ energy in a more-or-less closed system that involves >repeated amplification and transformation of the received signal. There is >power lost between stages, but since the signal levels are so low, the >amount of power involved is very low. Of course, there could be a >considerable amount of processing involved with decoding and deciphering. >Still .. > >You are implying a very advanced technology which sounds very interesting. >I will sure check this out! > >In my example, I did take into account the twice-reception rule. Assuming a >path of five, including end points, four of the nodes will receive the >packet twice. This is not all a loss, since the receipt of a packet >forwarded to the next node can function as an implicit ACK. Of course, if >other nodes are in the vicinity, they too will get the double reception. >The power consumed in the receiver would also be a function of how much >processing is needed to determine what to do with the packet. > >I think we agree, however, that conditions can speak in favor of either a >shout or whisper, so the protocol will have to be adaptive. > >John Mullen > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 12:01:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24737 for ; Tue, 2 Jul 2002 12:01:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00729; Tue, 2 Jul 2002 11:34:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00697 for ; Tue, 2 Jul 2002 11:34:56 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22739 for ; Tue, 2 Jul 2002 11:34:07 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id QAA12265; Tue, 2 Jul 2002 16:29:50 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62FTpE01437; Tue, 2 Jul 2002 16:29:51 +0100 Date: Tue, 2 Jul 2002 16:29:51 +0100 From: John Peter Tapsell Message-Id: <200207021529.g62FTpE01437@eng003.cs.man.ac.uk> To: misan@ieee.org, mullenjp.contractor@trac.wsmr.army.mil Subject: RE: [manet] tx power adjustment Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 12:01:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24751 for ; Tue, 2 Jul 2002 12:01:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05379 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 12:02:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00729; Tue, 2 Jul 2002 11:34:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00697 for ; Tue, 2 Jul 2002 11:34:56 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22739 for ; Tue, 2 Jul 2002 11:34:07 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id QAA12265; Tue, 2 Jul 2002 16:29:50 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62FTpE01437; Tue, 2 Jul 2002 16:29:51 +0100 Date: Tue, 2 Jul 2002 16:29:51 +0100 From: John Peter Tapsell Message-Id: <200207021529.g62FTpE01437@eng003.cs.man.ac.uk> To: misan@ieee.org, mullenjp.contractor@trac.wsmr.army.mil Subject: RE: [manet] tx power adjustment Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 12:09:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17464 for ; Tue, 2 Jul 2002 11:12:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28382 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 11:13:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23445; Tue, 2 Jul 2002 10:25:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23418 for ; Tue, 2 Jul 2002 10:25:55 -0400 (EDT) Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11803 for ; Tue, 2 Jul 2002 10:25:08 -0400 (EDT) From: T.Clausen@computer.org Received: from localhost (voop@pico.cs.auc.dk [130.225.194.80]) by mailhost.cs.auc.dk (8.12.3/8.12.3) with ESMTP id g62EPsnT021553 for ; Tue, 2 Jul 2002 16:25:54 +0200 (MEST) Date: Tue, 2 Jul 2002 16:25:54 +0200 (CEST) X-Sender: voop@armada To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: 8BIT Subject: [manet] New OLSR draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8BIT Dear All, We've submitted the revised OLSR draft to the secretariat. However I am afraid that we missed the official deadline. Still, the revised draft is available from here: http://byzantium.inria.fr:8080/OLSR-draft/draft-ietf-manet-olsr-07.txt -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 12:09:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27903 for ; Tue, 2 Jul 2002 12:09:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00503; Tue, 2 Jul 2002 11:32:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00459 for ; Tue, 2 Jul 2002 11:32:53 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22594 for ; Tue, 2 Jul 2002 11:32:05 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id QAA12375; Tue, 2 Jul 2002 16:32:38 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62FWf801443; Tue, 2 Jul 2002 16:32:41 +0100 Date: Tue, 2 Jul 2002 16:32:41 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] tx power adjustment Message-ID: <18137_1441_1025623960_1@eng003> Content-ID: <18137_1441_1025623960_2@eng003> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable 70% boggles my mind too :) Just to double check, this is per node? So if you had 1 node transmitting, and 10 listening, the listening would far outweigh the transmitting by an order of magnitude.. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 12:12:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28347 for ; Tue, 2 Jul 2002 12:12:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01967; Tue, 2 Jul 2002 11:44:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01866 for ; Tue, 2 Jul 2002 11:44:39 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23465 for ; Tue, 2 Jul 2002 11:43:50 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id QAA12977; Tue, 2 Jul 2002 16:44:36 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62FidB01456; Tue, 2 Jul 2002 16:44:39 +0100 Date: Tue, 2 Jul 2002 16:44:39 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_1454_1025624679_1@eng003> Content-ID: <18137_1454_1025624679_2@eng003> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] The Illusion of Spectrum Scarcity Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable I suspect this is old news to everyone, but just incase... http://slashdot.org/article.pl?sid=3D02/06/02/1251233&mode=3Dnested&tid=3D= 95 Comments! JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 12:12:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28357 for ; Tue, 2 Jul 2002 12:12:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06453 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 12:13:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01967; Tue, 2 Jul 2002 11:44:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01866 for ; Tue, 2 Jul 2002 11:44:39 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23465 for ; Tue, 2 Jul 2002 11:43:50 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id QAA12977; Tue, 2 Jul 2002 16:44:36 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62FidB01456; Tue, 2 Jul 2002 16:44:39 +0100 Date: Tue, 2 Jul 2002 16:44:39 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_1454_1025624679_1@eng003> Content-ID: <18137_1454_1025624679_2@eng003> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] The Illusion of Spectrum Scarcity Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable I suspect this is old news to everyone, but just incase... http://slashdot.org/article.pl?sid=3D02/06/02/1251233&mode=3Dnested&tid=3D= 95 Comments! JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 13:09:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27910 for ; Tue, 2 Jul 2002 12:09:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06208 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 12:10:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00503; Tue, 2 Jul 2002 11:32:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00459 for ; Tue, 2 Jul 2002 11:32:53 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22594 for ; Tue, 2 Jul 2002 11:32:05 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id QAA12375; Tue, 2 Jul 2002 16:32:38 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62FWf801443; Tue, 2 Jul 2002 16:32:41 +0100 Date: Tue, 2 Jul 2002 16:32:41 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] tx power adjustment Message-ID: <18137_1441_1025623960_1@eng003> Content-ID: <18137_1441_1025623960_2@eng003> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable 70% boggles my mind too :) Just to double check, this is per node? So if you had 1 node transmitting, and 10 listening, the listening would far outweigh the transmitting by an order of magnitude.. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 13:44:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03657 for ; Tue, 2 Jul 2002 13:44:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09380; Tue, 2 Jul 2002 13:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09333 for ; Tue, 2 Jul 2002 13:02:39 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00951 for ; Tue, 2 Jul 2002 13:01:49 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 2 Jul 2002 11:02:28 -0600 Message-Id: <02Jul2.110228mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: John Peter Tapsell Cc: manet@ietf.org Subject: RE: [manet] The Illusion of Spectrum Scarcity Date: Tue, 2 Jul 2002 11:02:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi John, Interesting, but a rather low S/N?? :-) For the record, my call letters are KH6DG. I became involved with the question of who own spectrum during a Digital Council Fires convention a few years ago. From a Native American perspective, it doesn't make sense for the FCC to sell spectrum rights on the reservation to a third party who then includes that cost in the price for providing spectrum access to the very same reservation community. There is feeling that the FCC should enforce the rules, but the spectrum belongs to the community. That way, the NA community can control who is using their spectrum and avoid paying for something they feel they already own. Much like police enforce laws against the theft of private property. That argument didn't go far with the Clinton administration and I'm not sure what is happening at this time. However, I'm not sure how this issue impacts the problem of designing MANET protocols. I suspect that at some level, it will impact performance, but not sure how. The greatest problem I see with the potential for new ideas and ventures is that of constructing a business model that investors can have confidence in. (Given the recent events in the US, that could be a very big problem). That could cause difficulties in implementing MANETs, but the nice thing about MANETs is that you can start small. At any rate, any tools that could be developed which would demonstrate to potential users the impact of MANET technology would probably help a lot. As for the technical details, I hold to the time honored Engineering two-and-one-half rule. That is, things tend to cost twice as much as expected and work half as well. (If what you are hearing is from a vendor, add an order of magnitude to both ends of the rule). I'm still not convinced on the "multipath improves reception" argument. :-) John Mullen -----Original Message----- From: John Peter Tapsell [mailto:tapselj0@cs.man.ac.uk] Sent: Tuesday, July 02, 2002 9:45 AM To: manet@ietf.org Subject: [manet] The Illusion of Spectrum Scarcity I suspect this is old news to everyone, but just incase... http://slashdot.org/article.pl?sid=02/06/02/1251233&mode=nested&tid=95 Comments! JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 13:44:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03666 for ; Tue, 2 Jul 2002 13:44:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12130 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 13:45:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09380; Tue, 2 Jul 2002 13:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09333 for ; Tue, 2 Jul 2002 13:02:39 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00951 for ; Tue, 2 Jul 2002 13:01:49 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117121>; Tue, 2 Jul 2002 11:02:28 -0600 Message-Id: <02Jul2.110228mdt.117121@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: John Peter Tapsell Cc: manet@ietf.org Subject: RE: [manet] The Illusion of Spectrum Scarcity Date: Tue, 2 Jul 2002 11:02:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi John, Interesting, but a rather low S/N?? :-) For the record, my call letters are KH6DG. I became involved with the question of who own spectrum during a Digital Council Fires convention a few years ago. From a Native American perspective, it doesn't make sense for the FCC to sell spectrum rights on the reservation to a third party who then includes that cost in the price for providing spectrum access to the very same reservation community. There is feeling that the FCC should enforce the rules, but the spectrum belongs to the community. That way, the NA community can control who is using their spectrum and avoid paying for something they feel they already own. Much like police enforce laws against the theft of private property. That argument didn't go far with the Clinton administration and I'm not sure what is happening at this time. However, I'm not sure how this issue impacts the problem of designing MANET protocols. I suspect that at some level, it will impact performance, but not sure how. The greatest problem I see with the potential for new ideas and ventures is that of constructing a business model that investors can have confidence in. (Given the recent events in the US, that could be a very big problem). That could cause difficulties in implementing MANETs, but the nice thing about MANETs is that you can start small. At any rate, any tools that could be developed which would demonstrate to potential users the impact of MANET technology would probably help a lot. As for the technical details, I hold to the time honored Engineering two-and-one-half rule. That is, things tend to cost twice as much as expected and work half as well. (If what you are hearing is from a vendor, add an order of magnitude to both ends of the rule). I'm still not convinced on the "multipath improves reception" argument. :-) John Mullen -----Original Message----- From: John Peter Tapsell [mailto:tapselj0@cs.man.ac.uk] Sent: Tuesday, July 02, 2002 9:45 AM To: manet@ietf.org Subject: [manet] The Illusion of Spectrum Scarcity I suspect this is old news to everyone, but just incase... http://slashdot.org/article.pl?sid=02/06/02/1251233&mode=nested&tid=95 Comments! JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 13:48:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03975 for ; Tue, 2 Jul 2002 13:48:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10071; Tue, 2 Jul 2002 13:15:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10042 for ; Tue, 2 Jul 2002 13:15:24 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01998 for ; Tue, 2 Jul 2002 13:14:35 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id SAA15272; Tue, 2 Jul 2002 18:15:18 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62HF1E01604; Tue, 2 Jul 2002 18:15:01 +0100 Date: Tue, 2 Jul 2002 18:15:01 +0100 From: John Peter Tapsell Message-Id: <200207021715.g62HF1E01604@eng003.cs.man.ac.uk> To: mullenjp.contractor@trac.wsmr.army.mil, tapselj0@cs.man.ac.uk Subject: RE: [manet] The Illusion of Spectrum Scarcity Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I can see how multipath could improve reception as long as the traffic was low.. Hmm, random thought, you could have everyone be an http proxy (ignoring security issues) hmm I used to be call sign MFL62 - I have no idea how to get back into HAM - hmm, I might just have to try again :) JohnFlux (Btw, I'm in the UK - are call signs globably unique?) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 14:39:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03983 for ; Tue, 2 Jul 2002 13:48:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12302 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 13:49:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10071; Tue, 2 Jul 2002 13:15:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10042 for ; Tue, 2 Jul 2002 13:15:24 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01998 for ; Tue, 2 Jul 2002 13:14:35 -0400 (EDT) Received: from eng003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id SAA15272; Tue, 2 Jul 2002 18:15:18 +0100 (BST) Received: (from tapselj0@localhost) by eng003.cs.man.ac.uk (8.11.6/8.9.3) id g62HF1E01604; Tue, 2 Jul 2002 18:15:01 +0100 Date: Tue, 2 Jul 2002 18:15:01 +0100 From: John Peter Tapsell Message-Id: <200207021715.g62HF1E01604@eng003.cs.man.ac.uk> To: mullenjp.contractor@trac.wsmr.army.mil, tapselj0@cs.man.ac.uk Subject: RE: [manet] The Illusion of Spectrum Scarcity Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I can see how multipath could improve reception as long as the traffic was low.. Hmm, random thought, you could have everyone be an http proxy (ignoring security issues) hmm I used to be call sign MFL62 - I have no idea how to get back into HAM - hmm, I might just have to try again :) JohnFlux (Btw, I'm in the UK - are call signs globably unique?) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 16:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12470 for ; Tue, 2 Jul 2002 16:01:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18784; Tue, 2 Jul 2002 15:28:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18753 for ; Tue, 2 Jul 2002 15:28:25 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10384 for ; Tue, 2 Jul 2002 15:27:34 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Tue, 2 Jul 2002 13:28:09 -0600 Message-Id: <02Jul2.132809mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Eric Brunner-Williams in Portland Maine Cc: manet@ietf.org Subject: RE: [manet] The Illusion of Spectrum Scarcity Date: Tue, 2 Jul 2002 13:28:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Eric, Small world, eh! I was on the team from NMSU that conducted a survey of infrastructure needs in Native American communities. Dr Riley gave the talk, but I participated in the Q&A. Believe it or not, the USG still has the report on the web. http://www.osec.doc.gov/eda/pdf/ATINC.pdf You know, I remember that dns talk. That was really good! Up till then, I really hadn't thought about it that much. Your talk made it really jell for me. So, what do you think about the use of MANETs on the rez? I don't think it will work in the Dineh Nation. Too much empty space between population centers, but other communities are not so spread out and their mileage may vary. Also, what is the legal situation? I know in Alaska, a local telephone company was able to block the implementation of a wireless (cellular) telephone system in an area they were not serving. Can MANETS get around the franchise problem? (anyone can jump in here). John Mullen -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Tuesday, July 02, 2002 1:00 PM To: Mullen, John P. (Contractor) Cc: John Peter Tapsell; manet@ietf.org Subject: Re: [manet] The Illusion of Spectrum Scarcity > I became involved with the question of who own spectrum during a Digital > Council Fires convention a few years ago. I'll be damned! Howdy John! Which talk did you give? I gave the one on the dns. Eric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 16:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12478 for ; Tue, 2 Jul 2002 16:01:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21406 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 16:02:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18784; Tue, 2 Jul 2002 15:28:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18753 for ; Tue, 2 Jul 2002 15:28:25 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10384 for ; Tue, 2 Jul 2002 15:27:34 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117126>; Tue, 2 Jul 2002 13:28:09 -0600 Message-Id: <02Jul2.132809mdt.117126@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Eric Brunner-Williams in Portland Maine Cc: manet@ietf.org Subject: RE: [manet] The Illusion of Spectrum Scarcity Date: Tue, 2 Jul 2002 13:28:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Eric, Small world, eh! I was on the team from NMSU that conducted a survey of infrastructure needs in Native American communities. Dr Riley gave the talk, but I participated in the Q&A. Believe it or not, the USG still has the report on the web. http://www.osec.doc.gov/eda/pdf/ATINC.pdf You know, I remember that dns talk. That was really good! Up till then, I really hadn't thought about it that much. Your talk made it really jell for me. So, what do you think about the use of MANETs on the rez? I don't think it will work in the Dineh Nation. Too much empty space between population centers, but other communities are not so spread out and their mileage may vary. Also, what is the legal situation? I know in Alaska, a local telephone company was able to block the implementation of a wireless (cellular) telephone system in an area they were not serving. Can MANETS get around the franchise problem? (anyone can jump in here). John Mullen -----Original Message----- From: Eric Brunner-Williams in Portland Maine [mailto:brunner@nic-naa.net] Sent: Tuesday, July 02, 2002 1:00 PM To: Mullen, John P. (Contractor) Cc: John Peter Tapsell; manet@ietf.org Subject: Re: [manet] The Illusion of Spectrum Scarcity > I became involved with the question of who own spectrum during a Digital > Council Fires convention a few years ago. I'll be damned! Howdy John! Which talk did you give? I gave the one on the dns. Eric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 20:19:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24358 for ; Tue, 2 Jul 2002 20:19:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02438; Tue, 2 Jul 2002 19:54:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02413 for ; Tue, 2 Jul 2002 19:54:15 -0400 (EDT) Received: from villinski.com ([63.226.81.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23384 for ; Tue, 2 Jul 2002 19:53:26 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Tue, 02 Jul 2002 17:54:13 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 2 Jul 02 17:54:13 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 2 Jul 02 17:53:45 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 2 Jul 02 17:53:38 -0700 Message-ID: <013901c22223$f41a76d0$390a640a@Transient> From: "Scott C. Lemon" To: Date: Tue, 2 Jul 2002 17:55:31 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01C221F1.A8949560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: [manet] Do MANET radios require collision detection? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0136_01C221F1.A8949560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello again, I appreciate all of the responses to my other questions/comments ... I'm = still digesting and reading and appreciate all of the expertise being = shared on this list. I'm sure that as I follow this conversation more, = I'll become more aware of the various topics and issues ... One area that I wanted to ask a question or two is related to current = commercial radios. It appears that most people are using 802.11b (or = maybe even "a") for their MANET work. I too use 802.11b, however the = distance is very limiting. I have recently been working with a company to develop an alternative = radio for my purposes, and am now interested in the radio requirements = to work with the software that is currently being used with the 802.11b = cards. My specific question is if most of these MANET protocols and software = require collision detection in the radio on transmission? We almost = have completed a prototype of a radio that can be serially or USB = attached, that would provide lower bitrates (~115kbps), however much = longer distances (1+ miles). In the current prototype, the radio will = just transmit without any collision detection. Will higher layers in = the stack/software perform retries, etc.? I know that TCP handles this = for its streams, however it appears that some of the MANET = protocols/software might be UDP or even lower level ... Again ... this might not be exactly the right question due to my new = understanding of some of the MANET software being developed ... am I = right to be concerned about this? Thank you in advance! Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ------=_NextPart_000_0136_01C221F1.A8949560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello again,
 
I appreciate all of the responses to my = other=20 questions/comments ... I'm still digesting and reading and appreciate = all of the=20 expertise being shared on this list.  I'm sure that as I follow = this=20 conversation more, I'll become more aware of the various topics and = issues=20 ...
 
One area that I wanted to ask a = question or two is=20 related to current commercial radios.  It appears that most people = are=20 using 802.11b (or maybe even "a") for their MANET work.  I too use = 802.11b,=20 however the distance is very limiting.
 
I have recently been working with a = company to=20 develop an alternative radio for my purposes, and am now interested in = the radio=20 requirements to work with the software that is currently being used with = the=20 802.11b cards.
 
My specific question is if most of = these MANET=20 protocols and software require collision detection in the radio on=20 transmission?  We almost have completed a prototype of a radio that = can be=20 serially or USB attached, that would provide lower bitrates (~115kbps), = however=20 much longer distances (1+ miles).  In the current prototype, the = radio will=20 just transmit without any collision detection.  Will higher layers = in the=20 stack/software perform retries, etc.?  I know that TCP handles this = for its=20 streams, however it appears that some of the MANET protocols/software = might be=20 UDP or even lower level ...
 
Again ... this might not be exactly the = right=20 question due to my new understanding of some of the MANET software being = developed ... am I right to be concerned about this?
 
Thank you in advance!
 

Scott C.=20 Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com
http://the.Inevitable.Org/anism
 
   "People often talk about = it being the=20 journey, not the = destination.
       =20 Consider the possibility that there is no destination=20 ...
           =         =20 that in life there is only journey!"
------=_NextPart_000_0136_01C221F1.A8949560-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 20:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24364 for ; Tue, 2 Jul 2002 20:19:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03856 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 20:20:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02438; Tue, 2 Jul 2002 19:54:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02413 for ; Tue, 2 Jul 2002 19:54:15 -0400 (EDT) Received: from villinski.com ([63.226.81.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23384 for ; Tue, 2 Jul 2002 19:53:26 -0400 (EDT) Received: from onepostal.com not authenticated [63.230.21.107] by villinski.com with Novell NIMS $Revision: 2.88.1.1 $ on Novell NetWare; Tue, 02 Jul 2002 17:54:13 -0600 Received: from STENCH/SpoolDir by onepostal.com (Mercury 1.48); 2 Jul 02 17:54:13 -0700 Received: from SpoolDir by STENCH (Mercury 1.48); 2 Jul 02 17:53:45 -0700 Received: from Transient (63.230.21.105) by onepostal.com (Mercury 1.48); 2 Jul 02 17:53:38 -0700 Message-ID: <013901c22223$f41a76d0$390a640a@Transient> From: "Scott C. Lemon" To: Date: Tue, 2 Jul 2002 17:55:31 -0600 Organization: HumanXtensions L.L.C. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01C221F1.A8949560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: [manet] Do MANET radios require collision detection? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0136_01C221F1.A8949560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello again, I appreciate all of the responses to my other questions/comments ... I'm = still digesting and reading and appreciate all of the expertise being = shared on this list. I'm sure that as I follow this conversation more, = I'll become more aware of the various topics and issues ... One area that I wanted to ask a question or two is related to current = commercial radios. It appears that most people are using 802.11b (or = maybe even "a") for their MANET work. I too use 802.11b, however the = distance is very limiting. I have recently been working with a company to develop an alternative = radio for my purposes, and am now interested in the radio requirements = to work with the software that is currently being used with the 802.11b = cards. My specific question is if most of these MANET protocols and software = require collision detection in the radio on transmission? We almost = have completed a prototype of a radio that can be serially or USB = attached, that would provide lower bitrates (~115kbps), however much = longer distances (1+ miles). In the current prototype, the radio will = just transmit without any collision detection. Will higher layers in = the stack/software perform retries, etc.? I know that TCP handles this = for its streams, however it appears that some of the MANET = protocols/software might be UDP or even lower level ... Again ... this might not be exactly the right question due to my new = understanding of some of the MANET software being developed ... am I = right to be concerned about this? Thank you in advance! Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ------=_NextPart_000_0136_01C221F1.A8949560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello again,
 
I appreciate all of the responses to my = other=20 questions/comments ... I'm still digesting and reading and appreciate = all of the=20 expertise being shared on this list.  I'm sure that as I follow = this=20 conversation more, I'll become more aware of the various topics and = issues=20 ...
 
One area that I wanted to ask a = question or two is=20 related to current commercial radios.  It appears that most people = are=20 using 802.11b (or maybe even "a") for their MANET work.  I too use = 802.11b,=20 however the distance is very limiting.
 
I have recently been working with a = company to=20 develop an alternative radio for my purposes, and am now interested in = the radio=20 requirements to work with the software that is currently being used with = the=20 802.11b cards.
 
My specific question is if most of = these MANET=20 protocols and software require collision detection in the radio on=20 transmission?  We almost have completed a prototype of a radio that = can be=20 serially or USB attached, that would provide lower bitrates (~115kbps), = however=20 much longer distances (1+ miles).  In the current prototype, the = radio will=20 just transmit without any collision detection.  Will higher layers = in the=20 stack/software perform retries, etc.?  I know that TCP handles this = for its=20 streams, however it appears that some of the MANET protocols/software = might be=20 UDP or even lower level ...
 
Again ... this might not be exactly the = right=20 question due to my new understanding of some of the MANET software being = developed ... am I right to be concerned about this?
 
Thank you in advance!
 

Scott C.=20 Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com
http://the.Inevitable.Org/anism
 
   "People often talk about = it being the=20 journey, not the = destination.
       =20 Consider the possibility that there is no destination=20 ...
           =         =20 that in life there is only journey!"
------=_NextPart_000_0136_01C221F1.A8949560-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 2 21:27:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27069 for ; Tue, 2 Jul 2002 21:27:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06447; Tue, 2 Jul 2002 21:05:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06418 for ; Tue, 2 Jul 2002 21:05:40 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25962 for ; Tue, 2 Jul 2002 21:04:50 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id UAA05588 for manet@ietf.org; Tue, 2 Jul 2002 20:05:03 -0500 Date: Tue, 2 Jul 2002 20:05:03 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Do MANET radios require collision detection? Message-ID: <20020702200503.B9477@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <013901c22223$f41a76d0$390a640a@Transient> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <013901c22223$f41a76d0$390a640a@Transient>; from Scott.Lemon@humanxtensions.com on Tue, Jul 02, 2002 at 05:55:31PM -0600 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I write this response from imprecise recollections of TCP and 802.11, so someone please correct me if I write something wrong. Collision detection is not really possible in a radio network like it is in a wired network because of the hidden terminal problem. Say radios A and C cannot hear each other, but B can hear both. If they both transmit to B at once, a collision will occur at B's receiver, but neither A or C will hear it. The only indication for a collision is the lack of an ACK. TCP will handle lost segments, true, but today's implementations assume links with few bit errors, and so a lost segment is interpreted as network congestion, not mis-transmission. A TCP implementation will actually slow its transmissions when segments are lost. This is exactly the wrong thing to do in a wireless network; because bits are received in error very often, a lost segment most likely means you should just re-transmit, and fast. So a wireless MAC protocol like 802.11's tries to "simulate" (shall we say) a more reliable medium by breaking a frame into fragments (so that if a portion of a frame is clobbered on the air, the whole frame need not be retransmitted) and sends those. Each fragment requires the receiver's timely acknowledgement or it is resent. The 1999 802.11 draft standard has a good discussion of this; you can download it from IEEE for free. Most applications using datagrams will tolerate lost datagrams. If not, they will provide their own retry mechanism. I imagine retries will be spaced very far apart, however, because the implementors of datagram retries will make similar assumptions as TCP implementors. So, to answer your question, if you will use a standard TCP implementation, your radio interface should protect the IP layer from common-case transmission errors so that TCP will not needlessly back-off on transmissions, and datagram apps will not invoke overly-long retransmit delays. Dave On Tue, Jul 02, 2002 at 05:55:31PM -0600, Scott C. Lemon wrote: > Hello again, > > I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list. I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ... > > One area that I wanted to ask a question or two is related to current commercial radios. It appears that most people are using 802.11b (or maybe even "a") for their MANET work. I too use 802.11b, however the distance is very limiting. > > I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards. > > My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission? We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles). In the current prototype, the radio will just transmit without any collision detection. Will higher layers in the stack/software perform retries, etc.? I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ... > > Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this? > > Thank you in advance! > > > Scott C. Lemon > HumanXtensions L.L.C. > http://www.HumanXtensions.com > http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 2 21:27:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27079 for ; Tue, 2 Jul 2002 21:27:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07376 for manet-archive@odin.ietf.org; Tue, 2 Jul 2002 21:28:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06447; Tue, 2 Jul 2002 21:05:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06418 for ; Tue, 2 Jul 2002 21:05:40 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25962 for ; Tue, 2 Jul 2002 21:04:50 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id UAA05588 for manet@ietf.org; Tue, 2 Jul 2002 20:05:03 -0500 Date: Tue, 2 Jul 2002 20:05:03 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Do MANET radios require collision detection? Message-ID: <20020702200503.B9477@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <013901c22223$f41a76d0$390a640a@Transient> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <013901c22223$f41a76d0$390a640a@Transient>; from Scott.Lemon@humanxtensions.com on Tue, Jul 02, 2002 at 05:55:31PM -0600 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I write this response from imprecise recollections of TCP and 802.11, so someone please correct me if I write something wrong. Collision detection is not really possible in a radio network like it is in a wired network because of the hidden terminal problem. Say radios A and C cannot hear each other, but B can hear both. If they both transmit to B at once, a collision will occur at B's receiver, but neither A or C will hear it. The only indication for a collision is the lack of an ACK. TCP will handle lost segments, true, but today's implementations assume links with few bit errors, and so a lost segment is interpreted as network congestion, not mis-transmission. A TCP implementation will actually slow its transmissions when segments are lost. This is exactly the wrong thing to do in a wireless network; because bits are received in error very often, a lost segment most likely means you should just re-transmit, and fast. So a wireless MAC protocol like 802.11's tries to "simulate" (shall we say) a more reliable medium by breaking a frame into fragments (so that if a portion of a frame is clobbered on the air, the whole frame need not be retransmitted) and sends those. Each fragment requires the receiver's timely acknowledgement or it is resent. The 1999 802.11 draft standard has a good discussion of this; you can download it from IEEE for free. Most applications using datagrams will tolerate lost datagrams. If not, they will provide their own retry mechanism. I imagine retries will be spaced very far apart, however, because the implementors of datagram retries will make similar assumptions as TCP implementors. So, to answer your question, if you will use a standard TCP implementation, your radio interface should protect the IP layer from common-case transmission errors so that TCP will not needlessly back-off on transmissions, and datagram apps will not invoke overly-long retransmit delays. Dave On Tue, Jul 02, 2002 at 05:55:31PM -0600, Scott C. Lemon wrote: > Hello again, > > I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list. I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ... > > One area that I wanted to ask a question or two is related to current commercial radios. It appears that most people are using 802.11b (or maybe even "a") for their MANET work. I too use 802.11b, however the distance is very limiting. > > I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards. > > My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission? We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles). In the current prototype, the radio will just transmit without any collision detection. Will higher layers in the stack/software perform retries, etc.? I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ... > > Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this? > > Thank you in advance! > > > Scott C. Lemon > HumanXtensions L.L.C. > http://www.HumanXtensions.com > http://the.Inevitable.Org/anism > > "People often talk about it being the journey, not the destination. > Consider the possibility that there is no destination ... > that in life there is only journey!" -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 01:02:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04762 for ; Wed, 3 Jul 2002 01:02:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18174; Wed, 3 Jul 2002 00:43:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18144 for ; Wed, 3 Jul 2002 00:43:05 -0400 (EDT) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04213 for ; Wed, 3 Jul 2002 00:42:16 -0400 (EDT) Message-ID: <20020703044302.14700.qmail@web21009.mail.yahoo.com> Received: from [12.72.137.103] by web21009.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 21:43:02 PDT Date: Tue, 2 Jul 2002 21:43:02 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] Do MANET radios require collision detection? To: dyoung@pobox.com, manet@ietf.org In-Reply-To: <20020702200503.B9477@che.onthejob.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dave Well, I know little about MANET. If I am wrong, please let me know. --- David Young wrote: > Collision detection is not really possible in a radio network like it > is in a wired network because of the hidden terminal problem. Say > radios A and C cannot hear each other, but B can hear both. If they > both transmit to B at once, a collision will occur at B's receiver, > but neither A or C will hear it. The only indication for a collision > is the lack of an ACK. Even though IEEE 802.11 does have the hidden terminal problem, the intent of 802.11 is to use indoor and assume that at most time, all the nodes are in the range. Therefore, IEEE 802.11 considers very little about the hidden terminal problem. Exceptions like: RTS/CTS and using lower data rate to transmit control frames can help a little bit on hidden terminal problem. > TCP will handle lost segments, true, but today's implementations > assume links with few bit errors, and so a lost segment is > interpreted as network > congestion, not mis-transmission. A TCP implementation will actually > slow its transmissions when segments are lost. This is exactly the > wrong thing to do in a wireless network; > because bits are received in error > very often, a lost segment most likely means you should just > re-transmit, > and fast. This is well known. Not particular for TCP over Wireless LAN, but TCP over any wireless Medium. I guess that the problem mostly like being TCP, but not lower layers (wireless networks). > So a wireless MAC protocol like 802.11's tries to > "simulate" > (shall we say) a more reliable medium by breaking a frame into > fragments Such a conclusion is not correct. The reliable transmission is achieved by using ACKs. Fragmentation is not required by the standard, and its threshold can be very large. > Most applications using datagrams will tolerate lost datagrams. If > not, > they will provide their own retry mechanism. I imagine retries will > be > spaced very far apart, however, because the implementors of datagram > retries will make similar assumptions as TCP implementors. > > So, to answer your question, if you will use a standard TCP > implementation, your radio interface should protect the IP layer from > common-case transmission errors so that TCP will not needlessly > back-off > on transmissions, and datagram apps will not invoke overly-long > retransmit > delays. Do you really think that PHY layer (radio) should have so much knowledge about higher layers (TCP/IP)? > On Tue, Jul 02, 2002 at 05:55:31PM -0600, Scott C. Lemon wrote: > > One area that I wanted to ask a question or two is related to > current commercial radios. It appears that most people are using > 802.11b (or maybe even "a") for their MANET work. I too use 802.11b, > however the distance is very limiting. I would like to claim that the goal of IEEE 802.11 standards and implementations is not for MANET. Many people in MANET choose 802.11 because 802.11 is available and it is difficult to find a better one. > > My specific question is if most of these MANET protocols and > software require collision detection in the radio on transmission? I guess that collision detection is a MAC/PHY issue, whereas MANET is a higher layer than MAC. Collision detection should not be an issue for MANET. Yang > We almost have completed a prototype of a radio that can be serially > or USB attached, that would provide lower bitrates (~115kbps), > however much longer distances (1+ miles). In the current prototype, > the radio will just transmit without any collision detection. Will > higher layers in the stack/software perform retries, etc.? I know > that TCP handles this for its streams, however it appears that some > of the MANET protocols/software might be UDP or even lower level ... > > > > Again ... this might not be exactly the right question due to my > new understanding of some of the MANET software being developed ... > am I right to be concerned about this? > > > > Thank you in advance! > > > > > > Scott C. Lemon > > HumanXtensions L.L.C. > > http://www.HumanXtensions.com > > http://the.Inevitable.Org/anism > > > > "People often talk about it being the journey, not the > destination. > > Consider the possibility that there is no destination ... > > that in life there is only journey!" > > -- > David Young OJC Technologies > dyoung@onthejob.net Engineering from the Right Brain > Urbana, IL * (217) 278-3933 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/man __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 3 01:02:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04771 for ; Wed, 3 Jul 2002 01:02:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19489 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 01:02:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18174; Wed, 3 Jul 2002 00:43:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18144 for ; Wed, 3 Jul 2002 00:43:05 -0400 (EDT) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04213 for ; Wed, 3 Jul 2002 00:42:16 -0400 (EDT) Message-ID: <20020703044302.14700.qmail@web21009.mail.yahoo.com> Received: from [12.72.137.103] by web21009.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 21:43:02 PDT Date: Tue, 2 Jul 2002 21:43:02 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] Do MANET radios require collision detection? To: dyoung@pobox.com, manet@ietf.org In-Reply-To: <20020702200503.B9477@che.onthejob.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dave Well, I know little about MANET. If I am wrong, please let me know. --- David Young wrote: > Collision detection is not really possible in a radio network like it > is in a wired network because of the hidden terminal problem. Say > radios A and C cannot hear each other, but B can hear both. If they > both transmit to B at once, a collision will occur at B's receiver, > but neither A or C will hear it. The only indication for a collision > is the lack of an ACK. Even though IEEE 802.11 does have the hidden terminal problem, the intent of 802.11 is to use indoor and assume that at most time, all the nodes are in the range. Therefore, IEEE 802.11 considers very little about the hidden terminal problem. Exceptions like: RTS/CTS and using lower data rate to transmit control frames can help a little bit on hidden terminal problem. > TCP will handle lost segments, true, but today's implementations > assume links with few bit errors, and so a lost segment is > interpreted as network > congestion, not mis-transmission. A TCP implementation will actually > slow its transmissions when segments are lost. This is exactly the > wrong thing to do in a wireless network; > because bits are received in error > very often, a lost segment most likely means you should just > re-transmit, > and fast. This is well known. Not particular for TCP over Wireless LAN, but TCP over any wireless Medium. I guess that the problem mostly like being TCP, but not lower layers (wireless networks). > So a wireless MAC protocol like 802.11's tries to > "simulate" > (shall we say) a more reliable medium by breaking a frame into > fragments Such a conclusion is not correct. The reliable transmission is achieved by using ACKs. Fragmentation is not required by the standard, and its threshold can be very large. > Most applications using datagrams will tolerate lost datagrams. If > not, > they will provide their own retry mechanism. I imagine retries will > be > spaced very far apart, however, because the implementors of datagram > retries will make similar assumptions as TCP implementors. > > So, to answer your question, if you will use a standard TCP > implementation, your radio interface should protect the IP layer from > common-case transmission errors so that TCP will not needlessly > back-off > on transmissions, and datagram apps will not invoke overly-long > retransmit > delays. Do you really think that PHY layer (radio) should have so much knowledge about higher layers (TCP/IP)? > On Tue, Jul 02, 2002 at 05:55:31PM -0600, Scott C. Lemon wrote: > > One area that I wanted to ask a question or two is related to > current commercial radios. It appears that most people are using > 802.11b (or maybe even "a") for their MANET work. I too use 802.11b, > however the distance is very limiting. I would like to claim that the goal of IEEE 802.11 standards and implementations is not for MANET. Many people in MANET choose 802.11 because 802.11 is available and it is difficult to find a better one. > > My specific question is if most of these MANET protocols and > software require collision detection in the radio on transmission? I guess that collision detection is a MAC/PHY issue, whereas MANET is a higher layer than MAC. Collision detection should not be an issue for MANET. Yang > We almost have completed a prototype of a radio that can be serially > or USB attached, that would provide lower bitrates (~115kbps), > however much longer distances (1+ miles). In the current prototype, > the radio will just transmit without any collision detection. Will > higher layers in the stack/software perform retries, etc.? I know > that TCP handles this for its streams, however it appears that some > of the MANET protocols/software might be UDP or even lower level ... > > > > Again ... this might not be exactly the right question due to my > new understanding of some of the MANET software being developed ... > am I right to be concerned about this? > > > > Thank you in advance! > > > > > > Scott C. Lemon > > HumanXtensions L.L.C. > > http://www.HumanXtensions.com > > http://the.Inevitable.Org/anism > > > > "People often talk about it being the journey, not the > destination. > > Consider the possibility that there is no destination ... > > that in life there is only journey!" > > -- > David Young OJC Technologies > dyoung@onthejob.net Engineering from the Right Brain > Urbana, IL * (217) 278-3933 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/man __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 03:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01095 for ; Wed, 3 Jul 2002 03:53:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16458; Wed, 3 Jul 2002 03:27:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16418 for ; Wed, 3 Jul 2002 03:27:37 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00562 for ; Wed, 3 Jul 2002 03:26:48 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id CAA18305 for manet@ietf.org; Wed, 3 Jul 2002 02:27:07 -0500 Date: Wed, 3 Jul 2002 02:27:07 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Do MANET radios require collision detection? Message-ID: <20020703022707.B12184@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <20020702200503.B9477@che.onthejob.net> <20020703044302.14700.qmail@web21009.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020703044302.14700.qmail@web21009.mail.yahoo.com>; from yangxiao_acm@yahoo.com on Tue, Jul 02, 2002 at 09:43:02PM -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Tue, Jul 02, 2002 at 09:43:02PM -0700, Yang Xiao wrote: > > > > So a wireless MAC protocol like 802.11's tries to > > "simulate" > > (shall we say) a more reliable medium by breaking a frame into > > fragments > > Such a conclusion is not correct. The reliable transmission is achieved > by using ACKs. Fragmentation is not required by the standard, and its > threshold can be very large. I did not say as much in the rest of the snipped sentence? =) I think we agree. Do you disagree that fragmentation is important where TCP is concerned? I expect short burst of bit errors on the wireless medium. Long-ish frames sent whole with just a few bit errors will take twice the time or more to reach their destination because they will be retransmitted whole, too. Seems like the delay of retransmitting in toto will often provoke TCP to back off from sending. However, if a long-ish frame is sent in fragments, you can retransmit one or two fragments and TCP hasn't an inkling. > > So, to answer your question, if you will use a standard TCP > > implementation, your radio interface should protect the IP layer from > > common-case transmission errors so that TCP will not needlessly > > back-off > > on transmissions, and datagram apps will not invoke overly-long > > retransmit > > delays. > > Do you really think that PHY layer (radio) should have so much > knowledge about higher layers (TCP/IP)? > In the short term, it doesn't matter what I think, because I cannot retroactively change TCP implementations. =( To answer your question, I don't know yet what a stream protocol that is suited to unreliable media (or mixed media) will look like, so if the PHY/MAC will take care of that for me, I will not protest. What do you think? > I would like to claim that the goal of IEEE 802.11 standards and > implementations is not for MANET. Many people in MANET choose 802.11 > because 802.11 is available and it is difficult to find a better one. Agreed. Dave -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 3 03:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01103 for ; Wed, 3 Jul 2002 03:53:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18575 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 03:53:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16458; Wed, 3 Jul 2002 03:27:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16418 for ; Wed, 3 Jul 2002 03:27:37 -0400 (EDT) Received: from che.onthejob.net (che.onthejob.net [63.146.38.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00562 for ; Wed, 3 Jul 2002 03:26:48 -0400 (EDT) Received: (from dyoung@localhost) by che.onthejob.net (8.9.3/8.9.3) id CAA18305 for manet@ietf.org; Wed, 3 Jul 2002 02:27:07 -0500 Date: Wed, 3 Jul 2002 02:27:07 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Do MANET radios require collision detection? Message-ID: <20020703022707.B12184@che.onthejob.net> Reply-To: dyoung@pobox.com Mail-Followup-To: David Young , manet@ietf.org References: <20020702200503.B9477@che.onthejob.net> <20020703044302.14700.qmail@web21009.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020703044302.14700.qmail@web21009.mail.yahoo.com>; from yangxiao_acm@yahoo.com on Tue, Jul 02, 2002 at 09:43:02PM -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Tue, Jul 02, 2002 at 09:43:02PM -0700, Yang Xiao wrote: > > > > So a wireless MAC protocol like 802.11's tries to > > "simulate" > > (shall we say) a more reliable medium by breaking a frame into > > fragments > > Such a conclusion is not correct. The reliable transmission is achieved > by using ACKs. Fragmentation is not required by the standard, and its > threshold can be very large. I did not say as much in the rest of the snipped sentence? =) I think we agree. Do you disagree that fragmentation is important where TCP is concerned? I expect short burst of bit errors on the wireless medium. Long-ish frames sent whole with just a few bit errors will take twice the time or more to reach their destination because they will be retransmitted whole, too. Seems like the delay of retransmitting in toto will often provoke TCP to back off from sending. However, if a long-ish frame is sent in fragments, you can retransmit one or two fragments and TCP hasn't an inkling. > > So, to answer your question, if you will use a standard TCP > > implementation, your radio interface should protect the IP layer from > > common-case transmission errors so that TCP will not needlessly > > back-off > > on transmissions, and datagram apps will not invoke overly-long > > retransmit > > delays. > > Do you really think that PHY layer (radio) should have so much > knowledge about higher layers (TCP/IP)? > In the short term, it doesn't matter what I think, because I cannot retroactively change TCP implementations. =( To answer your question, I don't know yet what a stream protocol that is suited to unreliable media (or mixed media) will look like, so if the PHY/MAC will take care of that for me, I will not protest. What do you think? > I would like to claim that the goal of IEEE 802.11 standards and > implementations is not for MANET. Many people in MANET choose 802.11 > because 802.11 is available and it is difficult to find a better one. Agreed. Dave -- David Young OJC Technologies dyoung@onthejob.net Engineering from the Right Brain Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 08:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08539 for ; Wed, 3 Jul 2002 08:13:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02265; Wed, 3 Jul 2002 07:44:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02235 for ; Wed, 3 Jul 2002 07:44:07 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06801 for ; Wed, 3 Jul 2002 07:43:16 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id MAA09876; Wed, 3 Jul 2002 12:44:04 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63Bi3402245; Wed, 3 Jul 2002 12:44:03 +0100 Date: Wed, 3 Jul 2002 12:44:03 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_2242_1025696643_1@ug002> Content-ID: <18137_2242_1025696643_2@ug002> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] routing + rsvp Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable Hey, When you have routing over an ad-hoc network and use rsvp, what hap= pen when a routing path breaks? (Say a node moves away, or gets shut down) = As far as i can gather, the routing layer will try to re-establish the li= nk and notify the rsvp layer. This will then try to repair the path, failin= g if it can't get the reservation.. But do the end points know? Or is it just dealt with on the nodes near t= he = tear? I'm after as much detail as possible.. :) = Thanks :) JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 08:13:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08548 for ; Wed, 3 Jul 2002 08:13:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA04300 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 08:13:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02265; Wed, 3 Jul 2002 07:44:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02235 for ; Wed, 3 Jul 2002 07:44:07 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06801 for ; Wed, 3 Jul 2002 07:43:16 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id MAA09876; Wed, 3 Jul 2002 12:44:04 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63Bi3402245; Wed, 3 Jul 2002 12:44:03 +0100 Date: Wed, 3 Jul 2002 12:44:03 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_2242_1025696643_1@ug002> Content-ID: <18137_2242_1025696643_2@ug002> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] routing + rsvp Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable Hey, When you have routing over an ad-hoc network and use rsvp, what hap= pen when a routing path breaks? (Say a node moves away, or gets shut down) = As far as i can gather, the routing layer will try to re-establish the li= nk and notify the rsvp layer. This will then try to repair the path, failin= g if it can't get the reservation.. But do the end points know? Or is it just dealt with on the nodes near t= he = tear? I'm after as much detail as possible.. :) = Thanks :) JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 09:24:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11959 for ; Wed, 3 Jul 2002 09:24:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07723; Wed, 3 Jul 2002 09:05:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07692 for ; Wed, 3 Jul 2002 09:05:42 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10986 for ; Wed, 3 Jul 2002 09:04:52 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id OAA12502; Wed, 3 Jul 2002 14:05:40 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63D5d002713; Wed, 3 Jul 2002 14:05:39 +0100 Date: Wed, 3 Jul 2002 14:05:39 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_2703_1025701539_1@ug002> Content-ID: <18137_2703_1025701539_2@ug002> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] dynamic diffserv over a MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable Has any research been done on having a dynamic QoS over diffserv on= a MANET? I'm thinking using diffserv, but somehow monitoring the available bandwid= th, and having clients adjust accordingly. Sorta emulating a dynamic intserv system... JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 09:24:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11967 for ; Wed, 3 Jul 2002 09:24:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08761 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 09:24:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07723; Wed, 3 Jul 2002 09:05:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07692 for ; Wed, 3 Jul 2002 09:05:42 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10986 for ; Wed, 3 Jul 2002 09:04:52 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id OAA12502; Wed, 3 Jul 2002 14:05:40 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63D5d002713; Wed, 3 Jul 2002 14:05:39 +0100 Date: Wed, 3 Jul 2002 14:05:39 +0100 From: John Peter Tapsell MIME-Version: 1.0 To: manet@ietf.org Message-ID: <18137_2703_1025701539_1@ug002> Content-ID: <18137_2703_1025701539_2@ug002> Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] dynamic diffserv over a MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: quoted-printable Has any research been done on having a dynamic QoS over diffserv on= a MANET? I'm thinking using diffserv, but somehow monitoring the available bandwid= th, and having clients adjust accordingly. Sorta emulating a dynamic intserv system... JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 09:58:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14200 for ; Wed, 3 Jul 2002 09:58:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10515; Wed, 3 Jul 2002 09:39:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10414 for ; Wed, 3 Jul 2002 09:39:04 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12880 for ; Wed, 3 Jul 2002 09:38:13 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 3 Jul 2002 07:38:58 -0600 Message-Id: <02Jul3.073858mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Scott C. Lemon" Cc: manet@ietf.org Subject: RE: [manet] Do MANET radios require collision detection? Date: Wed, 3 Jul 2002 07:38:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22296.FA7F7110" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C22296.FA7F7110 Content-Type: text/plain; charset="iso-8859-1" Hi Scott, I don't know if "require" is the right word, but some sort of collision management is prudent in wireless nets. If there were sufficient bandwidth and each terminal had a precise clock, one could assign a different time slice to each transmitter so that at no time would two transmitters be on at the same time. However, when a node is not using its time slice, it goes unused. Unless nodes are routinely and regularly chatty, this wastes lots of bandwidth. If there are a lot of nodes, it doesn't leave much for each one. There is a problem of what to do if a node joins or leaves the MANET. It also allows little flexibility in the event one node has more than the usual amount to say. Although I've seen limited use of this approach, I'd say the most effective strategy seems to be random access, together with collision detection. A prudent thing is to check to see if a transmitter is active in the area and, if one is detected, wait a random interval before checking again. Obviously, if another transmitter is already on the air, transmitting will cause a data collision. However, in some cases the transmitter cannot detect the other transmission (this is the hidden terminal problem) and only the receiving terminal will know a data collision occurred. The transmitter learns when it doesn't get its ACK. However, a transmitter could fail to get an ACK for other reasons, so figuring out what to do as a result is a bit of a guessing game. Relying solely on the retransmission of entire packets has a very nasty effect and really cuts into BW. A retransmission increases channel utilization by 100% while adding nothing to throughput. Also, it is possible to have waves of retransmissions causing even more data collisions, leading to more retransmissions and the network gets pretty much choked up. In short, data collision management is much more effective than letting the chips fall where they may. Coding, segmentation, error correction, etc. can reduce the impact of an occasional collision. RTS/CTS schemes also reduce the probability and impact of a collision. In this area, I'd take all the help I could get. In this working group, the emphasis is on Layer 3 and the upper part of Layer 2 of the OSI model. For this reason, the data collision problem is often not explicitly mentioned. However, it is a very significant element of the MANET environment and its impact cannot be ignored. Furthermore, it is the sort of problem that is best handled as low in the model as possible because attempts to manage it at higher levels may aggravate the problem even when the net is only moderately loaded. John Mullen -----Original Message----- From: Scott C. Lemon [mailto:Scott.Lemon@HumanXtensions.com] Sent: Tuesday, July 02, 2002 5:56 PM To: manet@ietf.org Subject: [manet] Do MANET radios require collision detection? Hello again, I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list. I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ... One area that I wanted to ask a question or two is related to current commercial radios. It appears that most people are using 802.11b (or maybe even "a") for their MANET work. I too use 802.11b, however the distance is very limiting. I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards. My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission? We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles). In the current prototype, the radio will just transmit without any collision detection. Will higher layers in the stack/software perform retries, etc.? I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ... Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this? Thank you in advance! Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ------_=_NextPart_001_01C22296.FA7F7110 Content-Type: text/html; charset="iso-8859-1"
Hi Scott,
 
I don't know if "require" is the right word, but some sort of collision management is prudent in wireless nets. 
 
If there were sufficient bandwidth and each terminal had a precise clock, one could assign a different time slice to each transmitter so that at no time would two transmitters be on at the same time.  However, when a node is not using its time slice, it goes unused.  Unless nodes are routinely and regularly chatty, this wastes lots of bandwidth.  If there are a lot of nodes, it doesn't leave much for each one.  There is a problem of what to do if a node joins or leaves the MANET.  It also allows little flexibility in the event one node has more than the usual amount to say.  Although I've seen limited use of this approach, I'd say the most effective strategy seems to be random access, together with collision detection.
 
A prudent thing is to check to see if a transmitter is active in the area and, if one is detected, wait a random interval before checking again.  Obviously, if another transmitter is already on the air, transmitting will cause a data collision.  However, in some cases the transmitter cannot detect the other transmission (this is the hidden terminal problem) and only the receiving terminal will know a data collision occurred.  The transmitter learns when it doesn't get its ACK.  However, a transmitter could fail to get an ACK for other reasons, so figuring out what to do as a result is a bit of a guessing game.
 
Relying solely on the retransmission of entire packets has a very nasty effect and really cuts into BW.  A retransmission increases channel utilization by 100% while adding nothing to throughput.  Also, it is possible to have waves of retransmissions causing even more data collisions, leading to more retransmissions and the network gets pretty much choked up.  In short, data collision management is much more effective than letting the chips fall where they may.
 
Coding, segmentation, error correction, etc. can reduce the impact of an occasional collision.  RTS/CTS schemes also reduce the probability and impact of a collision.  In this area, I'd take all the help I could get. 
 
In this working group, the emphasis is on Layer 3 and the upper part of Layer 2 of the OSI model.  For this reason, the data collision problem is often not explicitly mentioned.  However, it is a very significant element of the MANET environment and its impact cannot be ignored.  Furthermore, it is the sort of problem that is best handled as low in the model as possible because attempts to manage it at higher levels may aggravate the problem even when the net is only moderately loaded.
 
John Mullen
-----Original Message-----
From: Scott C. Lemon [mailto:Scott.Lemon@HumanXtensions.com]
Sent: Tuesday, July 02, 2002 5:56 PM
To: manet@ietf.org
Subject: [manet] Do MANET radios require collision detection?

Hello again,
 
I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list.  I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ...
 
One area that I wanted to ask a question or two is related to current commercial radios.  It appears that most people are using 802.11b (or maybe even "a") for their MANET work.  I too use 802.11b, however the distance is very limiting.
 
I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards.
 
My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission?  We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles).  In the current prototype, the radio will just transmit without any collision detection.  Will higher layers in the stack/software perform retries, etc.?  I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ...
 
Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this?
 
Thank you in advance!
 
 
   "People often talk about it being the journey, not the destination.
        Consider the possibility that there is no destination ...
                    that in life there is only journey!"
------_=_NextPart_001_01C22296.FA7F7110-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 09:58:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14205 for ; Wed, 3 Jul 2002 09:58:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12732 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 09:59:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10515; Wed, 3 Jul 2002 09:39:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10414 for ; Wed, 3 Jul 2002 09:39:04 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12880 for ; Wed, 3 Jul 2002 09:38:13 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 3 Jul 2002 07:38:58 -0600 Message-Id: <02Jul3.073858mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Scott C. Lemon" Cc: manet@ietf.org Subject: RE: [manet] Do MANET radios require collision detection? Date: Wed, 3 Jul 2002 07:38:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22296.FA7F7110" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org 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_01C22296.FA7F7110 Content-Type: text/plain; charset="iso-8859-1" Hi Scott, I don't know if "require" is the right word, but some sort of collision management is prudent in wireless nets. If there were sufficient bandwidth and each terminal had a precise clock, one could assign a different time slice to each transmitter so that at no time would two transmitters be on at the same time. However, when a node is not using its time slice, it goes unused. Unless nodes are routinely and regularly chatty, this wastes lots of bandwidth. If there are a lot of nodes, it doesn't leave much for each one. There is a problem of what to do if a node joins or leaves the MANET. It also allows little flexibility in the event one node has more than the usual amount to say. Although I've seen limited use of this approach, I'd say the most effective strategy seems to be random access, together with collision detection. A prudent thing is to check to see if a transmitter is active in the area and, if one is detected, wait a random interval before checking again. Obviously, if another transmitter is already on the air, transmitting will cause a data collision. However, in some cases the transmitter cannot detect the other transmission (this is the hidden terminal problem) and only the receiving terminal will know a data collision occurred. The transmitter learns when it doesn't get its ACK. However, a transmitter could fail to get an ACK for other reasons, so figuring out what to do as a result is a bit of a guessing game. Relying solely on the retransmission of entire packets has a very nasty effect and really cuts into BW. A retransmission increases channel utilization by 100% while adding nothing to throughput. Also, it is possible to have waves of retransmissions causing even more data collisions, leading to more retransmissions and the network gets pretty much choked up. In short, data collision management is much more effective than letting the chips fall where they may. Coding, segmentation, error correction, etc. can reduce the impact of an occasional collision. RTS/CTS schemes also reduce the probability and impact of a collision. In this area, I'd take all the help I could get. In this working group, the emphasis is on Layer 3 and the upper part of Layer 2 of the OSI model. For this reason, the data collision problem is often not explicitly mentioned. However, it is a very significant element of the MANET environment and its impact cannot be ignored. Furthermore, it is the sort of problem that is best handled as low in the model as possible because attempts to manage it at higher levels may aggravate the problem even when the net is only moderately loaded. John Mullen -----Original Message----- From: Scott C. Lemon [mailto:Scott.Lemon@HumanXtensions.com] Sent: Tuesday, July 02, 2002 5:56 PM To: manet@ietf.org Subject: [manet] Do MANET radios require collision detection? Hello again, I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list. I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ... One area that I wanted to ask a question or two is related to current commercial radios. It appears that most people are using 802.11b (or maybe even "a") for their MANET work. I too use 802.11b, however the distance is very limiting. I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards. My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission? We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles). In the current prototype, the radio will just transmit without any collision detection. Will higher layers in the stack/software perform retries, etc.? I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ... Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this? Thank you in advance! Scott C. Lemon HumanXtensions L.L.C. http://www.HumanXtensions.com http://the.Inevitable.Org/anism "People often talk about it being the journey, not the destination. Consider the possibility that there is no destination ... that in life there is only journey!" ------_=_NextPart_001_01C22296.FA7F7110 Content-Type: text/html; charset="iso-8859-1"
Hi Scott,
 
I don't know if "require" is the right word, but some sort of collision management is prudent in wireless nets. 
 
If there were sufficient bandwidth and each terminal had a precise clock, one could assign a different time slice to each transmitter so that at no time would two transmitters be on at the same time.  However, when a node is not using its time slice, it goes unused.  Unless nodes are routinely and regularly chatty, this wastes lots of bandwidth.  If there are a lot of nodes, it doesn't leave much for each one.  There is a problem of what to do if a node joins or leaves the MANET.  It also allows little flexibility in the event one node has more than the usual amount to say.  Although I've seen limited use of this approach, I'd say the most effective strategy seems to be random access, together with collision detection.
 
A prudent thing is to check to see if a transmitter is active in the area and, if one is detected, wait a random interval before checking again.  Obviously, if another transmitter is already on the air, transmitting will cause a data collision.  However, in some cases the transmitter cannot detect the other transmission (this is the hidden terminal problem) and only the receiving terminal will know a data collision occurred.  The transmitter learns when it doesn't get its ACK.  However, a transmitter could fail to get an ACK for other reasons, so figuring out what to do as a result is a bit of a guessing game.
 
Relying solely on the retransmission of entire packets has a very nasty effect and really cuts into BW.  A retransmission increases channel utilization by 100% while adding nothing to throughput.  Also, it is possible to have waves of retransmissions causing even more data collisions, leading to more retransmissions and the network gets pretty much choked up.  In short, data collision management is much more effective than letting the chips fall where they may.
 
Coding, segmentation, error correction, etc. can reduce the impact of an occasional collision.  RTS/CTS schemes also reduce the probability and impact of a collision.  In this area, I'd take all the help I could get. 
 
In this working group, the emphasis is on Layer 3 and the upper part of Layer 2 of the OSI model.  For this reason, the data collision problem is often not explicitly mentioned.  However, it is a very significant element of the MANET environment and its impact cannot be ignored.  Furthermore, it is the sort of problem that is best handled as low in the model as possible because attempts to manage it at higher levels may aggravate the problem even when the net is only moderately loaded.
 
John Mullen
-----Original Message-----
From: Scott C. Lemon [mailto:Scott.Lemon@HumanXtensions.com]
Sent: Tuesday, July 02, 2002 5:56 PM
To: manet@ietf.org
Subject: [manet] Do MANET radios require collision detection?

Hello again,
 
I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list.  I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ...
 
One area that I wanted to ask a question or two is related to current commercial radios.  It appears that most people are using 802.11b (or maybe even "a") for their MANET work.  I too use 802.11b, however the distance is very limiting.
 
I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards.
 
My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission?  We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles).  In the current prototype, the radio will just transmit without any collision detection.  Will higher layers in the stack/software perform retries, etc.?  I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ...
 
Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this?
 
Thank you in advance!
 
 
   "People often talk about it being the journey, not the destination.
        Consider the possibility that there is no destination ...
                    that in life there is only journey!"
------_=_NextPart_001_01C22296.FA7F7110-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 10:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14379 for ; Wed, 3 Jul 2002 10:01:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08960; Wed, 3 Jul 2002 09:27:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08918 for ; Wed, 3 Jul 2002 09:27:54 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12104 for ; Wed, 3 Jul 2002 09:27:03 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id OAA13266; Wed, 3 Jul 2002 14:27:52 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63DRlJ02738; Wed, 3 Jul 2002 14:27:47 +0100 Date: Wed, 3 Jul 2002 14:27:47 +0100 From: John Tapsell To: Harpreet Arora Cc: manet@ietf.org Subject: Re: [manet] QoS over a wireless Ad Hoc network Message-ID: <20020703142747.A2720@ug002.cs.man.ac.uk> References: <3D272BDE@webmail.drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D272BDE@webmail.drexel.edu>; from ha33@drexel.edu on Thu, Jun 27, 2002 at 10:59:19PM -0400 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Harpeet, Hi! I'm replying in reference to the Simulation Study of the Feasibility of Differentiated Services Framework for QoS in MANET's (long title..) An excellent paper :) A few comments: Is having 3 layers of priority enough? Should control packets for non-priority traffic be considered higher priority as priority traffic itself? What if you have more high priority traffic than bandwidth? In such a situation you need to either try to take another route (dynamically adjust weighting(cost) at the routing level), throttle back the clients (dynamically adjust output based on bandwidth), or drop some streams for the sake of others (perhaps could be done with more layers of priority) Comments! JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 10:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14387 for ; Wed, 3 Jul 2002 10:01:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13460 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 10:02:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08960; Wed, 3 Jul 2002 09:27:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08918 for ; Wed, 3 Jul 2002 09:27:54 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12104 for ; Wed, 3 Jul 2002 09:27:03 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id OAA13266; Wed, 3 Jul 2002 14:27:52 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63DRlJ02738; Wed, 3 Jul 2002 14:27:47 +0100 Date: Wed, 3 Jul 2002 14:27:47 +0100 From: John Tapsell To: Harpreet Arora Cc: manet@ietf.org Subject: Re: [manet] QoS over a wireless Ad Hoc network Message-ID: <20020703142747.A2720@ug002.cs.man.ac.uk> References: <3D272BDE@webmail.drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D272BDE@webmail.drexel.edu>; from ha33@drexel.edu on Thu, Jun 27, 2002 at 10:59:19PM -0400 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Harpeet, Hi! I'm replying in reference to the Simulation Study of the Feasibility of Differentiated Services Framework for QoS in MANET's (long title..) An excellent paper :) A few comments: Is having 3 layers of priority enough? Should control packets for non-priority traffic be considered higher priority as priority traffic itself? What if you have more high priority traffic than bandwidth? In such a situation you need to either try to take another route (dynamically adjust weighting(cost) at the routing level), throttle back the clients (dynamically adjust output based on bandwidth), or drop some streams for the sake of others (perhaps could be done with more layers of priority) Comments! JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 10:09:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15215 for ; Wed, 3 Jul 2002 10:09:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11068; Wed, 3 Jul 2002 09:43:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11006 for ; Wed, 3 Jul 2002 09:43:06 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13139 for ; Wed, 3 Jul 2002 09:42:15 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id OAA13728; Wed, 3 Jul 2002 14:42:56 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63Dgla02854; Wed, 3 Jul 2002 14:42:47 +0100 Date: Wed, 3 Jul 2002 14:42:47 +0100 From: John Peter Tapsell Message-Id: <200207031342.g63Dgla02854@ug002.cs.man.ac.uk> To: Chee-Yeew.Yong@uk.thalesgroup.com, tapselj0@cs.man.ac.uk Subject: RE: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Harpreet Arora sent me the paper.. I've put it up at www.cs.man.ac.uk/~tapselj0/paper2.pdf - I hope Harpreet doesn't mind .. JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 10:09:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15222 for ; Wed, 3 Jul 2002 10:09:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13931 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 10:10:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11068; Wed, 3 Jul 2002 09:43:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11006 for ; Wed, 3 Jul 2002 09:43:06 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13139 for ; Wed, 3 Jul 2002 09:42:15 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id OAA13728; Wed, 3 Jul 2002 14:42:56 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g63Dgla02854; Wed, 3 Jul 2002 14:42:47 +0100 Date: Wed, 3 Jul 2002 14:42:47 +0100 From: John Peter Tapsell Message-Id: <200207031342.g63Dgla02854@ug002.cs.man.ac.uk> To: Chee-Yeew.Yong@uk.thalesgroup.com, tapselj0@cs.man.ac.uk Subject: RE: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Harpreet Arora sent me the paper.. I've put it up at www.cs.man.ac.uk/~tapselj0/paper2.pdf - I hope Harpreet doesn't mind .. JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 14:39:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27832 for ; Wed, 3 Jul 2002 14:39:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01113 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 14:40:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22630; Wed, 3 Jul 2002 12:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22586 for ; Wed, 3 Jul 2002 12:28:34 -0400 (EDT) Received: from web21008.mail.yahoo.com (web21008.mail.yahoo.com [216.136.227.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20821 for ; Wed, 3 Jul 2002 12:27:46 -0400 (EDT) Message-ID: <20020703162743.40132.qmail@web21008.mail.yahoo.com> Received: from [65.88.242.115] by web21008.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 09:27:43 PDT Date: Wed, 3 Jul 2002 09:27:43 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] QoS over a wireless Ad Hoc network To: John Tapsell , Harpreet Arora Cc: manet@ietf.org In-Reply-To: <20020703142747.A2720@ug002.cs.man.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Harpeet and JohnFlux I did not follow this thread. Where can I find this paper? Thanks Yang --- John Tapsell wrote: > Harpeet, > Hi! I'm replying in reference to the Simulation Study of the > Feasibility of Differentiated Services Framework for QoS in > MANET's (long title..) > > An excellent paper :) > > A few comments: > Is having 3 layers of priority enough? > Should control packets for non-priority traffic be considered > higher priority as priority traffic itself? > What if you have more high priority traffic than bandwidth? > In such a situation you need to either try to take > another route (dynamically adjust weighting(cost) at the > routing level), throttle back the clients (dynamically > adjust output based on bandwidth), or drop some streams > for the sake of others (perhaps could be done with more > layers of priority) > Comments! > > JohnFlux > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 14:40:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27888 for ; Wed, 3 Jul 2002 14:40:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15324; Wed, 3 Jul 2002 10:36:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15291 for ; Wed, 3 Jul 2002 10:36:13 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16856 for ; Wed, 3 Jul 2002 10:35:24 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA26062; Wed, 3 Jul 2002 07:35:58 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA24068; Wed, 3 Jul 2002 07:35:44 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g63EZu013827; Wed, 3 Jul 2002 07:35:56 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jul 2002 10:35:56 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39ED@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'John Peter Tapsell'" , manet@ietf.org Subject: RE: [manet] routing + rsvp Date: Wed, 3 Jul 2002 10:35:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Peter Tapsell: > Hey, > When you have routing over an ad-hoc network and use > rsvp, what happen > when a routing path breaks? (Say a node moves away, or gets > shut down) According to RFC 2205, 2.3 Soft State RSVP takes a "soft state" approach to managing the reservation state in routers and hosts. RSVP soft state is created and periodically refreshed by Path and Resv messages. The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval. State may also be deleted by an explicit "teardown" message, described in the next section. At the expiration of each "refresh timeout" period and after a state change, RSVP scans its state to build and forward Path and Resv refresh messages to succeeding hops. Path and Resv messages are idempotent. When a route changes, the next Path message will initialize the path state on the new route, and future Resv messages will establish reservation state there; the state on the now-unused segment of the route will time out. Thus, whether a message is "new" or a "refresh" is determined separately at each node, depending upon the existence of state at that node. When a path breaks, the new PATH messages have to find a new path, with the appropriate flow descriptors, at each hop on this new path. And subsequent RESV messages will flow back upstream on this new path. In other words, the "flow" (i.e. the "pretend-circuit") will break and will need to be re-established. And if RSVP-enabled hops don't exist throughout, non-RSVP hops could be used. What does that say about QoS? > As far as i can gather, the routing layer will try to > re-establish the link > and notify the rsvp layer. This will then try to repair the > path, failing > if it can't get the reservation.. I don't see that in RSVP. I don't see anything in the routing protocols that notifies RSVP of anything. Unless I'm forgetting something pretty fundamental about RSVP. RSVP is not a routing protocol. It depends on some sort of constraint-based routing to be at its best, or on adequate headroom being available at all hops of a route, so that reservations can be made successfully. It's not clear to me that RSVP can work in a general MANET case, although it can probably work if the MANET hosts stay put and if they are RSVP capable. Same applies to diffserv, as far as I can tell. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 14:40:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27893 for ; Wed, 3 Jul 2002 14:40:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01179 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 14:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15324; Wed, 3 Jul 2002 10:36:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15291 for ; Wed, 3 Jul 2002 10:36:13 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16856 for ; Wed, 3 Jul 2002 10:35:24 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA26062; Wed, 3 Jul 2002 07:35:58 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA24068; Wed, 3 Jul 2002 07:35:44 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g63EZu013827; Wed, 3 Jul 2002 07:35:56 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jul 2002 10:35:56 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A39ED@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'John Peter Tapsell'" , manet@ietf.org Subject: RE: [manet] routing + rsvp Date: Wed, 3 Jul 2002 10:35:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Peter Tapsell: > Hey, > When you have routing over an ad-hoc network and use > rsvp, what happen > when a routing path breaks? (Say a node moves away, or gets > shut down) According to RFC 2205, 2.3 Soft State RSVP takes a "soft state" approach to managing the reservation state in routers and hosts. RSVP soft state is created and periodically refreshed by Path and Resv messages. The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval. State may also be deleted by an explicit "teardown" message, described in the next section. At the expiration of each "refresh timeout" period and after a state change, RSVP scans its state to build and forward Path and Resv refresh messages to succeeding hops. Path and Resv messages are idempotent. When a route changes, the next Path message will initialize the path state on the new route, and future Resv messages will establish reservation state there; the state on the now-unused segment of the route will time out. Thus, whether a message is "new" or a "refresh" is determined separately at each node, depending upon the existence of state at that node. When a path breaks, the new PATH messages have to find a new path, with the appropriate flow descriptors, at each hop on this new path. And subsequent RESV messages will flow back upstream on this new path. In other words, the "flow" (i.e. the "pretend-circuit") will break and will need to be re-established. And if RSVP-enabled hops don't exist throughout, non-RSVP hops could be used. What does that say about QoS? > As far as i can gather, the routing layer will try to > re-establish the link > and notify the rsvp layer. This will then try to repair the > path, failing > if it can't get the reservation.. I don't see that in RSVP. I don't see anything in the routing protocols that notifies RSVP of anything. Unless I'm forgetting something pretty fundamental about RSVP. RSVP is not a routing protocol. It depends on some sort of constraint-based routing to be at its best, or on adequate headroom being available at all hops of a route, so that reservations can be made successfully. It's not clear to me that RSVP can work in a general MANET case, although it can probably work if the MANET hosts stay put and if they are RSVP capable. Same applies to diffserv, as far as I can tell. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 14:41:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28073 for ; Wed, 3 Jul 2002 14:41:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23326; Wed, 3 Jul 2002 12:35:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23299 for ; Wed, 3 Jul 2002 12:35:33 -0400 (EDT) Received: from web21007.mail.yahoo.com (web21007.mail.yahoo.com [216.136.227.61]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21063 for ; Wed, 3 Jul 2002 12:34:45 -0400 (EDT) Message-ID: <20020703160852.32708.qmail@web21007.mail.yahoo.com> Received: from [65.88.242.115] by web21007.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 09:08:52 PDT Date: Wed, 3 Jul 2002 09:08:52 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] Do MANET radios require collision detection? To: dyoung@pobox.com, manet@ietf.org Cc: yangxiao@IEEE.ORG In-Reply-To: <20020703022707.B12184@che.onthejob.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dave, --- David Young wrote: > Do you disagree that fragmentation is important where TCP is > concerned? I expect short burst of bit errors on the wireless medium. > Long-ish frames sent whole with just a few bit errors will take twice > the time or more to reach their destination because they will be > retransmitted whole, too. Seems like the delay of retransmitting in > toto will often provoke TCP to back off from sending. However, if a > long-ish frame is sent in fragments, you can retransmit one or two > fragments and TCP hasn't an inkling. Sure, fragmentation can help packets go though wireless medium. Assume that we are discussing a pure ad hoc network in which no wired network is involved. Under such an assumption, TCP should adjust itself and set the re-transmission timer much longer than usual. I believe that TCP is the place to be adjusted, but not wireless MAC or PHY. > In the short term, it doesn't matter what I think, because I cannot > retroactively change TCP implementations. =( Why not? I believe that TCP implementations should be the right place to change. > To answer your question, I don't know yet what a stream protocol > that is suited to unreliable media (or mixed media) will look like, so > if the PHY/MAC will take care of that for me, I will not protest. > > What do you think? If PHY/MAC can, that is great. However, it is not easy or maybe not worthwhile taking the efforts. Let's make an analogy as follows. TCP takes care the ordering and reliable transmission of a stream over IP, but IP does not do these. One reason is that IP is not a stream protocol, and TCP is. Therefore, TCP needs to take care of it's own business. The similar thing happens for TCP over WLAN. WLAN can not take care anything about stream protocol, which is TCP's business. In order words, it is none of WLAN's business. Regards Yang __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 14:41:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28081 for ; Wed, 3 Jul 2002 14:41:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01290 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 14:42:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23326; Wed, 3 Jul 2002 12:35:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23299 for ; Wed, 3 Jul 2002 12:35:33 -0400 (EDT) Received: from web21007.mail.yahoo.com (web21007.mail.yahoo.com [216.136.227.61]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21063 for ; Wed, 3 Jul 2002 12:34:45 -0400 (EDT) Message-ID: <20020703160852.32708.qmail@web21007.mail.yahoo.com> Received: from [65.88.242.115] by web21007.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 09:08:52 PDT Date: Wed, 3 Jul 2002 09:08:52 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] Do MANET radios require collision detection? To: dyoung@pobox.com, manet@ietf.org Cc: yangxiao@IEEE.ORG In-Reply-To: <20020703022707.B12184@che.onthejob.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dave, --- David Young wrote: > Do you disagree that fragmentation is important where TCP is > concerned? I expect short burst of bit errors on the wireless medium. > Long-ish frames sent whole with just a few bit errors will take twice > the time or more to reach their destination because they will be > retransmitted whole, too. Seems like the delay of retransmitting in > toto will often provoke TCP to back off from sending. However, if a > long-ish frame is sent in fragments, you can retransmit one or two > fragments and TCP hasn't an inkling. Sure, fragmentation can help packets go though wireless medium. Assume that we are discussing a pure ad hoc network in which no wired network is involved. Under such an assumption, TCP should adjust itself and set the re-transmission timer much longer than usual. I believe that TCP is the place to be adjusted, but not wireless MAC or PHY. > In the short term, it doesn't matter what I think, because I cannot > retroactively change TCP implementations. =( Why not? I believe that TCP implementations should be the right place to change. > To answer your question, I don't know yet what a stream protocol > that is suited to unreliable media (or mixed media) will look like, so > if the PHY/MAC will take care of that for me, I will not protest. > > What do you think? If PHY/MAC can, that is great. However, it is not easy or maybe not worthwhile taking the efforts. Let's make an analogy as follows. TCP takes care the ordering and reliable transmission of a stream over IP, but IP does not do these. One reason is that IP is not a stream protocol, and TCP is. Therefore, TCP needs to take care of it's own business. The similar thing happens for TCP over WLAN. WLAN can not take care anything about stream protocol, which is TCP's business. In order words, it is none of WLAN's business. Regards Yang __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 15:39:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27826 for ; Wed, 3 Jul 2002 14:39:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22630; Wed, 3 Jul 2002 12:28:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22586 for ; Wed, 3 Jul 2002 12:28:34 -0400 (EDT) Received: from web21008.mail.yahoo.com (web21008.mail.yahoo.com [216.136.227.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20821 for ; Wed, 3 Jul 2002 12:27:46 -0400 (EDT) Message-ID: <20020703162743.40132.qmail@web21008.mail.yahoo.com> Received: from [65.88.242.115] by web21008.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 09:27:43 PDT Date: Wed, 3 Jul 2002 09:27:43 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] QoS over a wireless Ad Hoc network To: John Tapsell , Harpreet Arora Cc: manet@ietf.org In-Reply-To: <20020703142747.A2720@ug002.cs.man.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Harpeet and JohnFlux I did not follow this thread. Where can I find this paper? Thanks Yang --- John Tapsell wrote: > Harpeet, > Hi! I'm replying in reference to the Simulation Study of the > Feasibility of Differentiated Services Framework for QoS in > MANET's (long title..) > > An excellent paper :) > > A few comments: > Is having 3 layers of priority enough? > Should control packets for non-priority traffic be considered > higher priority as priority traffic itself? > What if you have more high priority traffic than bandwidth? > In such a situation you need to either try to take > another route (dynamically adjust weighting(cost) at the > routing level), throttle back the clients (dynamically > adjust output based on bandwidth), or drop some streams > for the sake of others (perhaps could be done with more > layers of priority) > Comments! > > JohnFlux > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 3 18:09:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09250 for ; Wed, 3 Jul 2002 18:09:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16737; Wed, 3 Jul 2002 17:45:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16708 for ; Wed, 3 Jul 2002 17:44:57 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07951 for ; Wed, 3 Jul 2002 17:44:07 -0400 (EDT) Received: from shim.irt.drexel.edu (shim.irt.drexel.edu [129.25.3.91]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GYP00F3A0DDF7@mail.drexel.edu> for manet@ietf.org; Wed, 3 Jul 2002 17:44:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by shim.irt.drexel.edu (Postfix) with ESMTP id A35947BED9; Wed, 03 Jul 2002 17:44:01 -0400 (EDT) Received: from glue.irt.drexel.edu (glue.irt.drexel.edu [129.25.3.22]) by shim.irt.drexel.edu (Postfix) with ESMTP id 52EC77BED3; Wed, 03 Jul 2002 17:12:55 -0400 (EDT) Received: from dunx1.irt.drexel.edu (dunx1.irt.drexel.edu [144.118.24.33]) by glue.irt.drexel.edu (8.11.3/8.11.3) with ESMTP id g63LCaG25809; Wed, 03 Jul 2002 17:12:37 -0400 (EDT) Date: Wed, 03 Jul 2002 17:12:16 -0400 (EDT) From: Harpreet Arora Subject: Re: [manet] QoS over a wireless Ad Hoc network In-reply-to: <20020703142747.A2720@ug002.cs.man.ac.uk> To: John Tapsell Cc: manet@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Virus-Scanned: by AMaViS snapshot-20010915 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi John, The number of levels of priority depends on the types of applications supported by the network and also on the situations where the network is used. For example a network used for rescue operations can have voice traffic with different priorities depending upon the urgency of the message. For commercial purposes, this decision I guess depends on the way the service providers decide to charge for the bandwidth and priority. If the bandwidth required by the high priority flow is greater than available, then the way it is processed can depend on the priority level of the flow. FOr example, for short urgent messages, the bandwidth of other flows can surely be throttled for a short time to make way for this flow. Else, the new flow can be denied admittance to ensure that the already existing flows are not disrupted for a long time. I think all these factors are completely dependent on the situation the network is used for and the kind of applications supported. Harpreet On Wed, 3 Jul 2002, John Tapsell wrote: > Harpeet, > Hi! I'm replying in reference to the Simulation Study of the > Feasibility of Differentiated Services Framework for QoS in > MANET's (long title..) > > An excellent paper :) > > A few comments: > Is having 3 layers of priority enough? > Should control packets for non-priority traffic be considered > higher priority as priority traffic itself? > What if you have more high priority traffic than bandwidth? > In such a situation you need to either try to take > another route (dynamically adjust weighting(cost) at the > routing level), throttle back the clients (dynamically > adjust output based on bandwidth), or drop some streams > for the sake of others (perhaps could be done with more > layers of priority) > Comments! > > JohnFlux > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Jul 3 18:09:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09258 for ; Wed, 3 Jul 2002 18:09:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA18268 for manet-archive@odin.ietf.org; Wed, 3 Jul 2002 18:10:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16737; Wed, 3 Jul 2002 17:45:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16708 for ; Wed, 3 Jul 2002 17:44:57 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07951 for ; Wed, 3 Jul 2002 17:44:07 -0400 (EDT) Received: from shim.irt.drexel.edu (shim.irt.drexel.edu [129.25.3.91]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GYP00F3A0DDF7@mail.drexel.edu> for manet@ietf.org; Wed, 3 Jul 2002 17:44:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by shim.irt.drexel.edu (Postfix) with ESMTP id A35947BED9; Wed, 03 Jul 2002 17:44:01 -0400 (EDT) Received: from glue.irt.drexel.edu (glue.irt.drexel.edu [129.25.3.22]) by shim.irt.drexel.edu (Postfix) with ESMTP id 52EC77BED3; Wed, 03 Jul 2002 17:12:55 -0400 (EDT) Received: from dunx1.irt.drexel.edu (dunx1.irt.drexel.edu [144.118.24.33]) by glue.irt.drexel.edu (8.11.3/8.11.3) with ESMTP id g63LCaG25809; Wed, 03 Jul 2002 17:12:37 -0400 (EDT) Date: Wed, 03 Jul 2002 17:12:16 -0400 (EDT) From: Harpreet Arora Subject: Re: [manet] QoS over a wireless Ad Hoc network In-reply-to: <20020703142747.A2720@ug002.cs.man.ac.uk> To: John Tapsell Cc: manet@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Virus-Scanned: by AMaViS snapshot-20010915 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi John, The number of levels of priority depends on the types of applications supported by the network and also on the situations where the network is used. For example a network used for rescue operations can have voice traffic with different priorities depending upon the urgency of the message. For commercial purposes, this decision I guess depends on the way the service providers decide to charge for the bandwidth and priority. If the bandwidth required by the high priority flow is greater than available, then the way it is processed can depend on the priority level of the flow. FOr example, for short urgent messages, the bandwidth of other flows can surely be throttled for a short time to make way for this flow. Else, the new flow can be denied admittance to ensure that the already existing flows are not disrupted for a long time. I think all these factors are completely dependent on the situation the network is used for and the kind of applications supported. Harpreet On Wed, 3 Jul 2002, John Tapsell wrote: > Harpeet, > Hi! I'm replying in reference to the Simulation Study of the > Feasibility of Differentiated Services Framework for QoS in > MANET's (long title..) > > An excellent paper :) > > A few comments: > Is having 3 layers of priority enough? > Should control packets for non-priority traffic be considered > higher priority as priority traffic itself? > What if you have more high priority traffic than bandwidth? > In such a situation you need to either try to take > another route (dynamically adjust weighting(cost) at the > routing level), throttle back the clients (dynamically > adjust output based on bandwidth), or drop some streams > for the sake of others (perhaps could be done with more > layers of priority) > Comments! > > JohnFlux > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jul 4 06:50:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13829 for ; Thu, 4 Jul 2002 06:50:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09907; Thu, 4 Jul 2002 06:27:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09878 for ; Thu, 4 Jul 2002 06:27:39 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13428 for ; Thu, 4 Jul 2002 06:26:50 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id LAA12181; Thu, 4 Jul 2002 11:27:33 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g64ARUp01883; Thu, 4 Jul 2002 11:27:30 +0100 Date: Thu, 4 Jul 2002 11:27:30 +0100 From: John Peter Tapsell Message-Id: <200207041027.g64ARUp01883@ug002.cs.man.ac.uk> To: campbell@ee.columbia.edu, ha33@drexel.edu, tapselj0@cs.man.ac.uk, YangXiao@IEEE.ORG Subject: RE: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I'm confused.. :) I thought diffserv was simply each node knowing about priority traffic so simply queueing that first.. ? In which case I can't see the difficulty in doing this in ad-hoc networks? Were you thinking of intserv ? Or am I going looney? :) JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jul 4 06:50:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13837 for ; Thu, 4 Jul 2002 06:50:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11400 for manet-archive@odin.ietf.org; Thu, 4 Jul 2002 06:51:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09907; Thu, 4 Jul 2002 06:27:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09878 for ; Thu, 4 Jul 2002 06:27:39 -0400 (EDT) Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13428 for ; Thu, 4 Jul 2002 06:26:50 -0400 (EDT) Received: from ug002.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0) id LAA12181; Thu, 4 Jul 2002 11:27:33 +0100 (BST) Received: (from tapselj0@localhost) by ug002.cs.man.ac.uk (8.11.6/8.9.3) id g64ARUp01883; Thu, 4 Jul 2002 11:27:30 +0100 Date: Thu, 4 Jul 2002 11:27:30 +0100 From: John Peter Tapsell Message-Id: <200207041027.g64ARUp01883@ug002.cs.man.ac.uk> To: campbell@ee.columbia.edu, ha33@drexel.edu, tapselj0@cs.man.ac.uk, YangXiao@IEEE.ORG Subject: RE: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I'm confused.. :) I thought diffserv was simply each node knowing about priority traffic so simply queueing that first.. ? In which case I can't see the difficulty in doing this in ad-hoc networks? Were you thinking of intserv ? Or am I going looney? :) JohnFlux _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jul 4 10:22:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17922 for ; Thu, 4 Jul 2002 10:22:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20688; Thu, 4 Jul 2002 10:01:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20657 for ; Thu, 4 Jul 2002 10:01:52 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17531 for ; Thu, 4 Jul 2002 10:01:01 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jul 4 07:01:07 2002 To: "John Tapsell" , "Harpreet Arora" Date: Thu, 04 Jul 2002 10:01:07 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [manet] QoS over a wireless Ad Hoc network X-Sender-Ip: 216.209.247.190 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Arora, I'm very confused here. First, what do you mean the periority depends on the service provider? Who is the service provider for ad-hoc bandwidth? Second, What do you mean by your classification of periorities? DiffServ rely on predefined PHB to achieve a PDB (Per Domain Behaviour). This is done by engineering the network with the help of provisioning systems, and human adminstration. How this could be solved for DiffServ is quite a challenge. I can't claim to have read your paper, I'll read it right now. Yasser Carleton U _____________________________________________________ Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads and NoTaglines --> LYCOS MAIL PLUS. http://www.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jul 4 10:22:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17930 for ; Thu, 4 Jul 2002 10:22:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21768 for manet-archive@odin.ietf.org; Thu, 4 Jul 2002 10:23:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20688; Thu, 4 Jul 2002 10:01:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20657 for ; Thu, 4 Jul 2002 10:01:52 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17531 for ; Thu, 4 Jul 2002 10:01:01 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jul 4 07:01:07 2002 To: "John Tapsell" , "Harpreet Arora" Date: Thu, 04 Jul 2002 10:01:07 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [manet] QoS over a wireless Ad Hoc network X-Sender-Ip: 216.209.247.190 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Arora, I'm very confused here. First, what do you mean the periority depends on the service provider? Who is the service provider for ad-hoc bandwidth? Second, What do you mean by your classification of periorities? DiffServ rely on predefined PHB to achieve a PDB (Per Domain Behaviour). This is done by engineering the network with the help of provisioning systems, and human adminstration. How this could be solved for DiffServ is quite a challenge. I can't claim to have read your paper, I'll read it right now. Yasser Carleton U _____________________________________________________ Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads and NoTaglines --> LYCOS MAIL PLUS. http://www.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jul 4 18:38:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26199 for ; Thu, 4 Jul 2002 18:38:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12872; Thu, 4 Jul 2002 18:15:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12843 for ; Thu, 4 Jul 2002 18:15:41 -0400 (EDT) Received: from SMTP1.ECE.NEU.EDU (markov.ece.neu.edu [129.10.60.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25829 for ; Thu, 4 Jul 2002 18:14:51 -0400 (EDT) Received: from dharma.ece.neu.edu (dharma.ece.neu.edu [129.10.60.101]) by SMTP1.ECE.NEU.EDU (8.11.3/8.11.3) with SMTP id g64MFdC16012 for ; Thu, 4 Jul 2002 18:15:39 -0400 (EDT) Received: from bibbiena.ece.neu.edu ([129.10.60.216]) by dharma.ece.neu.edu (NAVGW 2.5.2.9) with SMTP id M2002070418153911403 for ; Thu, 04 Jul 2002 18:15:39 -0400 Received: from localhost (basagni@localhost) by bibbiena.ece.neu.edu (8.9.3/8.9.3) with ESMTP id SAA23546 for ; Thu, 4 Jul 2002 18:15:39 -0400 (EDT) X-Authentication-Warning: bibbiena.ece.neu.edu: basagni owned process doing -bs Date: Thu, 4 Jul 2002 18:15:39 -0400 (EDT) From: Stefano Basagni X-Sender: basagni@bibbiena To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id SAA12844 Subject: [manet] IEEE PERCOM 2003 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Sincere apologies if you receive multiple copies of this announcement. ---------------------------------------------------------- P E R C O M 2 0 0 3 Dallas-Fort Worth Metroplex, Texas March 23-26, 2003 Conference Announcement and Preliminary Call for Papers --------------------------------------------------------- IEEE International Conference on Pervasive Computing and Communications (PerCom), Paper Submission Deadline---October 1, 2002 Sponsored by the IEEE Computer Society --------------------------------------------------------- Pervasive computing and communications is emerging as an exciting new paradigm with a goal to provide computing and communication services all the time everywhere. This is a natural outcome of research and technological advances in wireless networks, mobile computing, distributed computing and agent technologies. PerCom is the annual IEEE conference on pervasive computing and communications. PerCom2003 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest advances in the field of pervasive computing and communications. PerCom2003 will also feature two special tracks on intelligent environments and mobile agents. Topics: ---------------- Contributions are solicited in all pervasive computing research and applied areas. These include, but are not limited to the following feature topics: · Pervasive computing architectures · Intelligent environments · Wearable computers · Smart devices and smart spaces · Location-dependent / personalized applications · Service discovery mechanisms · Agent technologies · Sensors and actuators · Positioning and tracking technologies · Identification and authentication technologies · Integration of wired and wireless networks · Personal area networks · Enabling technologies such as Bluetooth, 802.11 and 802.15 · Software coordination models · Mobile / wireless computing systems and services · Context based and implicit computing · Speech processing / advanced computer vision · User interfaces and interaction models · Wireless/mobile service management and delivery · Ad hoc networking protocols and service discovery · Resource management in pervasive computing platforms · Security and privacy issues for pervasive computing systems Submission Guidelines: Papers must be unpublished and must not be submitted for publication elsewhere. Authors are encouraged to submit papers in electronic form, postscript or PDF only. The page limit for submissions is 15 pages (1.5 line spaced, excluding references, figures and tables). More details on submission procedures will be posted on the official PerCom website: http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. Conference proceedings will be published by IEEE. Papers of particular merit will be considered for publication in a special issue of a leading journal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Important Dates/Deadlines: Paper Submissions: October 1, 2002 Acceptance Notification: December 10, 2002 Camera Ready Manuscripts: January 10, 2003 Conference Dates: March 23-26, 2003 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Organizing Committee: General Chair Behrooz A. Shirazi University of Texas at Arlington General Vice Chair: Sajal K. Das University of Texas at Arlington Technical Program Committee Chair Mohan Kumar University of Texas at Arlington Local Chair: Gergely V. Záruba University of Texas at Arlington Finance Chair: David Levine University of Texas at Arlington Intelligent Environments Track Chair: Diane Cook University of Texas at Arlington Tutorials Chair: Azzedine Boukerche University of North Texas Industry Liaison: Kalyan Basu University of Texas at Arlington Publicity Chairs: Stefano Basagni Northeastern University Chiara Petrioli University of Rome Albert Zomaya University of Sydney Technical Program Committee: (Under Creation) Giuseppe Anastasi University of Pisa, Italy Jean Bacon University of Cambridge, UK Chatschik Bisdikian, IBM, USA Lisa Burnell, Texas Christian University, USA Liang Cheng, Lehigh University, USA Marco Conti, National Research Council, Italy Diane Cook, University of Texas at Arlington, USA Antonio Corradi, University of Bologna, Italy Jason Flinn, Carnegie Mellon University, USA Robert Gray, Dartmouth College, USA Liviu Iftode, Rutgers University, USA Archan Misra, IBM Center, USA Yannis Labrou, Fujitsu, USA Mohan Kumar, University of Texas at Arlington, USA Phil McKinley Michigan State University, USA Paddy Nixon, The University of Strathclyde, UK Gian Pietro, Dipartimento di Elettronica e Informazione, Italy Caluligi Raghavendra, University of Southern California, USA Ichiro Satoh, National Institute of Informatics, Japan Steven Shafer, Microsoft Corporation, USA HJ Siegel, Colorado State University, USA Anand Tripathi, University of Minnesota, USA Mohan Trivedi, University of California, San Diego, USA Ty Znati, University of Pittsburg, USA -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntigton Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jul 4 18:38:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26204 for ; Thu, 4 Jul 2002 18:38:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14128 for manet-archive@odin.ietf.org; Thu, 4 Jul 2002 18:39:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12872; Thu, 4 Jul 2002 18:15:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12843 for ; Thu, 4 Jul 2002 18:15:41 -0400 (EDT) Received: from SMTP1.ECE.NEU.EDU (markov.ece.neu.edu [129.10.60.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25829 for ; Thu, 4 Jul 2002 18:14:51 -0400 (EDT) Received: from dharma.ece.neu.edu (dharma.ece.neu.edu [129.10.60.101]) by SMTP1.ECE.NEU.EDU (8.11.3/8.11.3) with SMTP id g64MFdC16012 for ; Thu, 4 Jul 2002 18:15:39 -0400 (EDT) Received: from bibbiena.ece.neu.edu ([129.10.60.216]) by dharma.ece.neu.edu (NAVGW 2.5.2.9) with SMTP id M2002070418153911403 for ; Thu, 04 Jul 2002 18:15:39 -0400 Received: from localhost (basagni@localhost) by bibbiena.ece.neu.edu (8.9.3/8.9.3) with ESMTP id SAA23546 for ; Thu, 4 Jul 2002 18:15:39 -0400 (EDT) X-Authentication-Warning: bibbiena.ece.neu.edu: basagni owned process doing -bs Date: Thu, 4 Jul 2002 18:15:39 -0400 (EDT) From: Stefano Basagni X-Sender: basagni@bibbiena To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id SAA12844 Subject: [manet] IEEE PERCOM 2003 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Sincere apologies if you receive multiple copies of this announcement. ---------------------------------------------------------- P E R C O M 2 0 0 3 Dallas-Fort Worth Metroplex, Texas March 23-26, 2003 Conference Announcement and Preliminary Call for Papers --------------------------------------------------------- IEEE International Conference on Pervasive Computing and Communications (PerCom), Paper Submission Deadline---October 1, 2002 Sponsored by the IEEE Computer Society --------------------------------------------------------- Pervasive computing and communications is emerging as an exciting new paradigm with a goal to provide computing and communication services all the time everywhere. This is a natural outcome of research and technological advances in wireless networks, mobile computing, distributed computing and agent technologies. PerCom is the annual IEEE conference on pervasive computing and communications. PerCom2003 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest advances in the field of pervasive computing and communications. PerCom2003 will also feature two special tracks on intelligent environments and mobile agents. Topics: ---------------- Contributions are solicited in all pervasive computing research and applied areas. These include, but are not limited to the following feature topics: · Pervasive computing architectures · Intelligent environments · Wearable computers · Smart devices and smart spaces · Location-dependent / personalized applications · Service discovery mechanisms · Agent technologies · Sensors and actuators · Positioning and tracking technologies · Identification and authentication technologies · Integration of wired and wireless networks · Personal area networks · Enabling technologies such as Bluetooth, 802.11 and 802.15 · Software coordination models · Mobile / wireless computing systems and services · Context based and implicit computing · Speech processing / advanced computer vision · User interfaces and interaction models · Wireless/mobile service management and delivery · Ad hoc networking protocols and service discovery · Resource management in pervasive computing platforms · Security and privacy issues for pervasive computing systems Submission Guidelines: Papers must be unpublished and must not be submitted for publication elsewhere. Authors are encouraged to submit papers in electronic form, postscript or PDF only. The page limit for submissions is 15 pages (1.5 line spaced, excluding references, figures and tables). More details on submission procedures will be posted on the official PerCom website: http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. Conference proceedings will be published by IEEE. Papers of particular merit will be considered for publication in a special issue of a leading journal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Important Dates/Deadlines: Paper Submissions: October 1, 2002 Acceptance Notification: December 10, 2002 Camera Ready Manuscripts: January 10, 2003 Conference Dates: March 23-26, 2003 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Organizing Committee: General Chair Behrooz A. Shirazi University of Texas at Arlington General Vice Chair: Sajal K. Das University of Texas at Arlington Technical Program Committee Chair Mohan Kumar University of Texas at Arlington Local Chair: Gergely V. Záruba University of Texas at Arlington Finance Chair: David Levine University of Texas at Arlington Intelligent Environments Track Chair: Diane Cook University of Texas at Arlington Tutorials Chair: Azzedine Boukerche University of North Texas Industry Liaison: Kalyan Basu University of Texas at Arlington Publicity Chairs: Stefano Basagni Northeastern University Chiara Petrioli University of Rome Albert Zomaya University of Sydney Technical Program Committee: (Under Creation) Giuseppe Anastasi University of Pisa, Italy Jean Bacon University of Cambridge, UK Chatschik Bisdikian, IBM, USA Lisa Burnell, Texas Christian University, USA Liang Cheng, Lehigh University, USA Marco Conti, National Research Council, Italy Diane Cook, University of Texas at Arlington, USA Antonio Corradi, University of Bologna, Italy Jason Flinn, Carnegie Mellon University, USA Robert Gray, Dartmouth College, USA Liviu Iftode, Rutgers University, USA Archan Misra, IBM Center, USA Yannis Labrou, Fujitsu, USA Mohan Kumar, University of Texas at Arlington, USA Phil McKinley Michigan State University, USA Paddy Nixon, The University of Strathclyde, UK Gian Pietro, Dipartimento di Elettronica e Informazione, Italy Caluligi Raghavendra, University of Southern California, USA Ichiro Satoh, National Institute of Informatics, Japan Steven Shafer, Microsoft Corporation, USA HJ Siegel, Colorado State University, USA Anand Tripathi, University of Minnesota, USA Mohan Trivedi, University of California, San Diego, USA Ty Znati, University of Pittsburg, USA -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntigton Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jul 5 10:13:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26285 for ; Fri, 5 Jul 2002 10:13:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02273; Fri, 5 Jul 2002 09:40:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02244 for ; Fri, 5 Jul 2002 09:40:28 -0400 (EDT) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24768 for ; Fri, 5 Jul 2002 09:39:36 -0400 (EDT) Received: from [134.102.101.207] (helo=manet) by smtp.web.de with smtp (WEB.DE(Exim) 4.70 #5) id 17QTJU-000795-00 for manet@ietf.org; Fri, 05 Jul 2002 15:39:56 +0200 Message-ID: <001e01c22429$8dbb0be0$cf656686@vorstrasse.unibremen.de> From: "Michael Sessinghaus" To: Date: Fri, 5 Jul 2002 15:40:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C2243A.4F90FBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] AODV and Mobile IP References Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C2243A.4F90FBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi people, Has any research been done on simulation of aodv and mobile ip to assure = connectivity to internet? Any ns-simulation (tcl scripts) and references? Thanks for your Help Best regards, Michael. ------=_NextPart_000_001B_01C2243A.4F90FBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi people,
 
Has any research been done on simulation of aodv and mobile ip to = assure=20 connectivity to internet?
Any ns-simulation (tcl scripts) and references?
 
Thanks for your Help
 
Best regards, Michael.
 
------=_NextPart_000_001B_01C2243A.4F90FBC0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jul 5 10:13:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26291 for ; Fri, 5 Jul 2002 10:13:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04232 for manet-archive@odin.ietf.org; Fri, 5 Jul 2002 10:14:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02273; Fri, 5 Jul 2002 09:40:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02244 for ; Fri, 5 Jul 2002 09:40:28 -0400 (EDT) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24768 for ; Fri, 5 Jul 2002 09:39:36 -0400 (EDT) Received: from [134.102.101.207] (helo=manet) by smtp.web.de with smtp (WEB.DE(Exim) 4.70 #5) id 17QTJU-000795-00 for manet@ietf.org; Fri, 05 Jul 2002 15:39:56 +0200 Message-ID: <001e01c22429$8dbb0be0$cf656686@vorstrasse.unibremen.de> From: "Michael Sessinghaus" To: Date: Fri, 5 Jul 2002 15:40:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C2243A.4F90FBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] AODV and Mobile IP References Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C2243A.4F90FBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi people, Has any research been done on simulation of aodv and mobile ip to assure = connectivity to internet? Any ns-simulation (tcl scripts) and references? Thanks for your Help Best regards, Michael. ------=_NextPart_000_001B_01C2243A.4F90FBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi people,
 
Has any research been done on simulation of aodv and mobile ip to = assure=20 connectivity to internet?
Any ns-simulation (tcl scripts) and references?
 
Thanks for your Help
 
Best regards, Michael.
 
------=_NextPart_000_001B_01C2243A.4F90FBC0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Jul 5 14:18:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08392 for ; Fri, 5 Jul 2002 14:17:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15925; Fri, 5 Jul 2002 13:51:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15899 for ; Fri, 5 Jul 2002 13:51:37 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06601 for ; Fri, 5 Jul 2002 13:50:46 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddd37e.tkyoac00.ap.so-net.ne.jp [218.221.211.126]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g65Hp3fg011035; Sat, 6 Jul 2002 02:51:04 +0900 Date: Sat, 06 Jul 2002 02:49:01 +0900 Message-ID: From: Ryuji Wakikawa To: sessinghaus@web.de Cc: manet@ietf.org Subject: Re: [manet] AODV and Mobile IP References In-Reply-To: <001e01c22429$8dbb0be0$cf656686@vorstrasse.unibremen.de> References: <001e01c22429$8dbb0be0$cf656686@vorstrasse.unibremen.de> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Michael. We are working on this and have drafts about internet connectivity (IPv6) for manet. Please check the draft here. http://search.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-01.txt We have already implemented the system (AODV6 + global6-draft) on Linux and make sure to provide internet connectivity to mobile node and to general nodes from manet. I am also implementing AODV6+global6-draft on ANY-BSD+kamestack. I hope it will be soon available in public. We also simulate the system (not test MIP6 case). Prof.Elizabeth Belding-Royer is working on IPv4 connectivity for manet. http://www.cs.ucsb.edu/~eroyer/txt/globalv4.txt The draft for address auto-configuration in manet is also available. http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt best regards, ryuji At Fri, 5 Jul 2002 15:40:38 +0200, Michael Sessinghaus wrote: > > [1 ] > Hi people, > > Has any research been done on simulation of aodv and mobile ip to assure connectivity to internet? > Any ns-simulation (tcl scripts) and references? > > Thanks for your Help > > Best regards, Michael. > > [2 ] > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Jul 5 14:18:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08401 for ; Fri, 5 Jul 2002 14:18:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17716 for manet-archive@odin.ietf.org; Fri, 5 Jul 2002 14:18:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15925; Fri, 5 Jul 2002 13:51:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15899 for ; Fri, 5 Jul 2002 13:51:37 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06601 for ; Fri, 5 Jul 2002 13:50:46 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddd37e.tkyoac00.ap.so-net.ne.jp [218.221.211.126]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g65Hp3fg011035; Sat, 6 Jul 2002 02:51:04 +0900 Date: Sat, 06 Jul 2002 02:49:01 +0900 Message-ID: From: Ryuji Wakikawa To: sessinghaus@web.de Cc: manet@ietf.org Subject: Re: [manet] AODV and Mobile IP References In-Reply-To: <001e01c22429$8dbb0be0$cf656686@vorstrasse.unibremen.de> References: <001e01c22429$8dbb0be0$cf656686@vorstrasse.unibremen.de> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Michael. We are working on this and have drafts about internet connectivity (IPv6) for manet. Please check the draft here. http://search.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-01.txt We have already implemented the system (AODV6 + global6-draft) on Linux and make sure to provide internet connectivity to mobile node and to general nodes from manet. I am also implementing AODV6+global6-draft on ANY-BSD+kamestack. I hope it will be soon available in public. We also simulate the system (not test MIP6 case). Prof.Elizabeth Belding-Royer is working on IPv4 connectivity for manet. http://www.cs.ucsb.edu/~eroyer/txt/globalv4.txt The draft for address auto-configuration in manet is also available. http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt best regards, ryuji At Fri, 5 Jul 2002 15:40:38 +0200, Michael Sessinghaus wrote: > > [1 ] > Hi people, > > Has any research been done on simulation of aodv and mobile ip to assure connectivity to internet? > Any ns-simulation (tcl scripts) and references? > > Thanks for your Help > > Best regards, Michael. > > [2 ] > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Jul 6 11:01:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22813 for ; Sat, 6 Jul 2002 11:01:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11099; Sat, 6 Jul 2002 10:29:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11072 for ; Sat, 6 Jul 2002 10:29:50 -0400 (EDT) Received: from hawk.cs.ucla.edu (Hawk.CS.UCLA.EDU [131.179.128.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22187 for ; Sat, 6 Jul 2002 10:28:59 -0400 (EDT) Received: from onr8 (ts18-95.dialup.bol.ucla.edu [164.67.35.104]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with SMTP id g66ET7l12877 for ; Sat, 6 Jul 2002 07:29:07 -0700 (PDT) Message-ID: <001801c224f8$fb8482d0$682343a4@onr8> From: "Mario Gerla" To: Date: Sat, 6 Jul 2002 07:25:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C224BE.4E481C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [manet] med-hoc-net deadline extension Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C224BE.4E481C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The submission deadline to=20 **** Med-Hoc-Net 2002 **** is extended to=20 *** July 12, 2002. *** Our apologies if you receive multiple copies of this message.=20 The CFP can be found at=20 http://www.med-hoc-net.org The First Annual Mediterranean Ad Hoc Networking Workshop,Med-hoc-Net 2002, sponsored by IFIP, will take place in Hotel Chia Laguna ( http://www.hotelchialaguna.com ), Sardegna, Italy, Sept4-6,2002. =20 The aim of the Med-hoc-Net Workshop is to bring together researchers from both sides of the Atlantic (and Pacific) to the shores of the Mediterranean sea. The Workshop will serve as a forum for ad hoc network technologists and visionaries from academia, industry and research labs, to present current research, advanced technology, ongoing prototyping efforts, experience reports, case studies, and descriptions of innovative ad hoc systems.=20 Each offering of the Workshop will have a different theme.=20 The specific theme this year will be "Quality of Service" in ad hoc networks.=20 The best papers will be published in a special issue of the ACM WINET Journal =20 Invited speaker: Leonard Kleinrock(UCLA)=20 Topics will include (but are not limited to) :=20 QoS-Oriented multi-hop mobile network architectures, Intserv, Diffserv, MPLS etc. protocols =20 over AdHoc networks=20 QoS support in Bluetooth, HomeR, HIPERLAN, IEEE 802.11 etc.=20 Multimedia applications Middleware for support in Ad Hoc networks and real-time transports over Ad Hoc networks=20 Unicast and multicast routing in ad hoc multi-hop wireless networks=20 Resource discovery and network reconfiguration=20 Multimedia location services=20 Scheduling, radio resource sharing and MAC protocols for multi hop networks=20 Call admission and traffic control policies for ad hoc networks=20 Power management and control algorithms=20 Fault tolerance and error recovery=20 Interconnection between Ad Hoc and wired networks=20 Congestion control=20 Ad Hoc TCP implementations=20 Fair sharing between different traffic classes=20 Performance evaluation of QoS-oriented protocols, middleware and applications via measurement, analytical models or simulation=20 QoS enabling ad hoc network prototypes=20 Signal processing algorithms (coding, compression) for Ad Hoc networks=20 Security in Ad Hoc networks=20 General Chairs :=20 Mario Gerla and Guy Pujolle=20 Technical Program Chair :=20 Khaldoun Al Agha (LRI, France)=20 Technical Program Committee :=20 Arve Aagesen Norvegian University, Norway) Hossam Afifi (INT, France)=20 Ian Akyildiz (Georgia Tech, USA)=20 Khaldoun Al Agha(LRI, France)=20 Hamid Aghvami (King's College London, UK)=20 Roberto Battiti (University of Trento, Italy)=20 Elizabeth Belding-Royer (UCSB, USA)=20 Raouf Boutaba (Waterloo, Canada)=20 Otto Duarte (UFRJ, Brazil)=20 Anne Fladenmuller (LIP6, France)=20 Jean-Pierre Hubaux (EPFL, Switzerland)=20 Philippe Jacquet (INRIA, France)=20 Farouk Kamoun (ENSI, Tunis, Tunisia)=20 Parviz Kermani (IBM, USA)=20 Ulf K=F6rner(Lund University, Sweden)=20 G=E9rard Le Lann (INRIA, France)=20 Daniela Maniezzo (UCLA, USA)=20 Gianluca Mazzini (University of Ferrara, Italy)=20 Lazaros Merakos (University of Athens, Greece)=20 Guy Omidyar (CWC, Singapure)=20 Sergio Palazzo (University of Catania, Italy)=20 Giovanni Pau (UCLA, USA)=20 Kimmo Raatikainen (Univ. of Helsinki, Finland)=20 Tomas Robles (Univ. of Madrid - DIM, Spain)=20 Jan Slavik (Testcom,CZ)=20 Sami Tabbabe (Sup Com) Samir Tohm=E9 (ENST, France)=20 Franco Vatalaro (University of Rome) Bernhard Walke (Univ of Aachen, Germany) ------=_NextPart_000_0015_01C224BE.4E481C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The = submission deadline to=20

****  Med-Hoc-Net 2002  ****

is extended to =

***=20 July 12, 2002. ***

Our apologies if you receive multiple copies = of this=20 message.

The CFP can be found at

 http://www.med-hoc-net.org

The=20 First Annual Mediterranean Ad Hoc Networking = Workshop,Med-hoc-Net
2002,=20 sponsored by IFIP, will take place in Hotel Chia Laguna (
http://www.hotelchialaguna.com ),=20 Sardegna, Italy,=20 Sept4-6,2002.
         &n= bsp;           &nb= sp;=20
The aim of the Med-hoc-Net Workshop is to bring together = researchers
from=20 both sides of the Atlantic (and Pacific) to the shores of = the
Mediterranean=20 sea. The Workshop will serve as a forum for ad hoc = network
technologists and=20 visionaries from academia, industry and research labs,
to present = current=20 research, advanced technology, ongoing prototyping
efforts, = experience=20 reports, case studies, and descriptions of
innovative ad hoc systems. =
Each offering of the Workshop will have a different theme.
The = specific=20 theme this year will be "Quality of Service" in ad hoc
networks.=20


The best papers will be published in a special issue of the = ACM=20 WINET
Journal 

Invited speaker: Leonard Kleinrock(UCLA)=20


Topics will include (but are not limited to) : =

QoS-Oriented=20 multi-hop mobile network architectures, Intserv, Diffserv,
MPLS etc.=20 protocols  
over AdHoc networks

QoS support in = Bluetooth,=20 HomeR, HIPERLAN, IEEE 802.11 etc.

Multimedia applications = Middleware for=20 support in Ad Hoc networks and
real-time transports over Ad Hoc = networks=20

Unicast and multicast routing in ad hoc multi-hop wireless = networks=20

Resource discovery and network reconfiguration =

Multimedia=20 location services

Scheduling, radio resource sharing and MAC = protocols=20 for multi hop
networks

Call admission and traffic control = policies=20 for ad hoc networks

Power management and control algorithms=20

Fault tolerance and error recovery

Interconnection = between Ad=20 Hoc and wired networks

Congestion control

Ad Hoc TCP=20 implementations

Fair sharing between different traffic classes=20

Performance evaluation of QoS-oriented protocols, middleware=20 and
applications via measurement, analytical models or simulation =

QoS=20 enabling ad hoc network prototypes

Signal processing algorithms = (coding,=20 compression) for Ad Hoc networks

Security in Ad Hoc networks=20


General Chairs :
Mario Gerla and Guy Pujolle =

Technical=20 Program Chair :
Khaldoun Al Agha (LRI, France)

Technical = Program=20 Committee :

Arve Aagesen Norvegian University, Norway)
Hossam = Afifi=20 (INT, France)
Ian Akyildiz (Georgia Tech, USA)
Khaldoun Al = Agha(LRI,=20 France)
Hamid Aghvami (King's College London, UK)
Roberto = Battiti=20 (University of Trento, Italy)
Elizabeth Belding-Royer (UCSB, USA) =
Raouf=20 Boutaba (Waterloo, Canada)
Otto Duarte (UFRJ, Brazil)
Anne = Fladenmuller=20 (LIP6, France)
Jean-Pierre Hubaux (EPFL, Switzerland)
Philippe = Jacquet=20 (INRIA, France)
Farouk Kamoun (ENSI, Tunis, Tunisia)
Parviz = Kermani=20 (IBM, USA)
Ulf K=F6rner(Lund University, Sweden)
G=E9rard Le = Lann (INRIA,=20 France)
Daniela Maniezzo (UCLA, USA)
Gianluca Mazzini = (University of=20 Ferrara, Italy)
Lazaros Merakos (University of Athens, Greece) =
Guy=20 Omidyar (CWC, Singapure)
Sergio Palazzo (University of Catania, = Italy)=20
Giovanni Pau (UCLA, USA)
Kimmo Raatikainen (Univ. of Helsinki, = Finland)=20
Tomas Robles (Univ. of Madrid - DIM, Spain)
Jan Slavik = (Testcom,CZ)=20
Sami Tabbabe (Sup Com)
Samir Tohm=E9 (ENST, France)
Franco = Vatalaro=20 (University of Rome)
Bernhard Walke (Univ of Aachen,=20 Germany)


------=_NextPart_000_0015_01C224BE.4E481C10-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Jul 6 11:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22821 for ; Sat, 6 Jul 2002 11:01:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13315 for manet-archive@odin.ietf.org; Sat, 6 Jul 2002 11:02:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11099; Sat, 6 Jul 2002 10:29:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11072 for ; Sat, 6 Jul 2002 10:29:50 -0400 (EDT) Received: from hawk.cs.ucla.edu (Hawk.CS.UCLA.EDU [131.179.128.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22187 for ; Sat, 6 Jul 2002 10:28:59 -0400 (EDT) Received: from onr8 (ts18-95.dialup.bol.ucla.edu [164.67.35.104]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with SMTP id g66ET7l12877 for ; Sat, 6 Jul 2002 07:29:07 -0700 (PDT) Message-ID: <001801c224f8$fb8482d0$682343a4@onr8> From: "Mario Gerla" To: Date: Sat, 6 Jul 2002 07:25:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C224BE.4E481C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [manet] med-hoc-net deadline extension Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C224BE.4E481C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The submission deadline to=20 **** Med-Hoc-Net 2002 **** is extended to=20 *** July 12, 2002. *** Our apologies if you receive multiple copies of this message.=20 The CFP can be found at=20 http://www.med-hoc-net.org The First Annual Mediterranean Ad Hoc Networking Workshop,Med-hoc-Net 2002, sponsored by IFIP, will take place in Hotel Chia Laguna ( http://www.hotelchialaguna.com ), Sardegna, Italy, Sept4-6,2002. =20 The aim of the Med-hoc-Net Workshop is to bring together researchers from both sides of the Atlantic (and Pacific) to the shores of the Mediterranean sea. The Workshop will serve as a forum for ad hoc network technologists and visionaries from academia, industry and research labs, to present current research, advanced technology, ongoing prototyping efforts, experience reports, case studies, and descriptions of innovative ad hoc systems.=20 Each offering of the Workshop will have a different theme.=20 The specific theme this year will be "Quality of Service" in ad hoc networks.=20 The best papers will be published in a special issue of the ACM WINET Journal =20 Invited speaker: Leonard Kleinrock(UCLA)=20 Topics will include (but are not limited to) :=20 QoS-Oriented multi-hop mobile network architectures, Intserv, Diffserv, MPLS etc. protocols =20 over AdHoc networks=20 QoS support in Bluetooth, HomeR, HIPERLAN, IEEE 802.11 etc.=20 Multimedia applications Middleware for support in Ad Hoc networks and real-time transports over Ad Hoc networks=20 Unicast and multicast routing in ad hoc multi-hop wireless networks=20 Resource discovery and network reconfiguration=20 Multimedia location services=20 Scheduling, radio resource sharing and MAC protocols for multi hop networks=20 Call admission and traffic control policies for ad hoc networks=20 Power management and control algorithms=20 Fault tolerance and error recovery=20 Interconnection between Ad Hoc and wired networks=20 Congestion control=20 Ad Hoc TCP implementations=20 Fair sharing between different traffic classes=20 Performance evaluation of QoS-oriented protocols, middleware and applications via measurement, analytical models or simulation=20 QoS enabling ad hoc network prototypes=20 Signal processing algorithms (coding, compression) for Ad Hoc networks=20 Security in Ad Hoc networks=20 General Chairs :=20 Mario Gerla and Guy Pujolle=20 Technical Program Chair :=20 Khaldoun Al Agha (LRI, France)=20 Technical Program Committee :=20 Arve Aagesen Norvegian University, Norway) Hossam Afifi (INT, France)=20 Ian Akyildiz (Georgia Tech, USA)=20 Khaldoun Al Agha(LRI, France)=20 Hamid Aghvami (King's College London, UK)=20 Roberto Battiti (University of Trento, Italy)=20 Elizabeth Belding-Royer (UCSB, USA)=20 Raouf Boutaba (Waterloo, Canada)=20 Otto Duarte (UFRJ, Brazil)=20 Anne Fladenmuller (LIP6, France)=20 Jean-Pierre Hubaux (EPFL, Switzerland)=20 Philippe Jacquet (INRIA, France)=20 Farouk Kamoun (ENSI, Tunis, Tunisia)=20 Parviz Kermani (IBM, USA)=20 Ulf K=F6rner(Lund University, Sweden)=20 G=E9rard Le Lann (INRIA, France)=20 Daniela Maniezzo (UCLA, USA)=20 Gianluca Mazzini (University of Ferrara, Italy)=20 Lazaros Merakos (University of Athens, Greece)=20 Guy Omidyar (CWC, Singapure)=20 Sergio Palazzo (University of Catania, Italy)=20 Giovanni Pau (UCLA, USA)=20 Kimmo Raatikainen (Univ. of Helsinki, Finland)=20 Tomas Robles (Univ. of Madrid - DIM, Spain)=20 Jan Slavik (Testcom,CZ)=20 Sami Tabbabe (Sup Com) Samir Tohm=E9 (ENST, France)=20 Franco Vatalaro (University of Rome) Bernhard Walke (Univ of Aachen, Germany) ------=_NextPart_000_0015_01C224BE.4E481C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The = submission deadline to=20

****  Med-Hoc-Net 2002  ****

is extended to =

***=20 July 12, 2002. ***

Our apologies if you receive multiple copies = of this=20 message.

The CFP can be found at

 http://www.med-hoc-net.org

The=20 First Annual Mediterranean Ad Hoc Networking = Workshop,Med-hoc-Net
2002,=20 sponsored by IFIP, will take place in Hotel Chia Laguna (
http://www.hotelchialaguna.com ),=20 Sardegna, Italy,=20 Sept4-6,2002.
         &n= bsp;           &nb= sp;=20
The aim of the Med-hoc-Net Workshop is to bring together = researchers
from=20 both sides of the Atlantic (and Pacific) to the shores of = the
Mediterranean=20 sea. The Workshop will serve as a forum for ad hoc = network
technologists and=20 visionaries from academia, industry and research labs,
to present = current=20 research, advanced technology, ongoing prototyping
efforts, = experience=20 reports, case studies, and descriptions of
innovative ad hoc systems. =
Each offering of the Workshop will have a different theme.
The = specific=20 theme this year will be "Quality of Service" in ad hoc
networks.=20


The best papers will be published in a special issue of the = ACM=20 WINET
Journal 

Invited speaker: Leonard Kleinrock(UCLA)=20


Topics will include (but are not limited to) : =

QoS-Oriented=20 multi-hop mobile network architectures, Intserv, Diffserv,
MPLS etc.=20 protocols  
over AdHoc networks

QoS support in = Bluetooth,=20 HomeR, HIPERLAN, IEEE 802.11 etc.

Multimedia applications = Middleware for=20 support in Ad Hoc networks and
real-time transports over Ad Hoc = networks=20

Unicast and multicast routing in ad hoc multi-hop wireless = networks=20

Resource discovery and network reconfiguration =

Multimedia=20 location services

Scheduling, radio resource sharing and MAC = protocols=20 for multi hop
networks

Call admission and traffic control = policies=20 for ad hoc networks

Power management and control algorithms=20

Fault tolerance and error recovery

Interconnection = between Ad=20 Hoc and wired networks

Congestion control

Ad Hoc TCP=20 implementations

Fair sharing between different traffic classes=20

Performance evaluation of QoS-oriented protocols, middleware=20 and
applications via measurement, analytical models or simulation =

QoS=20 enabling ad hoc network prototypes

Signal processing algorithms = (coding,=20 compression) for Ad Hoc networks

Security in Ad Hoc networks=20


General Chairs :
Mario Gerla and Guy Pujolle =

Technical=20 Program Chair :
Khaldoun Al Agha (LRI, France)

Technical = Program=20 Committee :

Arve Aagesen Norvegian University, Norway)
Hossam = Afifi=20 (INT, France)
Ian Akyildiz (Georgia Tech, USA)
Khaldoun Al = Agha(LRI,=20 France)
Hamid Aghvami (King's College London, UK)
Roberto = Battiti=20 (University of Trento, Italy)
Elizabeth Belding-Royer (UCSB, USA) =
Raouf=20 Boutaba (Waterloo, Canada)
Otto Duarte (UFRJ, Brazil)
Anne = Fladenmuller=20 (LIP6, France)
Jean-Pierre Hubaux (EPFL, Switzerland)
Philippe = Jacquet=20 (INRIA, France)
Farouk Kamoun (ENSI, Tunis, Tunisia)
Parviz = Kermani=20 (IBM, USA)
Ulf K=F6rner(Lund University, Sweden)
G=E9rard Le = Lann (INRIA,=20 France)
Daniela Maniezzo (UCLA, USA)
Gianluca Mazzini = (University of=20 Ferrara, Italy)
Lazaros Merakos (University of Athens, Greece) =
Guy=20 Omidyar (CWC, Singapure)
Sergio Palazzo (University of Catania, = Italy)=20
Giovanni Pau (UCLA, USA)
Kimmo Raatikainen (Univ. of Helsinki, = Finland)=20
Tomas Robles (Univ. of Madrid - DIM, Spain)
Jan Slavik = (Testcom,CZ)=20
Sami Tabbabe (Sup Com)
Samir Tohm=E9 (ENST, France)
Franco = Vatalaro=20 (University of Rome)
Bernhard Walke (Univ of Aachen,=20 Germany)


------=_NextPart_000_0015_01C224BE.4E481C10-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Jul 6 12:02:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24148 for ; Sat, 6 Jul 2002 12:02:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14376; Sat, 6 Jul 2002 11:34:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14346 for ; Sat, 6 Jul 2002 11:34:16 -0400 (EDT) Received: from einstmob (lsanca1-ar8-039-054.lsanca1.dsl-verizon.net [4.35.39.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23568 for ; Sat, 6 Jul 2002 11:33:24 -0400 (EDT) Received: from einstmob ([127.0.0.1]) by einstmob (Kerio MailServer 5.0.5) for manet@ietf.org; Sat, 6 Jul 2002 08:33:36 -0700 Reply-To: From: "Giovanni Pau" To: Date: Sat, 6 Jul 2002 08:33:36 -0700 Organization: UCLA Message-ID: <001101c22502$7ee11e00$1464a8c0@einstmob> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14347 Subject: [manet] Med-Hoc-Net DEADLINE EXTENSION July 12th Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit The submission deadline to **** Med-Hoc-Net 2002 **** is extended to *** July 12, 2002. *** Our apologies if you receive multiple copies of this message. The CFP can be found at http://www.med-hoc-net.org The First Annual Mediterranean Ad Hoc Networking Workshop,Med-hoc-Net 2002, sponsored by IFIP, will take place in Hotel Chia Laguna ( http://www.hotelchialaguna.com ), Sardegna, Italy, Sept4-6,2002. The aim of the Med-hoc-Net Workshop is to bring together researchers from both sides of the Atlantic (and Pacific) to the shores of the Mediterranean sea. The Workshop will serve as a forum for ad hoc network technologists and visionaries from academia, industry and research labs, to present current research, advanced technology, ongoing prototyping efforts, experience reports, case studies, and descriptions of innovative ad hoc systems. Each offering of the Workshop will have a different theme. The specific theme this year will be “Quality of Service” in ad hoc networks. The best papers will be published in a special issue of the ACM WINET Journal Invited speaker: Leonard Kleinrock(UCLA) Topics will include (but are not limited to) : QoS-Oriented multi-hop mobile network architectures, Intserv, Diffserv, MPLS etc. protocols over AdHoc networks QoS support in Bluetooth, HomeR, HIPERLAN, IEEE 802.11 etc. Multimedia applications Middleware for support in Ad Hoc networks and real-time transports over Ad Hoc networks Unicast and multicast routing in ad hoc multi-hop wireless networks Resource discovery and network reconfiguration Multimedia location services Scheduling, radio resource sharing and MAC protocols for multi hop networks Call admission and traffic control policies for ad hoc networks Power management and control algorithms Fault tolerance and error recovery Interconnection between Ad Hoc and wired networks Congestion control Ad Hoc TCP implementations Fair sharing between different traffic classes Performance evaluation of QoS-oriented protocols, middleware and applications via measurement, analytical models or simulation QoS enabling ad hoc network prototypes Signal processing algorithms (coding, compression) for Ad Hoc networks Security in Ad Hoc networks General Chairs : Mario Gerla and Guy Pujolle Technical Program Chair : Khaldoun Al Agha (LRI, France) Technical Program Committee : Arve Aagesen Norvegian University, Norway) Hossam Afifi (INT, France) Ian Akyildiz (Georgia Tech, USA) Khaldoun Al Agha(LRI, France) Hamid Aghvami (King's College London, UK) Roberto Battiti (University of Trento, Italy) Elizabeth Belding-Royer (UCSB, USA) Raouf Boutaba (Waterloo, Canada) Otto Duarte (UFRJ, Brazil) Anne Fladenmuller (LIP6, France) Jean-Pierre Hubaux (EPFL, Switzerland) Philippe Jacquet (INRIA, France) Farouk Kamoun (ENSI, Tunis, Tunisia) Parviz Kermani (IBM, USA) Ulf Körner(Lund University, Sweden) Gérard Le Lann (INRIA, France) Daniela Maniezzo (UCLA, USA) Gianluca Mazzini (University of Ferrara, Italy) Lazaros Merakos (University of Athens, Greece) Guy Omidyar (CWC, Singapure) Sergio Palazzo (University of Catania, Italy) Giovanni Pau (UCLA, USA) Kimmo Raatikainen (Univ. of Helsinki, Finland) Tomas Robles (Univ. of Madrid – DIM, Spain) Jan Slavik (Testcom,CZ) Sami Tabbabe (Sup Com) Samir Tohmé (ENST, France) Franco Vatalaro (University of Rome) Bernhard Walke (Univ of Aachen, Germany) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Jul 6 12:02:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24156 for ; Sat, 6 Jul 2002 12:02:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16937 for manet-archive@odin.ietf.org; Sat, 6 Jul 2002 12:03:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14376; Sat, 6 Jul 2002 11:34:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14346 for ; Sat, 6 Jul 2002 11:34:16 -0400 (EDT) Received: from einstmob (lsanca1-ar8-039-054.lsanca1.dsl-verizon.net [4.35.39.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23568 for ; Sat, 6 Jul 2002 11:33:24 -0400 (EDT) Received: from einstmob ([127.0.0.1]) by einstmob (Kerio MailServer 5.0.5) for manet@ietf.org; Sat, 6 Jul 2002 08:33:36 -0700 Reply-To: From: "Giovanni Pau" To: Date: Sat, 6 Jul 2002 08:33:36 -0700 Organization: UCLA Message-ID: <001101c22502$7ee11e00$1464a8c0@einstmob> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14347 Subject: [manet] Med-Hoc-Net DEADLINE EXTENSION July 12th Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit The submission deadline to **** Med-Hoc-Net 2002 **** is extended to *** July 12, 2002. *** Our apologies if you receive multiple copies of this message. The CFP can be found at http://www.med-hoc-net.org The First Annual Mediterranean Ad Hoc Networking Workshop,Med-hoc-Net 2002, sponsored by IFIP, will take place in Hotel Chia Laguna ( http://www.hotelchialaguna.com ), Sardegna, Italy, Sept4-6,2002. The aim of the Med-hoc-Net Workshop is to bring together researchers from both sides of the Atlantic (and Pacific) to the shores of the Mediterranean sea. The Workshop will serve as a forum for ad hoc network technologists and visionaries from academia, industry and research labs, to present current research, advanced technology, ongoing prototyping efforts, experience reports, case studies, and descriptions of innovative ad hoc systems. Each offering of the Workshop will have a different theme. The specific theme this year will be “Quality of Service” in ad hoc networks. The best papers will be published in a special issue of the ACM WINET Journal Invited speaker: Leonard Kleinrock(UCLA) Topics will include (but are not limited to) : QoS-Oriented multi-hop mobile network architectures, Intserv, Diffserv, MPLS etc. protocols over AdHoc networks QoS support in Bluetooth, HomeR, HIPERLAN, IEEE 802.11 etc. Multimedia applications Middleware for support in Ad Hoc networks and real-time transports over Ad Hoc networks Unicast and multicast routing in ad hoc multi-hop wireless networks Resource discovery and network reconfiguration Multimedia location services Scheduling, radio resource sharing and MAC protocols for multi hop networks Call admission and traffic control policies for ad hoc networks Power management and control algorithms Fault tolerance and error recovery Interconnection between Ad Hoc and wired networks Congestion control Ad Hoc TCP implementations Fair sharing between different traffic classes Performance evaluation of QoS-oriented protocols, middleware and applications via measurement, analytical models or simulation QoS enabling ad hoc network prototypes Signal processing algorithms (coding, compression) for Ad Hoc networks Security in Ad Hoc networks General Chairs : Mario Gerla and Guy Pujolle Technical Program Chair : Khaldoun Al Agha (LRI, France) Technical Program Committee : Arve Aagesen Norvegian University, Norway) Hossam Afifi (INT, France) Ian Akyildiz (Georgia Tech, USA) Khaldoun Al Agha(LRI, France) Hamid Aghvami (King's College London, UK) Roberto Battiti (University of Trento, Italy) Elizabeth Belding-Royer (UCSB, USA) Raouf Boutaba (Waterloo, Canada) Otto Duarte (UFRJ, Brazil) Anne Fladenmuller (LIP6, France) Jean-Pierre Hubaux (EPFL, Switzerland) Philippe Jacquet (INRIA, France) Farouk Kamoun (ENSI, Tunis, Tunisia) Parviz Kermani (IBM, USA) Ulf Körner(Lund University, Sweden) Gérard Le Lann (INRIA, France) Daniela Maniezzo (UCLA, USA) Gianluca Mazzini (University of Ferrara, Italy) Lazaros Merakos (University of Athens, Greece) Guy Omidyar (CWC, Singapure) Sergio Palazzo (University of Catania, Italy) Giovanni Pau (UCLA, USA) Kimmo Raatikainen (Univ. of Helsinki, Finland) Tomas Robles (Univ. of Madrid – DIM, Spain) Jan Slavik (Testcom,CZ) Sami Tabbabe (Sup Com) Samir Tohmé (ENST, France) Franco Vatalaro (University of Rome) Bernhard Walke (Univ of Aachen, Germany) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 11:53:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21007 for ; Mon, 8 Jul 2002 11:53:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24234; Mon, 8 Jul 2002 11:22:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24203 for ; Mon, 8 Jul 2002 11:22:10 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19277 for ; Mon, 8 Jul 2002 11:21:17 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117124>; Mon, 8 Jul 2002 09:21:55 -0600 Message-Id: <02Jul8.092155mdt.117124@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Cc: jomullen@nmsu.edu Date: Mon, 8 Jul 2002 09:21:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] A Measure of Throughput Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I notice in this working group's statement of scope that statistical measures of end-to-end data throughput and delay are included in measures of MANET routing protocols. I have done some work in this area and would like to see if exploration of this topic is within the scope of this working group. This following is a sketch of my approach. In measuring throughput, I took the approach that one should consider the impact of delay on the value of throughput. In addition, I tried to look at the anticipated impact of this delayed throughput on the MANET's eventual users in a way that is independent of the manner in which the MANET is implemented. In this way, one gets a measure of effectiveness that 1) combines the consideration of throughput and delay into a single measure, 2) compares different options on an equal footing and 3) is meaningful to the eventual users (who will pay for the system and want to have some idea whether or not they will be getting their money's worth). A message has two sorts of value. The first is Importance (I), which is a quantifiable estimate of the impact the message would have on the simulated evolution. The second is Timeliness (T), which describes how that impact is degraded by delay in the delivery of that message. Timeliness is a non-increasing function of the delay time (t) and differs from message to message. If a message is urgent, its T(t) decreases very quickly to zero, while less urgent messages decay more gradually. There is no necessary linkage between Timeliness and Importance. A message may be extremely urgent, but not very important. Finally, a message that is never delivered would have a timeliness of zero. Throughput can be thought of as a situation in which all messages are of equal importance and T(t) is a binary function equal to 1.0 for all finite values of t, but equal to zero at infinity. Alternatively, one can look at this weighted, time-degraded value as a refinement of throughput. The value of a delivered message is the product V(t) = IT(t). A figure of a protocol's merit would be the relative value of delivered messages, the weighted sum of actual time-affected message values divided by the same, assuming all delays were zero. Of course, this would have to be estimated over a set of standard scenarios, but that would have to be true for any measure of performance or effectiveness to have any relevancy. Although the determination of I and T(t) would be a matter for MANET users, it would be best if the models of I and T(t) were compatible with the design and evaluation carried out by MANET designers. There are also some mathematical properties one can exploit. For example, one can adopt the convention that T(0) = 1.0 and the limit as t approaches infinity of T(t) is zero. It is also reasonable to assume that dT(t)/dt <= 0 for all non-negative values of t. Models that are both determinable by MANET users and tractable by MANET designers can serve as a means of communication between the two communities. MANET users can use them to effectively communicate to designers important performance needs while MANET designers can use the same functions to communicate to users reasonable expectations of their system's performance. In my own work, I found that such functions enable designers to make intermediate design choices on the basis of user's input. Also, one can estimate the uncertainty due to the problem statement by looking at the tolerance in model parameters to determine if further analysis will be productive or not. That is, there is little value in calculating a performance measure to three decimal places when the tolerance in model parameters implies no greater precision than two. Anyhow, if there is some interest, please let me know. Thanks, John P. Mullen, Contractor Mail to: Director USATRAC-WSMR Attn: ATRC-WBC (John Mullen) White Sands Missile Range, NM 88002-5502 Phone: (505) 678-5275 DSN 258-5275 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 11:53:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21020 for ; Mon, 8 Jul 2002 11:53:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26721 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 11:54:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24234; Mon, 8 Jul 2002 11:22:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24203 for ; Mon, 8 Jul 2002 11:22:10 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19277 for ; Mon, 8 Jul 2002 11:21:17 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117124>; Mon, 8 Jul 2002 09:21:55 -0600 Message-Id: <02Jul8.092155mdt.117124@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: manet@ietf.org Cc: jomullen@nmsu.edu Date: Mon, 8 Jul 2002 09:21:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] A Measure of Throughput Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I notice in this working group's statement of scope that statistical measures of end-to-end data throughput and delay are included in measures of MANET routing protocols. I have done some work in this area and would like to see if exploration of this topic is within the scope of this working group. This following is a sketch of my approach. In measuring throughput, I took the approach that one should consider the impact of delay on the value of throughput. In addition, I tried to look at the anticipated impact of this delayed throughput on the MANET's eventual users in a way that is independent of the manner in which the MANET is implemented. In this way, one gets a measure of effectiveness that 1) combines the consideration of throughput and delay into a single measure, 2) compares different options on an equal footing and 3) is meaningful to the eventual users (who will pay for the system and want to have some idea whether or not they will be getting their money's worth). A message has two sorts of value. The first is Importance (I), which is a quantifiable estimate of the impact the message would have on the simulated evolution. The second is Timeliness (T), which describes how that impact is degraded by delay in the delivery of that message. Timeliness is a non-increasing function of the delay time (t) and differs from message to message. If a message is urgent, its T(t) decreases very quickly to zero, while less urgent messages decay more gradually. There is no necessary linkage between Timeliness and Importance. A message may be extremely urgent, but not very important. Finally, a message that is never delivered would have a timeliness of zero. Throughput can be thought of as a situation in which all messages are of equal importance and T(t) is a binary function equal to 1.0 for all finite values of t, but equal to zero at infinity. Alternatively, one can look at this weighted, time-degraded value as a refinement of throughput. The value of a delivered message is the product V(t) = IT(t). A figure of a protocol's merit would be the relative value of delivered messages, the weighted sum of actual time-affected message values divided by the same, assuming all delays were zero. Of course, this would have to be estimated over a set of standard scenarios, but that would have to be true for any measure of performance or effectiveness to have any relevancy. Although the determination of I and T(t) would be a matter for MANET users, it would be best if the models of I and T(t) were compatible with the design and evaluation carried out by MANET designers. There are also some mathematical properties one can exploit. For example, one can adopt the convention that T(0) = 1.0 and the limit as t approaches infinity of T(t) is zero. It is also reasonable to assume that dT(t)/dt <= 0 for all non-negative values of t. Models that are both determinable by MANET users and tractable by MANET designers can serve as a means of communication between the two communities. MANET users can use them to effectively communicate to designers important performance needs while MANET designers can use the same functions to communicate to users reasonable expectations of their system's performance. In my own work, I found that such functions enable designers to make intermediate design choices on the basis of user's input. Also, one can estimate the uncertainty due to the problem statement by looking at the tolerance in model parameters to determine if further analysis will be productive or not. That is, there is little value in calculating a performance measure to three decimal places when the tolerance in model parameters implies no greater precision than two. Anyhow, if there is some interest, please let me know. Thanks, John P. Mullen, Contractor Mail to: Director USATRAC-WSMR Attn: ATRC-WBC (John Mullen) White Sands Missile Range, NM 88002-5502 Phone: (505) 678-5275 DSN 258-5275 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 13:08:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25534 for ; Mon, 8 Jul 2002 13:08:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02653; Mon, 8 Jul 2002 12:40:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02590 for ; Mon, 8 Jul 2002 12:40:26 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23733 for ; Mon, 8 Jul 2002 12:39:34 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-166.sfc.wide.ad.jp [203.178.143.166]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g68Gdmfg031272; Tue, 9 Jul 2002 01:39:50 +0900 Date: Tue, 09 Jul 2002 01:39:42 +0900 Message-ID: From: Ryuji Wakikawa To: Fredrik.Alriksson@era.ericsson.se Cc: charliep@iprg.nokia.com, ryuji@sfc.wide.ad.jp, jmalinen@ipgr.nokia.com, ajtuomin@tml.hut.fi, andersn@telecom.lth.se, manet@ietf.org In-Reply-To: <1F55F6582266314A85A55F6241509B674180B7@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B674180B7@Esealnt863.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Fredrik. In the draft, unnecessary packets basically indicates un-necessary gateway advertisements. For example, if a gateway generates a route advertisement every 1 sec, most of router advertisements are redundant for manet nodes which have already had a global address. They may update lifetime of their global address, but the interval(1sec) is still too short for this operations. Since flooding packets is easy to cause performance damage in manet, our approach tries to reduce a number of packets which are flooded over manet. I think manet nodes should not wait flooded advertisements from gateway, instead manet node should discover gateways on their initiative. It is also difficult for gateways to decide TTL for flooded advertisements. Expanding ring search technique can not be applied to this situation, because advertisements should reach at the edge of manet. It can imagine that unnecessary network-wide dissemination of advertisements will occur when a gateway sets larger TTL than manet scale. regards, ryuji At Mon, 8 Jul 2002 17:27:19 +0200 , Fredrik Alriksson (EAB) wrote: > > Hi All, > > In draft-wakikawa-manet-globalv6-00.txt you claim that sending gateway advertisements peridically would generate unnecessary packets in the Manet. Can you please explain how you came to that conclusion? Our simulation study on MIPMANET from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) indicates that it actually can decrease the number of packet transmissions in the MANET. > > BR, > Fredrik > > --- > Fredrik Alriksson, Ericsson Research > Email: fredrik.alriksson@ericsson.com > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 13:08:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25543 for ; Mon, 8 Jul 2002 13:08:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05347 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 13:09:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02653; Mon, 8 Jul 2002 12:40:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02590 for ; Mon, 8 Jul 2002 12:40:26 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23733 for ; Mon, 8 Jul 2002 12:39:34 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-166.sfc.wide.ad.jp [203.178.143.166]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g68Gdmfg031272; Tue, 9 Jul 2002 01:39:50 +0900 Date: Tue, 09 Jul 2002 01:39:42 +0900 Message-ID: From: Ryuji Wakikawa To: Fredrik.Alriksson@era.ericsson.se Cc: charliep@iprg.nokia.com, ryuji@sfc.wide.ad.jp, jmalinen@ipgr.nokia.com, ajtuomin@tml.hut.fi, andersn@telecom.lth.se, manet@ietf.org In-Reply-To: <1F55F6582266314A85A55F6241509B674180B7@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B674180B7@Esealnt863.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Fredrik. In the draft, unnecessary packets basically indicates un-necessary gateway advertisements. For example, if a gateway generates a route advertisement every 1 sec, most of router advertisements are redundant for manet nodes which have already had a global address. They may update lifetime of their global address, but the interval(1sec) is still too short for this operations. Since flooding packets is easy to cause performance damage in manet, our approach tries to reduce a number of packets which are flooded over manet. I think manet nodes should not wait flooded advertisements from gateway, instead manet node should discover gateways on their initiative. It is also difficult for gateways to decide TTL for flooded advertisements. Expanding ring search technique can not be applied to this situation, because advertisements should reach at the edge of manet. It can imagine that unnecessary network-wide dissemination of advertisements will occur when a gateway sets larger TTL than manet scale. regards, ryuji At Mon, 8 Jul 2002 17:27:19 +0200 , Fredrik Alriksson (EAB) wrote: > > Hi All, > > In draft-wakikawa-manet-globalv6-00.txt you claim that sending gateway advertisements peridically would generate unnecessary packets in the Manet. Can you please explain how you came to that conclusion? Our simulation study on MIPMANET from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) indicates that it actually can decrease the number of packet transmissions in the MANET. > > BR, > Fredrik > > --- > Fredrik Alriksson, Ericsson Research > Email: fredrik.alriksson@ericsson.com > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 14:33:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00480 for ; Mon, 8 Jul 2002 14:33:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07529; Mon, 8 Jul 2002 13:36:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07483 for ; Mon, 8 Jul 2002 13:36:50 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26944 for ; Mon, 8 Jul 2002 13:35:57 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GYX00J7AY7UD1@mail.drexel.edu> for manet@ietf.org; Mon, 8 Jul 2002 13:35:54 -0400 (EDT) Date: Mon, 08 Jul 2002 13:50:03 -0400 From: Harpreet Arora Subject: RE: [manet] QoS over a wireless Ad Hoc network To: yasser.lotfy@lycos.com Cc: manet@ietf.org Message-id: <3D3011FC@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi Yasser, > >I'm very confused here. First, what do you mean the periority depends on the >service provider? Who is the service provider for ad-hoc bandwidth? I agree that in an ad hoc network there is no service provider. Well, in that case, the problem of providing QoS guarantees in an ad hoc network becomes very complex. If there is no one to bill a user for using higher bandwidth, everyone in the netwrok wud try to use the maximum bandwidth available. Then the classification of traffic into priorities in an ad hoc network makes sense only for networks where some users are more powerful than others. For example in an ad hoc network formed by laptops in a classroom, the messages from the professor can be assigned higher priority than that of students. Or, the priorities can be assigned at the application level, which cannot be modified by the user. For e.g, an email application always uses best effort traffic, and packets of voice application can always be set to receive a certain priority. > >Second, What do you mean by your classification of periorities? DiffServ rely on predefined PHB to achieve a PDB (Per Domain Behaviour). This is done by engineering the network with the help of provisioning systems, and human adminstration. How this could be solved for DiffServ is quite a challenge. It is the PHB that provides classification of priorities. The PHBs are defined such that traffic of different streams get different priorities within the queue and at the schedular. Let me know if I am wrong in my thinking here. regards, Harpreet > >I can't claim to have read your paper, I'll read it right now. > >Yasser >Carleton U > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 14:33:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00487 for ; Mon, 8 Jul 2002 14:33:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11390 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 14:34:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07529; Mon, 8 Jul 2002 13:36:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA07483 for ; Mon, 8 Jul 2002 13:36:50 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26944 for ; Mon, 8 Jul 2002 13:35:57 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GYX00J7AY7UD1@mail.drexel.edu> for manet@ietf.org; Mon, 8 Jul 2002 13:35:54 -0400 (EDT) Date: Mon, 08 Jul 2002 13:50:03 -0400 From: Harpreet Arora Subject: RE: [manet] QoS over a wireless Ad Hoc network To: yasser.lotfy@lycos.com Cc: manet@ietf.org Message-id: <3D3011FC@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi Yasser, > >I'm very confused here. First, what do you mean the periority depends on the >service provider? Who is the service provider for ad-hoc bandwidth? I agree that in an ad hoc network there is no service provider. Well, in that case, the problem of providing QoS guarantees in an ad hoc network becomes very complex. If there is no one to bill a user for using higher bandwidth, everyone in the netwrok wud try to use the maximum bandwidth available. Then the classification of traffic into priorities in an ad hoc network makes sense only for networks where some users are more powerful than others. For example in an ad hoc network formed by laptops in a classroom, the messages from the professor can be assigned higher priority than that of students. Or, the priorities can be assigned at the application level, which cannot be modified by the user. For e.g, an email application always uses best effort traffic, and packets of voice application can always be set to receive a certain priority. > >Second, What do you mean by your classification of periorities? DiffServ rely on predefined PHB to achieve a PDB (Per Domain Behaviour). This is done by engineering the network with the help of provisioning systems, and human adminstration. How this could be solved for DiffServ is quite a challenge. It is the PHB that provides classification of priorities. The PHBs are defined such that traffic of different streams get different priorities within the queue and at the schedular. Let me know if I am wrong in my thinking here. regards, Harpreet > >I can't claim to have read your paper, I'll read it right now. > >Yasser >Carleton U > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 15:01:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02909 for ; Mon, 8 Jul 2002 15:01:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11812; Mon, 8 Jul 2002 14:42:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11783 for ; Mon, 8 Jul 2002 14:42:15 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01075 for ; Mon, 8 Jul 2002 14:41:16 -0400 (EDT) Received: from cs.dartmouth.edu (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with ESMTP id g68Ig219002176; Mon, 8 Jul 2002 14:42:02 -0400 Message-ID: <3D29DCEE.5020303@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 14:41:50 -0400 From: Yougu Yuan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: manet@ietf.org CC: "Xiaowen (Jason) Liu" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MAC queuing delay Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, all, I'm doing validation of a wireless network simulation testbed, and have some problem regarding MAC 802.11. With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte packets per second per session) , we noticed that the MAC layer queuing delay in our simulation could be several hundred of millisecond or even a couple of seconds. This will break some assumptions of routing protocols and cause problems like route loops. A little bit more about the setup: in the experiment, the maximum queue length for the MAC is set to 100 packets, and the routing packets and normal packets use separate queues. A distance-fading radio propagation model is used by the physical layer. Is there some work about the MAC layer delay statistics that one can expect? If any, can someone give me a reference for that? Another related question is, if the assumption of hop-by-hop delay is broken, does any known routing protocol has a way to detect/adjust, or it just has to live with the situation? If you can spot any obvious problem with the delay we observed, please also let me know. Thanks in advance. -Yougu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 15:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02917 for ; Mon, 8 Jul 2002 15:01:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14021 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 15:02:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11812; Mon, 8 Jul 2002 14:42:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11783 for ; Mon, 8 Jul 2002 14:42:15 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01075 for ; Mon, 8 Jul 2002 14:41:16 -0400 (EDT) Received: from cs.dartmouth.edu (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with ESMTP id g68Ig219002176; Mon, 8 Jul 2002 14:42:02 -0400 Message-ID: <3D29DCEE.5020303@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 14:41:50 -0400 From: Yougu Yuan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: manet@ietf.org CC: "Xiaowen (Jason) Liu" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MAC queuing delay Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, all, I'm doing validation of a wireless network simulation testbed, and have some problem regarding MAC 802.11. With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte packets per second per session) , we noticed that the MAC layer queuing delay in our simulation could be several hundred of millisecond or even a couple of seconds. This will break some assumptions of routing protocols and cause problems like route loops. A little bit more about the setup: in the experiment, the maximum queue length for the MAC is set to 100 packets, and the routing packets and normal packets use separate queues. A distance-fading radio propagation model is used by the physical layer. Is there some work about the MAC layer delay statistics that one can expect? If any, can someone give me a reference for that? Another related question is, if the assumption of hop-by-hop delay is broken, does any known routing protocol has a way to detect/adjust, or it just has to live with the situation? If you can spot any obvious problem with the delay we observed, please also let me know. Thanks in advance. -Yougu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 15:26:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04403 for ; Mon, 8 Jul 2002 15:26:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13123; Mon, 8 Jul 2002 14:57:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13084 for ; Mon, 8 Jul 2002 14:57:33 -0400 (EDT) Received: from dhcp47.ists.dartmouth.edu (dhcp47.ISTS.dartmouth.edu [129.170.249.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02471 for ; Mon, 8 Jul 2002 14:56:40 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by dhcp47.ists.dartmouth.edu (8.11.6/8.11.6) with ESMTP id g68IuMp09600 for ; Mon, 8 Jul 2002 14:56:22 -0400 Message-ID: <3D29E056.6060203@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 14:56:22 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 CC: manet@ietf.org References: <3D29DCEE.5020303@cs.dartmouth.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Re: MAC queuing delay Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Just to make Yougu's question a bit clearer: we're validating an AODV (draft 10) implementation; we found loop routes as a result of the exaggerated MAC layer delays. We know that AODV can adjust its hop-by-hop delay parameter, but it seems unclear to us how large would be enough. Is it "normal", if the assumption is broken, we would find loop routes in AODV ? -jason. Yougu Yuan wrote: > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer queuing > delay in our simulation could be several hundred of millisecond or even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum queue > length for the MAC is set to 100 packets, and the routing packets and > normal packets use separate queues. A distance-fading radio propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is broken, > does any known routing protocol has a way to detect/adjust, or it just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, please > also let me know. > > Thanks in advance. > > -Yougu > > -- Xiaowen (Jason) Liu (jasonliu@cs.dartmouth.edu) --------------------------------------------------------------- Computer Science Department ISTS, Cybersecurity Research Group Dartmouth College Dartmouth College 6211 Sudikoff Laboratory 45 Lyme Road, Suite 201 Hanover, NH 03755 Hanover, NH 03755 Telephone: 603-646-0676 Fax: 603-646-0660 WWW Home Page: http://www.cs.dartmouth.edu/~jasonliu/ --------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 15:26:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04409 for ; Mon, 8 Jul 2002 15:26:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15947 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 15:27:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13123; Mon, 8 Jul 2002 14:57:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13084 for ; Mon, 8 Jul 2002 14:57:33 -0400 (EDT) Received: from dhcp47.ists.dartmouth.edu (dhcp47.ISTS.dartmouth.edu [129.170.249.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02471 for ; Mon, 8 Jul 2002 14:56:40 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by dhcp47.ists.dartmouth.edu (8.11.6/8.11.6) with ESMTP id g68IuMp09600 for ; Mon, 8 Jul 2002 14:56:22 -0400 Message-ID: <3D29E056.6060203@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 14:56:22 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 CC: manet@ietf.org References: <3D29DCEE.5020303@cs.dartmouth.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Re: MAC queuing delay Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Just to make Yougu's question a bit clearer: we're validating an AODV (draft 10) implementation; we found loop routes as a result of the exaggerated MAC layer delays. We know that AODV can adjust its hop-by-hop delay parameter, but it seems unclear to us how large would be enough. Is it "normal", if the assumption is broken, we would find loop routes in AODV ? -jason. Yougu Yuan wrote: > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer queuing > delay in our simulation could be several hundred of millisecond or even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum queue > length for the MAC is set to 100 packets, and the routing packets and > normal packets use separate queues. A distance-fading radio propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is broken, > does any known routing protocol has a way to detect/adjust, or it just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, please > also let me know. > > Thanks in advance. > > -Yougu > > -- Xiaowen (Jason) Liu (jasonliu@cs.dartmouth.edu) --------------------------------------------------------------- Computer Science Department ISTS, Cybersecurity Research Group Dartmouth College Dartmouth College 6211 Sudikoff Laboratory 45 Lyme Road, Suite 201 Hanover, NH 03755 Hanover, NH 03755 Telephone: 603-646-0676 Fax: 603-646-0660 WWW Home Page: http://www.cs.dartmouth.edu/~jasonliu/ --------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 15:52:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05415 for ; Mon, 8 Jul 2002 15:52:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14415; Mon, 8 Jul 2002 15:09:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14387 for ; Mon, 8 Jul 2002 15:09:33 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03369 for ; Mon, 8 Jul 2002 15:08:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA00861; Mon, 8 Jul 2002 12:08:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68J8rD03760; Mon, 8 Jul 2002 12:08:53 -0700 X-mProtect: <200207081908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfwXLbn; Mon, 08 Jul 2002 12:08:52 PDT Message-ID: <3D29E344.F0D03003@iprg.nokia.com> Date: Mon, 08 Jul 2002 12:08:52 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Yougu Yuan CC: manet@ietf.org, "Xiaowen (Jason) Liu" Subject: Re: [manet] MAC queuing delay References: <3D29DCEE.5020303@cs.dartmouth.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Yougu and Jason, This is something that needs to be fixed. I am not yet understanding how the route loops form as a result of the variable per-node delay setting. Could one of you be specific about the kinds of loops that occur, in order that we can try to devise a solution. With queues as long as 100 packets, it may be unreasonable to set that parameter to be as long as the maximum time for waiting in the queue. Then it could be that sometimes a new RREQ is transmitted by the source prematurely. But I don't see that causing any route loops. There must be something else! Thanks for any more information you can provide... Regards, Charlie P. Yougu Yuan wrote: > > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer queuing > delay in our simulation could be several hundred of millisecond or even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum queue > length for the MAC is set to 100 packets, and the routing packets and > normal packets use separate queues. A distance-fading radio propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is broken, > does any known routing protocol has a way to detect/adjust, or it just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, please > also let me know. > > Thanks in advance. > > -Yougu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 15:52:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05423 for ; Mon, 8 Jul 2002 15:52:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18692 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 15:52:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14415; Mon, 8 Jul 2002 15:09:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14387 for ; Mon, 8 Jul 2002 15:09:33 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03369 for ; Mon, 8 Jul 2002 15:08:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA00861; Mon, 8 Jul 2002 12:08:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68J8rD03760; Mon, 8 Jul 2002 12:08:53 -0700 X-mProtect: <200207081908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfwXLbn; Mon, 08 Jul 2002 12:08:52 PDT Message-ID: <3D29E344.F0D03003@iprg.nokia.com> Date: Mon, 08 Jul 2002 12:08:52 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Yougu Yuan CC: manet@ietf.org, "Xiaowen (Jason) Liu" Subject: Re: [manet] MAC queuing delay References: <3D29DCEE.5020303@cs.dartmouth.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Yougu and Jason, This is something that needs to be fixed. I am not yet understanding how the route loops form as a result of the variable per-node delay setting. Could one of you be specific about the kinds of loops that occur, in order that we can try to devise a solution. With queues as long as 100 packets, it may be unreasonable to set that parameter to be as long as the maximum time for waiting in the queue. Then it could be that sometimes a new RREQ is transmitted by the source prematurely. But I don't see that causing any route loops. There must be something else! Thanks for any more information you can provide... Regards, Charlie P. Yougu Yuan wrote: > > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer queuing > delay in our simulation could be several hundred of millisecond or even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum queue > length for the MAC is set to 100 packets, and the routing packets and > normal packets use separate queues. A distance-fading radio propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is broken, > does any known routing protocol has a way to detect/adjust, or it just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, please > also let me know. > > Thanks in advance. > > -Yougu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 16:08:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06280 for ; Mon, 8 Jul 2002 16:08:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18652; Mon, 8 Jul 2002 15:52:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18624 for ; Mon, 8 Jul 2002 15:52:06 -0400 (EDT) Received: from web21008.mail.yahoo.com (web21008.mail.yahoo.com [216.136.227.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05384 for ; Mon, 8 Jul 2002 15:51:13 -0400 (EDT) Message-ID: <20020708195204.56548.qmail@web21008.mail.yahoo.com> Received: from [65.88.242.115] by web21008.mail.yahoo.com via HTTP; Mon, 08 Jul 2002 12:52:04 PDT Date: Mon, 8 Jul 2002 12:52:04 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] MAC queuing delay To: Yougu Yuan , manet@ietf.org Cc: "Xiaowen \(Jason\) Liu" , yangxiao@IEEE.ORG In-Reply-To: <3D29DCEE.5020303@cs.dartmouth.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yougu, I know little about MANET routing. However, I did a lot of IEEE 802.11 simulations, basically in MAC layer. I am not sure how you can calculate delays in IEEE 802.11 very well since delays depends a lot of factors. One important factor is the traffic load. Different traffic load will result different delays. What platform are you using? I use OPNET to do simulations. In OPNET, delays become a little difficult to calculate. The built-in delays measures in OPNET are not very accurate. In OPNET, delays involve the features of traffic generators, queue sizes, the number of nodes, and etc. My point is that you must make sure that your settings are good enough to obtain accurate delay measures. If you use OPNET, please let me know so that we can have further discussions. Regards Yang --- Yougu Yuan wrote: > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and > have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer > queuing > delay in our simulation could be several hundred of millisecond or > even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum > queue > length for the MAC is set to 100 packets, and the routing packets and > > normal packets use separate queues. A distance-fading radio > propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is > broken, > does any known routing protocol has a way to detect/adjust, or it > just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, > please > also let me know. > > Thanks in advance. > > -Yougu > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 16:08:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06288 for ; Mon, 8 Jul 2002 16:08:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20358 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 16:09:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18652; Mon, 8 Jul 2002 15:52:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18624 for ; Mon, 8 Jul 2002 15:52:06 -0400 (EDT) Received: from web21008.mail.yahoo.com (web21008.mail.yahoo.com [216.136.227.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05384 for ; Mon, 8 Jul 2002 15:51:13 -0400 (EDT) Message-ID: <20020708195204.56548.qmail@web21008.mail.yahoo.com> Received: from [65.88.242.115] by web21008.mail.yahoo.com via HTTP; Mon, 08 Jul 2002 12:52:04 PDT Date: Mon, 8 Jul 2002 12:52:04 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] MAC queuing delay To: Yougu Yuan , manet@ietf.org Cc: "Xiaowen \(Jason\) Liu" , yangxiao@IEEE.ORG In-Reply-To: <3D29DCEE.5020303@cs.dartmouth.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yougu, I know little about MANET routing. However, I did a lot of IEEE 802.11 simulations, basically in MAC layer. I am not sure how you can calculate delays in IEEE 802.11 very well since delays depends a lot of factors. One important factor is the traffic load. Different traffic load will result different delays. What platform are you using? I use OPNET to do simulations. In OPNET, delays become a little difficult to calculate. The built-in delays measures in OPNET are not very accurate. In OPNET, delays involve the features of traffic generators, queue sizes, the number of nodes, and etc. My point is that you must make sure that your settings are good enough to obtain accurate delay measures. If you use OPNET, please let me know so that we can have further discussions. Regards Yang --- Yougu Yuan wrote: > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and > have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer > queuing > delay in our simulation could be several hundred of millisecond or > even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum > queue > length for the MAC is set to 100 packets, and the routing packets and > > normal packets use separate queues. A distance-fading radio > propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is > broken, > does any known routing protocol has a way to detect/adjust, or it > just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, > please > also let me know. > > Thanks in advance. > > -Yougu > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 16:30:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07273 for ; Mon, 8 Jul 2002 16:30:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19863; Mon, 8 Jul 2002 16:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19832 for ; Mon, 8 Jul 2002 16:03:16 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05904 for ; Mon, 8 Jul 2002 16:02:22 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68K3A19004482; Mon, 8 Jul 2002 16:03:10 -0400 Message-Id: <200207082003.g68K3A19004482@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 16:02:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, "Xiaowen (Jason) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> <3D29E344.F0D03003@iprg.nokia.com> In-Reply-To: <3D29E344.F0D03003@iprg.nokia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, Prof. Perkins, Let me explain in detail how a loop can be formed within AODV if the assumption about the one hop delay is broken. I will use AODV draft 10 in the example. I haven't read draft 11 very carefully yet, but I think it won't change much on the result. In AODV, the one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and the PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. After an RREQ has been received, a node will keep a record of its originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any rreq with the same values in this period of time. So far so good. Here comes the scenario, in which I will exagerate the MAC queuing delay a little bit more to make the story shorter. 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and after some hops, it's picked up and forwarded by Node X. X created its reverse route to S and kept the rreq record as specified. Unfortunately, the request sent out by X is delayed in the MAC layer a lot, say, for 2.5 second. 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same thing as X, put a reverse route **Y->S (through X)** in its table and forwarded the request, really bad luck, it's again delayed in the MAC layer for 2.5 second. 3) So after 5 seconds, X received this RREQ(D,i) again, but this time from Y. If X were to ignore this old RREQ from Y, everything would be fine. However, at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has discarded the record for the previous RREQ(D, i), and the reverse route to S has been invalidated because its lifetime expired. Given all above conditions, X would update its reverse route to S: **X->S (through Y)**, and this created a loop because the route to S in Y was still active, and it used X as the next hop. -Yougu On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > Hello Yougu and Jason, > > This is something that needs to be fixed. I am not yet > understanding how the route loops form as a result of the > variable per-node delay setting. Could one of you be > specific about the kinds of loops that occur, in order > that we can try to devise a solution. With queues as > long as 100 packets, it may be unreasonable to set that > parameter to be as long as the maximum time for waiting > in the queue. Then it could be that sometimes a new > RREQ is transmitted by the source prematurely. But I > don't see that causing any route loops. There must be > something else! > > Thanks for any more information you can provide... > > Regards, > Charlie P. > > Yougu Yuan wrote: > > Hi, all, > > > > I'm doing validation of a wireless network simulation testbed, and have > > some problem regarding MAC 802.11. > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > packets per second per session) , we noticed that the MAC layer queuing > > delay in our simulation could be several hundred of millisecond or even > > a couple of seconds. This will break some assumptions of routing > > protocols and cause problems like route loops. > > > > A little bit more about the setup: in the experiment, the maximum queue > > length for the MAC is set to 100 packets, and the routing packets and > > normal packets use separate queues. A distance-fading radio propagation > > model is used by the physical layer. > > > > Is there some work about the MAC layer delay statistics that one can > > expect? If any, can someone give me a reference for that? Another > > related question is, if the assumption of hop-by-hop delay is broken, > > does any known routing protocol has a way to detect/adjust, or it just > > has to live with the situation? > > > > If you can spot any obvious problem with the delay we observed, please > > also let me know. > > > > Thanks in advance. > > > > -Yougu > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 16:52:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08249 for ; Mon, 8 Jul 2002 16:52:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21755; Mon, 8 Jul 2002 16:31:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21716 for ; Mon, 8 Jul 2002 16:31:19 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07315 for ; Mon, 8 Jul 2002 16:30:25 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Jul 8 13:30:29 2002 To: yasser.lotfy@lycos.com, "Harpreet Arora" Date: Mon, 08 Jul 2002 16:30:29 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] QoS over a wireless Ad Hoc network X-Sender-Ip: 206.172.157.175 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good day Arora, I believe we went through the same arguments on DiffServ work group. The main assumption you're after is that some traffic is has higher priority (based on user class). But traffic can also be classified based on (traffic type class). There are a long argument around that which ended with setting policies (adminstrator defined), aggregate traffic based on those policies, then police traffic marking. Then the second issue of viewing PHB as a priority engine is too simplistic. DiffServ domains need to be engineered using service provisioning policies to reach maximum thoughput. When applying this to a MANET like network, I have many questions as to how to provision policies in a dynamic topology environment? Yasser Carleton University --------------------------------------------------- Hi Yasser, > >I'm very confused here. First, what do you mean the periority > depends on the service provider? Who is the service provider > for ad-hoc bandwidth? I agree that in an ad hoc network there is no service provider. Well, in that case, the problem of providing QoS guarantees in an ad hoc network becomes very complex. If there is no one to bill a user for using higher bandwidth, everyone in the netwrok wud try to use the maximum bandwidth available. Then the classification of traffic into priorities in an ad hoc network makes sense only for networks where some users are more powerful than others. For example in an ad hoc network formed by laptops in a classroom, the messages from the professor can be assigned higher priority than that of students. Or, the priorities can be assigned at the application level, which cannot be modified by the user. For e.g, an email application always uses best effort traffic, and packets of voice application can always be set to receive a certain priority. > >Second, What do you mean by your classification of periorities? >DiffServ rely on predefined PHB to achieve a PDB (Per Domain >Behaviour). This is done by engineering the network with the >help of provisioning systems, and human adminstration. How >this could be solved for DiffServ is quite a challenge. It is the PHB that provides classification of priorities. The PHBs are defined such that traffic of different streams get different priorities within the queue and at the schedular. Let me know if I am wrong in my thinking here. regards, Harpreet > >I can't claim to have read your paper, I'll read it right now. > >Yasser >Carleton U > > _____________________________________________________ Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads and NoTaglines --> LYCOS MAIL PLUS. http://www.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 16:52:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08258 for ; Mon, 8 Jul 2002 16:52:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23734 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 16:53:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21755; Mon, 8 Jul 2002 16:31:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21716 for ; Mon, 8 Jul 2002 16:31:19 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07315 for ; Mon, 8 Jul 2002 16:30:25 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Jul 8 13:30:29 2002 To: yasser.lotfy@lycos.com, "Harpreet Arora" Date: Mon, 08 Jul 2002 16:30:29 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 Cc: manet@ietf.org X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] QoS over a wireless Ad Hoc network X-Sender-Ip: 206.172.157.175 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good day Arora, I believe we went through the same arguments on DiffServ work group. The main assumption you're after is that some traffic is has higher priority (based on user class). But traffic can also be classified based on (traffic type class). There are a long argument around that which ended with setting policies (adminstrator defined), aggregate traffic based on those policies, then police traffic marking. Then the second issue of viewing PHB as a priority engine is too simplistic. DiffServ domains need to be engineered using service provisioning policies to reach maximum thoughput. When applying this to a MANET like network, I have many questions as to how to provision policies in a dynamic topology environment? Yasser Carleton University --------------------------------------------------- Hi Yasser, > >I'm very confused here. First, what do you mean the periority > depends on the service provider? Who is the service provider > for ad-hoc bandwidth? I agree that in an ad hoc network there is no service provider. Well, in that case, the problem of providing QoS guarantees in an ad hoc network becomes very complex. If there is no one to bill a user for using higher bandwidth, everyone in the netwrok wud try to use the maximum bandwidth available. Then the classification of traffic into priorities in an ad hoc network makes sense only for networks where some users are more powerful than others. For example in an ad hoc network formed by laptops in a classroom, the messages from the professor can be assigned higher priority than that of students. Or, the priorities can be assigned at the application level, which cannot be modified by the user. For e.g, an email application always uses best effort traffic, and packets of voice application can always be set to receive a certain priority. > >Second, What do you mean by your classification of periorities? >DiffServ rely on predefined PHB to achieve a PDB (Per Domain >Behaviour). This is done by engineering the network with the >help of provisioning systems, and human adminstration. How >this could be solved for DiffServ is quite a challenge. It is the PHB that provides classification of priorities. The PHBs are defined such that traffic of different streams get different priorities within the queue and at the schedular. Let me know if I am wrong in my thinking here. regards, Harpreet > >I can't claim to have read your paper, I'll read it right now. > >Yasser >Carleton U > > _____________________________________________________ Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads and NoTaglines --> LYCOS MAIL PLUS. http://www.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 17:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10149 for ; Mon, 8 Jul 2002 17:07:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22382; Mon, 8 Jul 2002 16:39:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22353 for ; Mon, 8 Jul 2002 16:39:45 -0400 (EDT) Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07501 for ; Mon, 8 Jul 2002 16:38:51 -0400 (EDT) Received: from mirage (Miracle.CS.UCLA.EDU [131.179.136.76]) by cheetah.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with SMTP id g68Kcw228561; Mon, 8 Jul 2002 13:38:58 -0700 (PDT) Message-ID: <01a201c226bf$f57b6930$4820b383@mirage> From: "Kaixin Xu" To: "Yougu Yuan" , Cc: "Xiaowen \(Jason\) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 13:42:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yougu, I think hundreds of milliseconds are not a surprise. From my experience, this is due to the binary exponential backoff of IEEE 802.11 DCF. Actually you can build a Markov Chain model to calculate the average delay using the retry counter as state variable. The key point I think is that in ad hoc networks, the delay at the MAC layer is more important than queuing delay at the network layer buffers. This is partly due to the feature that the MAC layer will drop packet after 7 retries. Thus, long queue is unlikely to build up. The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If you then consider the time the backoff timer is suspended when the node sensing the media is busy and the time for transmitting the RTS and time for waitting CTS timeout several times, blah, blah. I think hundreds of ms delay is not rare. However, if you get delay in several seconds, that should not be common. I guess that means the network is really overloaded. Hope this is helpful. Kaixin ----- Original Message ----- From: "Yougu Yuan" To: Cc: "Xiaowen (Jason) Liu" Sent: Monday, July 08, 2002 11:41 AM Subject: [manet] MAC queuing delay > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer queuing > delay in our simulation could be several hundred of millisecond or even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum queue > length for the MAC is set to 100 packets, and the routing packets and > normal packets use separate queues. A distance-fading radio propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is broken, > does any known routing protocol has a way to detect/adjust, or it just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, please > also let me know. > > Thanks in advance. > > -Yougu > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 17:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10156 for ; Mon, 8 Jul 2002 17:07:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25817 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 17:08:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22382; Mon, 8 Jul 2002 16:39:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22353 for ; Mon, 8 Jul 2002 16:39:45 -0400 (EDT) Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07501 for ; Mon, 8 Jul 2002 16:38:51 -0400 (EDT) Received: from mirage (Miracle.CS.UCLA.EDU [131.179.136.76]) by cheetah.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with SMTP id g68Kcw228561; Mon, 8 Jul 2002 13:38:58 -0700 (PDT) Message-ID: <01a201c226bf$f57b6930$4820b383@mirage> From: "Kaixin Xu" To: "Yougu Yuan" , Cc: "Xiaowen \(Jason\) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 13:42:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yougu, I think hundreds of milliseconds are not a surprise. From my experience, this is due to the binary exponential backoff of IEEE 802.11 DCF. Actually you can build a Markov Chain model to calculate the average delay using the retry counter as state variable. The key point I think is that in ad hoc networks, the delay at the MAC layer is more important than queuing delay at the network layer buffers. This is partly due to the feature that the MAC layer will drop packet after 7 retries. Thus, long queue is unlikely to build up. The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If you then consider the time the backoff timer is suspended when the node sensing the media is busy and the time for transmitting the RTS and time for waitting CTS timeout several times, blah, blah. I think hundreds of ms delay is not rare. However, if you get delay in several seconds, that should not be common. I guess that means the network is really overloaded. Hope this is helpful. Kaixin ----- Original Message ----- From: "Yougu Yuan" To: Cc: "Xiaowen (Jason) Liu" Sent: Monday, July 08, 2002 11:41 AM Subject: [manet] MAC queuing delay > Hi, all, > > I'm doing validation of a wireless network simulation testbed, and have > some problem regarding MAC 802.11. > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > packets per second per session) , we noticed that the MAC layer queuing > delay in our simulation could be several hundred of millisecond or even > a couple of seconds. This will break some assumptions of routing > protocols and cause problems like route loops. > > A little bit more about the setup: in the experiment, the maximum queue > length for the MAC is set to 100 packets, and the routing packets and > normal packets use separate queues. A distance-fading radio propagation > model is used by the physical layer. > > Is there some work about the MAC layer delay statistics that one can > expect? If any, can someone give me a reference for that? Another > related question is, if the assumption of hop-by-hop delay is broken, > does any known routing protocol has a way to detect/adjust, or it just > has to live with the situation? > > If you can spot any obvious problem with the delay we observed, please > also let me know. > > Thanks in advance. > > -Yougu > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 17:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10468 for ; Mon, 8 Jul 2002 17:13:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22880; Mon, 8 Jul 2002 16:43:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22744 for ; Mon, 8 Jul 2002 16:43:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07656 for ; Mon, 8 Jul 2002 16:42:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA05387; Mon, 8 Jul 2002 13:43:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68Kh7J10359; Mon, 8 Jul 2002 13:43:07 -0700 X-mProtect: <200207082043> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeaGWgi; Mon, 08 Jul 2002 13:43:04 PDT Message-ID: <3D29F958.DCA71B38@iprg.nokia.com> Date: Mon, 08 Jul 2002 13:43:04 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: yuanyg@cs.dartmouth.edu CC: manet@ietf.org Subject: Re: [manet] MAC queuing delay References: <3D29DCEE.5020303@cs.dartmouth.edu> <3D29E344.F0D03003@iprg.nokia.com> <200207082003.g68K3A19004482@cs.dartmouth.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Yougu, If I may summarize, the route loop is caused if a node forgets about the RREQ too soon, and then sets up the reverse route through a neighbor to whom it had recently transmitted the RREQ. The solution to this problem is to require nodes to remember the RRED_ID for a long time. This time can be made very long, at the cost of increased memory requirement. But I think the extra memory is a matter of a few dozen bytes, and that's not so terrible. Maybe we should re-institute the "RREQ_RECORD_TIME", and cause it to be (10 * PATH_DISCOVERY_TIME). Would you be willing to try this in your simulation to see if it fixes the problem? Also, I think it is worthwhile to observe that this is a basic problem with any flooding scheme. In the scenario you describe, node X would not only set up the reverse route incorrectly, but it would also retransmit the RREQ. All of X's neighbors that had themselves forgotten about the RREQ, would react similarly. In other reasonable flooding schemes, there will typically be some other parameter that has exactly the same functionality of the RREQ_ID. The RREQ_ID really has to be remembered for a long-enough time so that this cannot happen. Regards, Charlie P. Yougu Yuan wrote: > > Hi, Prof. Perkins, > > Let me explain in detail how a loop can be formed within AODV if the > assumption about the one hop delay is broken. > > I will use AODV draft 10 in the example. I haven't read draft 11 very > carefully yet, but I think it won't change much on the result. In AODV, the > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and the > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > After an RREQ has been received, a node will keep a record of its > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > rreq with the same values in this period of time. So far so good. > > Here comes the scenario, in which I will exagerate the MAC queuing delay a > little bit more to make the story shorter. > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > after some hops, it's picked up and forwarded by Node X. X created its > reverse route to S and kept the rreq record as specified. Unfortunately, the > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 second. > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > thing as X, put a reverse route **Y->S (through X)** in its table and > forwarded the request, really bad luck, it's again delayed in the MAC layer > for 2.5 second. > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time from Y. > If X were to ignore this old RREQ from Y, everything would be fine. However, > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has discarded > the record for the previous RREQ(D, i), and the reverse route to S has been > invalidated because its lifetime expired. Given all above conditions, X would > update its reverse route to S: **X->S (through Y)**, and this created a loop > because the route to S in Y was still active, and it used X as the next hop. > > -Yougu > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > Hello Yougu and Jason, > > > > This is something that needs to be fixed. I am not yet > > understanding how the route loops form as a result of the > > variable per-node delay setting. Could one of you be > > specific about the kinds of loops that occur, in order > > that we can try to devise a solution. With queues as > > long as 100 packets, it may be unreasonable to set that > > parameter to be as long as the maximum time for waiting > > in the queue. Then it could be that sometimes a new > > RREQ is transmitted by the source prematurely. But I > > don't see that causing any route loops. There must be > > something else! > > > > Thanks for any more information you can provide... > > > > Regards, > > Charlie P. > > > > Yougu Yuan wrote: > > > Hi, all, > > > > > > I'm doing validation of a wireless network simulation testbed, and have > > > some problem regarding MAC 802.11. > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > packets per second per session) , we noticed that the MAC layer queuing > > > delay in our simulation could be several hundred of millisecond or even > > > a couple of seconds. This will break some assumptions of routing > > > protocols and cause problems like route loops. > > > > > > A little bit more about the setup: in the experiment, the maximum queue > > > length for the MAC is set to 100 packets, and the routing packets and > > > normal packets use separate queues. A distance-fading radio propagation > > > model is used by the physical layer. > > > > > > Is there some work about the MAC layer delay statistics that one can > > > expect? If any, can someone give me a reference for that? Another > > > related question is, if the assumption of hop-by-hop delay is broken, > > > does any known routing protocol has a way to detect/adjust, or it just > > > has to live with the situation? > > > > > > If you can spot any obvious problem with the delay we observed, please > > > also let me know. > > > > > > Thanks in advance. > > > > > > -Yougu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Yougu Yuan > > ---------------------------------------------------- > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 17:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10479 for ; Mon, 8 Jul 2002 17:13:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26219 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 17:14:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22880; Mon, 8 Jul 2002 16:43:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22744 for ; Mon, 8 Jul 2002 16:43:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07656 for ; Mon, 8 Jul 2002 16:42:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA05387; Mon, 8 Jul 2002 13:43:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g68Kh7J10359; Mon, 8 Jul 2002 13:43:07 -0700 X-mProtect: <200207082043> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeaGWgi; Mon, 08 Jul 2002 13:43:04 PDT Message-ID: <3D29F958.DCA71B38@iprg.nokia.com> Date: Mon, 08 Jul 2002 13:43:04 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: yuanyg@cs.dartmouth.edu CC: manet@ietf.org Subject: Re: [manet] MAC queuing delay References: <3D29DCEE.5020303@cs.dartmouth.edu> <3D29E344.F0D03003@iprg.nokia.com> <200207082003.g68K3A19004482@cs.dartmouth.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Yougu, If I may summarize, the route loop is caused if a node forgets about the RREQ too soon, and then sets up the reverse route through a neighbor to whom it had recently transmitted the RREQ. The solution to this problem is to require nodes to remember the RRED_ID for a long time. This time can be made very long, at the cost of increased memory requirement. But I think the extra memory is a matter of a few dozen bytes, and that's not so terrible. Maybe we should re-institute the "RREQ_RECORD_TIME", and cause it to be (10 * PATH_DISCOVERY_TIME). Would you be willing to try this in your simulation to see if it fixes the problem? Also, I think it is worthwhile to observe that this is a basic problem with any flooding scheme. In the scenario you describe, node X would not only set up the reverse route incorrectly, but it would also retransmit the RREQ. All of X's neighbors that had themselves forgotten about the RREQ, would react similarly. In other reasonable flooding schemes, there will typically be some other parameter that has exactly the same functionality of the RREQ_ID. The RREQ_ID really has to be remembered for a long-enough time so that this cannot happen. Regards, Charlie P. Yougu Yuan wrote: > > Hi, Prof. Perkins, > > Let me explain in detail how a loop can be formed within AODV if the > assumption about the one hop delay is broken. > > I will use AODV draft 10 in the example. I haven't read draft 11 very > carefully yet, but I think it won't change much on the result. In AODV, the > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and the > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > After an RREQ has been received, a node will keep a record of its > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > rreq with the same values in this period of time. So far so good. > > Here comes the scenario, in which I will exagerate the MAC queuing delay a > little bit more to make the story shorter. > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > after some hops, it's picked up and forwarded by Node X. X created its > reverse route to S and kept the rreq record as specified. Unfortunately, the > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 second. > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > thing as X, put a reverse route **Y->S (through X)** in its table and > forwarded the request, really bad luck, it's again delayed in the MAC layer > for 2.5 second. > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time from Y. > If X were to ignore this old RREQ from Y, everything would be fine. However, > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has discarded > the record for the previous RREQ(D, i), and the reverse route to S has been > invalidated because its lifetime expired. Given all above conditions, X would > update its reverse route to S: **X->S (through Y)**, and this created a loop > because the route to S in Y was still active, and it used X as the next hop. > > -Yougu > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > Hello Yougu and Jason, > > > > This is something that needs to be fixed. I am not yet > > understanding how the route loops form as a result of the > > variable per-node delay setting. Could one of you be > > specific about the kinds of loops that occur, in order > > that we can try to devise a solution. With queues as > > long as 100 packets, it may be unreasonable to set that > > parameter to be as long as the maximum time for waiting > > in the queue. Then it could be that sometimes a new > > RREQ is transmitted by the source prematurely. But I > > don't see that causing any route loops. There must be > > something else! > > > > Thanks for any more information you can provide... > > > > Regards, > > Charlie P. > > > > Yougu Yuan wrote: > > > Hi, all, > > > > > > I'm doing validation of a wireless network simulation testbed, and have > > > some problem regarding MAC 802.11. > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > packets per second per session) , we noticed that the MAC layer queuing > > > delay in our simulation could be several hundred of millisecond or even > > > a couple of seconds. This will break some assumptions of routing > > > protocols and cause problems like route loops. > > > > > > A little bit more about the setup: in the experiment, the maximum queue > > > length for the MAC is set to 100 packets, and the routing packets and > > > normal packets use separate queues. A distance-fading radio propagation > > > model is used by the physical layer. > > > > > > Is there some work about the MAC layer delay statistics that one can > > > expect? If any, can someone give me a reference for that? Another > > > related question is, if the assumption of hop-by-hop delay is broken, > > > does any known routing protocol has a way to detect/adjust, or it just > > > has to live with the situation? > > > > > > If you can spot any obvious problem with the delay we observed, please > > > also let me know. > > > > > > Thanks in advance. > > > > > > -Yougu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Yougu Yuan > > ---------------------------------------------------- > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 17:23:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11075 for ; Mon, 8 Jul 2002 17:23:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23338; Mon, 8 Jul 2002 16:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23311 for ; Mon, 8 Jul 2002 16:49:24 -0400 (EDT) Received: from dhcp47.ists.dartmouth.edu (dhcp47.ists.dartmouth.edu [129.170.249.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07906 for ; Mon, 8 Jul 2002 16:48:26 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by dhcp47.ists.dartmouth.edu (8.11.6/8.11.6) with ESMTP id g68Km5p09705; Mon, 8 Jul 2002 16:48:05 -0400 Message-ID: <3D29FA85.1020008@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 16:48:05 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 To: YangXiao@IEEE.ORG CC: Yougu Yuan , manet@ietf.org Subject: Re: [manet] MAC queuing delay References: <20020708195204.56548.qmail@web21008.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yang, We ported GloMoSim's 802.11 layer to our simulator and we instrumented the simulator to observe the delays at the MAC layer. In the experiment setup, the network is highly congested. Hence the multi-second delay. -jason. Yang Xiao wrote: > Yougu, > > I know little about MANET routing. However, I did a lot of IEEE 802.11 > simulations, basically in MAC layer. > > I am not sure how you can calculate delays in IEEE 802.11 very well > since delays depends a lot of factors. One important factor is the > traffic load. Different traffic load will result different delays. What > platform are you using? I use OPNET to do simulations. In OPNET, delays > become a little difficult to calculate. The built-in delays measures in > OPNET are not very accurate. In OPNET, delays involve the features of > traffic generators, queue sizes, the number of nodes, and etc. My point > is that you must make sure that your settings are good enough to obtain > accurate delay measures. If you use OPNET, please let me know so that > we can have further discussions. > > Regards > > Yang > > > --- Yougu Yuan wrote: > >>Hi, all, >> >>I'm doing validation of a wireless network simulation testbed, and >>have >>some problem regarding MAC 802.11. >> >>With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte >>packets per second per session) , we noticed that the MAC layer >>queuing >>delay in our simulation could be several hundred of millisecond or >>even >>a couple of seconds. This will break some assumptions of routing >>protocols and cause problems like route loops. >> >>A little bit more about the setup: in the experiment, the maximum >>queue >>length for the MAC is set to 100 packets, and the routing packets and >> >>normal packets use separate queues. A distance-fading radio >>propagation >>model is used by the physical layer. >> >>Is there some work about the MAC layer delay statistics that one can >>expect? If any, can someone give me a reference for that? Another >>related question is, if the assumption of hop-by-hop delay is >>broken, >> does any known routing protocol has a way to detect/adjust, or it >>just >>has to live with the situation? >> >>If you can spot any obvious problem with the delay we observed, >>please >>also let me know. >> >>Thanks in advance. >> >>-Yougu >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > -- Xiaowen (Jason) Liu (jasonliu@cs.dartmouth.edu) --------------------------------------------------------------- Computer Science Department ISTS, Cybersecurity Research Group Dartmouth College Dartmouth College 6211 Sudikoff Laboratory 45 Lyme Road, Suite 201 Hanover, NH 03755 Hanover, NH 03755 Telephone: 603-646-0676 Fax: 603-646-0660 WWW Home Page: http://www.cs.dartmouth.edu/~jasonliu/ --------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 17:23:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11083 for ; Mon, 8 Jul 2002 17:23:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26974 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 17:23:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23338; Mon, 8 Jul 2002 16:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23311 for ; Mon, 8 Jul 2002 16:49:24 -0400 (EDT) Received: from dhcp47.ists.dartmouth.edu (dhcp47.ists.dartmouth.edu [129.170.249.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07906 for ; Mon, 8 Jul 2002 16:48:26 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by dhcp47.ists.dartmouth.edu (8.11.6/8.11.6) with ESMTP id g68Km5p09705; Mon, 8 Jul 2002 16:48:05 -0400 Message-ID: <3D29FA85.1020008@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 16:48:05 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 To: YangXiao@IEEE.ORG CC: Yougu Yuan , manet@ietf.org Subject: Re: [manet] MAC queuing delay References: <20020708195204.56548.qmail@web21008.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yang, We ported GloMoSim's 802.11 layer to our simulator and we instrumented the simulator to observe the delays at the MAC layer. In the experiment setup, the network is highly congested. Hence the multi-second delay. -jason. Yang Xiao wrote: > Yougu, > > I know little about MANET routing. However, I did a lot of IEEE 802.11 > simulations, basically in MAC layer. > > I am not sure how you can calculate delays in IEEE 802.11 very well > since delays depends a lot of factors. One important factor is the > traffic load. Different traffic load will result different delays. What > platform are you using? I use OPNET to do simulations. In OPNET, delays > become a little difficult to calculate. The built-in delays measures in > OPNET are not very accurate. In OPNET, delays involve the features of > traffic generators, queue sizes, the number of nodes, and etc. My point > is that you must make sure that your settings are good enough to obtain > accurate delay measures. If you use OPNET, please let me know so that > we can have further discussions. > > Regards > > Yang > > > --- Yougu Yuan wrote: > >>Hi, all, >> >>I'm doing validation of a wireless network simulation testbed, and >>have >>some problem regarding MAC 802.11. >> >>With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte >>packets per second per session) , we noticed that the MAC layer >>queuing >>delay in our simulation could be several hundred of millisecond or >>even >>a couple of seconds. This will break some assumptions of routing >>protocols and cause problems like route loops. >> >>A little bit more about the setup: in the experiment, the maximum >>queue >>length for the MAC is set to 100 packets, and the routing packets and >> >>normal packets use separate queues. A distance-fading radio >>propagation >>model is used by the physical layer. >> >>Is there some work about the MAC layer delay statistics that one can >>expect? If any, can someone give me a reference for that? Another >>related question is, if the assumption of hop-by-hop delay is >>broken, >> does any known routing protocol has a way to detect/adjust, or it >>just >>has to live with the situation? >> >>If you can spot any obvious problem with the delay we observed, >>please >>also let me know. >> >>Thanks in advance. >> >>-Yougu >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > -- Xiaowen (Jason) Liu (jasonliu@cs.dartmouth.edu) --------------------------------------------------------------- Computer Science Department ISTS, Cybersecurity Research Group Dartmouth College Dartmouth College 6211 Sudikoff Laboratory 45 Lyme Road, Suite 201 Hanover, NH 03755 Hanover, NH 03755 Telephone: 603-646-0676 Fax: 603-646-0660 WWW Home Page: http://www.cs.dartmouth.edu/~jasonliu/ --------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 17:25:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07282 for ; Mon, 8 Jul 2002 16:30:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21526 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 16:30:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19863; Mon, 8 Jul 2002 16:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19832 for ; Mon, 8 Jul 2002 16:03:16 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05904 for ; Mon, 8 Jul 2002 16:02:22 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68K3A19004482; Mon, 8 Jul 2002 16:03:10 -0400 Message-Id: <200207082003.g68K3A19004482@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 16:02:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, "Xiaowen (Jason) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> <3D29E344.F0D03003@iprg.nokia.com> In-Reply-To: <3D29E344.F0D03003@iprg.nokia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, Prof. Perkins, Let me explain in detail how a loop can be formed within AODV if the assumption about the one hop delay is broken. I will use AODV draft 10 in the example. I haven't read draft 11 very carefully yet, but I think it won't change much on the result. In AODV, the one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and the PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. After an RREQ has been received, a node will keep a record of its originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any rreq with the same values in this period of time. So far so good. Here comes the scenario, in which I will exagerate the MAC queuing delay a little bit more to make the story shorter. 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and after some hops, it's picked up and forwarded by Node X. X created its reverse route to S and kept the rreq record as specified. Unfortunately, the request sent out by X is delayed in the MAC layer a lot, say, for 2.5 second. 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same thing as X, put a reverse route **Y->S (through X)** in its table and forwarded the request, really bad luck, it's again delayed in the MAC layer for 2.5 second. 3) So after 5 seconds, X received this RREQ(D,i) again, but this time from Y. If X were to ignore this old RREQ from Y, everything would be fine. However, at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has discarded the record for the previous RREQ(D, i), and the reverse route to S has been invalidated because its lifetime expired. Given all above conditions, X would update its reverse route to S: **X->S (through Y)**, and this created a loop because the route to S in Y was still active, and it used X as the next hop. -Yougu On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > Hello Yougu and Jason, > > This is something that needs to be fixed. I am not yet > understanding how the route loops form as a result of the > variable per-node delay setting. Could one of you be > specific about the kinds of loops that occur, in order > that we can try to devise a solution. With queues as > long as 100 packets, it may be unreasonable to set that > parameter to be as long as the maximum time for waiting > in the queue. Then it could be that sometimes a new > RREQ is transmitted by the source prematurely. But I > don't see that causing any route loops. There must be > something else! > > Thanks for any more information you can provide... > > Regards, > Charlie P. > > Yougu Yuan wrote: > > Hi, all, > > > > I'm doing validation of a wireless network simulation testbed, and have > > some problem regarding MAC 802.11. > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > packets per second per session) , we noticed that the MAC layer queuing > > delay in our simulation could be several hundred of millisecond or even > > a couple of seconds. This will break some assumptions of routing > > protocols and cause problems like route loops. > > > > A little bit more about the setup: in the experiment, the maximum queue > > length for the MAC is set to 100 packets, and the routing packets and > > normal packets use separate queues. A distance-fading radio propagation > > model is used by the physical layer. > > > > Is there some work about the MAC layer delay statistics that one can > > expect? If any, can someone give me a reference for that? Another > > related question is, if the assumption of hop-by-hop delay is broken, > > does any known routing protocol has a way to detect/adjust, or it just > > has to live with the situation? > > > > If you can spot any obvious problem with the delay we observed, please > > also let me know. > > > > Thanks in advance. > > > > -Yougu > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 17:42:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12464 for ; Mon, 8 Jul 2002 17:42:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25986; Mon, 8 Jul 2002 17:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25955 for ; Mon, 8 Jul 2002 17:11:57 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10347 for ; Mon, 8 Jul 2002 17:11:02 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68LBr19006233; Mon, 8 Jul 2002 17:11:53 -0400 Message-Id: <200207082111.g68LBr19006233@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 17:11:40 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, jasonliu@cs.dartmouth.edu References: <3D29DCEE.5020303@cs.dartmouth.edu> <200207082003.g68K3A19004482@cs.dartmouth.edu> <3D29F958.DCA71B38@iprg.nokia.com> In-Reply-To: <3D29F958.DCA71B38@iprg.nokia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Prof. Perkins, Actually we did the test with an extended time for RREQ record, and yes it fixed the problem of route loops. The summary you have done is almost exact except that the scenario I described could happen in a multi-hop fashion as well, that is, multi-hop loops can be formed. The reason we raised the question about the MAC layer delay is not only because of the route loop although it is the largest problem. There may be some other issues too. For example, this is one that I can think of right now: AODV estimates the round trip time of a request, and initialize another round if it hasn't received any reply after the timer expires. The round trip time is also computed based on NODE_TRAVERSAL_TIME. Underestimate the NODE_TRAVERSAL_TIME means that the node can send out unnecessary broadcasting requests, putting more burden on the network. -Yougu On Monday 08 July 2002 16:43, Charles E. Perkins wrote: > Hello Yougu, > > If I may summarize, the route loop is caused if a node forgets > about the RREQ too soon, and then sets up the reverse route > through a neighbor to whom it had recently transmitted the RREQ. > > The solution to this problem is to require nodes to remember > the RRED_ID for a long time. This time can be made very long, > at the cost of increased memory requirement. But I think the > extra memory is a matter of a few dozen bytes, and that's not > so terrible. > > Maybe we should re-institute the "RREQ_RECORD_TIME", and > cause it to be (10 * PATH_DISCOVERY_TIME). Would you be > willing to try this in your simulation to see if it fixes > the problem? > > Also, I think it is worthwhile to observe that this is a basic > problem with any flooding scheme. In the scenario you describe, > node X would not only set up the reverse route incorrectly, but > it would also retransmit the RREQ. All of X's neighbors that > had themselves forgotten about the RREQ, would react similarly. > In other reasonable flooding schemes, there will typically be > some other parameter that has exactly the same functionality > of the RREQ_ID. > > The RREQ_ID really has to be remembered for a long-enough > time so that this cannot happen. > > Regards, > Charlie P. > > Yougu Yuan wrote: > > Hi, Prof. Perkins, > > > > Let me explain in detail how a loop can be formed within AODV if the > > assumption about the one hop delay is broken. > > > > I will use AODV draft 10 in the example. I haven't read draft 11 very > > carefully yet, but I think it won't change much on the result. In AODV, > > the one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, > > and the PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER > > 35. > > > > After an RREQ has been received, a node will keep a record of its > > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > > rreq with the same values in this period of time. So far so good. > > > > Here comes the scenario, in which I will exagerate the MAC queuing delay > > a little bit more to make the story shorter. > > > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > > after some hops, it's picked up and forwarded by Node X. X created its > > reverse route to S and kept the rreq record as specified. Unfortunately, > > the request sent out by X is delayed in the MAC layer a lot, say, for 2.5 > > second. > > > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > > thing as X, put a reverse route **Y->S (through X)** in its table and > > forwarded the request, really bad luck, it's again delayed in the MAC > > layer for 2.5 second. > > > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time > > from Y. If X were to ignore this old RREQ from Y, everything would be > > fine. However, at this moment, the PATH_DISCOVERY_TIME has been exceeded, > > X has discarded the record for the previous RREQ(D, i), and the reverse > > route to S has been invalidated because its lifetime expired. Given all > > above conditions, X would update its reverse route to S: **X->S (through > > Y)**, and this created a loop because the route to S in Y was still > > active, and it used X as the next hop. > > > > -Yougu > > > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > > Hello Yougu and Jason, > > > > > > This is something that needs to be fixed. I am not yet > > > understanding how the route loops form as a result of the > > > variable per-node delay setting. Could one of you be > > > specific about the kinds of loops that occur, in order > > > that we can try to devise a solution. With queues as > > > long as 100 packets, it may be unreasonable to set that > > > parameter to be as long as the maximum time for waiting > > > in the queue. Then it could be that sometimes a new > > > RREQ is transmitted by the source prematurely. But I > > > don't see that causing any route loops. There must be > > > something else! > > > > > > Thanks for any more information you can provide... > > > > > > Regards, > > > Charlie P. > > > > > > Yougu Yuan wrote: > > > > Hi, all, > > > > > > > > I'm doing validation of a wireless network simulation testbed, and > > > > have some problem regarding MAC 802.11. > > > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > > packets per second per session) , we noticed that the MAC layer > > > > queuing delay in our simulation could be several hundred of > > > > millisecond or even a couple of seconds. This will break some > > > > assumptions of routing protocols and cause problems like route loops. > > > > > > > > A little bit more about the setup: in the experiment, the maximum > > > > queue length for the MAC is set to 100 packets, and the routing > > > > packets and normal packets use separate queues. A distance-fading > > > > radio propagation model is used by the physical layer. > > > > > > > > Is there some work about the MAC layer delay statistics that one can > > > > expect? If any, can someone give me a reference for that? Another > > > > related question is, if the assumption of hop-by-hop delay is > > > > broken, does any known routing protocol has a way to detect/adjust, > > > > or it just has to live with the situation? > > > > > > > > If you can spot any obvious problem with the delay we observed, > > > > please also let me know. > > > > > > > > Thanks in advance. > > > > > > > > -Yougu > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > Yougu Yuan > > > > ---------------------------------------------------- > > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > > Dept. of Computer Science, Dartmouth College -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 17:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12472 for ; Mon, 8 Jul 2002 17:42:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29191 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 17:43:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25986; Mon, 8 Jul 2002 17:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25955 for ; Mon, 8 Jul 2002 17:11:57 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10347 for ; Mon, 8 Jul 2002 17:11:02 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68LBr19006233; Mon, 8 Jul 2002 17:11:53 -0400 Message-Id: <200207082111.g68LBr19006233@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 17:11:40 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, jasonliu@cs.dartmouth.edu References: <3D29DCEE.5020303@cs.dartmouth.edu> <200207082003.g68K3A19004482@cs.dartmouth.edu> <3D29F958.DCA71B38@iprg.nokia.com> In-Reply-To: <3D29F958.DCA71B38@iprg.nokia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Prof. Perkins, Actually we did the test with an extended time for RREQ record, and yes it fixed the problem of route loops. The summary you have done is almost exact except that the scenario I described could happen in a multi-hop fashion as well, that is, multi-hop loops can be formed. The reason we raised the question about the MAC layer delay is not only because of the route loop although it is the largest problem. There may be some other issues too. For example, this is one that I can think of right now: AODV estimates the round trip time of a request, and initialize another round if it hasn't received any reply after the timer expires. The round trip time is also computed based on NODE_TRAVERSAL_TIME. Underestimate the NODE_TRAVERSAL_TIME means that the node can send out unnecessary broadcasting requests, putting more burden on the network. -Yougu On Monday 08 July 2002 16:43, Charles E. Perkins wrote: > Hello Yougu, > > If I may summarize, the route loop is caused if a node forgets > about the RREQ too soon, and then sets up the reverse route > through a neighbor to whom it had recently transmitted the RREQ. > > The solution to this problem is to require nodes to remember > the RRED_ID for a long time. This time can be made very long, > at the cost of increased memory requirement. But I think the > extra memory is a matter of a few dozen bytes, and that's not > so terrible. > > Maybe we should re-institute the "RREQ_RECORD_TIME", and > cause it to be (10 * PATH_DISCOVERY_TIME). Would you be > willing to try this in your simulation to see if it fixes > the problem? > > Also, I think it is worthwhile to observe that this is a basic > problem with any flooding scheme. In the scenario you describe, > node X would not only set up the reverse route incorrectly, but > it would also retransmit the RREQ. All of X's neighbors that > had themselves forgotten about the RREQ, would react similarly. > In other reasonable flooding schemes, there will typically be > some other parameter that has exactly the same functionality > of the RREQ_ID. > > The RREQ_ID really has to be remembered for a long-enough > time so that this cannot happen. > > Regards, > Charlie P. > > Yougu Yuan wrote: > > Hi, Prof. Perkins, > > > > Let me explain in detail how a loop can be formed within AODV if the > > assumption about the one hop delay is broken. > > > > I will use AODV draft 10 in the example. I haven't read draft 11 very > > carefully yet, but I think it won't change much on the result. In AODV, > > the one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, > > and the PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER > > 35. > > > > After an RREQ has been received, a node will keep a record of its > > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > > rreq with the same values in this period of time. So far so good. > > > > Here comes the scenario, in which I will exagerate the MAC queuing delay > > a little bit more to make the story shorter. > > > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > > after some hops, it's picked up and forwarded by Node X. X created its > > reverse route to S and kept the rreq record as specified. Unfortunately, > > the request sent out by X is delayed in the MAC layer a lot, say, for 2.5 > > second. > > > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > > thing as X, put a reverse route **Y->S (through X)** in its table and > > forwarded the request, really bad luck, it's again delayed in the MAC > > layer for 2.5 second. > > > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time > > from Y. If X were to ignore this old RREQ from Y, everything would be > > fine. However, at this moment, the PATH_DISCOVERY_TIME has been exceeded, > > X has discarded the record for the previous RREQ(D, i), and the reverse > > route to S has been invalidated because its lifetime expired. Given all > > above conditions, X would update its reverse route to S: **X->S (through > > Y)**, and this created a loop because the route to S in Y was still > > active, and it used X as the next hop. > > > > -Yougu > > > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > > Hello Yougu and Jason, > > > > > > This is something that needs to be fixed. I am not yet > > > understanding how the route loops form as a result of the > > > variable per-node delay setting. Could one of you be > > > specific about the kinds of loops that occur, in order > > > that we can try to devise a solution. With queues as > > > long as 100 packets, it may be unreasonable to set that > > > parameter to be as long as the maximum time for waiting > > > in the queue. Then it could be that sometimes a new > > > RREQ is transmitted by the source prematurely. But I > > > don't see that causing any route loops. There must be > > > something else! > > > > > > Thanks for any more information you can provide... > > > > > > Regards, > > > Charlie P. > > > > > > Yougu Yuan wrote: > > > > Hi, all, > > > > > > > > I'm doing validation of a wireless network simulation testbed, and > > > > have some problem regarding MAC 802.11. > > > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > > packets per second per session) , we noticed that the MAC layer > > > > queuing delay in our simulation could be several hundred of > > > > millisecond or even a couple of seconds. This will break some > > > > assumptions of routing protocols and cause problems like route loops. > > > > > > > > A little bit more about the setup: in the experiment, the maximum > > > > queue length for the MAC is set to 100 packets, and the routing > > > > packets and normal packets use separate queues. A distance-fading > > > > radio propagation model is used by the physical layer. > > > > > > > > Is there some work about the MAC layer delay statistics that one can > > > > expect? If any, can someone give me a reference for that? Another > > > > related question is, if the assumption of hop-by-hop delay is > > > > broken, does any known routing protocol has a way to detect/adjust, > > > > or it just has to live with the situation? > > > > > > > > If you can spot any obvious problem with the delay we observed, > > > > please also let me know. > > > > > > > > Thanks in advance. > > > > > > > > -Yougu > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > Yougu Yuan > > > > ---------------------------------------------------- > > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > > Dept. of Computer Science, Dartmouth College -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 17:56:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13308 for ; Mon, 8 Jul 2002 17:56:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27167; Mon, 8 Jul 2002 17:26:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27138 for ; Mon, 8 Jul 2002 17:25:59 -0400 (EDT) Received: from dhcp47.ists.dartmouth.edu (dhcp47.ists.dartmouth.edu [129.170.249.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11542 for ; Mon, 8 Jul 2002 17:25:05 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by dhcp47.ists.dartmouth.edu (8.11.6/8.11.6) with ESMTP id g68LOIp09723; Mon, 8 Jul 2002 17:24:18 -0400 Message-ID: <3D2A0302.8000602@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 17:24:18 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 To: Kaixin Xu CC: Yougu Yuan , manet@ietf.org Subject: Re: [manet] MAC queuing delay References: <3D29DCEE.5020303@cs.dartmouth.edu> <01a201c226bf$f57b6930$4820b383@mirage> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Kaixin, The estimate is correct for one packet. But if there're 100 packets in the queue, each one will experience 100 times the worst delay of the one packet. It could sum to as much as tens of seconds. Well, I'm talking about the worst scenario. The network is really really overloaded... -jason. Kaixin Xu wrote: > Yougu, > > I think hundreds of milliseconds are not a surprise. From my experience, > this is due to the binary exponential backoff of IEEE 802.11 DCF. Actually > you can build a Markov Chain model to calculate the average delay using the > retry counter as state variable. The key point I think is that in ad hoc > networks, the delay at the MAC layer is more important than queuing delay at > the network layer buffers. This is partly due to the feature that the MAC > layer will drop packet after 7 retries. Thus, long queue is unlikely to > build up. > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > you then consider the time the backoff timer is suspended when the node > sensing the media is busy and the time for transmitting the RTS and time > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > delay is not rare. However, if you get delay in several seconds, that should > not be common. I guess that means the network is really overloaded. Hope > this is helpful. > > Kaixin > > ----- Original Message ----- > From: "Yougu Yuan" > To: > Cc: "Xiaowen (Jason) Liu" > Sent: Monday, July 08, 2002 11:41 AM > Subject: [manet] MAC queuing delay > > > >>Hi, all, >> >>I'm doing validation of a wireless network simulation testbed, and have >>some problem regarding MAC 802.11. >> >>With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte >>packets per second per session) , we noticed that the MAC layer queuing >>delay in our simulation could be several hundred of millisecond or even >>a couple of seconds. This will break some assumptions of routing >>protocols and cause problems like route loops. >> >>A little bit more about the setup: in the experiment, the maximum queue >>length for the MAC is set to 100 packets, and the routing packets and >>normal packets use separate queues. A distance-fading radio propagation >>model is used by the physical layer. >> >>Is there some work about the MAC layer delay statistics that one can >>expect? If any, can someone give me a reference for that? Another >>related question is, if the assumption of hop-by-hop delay is broken, >> does any known routing protocol has a way to detect/adjust, or it just >>has to live with the situation? >> >>If you can spot any obvious problem with the delay we observed, please >>also let me know. >> >>Thanks in advance. >> >>-Yougu >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > > -- Xiaowen (Jason) Liu (jasonliu@cs.dartmouth.edu) --------------------------------------------------------------- Computer Science Department ISTS, Cybersecurity Research Group Dartmouth College Dartmouth College 6211 Sudikoff Laboratory 45 Lyme Road, Suite 201 Hanover, NH 03755 Hanover, NH 03755 Telephone: 603-646-0676 Fax: 603-646-0660 WWW Home Page: http://www.cs.dartmouth.edu/~jasonliu/ --------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 17:56:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13315 for ; Mon, 8 Jul 2002 17:56:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00380 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 17:57:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27167; Mon, 8 Jul 2002 17:26:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27138 for ; Mon, 8 Jul 2002 17:25:59 -0400 (EDT) Received: from dhcp47.ists.dartmouth.edu (dhcp47.ists.dartmouth.edu [129.170.249.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11542 for ; Mon, 8 Jul 2002 17:25:05 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by dhcp47.ists.dartmouth.edu (8.11.6/8.11.6) with ESMTP id g68LOIp09723; Mon, 8 Jul 2002 17:24:18 -0400 Message-ID: <3D2A0302.8000602@cs.dartmouth.edu> Date: Mon, 08 Jul 2002 17:24:18 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 To: Kaixin Xu CC: Yougu Yuan , manet@ietf.org Subject: Re: [manet] MAC queuing delay References: <3D29DCEE.5020303@cs.dartmouth.edu> <01a201c226bf$f57b6930$4820b383@mirage> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Kaixin, The estimate is correct for one packet. But if there're 100 packets in the queue, each one will experience 100 times the worst delay of the one packet. It could sum to as much as tens of seconds. Well, I'm talking about the worst scenario. The network is really really overloaded... -jason. Kaixin Xu wrote: > Yougu, > > I think hundreds of milliseconds are not a surprise. From my experience, > this is due to the binary exponential backoff of IEEE 802.11 DCF. Actually > you can build a Markov Chain model to calculate the average delay using the > retry counter as state variable. The key point I think is that in ad hoc > networks, the delay at the MAC layer is more important than queuing delay at > the network layer buffers. This is partly due to the feature that the MAC > layer will drop packet after 7 retries. Thus, long queue is unlikely to > build up. > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > you then consider the time the backoff timer is suspended when the node > sensing the media is busy and the time for transmitting the RTS and time > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > delay is not rare. However, if you get delay in several seconds, that should > not be common. I guess that means the network is really overloaded. Hope > this is helpful. > > Kaixin > > ----- Original Message ----- > From: "Yougu Yuan" > To: > Cc: "Xiaowen (Jason) Liu" > Sent: Monday, July 08, 2002 11:41 AM > Subject: [manet] MAC queuing delay > > > >>Hi, all, >> >>I'm doing validation of a wireless network simulation testbed, and have >>some problem regarding MAC 802.11. >> >>With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte >>packets per second per session) , we noticed that the MAC layer queuing >>delay in our simulation could be several hundred of millisecond or even >>a couple of seconds. This will break some assumptions of routing >>protocols and cause problems like route loops. >> >>A little bit more about the setup: in the experiment, the maximum queue >>length for the MAC is set to 100 packets, and the routing packets and >>normal packets use separate queues. A distance-fading radio propagation >>model is used by the physical layer. >> >>Is there some work about the MAC layer delay statistics that one can >>expect? If any, can someone give me a reference for that? Another >>related question is, if the assumption of hop-by-hop delay is broken, >> does any known routing protocol has a way to detect/adjust, or it just >>has to live with the situation? >> >>If you can spot any obvious problem with the delay we observed, please >>also let me know. >> >>Thanks in advance. >> >>-Yougu >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> > > > -- Xiaowen (Jason) Liu (jasonliu@cs.dartmouth.edu) --------------------------------------------------------------- Computer Science Department ISTS, Cybersecurity Research Group Dartmouth College Dartmouth College 6211 Sudikoff Laboratory 45 Lyme Road, Suite 201 Hanover, NH 03755 Hanover, NH 03755 Telephone: 603-646-0676 Fax: 603-646-0660 WWW Home Page: http://www.cs.dartmouth.edu/~jasonliu/ --------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 19:30:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17074 for ; Mon, 8 Jul 2002 19:30:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04378; Mon, 8 Jul 2002 18:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04347 for ; Mon, 8 Jul 2002 18:48:59 -0400 (EDT) Received: from sneezy.usu.edu (sneezy.usu.edu [129.123.1.87]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15369 for ; Mon, 8 Jul 2002 18:48:08 -0400 (EDT) Received: from D7KQ4P01 ("port 3153"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #39375) with SMTP id <01KJUXX7LK32AH2PTT@cc.usu.edu> for manet@ietf.org; Mon, 8 Jul 2002 16:48:48 MDT Date: Mon, 08 Jul 2002 16:52:35 -0600 From: Sumeeth Nagaraj Subject: Re: [manet] MAC queuing delay To: yuanyg@cs.dartmouth.edu, "Charles E. Perkins" Cc: manet@ietf.org, "Xiaowen (Jason) Liu" Message-id: <017001c226d2$26a9e010$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <3D29DCEE.5020303@cs.dartmouth.edu> <3D29E344.F0D03003@iprg.nokia.com> <200207082003.g68K3A19004482@cs.dartmouth.edu> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, NET_TRAVERSAL_TIME = 2* 35*40 milliseconds, In the scenario described below, I think the source would generate a new RREQ and each time a new RREQ ID is used so when X receives a new RREQ before it can hear from Y then it would discard the RREQ from Y right. I think still no loops are formed. I think I understand the problem in case I am wrong please let me know. Regards, Sumeeth ----- Original Message ----- From: "Yougu Yuan" To: "Charles E. Perkins" Cc: ; "Xiaowen (Jason) Liu" Sent: Monday, July 08, 2002 2:02 PM Subject: Re: [manet] MAC queuing delay > Hi, Prof. Perkins, > > Let me explain in detail how a loop can be formed within AODV if the > assumption about the one hop delay is broken. > > I will use AODV draft 10 in the example. I haven't read draft 11 very > carefully yet, but I think it won't change much on the result. In AODV, the > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and the > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > After an RREQ has been received, a node will keep a record of its > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > rreq with the same values in this period of time. So far so good. > > Here comes the scenario, in which I will exagerate the MAC queuing delay a > little bit more to make the story shorter. > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > after some hops, it's picked up and forwarded by Node X. X created its > reverse route to S and kept the rreq record as specified. Unfortunately, the > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 second. > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > thing as X, put a reverse route **Y->S (through X)** in its table and > forwarded the request, really bad luck, it's again delayed in the MAC layer > for 2.5 second. > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time from Y. > If X were to ignore this old RREQ from Y, everything would be fine. However, > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has discarded > the record for the previous RREQ(D, i), and the reverse route to S has been > invalidated because its lifetime expired. Given all above conditions, X would > update its reverse route to S: **X->S (through Y)**, and this created a loop > because the route to S in Y was still active, and it used X as the next hop. > > -Yougu > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > Hello Yougu and Jason, > > > > This is something that needs to be fixed. I am not yet > > understanding how the route loops form as a result of the > > variable per-node delay setting. Could one of you be > > specific about the kinds of loops that occur, in order > > that we can try to devise a solution. With queues as > > long as 100 packets, it may be unreasonable to set that > > parameter to be as long as the maximum time for waiting > > in the queue. Then it could be that sometimes a new > > RREQ is transmitted by the source prematurely. But I > > don't see that causing any route loops. There must be > > something else! > > > > Thanks for any more information you can provide... > > > > Regards, > > Charlie P. > > > > Yougu Yuan wrote: > > > Hi, all, > > > > > > I'm doing validation of a wireless network simulation testbed, and have > > > some problem regarding MAC 802.11. > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > packets per second per session) , we noticed that the MAC layer queuing > > > delay in our simulation could be several hundred of millisecond or even > > > a couple of seconds. This will break some assumptions of routing > > > protocols and cause problems like route loops. > > > > > > A little bit more about the setup: in the experiment, the maximum queue > > > length for the MAC is set to 100 packets, and the routing packets and > > > normal packets use separate queues. A distance-fading radio propagation > > > model is used by the physical layer. > > > > > > Is there some work about the MAC layer delay statistics that one can > > > expect? If any, can someone give me a reference for that? Another > > > related question is, if the assumption of hop-by-hop delay is broken, > > > does any known routing protocol has a way to detect/adjust, or it just > > > has to live with the situation? > > > > > > If you can spot any obvious problem with the delay we observed, please > > > also let me know. > > > > > > Thanks in advance. > > > > > > -Yougu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Yougu Yuan > > ---------------------------------------------------- > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > Dept. of Computer Science, Dartmouth College > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 19:30:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17082 for ; Mon, 8 Jul 2002 19:30:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08051 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 19:30:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04378; Mon, 8 Jul 2002 18:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04347 for ; Mon, 8 Jul 2002 18:48:59 -0400 (EDT) Received: from sneezy.usu.edu (sneezy.usu.edu [129.123.1.87]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15369 for ; Mon, 8 Jul 2002 18:48:08 -0400 (EDT) Received: from D7KQ4P01 ("port 3153"@maxwell-6.ece.usu.edu [129.123.85.141]) by cc.usu.edu (PMDF V5.2-32 #39375) with SMTP id <01KJUXX7LK32AH2PTT@cc.usu.edu> for manet@ietf.org; Mon, 8 Jul 2002 16:48:48 MDT Date: Mon, 08 Jul 2002 16:52:35 -0600 From: Sumeeth Nagaraj Subject: Re: [manet] MAC queuing delay To: yuanyg@cs.dartmouth.edu, "Charles E. Perkins" Cc: manet@ietf.org, "Xiaowen (Jason) Liu" Message-id: <017001c226d2$26a9e010$8d557b81@D7KQ4P01> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <3D29DCEE.5020303@cs.dartmouth.edu> <3D29E344.F0D03003@iprg.nokia.com> <200207082003.g68K3A19004482@cs.dartmouth.edu> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, NET_TRAVERSAL_TIME = 2* 35*40 milliseconds, In the scenario described below, I think the source would generate a new RREQ and each time a new RREQ ID is used so when X receives a new RREQ before it can hear from Y then it would discard the RREQ from Y right. I think still no loops are formed. I think I understand the problem in case I am wrong please let me know. Regards, Sumeeth ----- Original Message ----- From: "Yougu Yuan" To: "Charles E. Perkins" Cc: ; "Xiaowen (Jason) Liu" Sent: Monday, July 08, 2002 2:02 PM Subject: Re: [manet] MAC queuing delay > Hi, Prof. Perkins, > > Let me explain in detail how a loop can be formed within AODV if the > assumption about the one hop delay is broken. > > I will use AODV draft 10 in the example. I haven't read draft 11 very > carefully yet, but I think it won't change much on the result. In AODV, the > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and the > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > After an RREQ has been received, a node will keep a record of its > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > rreq with the same values in this period of time. So far so good. > > Here comes the scenario, in which I will exagerate the MAC queuing delay a > little bit more to make the story shorter. > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > after some hops, it's picked up and forwarded by Node X. X created its > reverse route to S and kept the rreq record as specified. Unfortunately, the > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 second. > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > thing as X, put a reverse route **Y->S (through X)** in its table and > forwarded the request, really bad luck, it's again delayed in the MAC layer > for 2.5 second. > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time from Y. > If X were to ignore this old RREQ from Y, everything would be fine. However, > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has discarded > the record for the previous RREQ(D, i), and the reverse route to S has been > invalidated because its lifetime expired. Given all above conditions, X would > update its reverse route to S: **X->S (through Y)**, and this created a loop > because the route to S in Y was still active, and it used X as the next hop. > > -Yougu > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > Hello Yougu and Jason, > > > > This is something that needs to be fixed. I am not yet > > understanding how the route loops form as a result of the > > variable per-node delay setting. Could one of you be > > specific about the kinds of loops that occur, in order > > that we can try to devise a solution. With queues as > > long as 100 packets, it may be unreasonable to set that > > parameter to be as long as the maximum time for waiting > > in the queue. Then it could be that sometimes a new > > RREQ is transmitted by the source prematurely. But I > > don't see that causing any route loops. There must be > > something else! > > > > Thanks for any more information you can provide... > > > > Regards, > > Charlie P. > > > > Yougu Yuan wrote: > > > Hi, all, > > > > > > I'm doing validation of a wireless network simulation testbed, and have > > > some problem regarding MAC 802.11. > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > packets per second per session) , we noticed that the MAC layer queuing > > > delay in our simulation could be several hundred of millisecond or even > > > a couple of seconds. This will break some assumptions of routing > > > protocols and cause problems like route loops. > > > > > > A little bit more about the setup: in the experiment, the maximum queue > > > length for the MAC is set to 100 packets, and the routing packets and > > > normal packets use separate queues. A distance-fading radio propagation > > > model is used by the physical layer. > > > > > > Is there some work about the MAC layer delay statistics that one can > > > expect? If any, can someone give me a reference for that? Another > > > related question is, if the assumption of hop-by-hop delay is broken, > > > does any known routing protocol has a way to detect/adjust, or it just > > > has to live with the situation? > > > > > > If you can spot any obvious problem with the delay we observed, please > > > also let me know. > > > > > > Thanks in advance. > > > > > > -Yougu > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Yougu Yuan > > ---------------------------------------------------- > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > Dept. of Computer Science, Dartmouth College > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 19:35:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17306 for ; Mon, 8 Jul 2002 19:35:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04903; Mon, 8 Jul 2002 18:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04865 for ; Mon, 8 Jul 2002 18:57:34 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15722 for ; Mon, 8 Jul 2002 18:56:41 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68MvS19008203; Mon, 8 Jul 2002 18:57:29 -0400 Message-Id: <200207082257.g68MvS19008203@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: Sumeeth Nagaraj , "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 18:57:15 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, "Xiaowen (Jason) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> <200207082003.g68K3A19004482@cs.dartmouth.edu> <017001c226d2$26a9e010$8d557b81@D7KQ4P01> In-Reply-To: <017001c226d2$26a9e010$8d557b81@D7KQ4P01> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Sumeeth, your observation is correct, but there are exceptions. 1) This may happen for the last try of RREQ_RETRIES, which means there won't be a new RREQ for a while. 2) With mobility, ad-hoc network has very high error rate as we observed in the simulation, and the new RREQ, if any, might be tossed and hasn't been received correctly by X. -Yougu On Monday 08 July 2002 18:52, Sumeeth Nagaraj wrote: > Hi, > > NET_TRAVERSAL_TIME = 2* 35*40 milliseconds, In the scenario described > below, I think the source would generate a new RREQ and each time a new > RREQ ID is used so when X receives a new RREQ before it can hear from Y > then it would discard the RREQ from Y right. I think still no loops are > formed. > > I think I understand the problem in case I am wrong please let me know. > > Regards, > Sumeeth > > > ----- Original Message ----- > From: "Yougu Yuan" > To: "Charles E. Perkins" > Cc: ; "Xiaowen (Jason) Liu" > Sent: Monday, July 08, 2002 2:02 PM > Subject: Re: [manet] MAC queuing delay > > > Hi, Prof. Perkins, > > > > Let me explain in detail how a loop can be formed within AODV if the > > assumption about the one hop delay is broken. > > > > I will use AODV draft 10 in the example. I haven't read draft 11 very > > carefully yet, but I think it won't change much on the result. In AODV, > > the > > > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and > > the > > > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > > > After an RREQ has been received, a node will keep a record of its > > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > > rreq with the same values in this period of time. So far so good. > > > > Here comes the scenario, in which I will exagerate the MAC queuing delay > > a little bit more to make the story shorter. > > > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > > after some hops, it's picked up and forwarded by Node X. X created its > > reverse route to S and kept the rreq record as specified. Unfortunately, > > the > > > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 > > second. > > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > > thing as X, put a reverse route **Y->S (through X)** in its table and > > forwarded the request, really bad luck, it's again delayed in the MAC > > layer > > > for 2.5 second. > > > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time > > from > > Y. > > > If X were to ignore this old RREQ from Y, everything would be fine. > > However, > > > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has > > discarded the record for the previous RREQ(D, i), and the reverse route > > to S has > > been > > > invalidated because its lifetime expired. Given all above conditions, X > > would > > > update its reverse route to S: **X->S (through Y)**, and this created a > > loop > > > because the route to S in Y was still active, and it used X as the next > > hop. > > > -Yougu > > > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > > Hello Yougu and Jason, > > > > > > This is something that needs to be fixed. I am not yet > > > understanding how the route loops form as a result of the > > > variable per-node delay setting. Could one of you be > > > specific about the kinds of loops that occur, in order > > > that we can try to devise a solution. With queues as > > > long as 100 packets, it may be unreasonable to set that > > > parameter to be as long as the maximum time for waiting > > > in the queue. Then it could be that sometimes a new > > > RREQ is transmitted by the source prematurely. But I > > > don't see that causing any route loops. There must be > > > something else! > > > > > > Thanks for any more information you can provide... > > > > > > Regards, > > > Charlie P. > > > > > > Yougu Yuan wrote: > > > > Hi, all, > > > > > > > > I'm doing validation of a wireless network simulation testbed, and > > have > > > > > some problem regarding MAC 802.11. > > > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > > packets per second per session) , we noticed that the MAC layer > > queuing > > > > > delay in our simulation could be several hundred of millisecond or > > even > > > > > a couple of seconds. This will break some assumptions of routing > > > > protocols and cause problems like route loops. > > > > > > > > A little bit more about the setup: in the experiment, the maximum > > queue > > > > > length for the MAC is set to 100 packets, and the routing packets and > > > > normal packets use separate queues. A distance-fading radio > > propagation > > > > > model is used by the physical layer. > > > > > > > > Is there some work about the MAC layer delay statistics that one can > > > > expect? If any, can someone give me a reference for that? Another > > > > related question is, if the assumption of hop-by-hop delay is > > > > broken, does any known routing protocol has a way to detect/adjust, > > > > or it > > just > > > > > has to live with the situation? > > > > > > > > If you can spot any obvious problem with the delay we observed, > > > > please also let me know. > > > > > > > > Thanks in advance. > > > > > > > > -Yougu > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > Yougu Yuan > > > > ---------------------------------------------------- > > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > > Dept. of Computer Science, Dartmouth College > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 19:35:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17314 for ; Mon, 8 Jul 2002 19:35:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08454 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 19:36:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04903; Mon, 8 Jul 2002 18:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04865 for ; Mon, 8 Jul 2002 18:57:34 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15722 for ; Mon, 8 Jul 2002 18:56:41 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68MvS19008203; Mon, 8 Jul 2002 18:57:29 -0400 Message-Id: <200207082257.g68MvS19008203@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: Sumeeth Nagaraj , "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 18:57:15 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, "Xiaowen (Jason) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> <200207082003.g68K3A19004482@cs.dartmouth.edu> <017001c226d2$26a9e010$8d557b81@D7KQ4P01> In-Reply-To: <017001c226d2$26a9e010$8d557b81@D7KQ4P01> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Sumeeth, your observation is correct, but there are exceptions. 1) This may happen for the last try of RREQ_RETRIES, which means there won't be a new RREQ for a while. 2) With mobility, ad-hoc network has very high error rate as we observed in the simulation, and the new RREQ, if any, might be tossed and hasn't been received correctly by X. -Yougu On Monday 08 July 2002 18:52, Sumeeth Nagaraj wrote: > Hi, > > NET_TRAVERSAL_TIME = 2* 35*40 milliseconds, In the scenario described > below, I think the source would generate a new RREQ and each time a new > RREQ ID is used so when X receives a new RREQ before it can hear from Y > then it would discard the RREQ from Y right. I think still no loops are > formed. > > I think I understand the problem in case I am wrong please let me know. > > Regards, > Sumeeth > > > ----- Original Message ----- > From: "Yougu Yuan" > To: "Charles E. Perkins" > Cc: ; "Xiaowen (Jason) Liu" > Sent: Monday, July 08, 2002 2:02 PM > Subject: Re: [manet] MAC queuing delay > > > Hi, Prof. Perkins, > > > > Let me explain in detail how a loop can be formed within AODV if the > > assumption about the one hop delay is broken. > > > > I will use AODV draft 10 in the example. I haven't read draft 11 very > > carefully yet, but I think it won't change much on the result. In AODV, > > the > > > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and > > the > > > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > > > After an RREQ has been received, a node will keep a record of its > > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > > rreq with the same values in this period of time. So far so good. > > > > Here comes the scenario, in which I will exagerate the MAC queuing delay > > a little bit more to make the story shorter. > > > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > > after some hops, it's picked up and forwarded by Node X. X created its > > reverse route to S and kept the rreq record as specified. Unfortunately, > > the > > > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 > > second. > > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > > thing as X, put a reverse route **Y->S (through X)** in its table and > > forwarded the request, really bad luck, it's again delayed in the MAC > > layer > > > for 2.5 second. > > > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time > > from > > Y. > > > If X were to ignore this old RREQ from Y, everything would be fine. > > However, > > > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has > > discarded the record for the previous RREQ(D, i), and the reverse route > > to S has > > been > > > invalidated because its lifetime expired. Given all above conditions, X > > would > > > update its reverse route to S: **X->S (through Y)**, and this created a > > loop > > > because the route to S in Y was still active, and it used X as the next > > hop. > > > -Yougu > > > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > > Hello Yougu and Jason, > > > > > > This is something that needs to be fixed. I am not yet > > > understanding how the route loops form as a result of the > > > variable per-node delay setting. Could one of you be > > > specific about the kinds of loops that occur, in order > > > that we can try to devise a solution. With queues as > > > long as 100 packets, it may be unreasonable to set that > > > parameter to be as long as the maximum time for waiting > > > in the queue. Then it could be that sometimes a new > > > RREQ is transmitted by the source prematurely. But I > > > don't see that causing any route loops. There must be > > > something else! > > > > > > Thanks for any more information you can provide... > > > > > > Regards, > > > Charlie P. > > > > > > Yougu Yuan wrote: > > > > Hi, all, > > > > > > > > I'm doing validation of a wireless network simulation testbed, and > > have > > > > > some problem regarding MAC 802.11. > > > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > > packets per second per session) , we noticed that the MAC layer > > queuing > > > > > delay in our simulation could be several hundred of millisecond or > > even > > > > > a couple of seconds. This will break some assumptions of routing > > > > protocols and cause problems like route loops. > > > > > > > > A little bit more about the setup: in the experiment, the maximum > > queue > > > > > length for the MAC is set to 100 packets, and the routing packets and > > > > normal packets use separate queues. A distance-fading radio > > propagation > > > > > model is used by the physical layer. > > > > > > > > Is there some work about the MAC layer delay statistics that one can > > > > expect? If any, can someone give me a reference for that? Another > > > > related question is, if the assumption of hop-by-hop delay is > > > > broken, does any known routing protocol has a way to detect/adjust, > > > > or it > > just > > > > > has to live with the situation? > > > > > > > > If you can spot any obvious problem with the delay we observed, > > > > please also let me know. > > > > > > > > Thanks in advance. > > > > > > > > -Yougu > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > Yougu Yuan > > > > ---------------------------------------------------- > > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > > Dept. of Computer Science, Dartmouth College > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Jul 8 19:47:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17716 for ; Mon, 8 Jul 2002 19:47:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06880; Mon, 8 Jul 2002 19:18:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06761 for ; Mon, 8 Jul 2002 19:18:14 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16602 for ; Mon, 8 Jul 2002 19:17:23 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68NIA19008503; Mon, 8 Jul 2002 19:18:10 -0400 Message-Id: <200207082318.g68NIA19008503@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: Sumeeth Nagaraj , "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 19:17:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, "Xiaowen (Jason) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> <200207082003.g68K3A19004482@cs.dartmouth.edu> <017001c226d2$26a9e010$8d557b81@D7KQ4P01> In-Reply-To: <017001c226d2$26a9e010$8d557b81@D7KQ4P01> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit I forgot to mention another "exception" in the last e-mail. The newly sent RREQ also suffers the same problem of MAC layer delay, so it might be stuck in the MAC layer of some node in the middle and hasn't arrived at X yet. -Yougu On Monday 08 July 2002 18:52, Sumeeth Nagaraj wrote: > Hi, > > NET_TRAVERSAL_TIME = 2* 35*40 milliseconds, In the scenario described > below, I think the source would generate a new RREQ and each time a new > RREQ ID is used so when X receives a new RREQ before it can hear from Y > then it would discard the RREQ from Y right. I think still no loops are > formed. > > I think I understand the problem in case I am wrong please let me know. > > Regards, > Sumeeth > > > ----- Original Message ----- > From: "Yougu Yuan" > To: "Charles E. Perkins" > Cc: ; "Xiaowen (Jason) Liu" > Sent: Monday, July 08, 2002 2:02 PM > Subject: Re: [manet] MAC queuing delay > > > Hi, Prof. Perkins, > > > > Let me explain in detail how a loop can be formed within AODV if the > > assumption about the one hop delay is broken. > > > > I will use AODV draft 10 in the example. I haven't read draft 11 very > > carefully yet, but I think it won't change much on the result. In AODV, > > the > > > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and > > the > > > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > > > After an RREQ has been received, a node will keep a record of its > > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > > rreq with the same values in this period of time. So far so good. > > > > Here comes the scenario, in which I will exagerate the MAC queuing delay > > a little bit more to make the story shorter. > > > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > > after some hops, it's picked up and forwarded by Node X. X created its > > reverse route to S and kept the rreq record as specified. Unfortunately, > > the > > > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 > > second. > > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > > thing as X, put a reverse route **Y->S (through X)** in its table and > > forwarded the request, really bad luck, it's again delayed in the MAC > > layer > > > for 2.5 second. > > > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time > > from > > Y. > > > If X were to ignore this old RREQ from Y, everything would be fine. > > However, > > > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has > > discarded the record for the previous RREQ(D, i), and the reverse route > > to S has > > been > > > invalidated because its lifetime expired. Given all above conditions, X > > would > > > update its reverse route to S: **X->S (through Y)**, and this created a > > loop > > > because the route to S in Y was still active, and it used X as the next > > hop. > > > -Yougu > > > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > > Hello Yougu and Jason, > > > > > > This is something that needs to be fixed. I am not yet > > > understanding how the route loops form as a result of the > > > variable per-node delay setting. Could one of you be > > > specific about the kinds of loops that occur, in order > > > that we can try to devise a solution. With queues as > > > long as 100 packets, it may be unreasonable to set that > > > parameter to be as long as the maximum time for waiting > > > in the queue. Then it could be that sometimes a new > > > RREQ is transmitted by the source prematurely. But I > > > don't see that causing any route loops. There must be > > > something else! > > > > > > Thanks for any more information you can provide... > > > > > > Regards, > > > Charlie P. > > > > > > Yougu Yuan wrote: > > > > Hi, all, > > > > > > > > I'm doing validation of a wireless network simulation testbed, and > > have > > > > > some problem regarding MAC 802.11. > > > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > > packets per second per session) , we noticed that the MAC layer > > queuing > > > > > delay in our simulation could be several hundred of millisecond or > > even > > > > > a couple of seconds. This will break some assumptions of routing > > > > protocols and cause problems like route loops. > > > > > > > > A little bit more about the setup: in the experiment, the maximum > > queue > > > > > length for the MAC is set to 100 packets, and the routing packets and > > > > normal packets use separate queues. A distance-fading radio > > propagation > > > > > model is used by the physical layer. > > > > > > > > Is there some work about the MAC layer delay statistics that one can > > > > expect? If any, can someone give me a reference for that? Another > > > > related question is, if the assumption of hop-by-hop delay is > > > > broken, does any known routing protocol has a way to detect/adjust, > > > > or it > > just > > > > > has to live with the situation? > > > > > > > > If you can spot any obvious problem with the delay we observed, > > > > please also let me know. > > > > > > > > Thanks in advance. > > > > > > > > -Yougu > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > Yougu Yuan > > > > ---------------------------------------------------- > > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > > Dept. of Computer Science, Dartmouth College > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Jul 8 19:47:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17724 for ; Mon, 8 Jul 2002 19:47:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA08938 for manet-archive@odin.ietf.org; Mon, 8 Jul 2002 19:47:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06880; Mon, 8 Jul 2002 19:18:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06761 for ; Mon, 8 Jul 2002 19:18:14 -0400 (EDT) Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16602 for ; Mon, 8 Jul 2002 19:17:23 -0400 (EDT) Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205]) by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g68NIA19008503; Mon, 8 Jul 2002 19:18:10 -0400 Message-Id: <200207082318.g68NIA19008503@cs.dartmouth.edu> Content-Type: text/plain; charset="iso-8859-1" From: Yougu Yuan Reply-To: yuanyg@cs.dartmouth.edu Organization: Dept. of Computer Science, Dartmouth College To: Sumeeth Nagaraj , "Charles E. Perkins" Subject: Re: [manet] MAC queuing delay Date: Mon, 8 Jul 2002 19:17:57 -0400 X-Mailer: KMail [version 1.3.2] Cc: manet@ietf.org, "Xiaowen (Jason) Liu" References: <3D29DCEE.5020303@cs.dartmouth.edu> <200207082003.g68K3A19004482@cs.dartmouth.edu> <017001c226d2$26a9e010$8d557b81@D7KQ4P01> In-Reply-To: <017001c226d2$26a9e010$8d557b81@D7KQ4P01> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit I forgot to mention another "exception" in the last e-mail. The newly sent RREQ also suffers the same problem of MAC layer delay, so it might be stuck in the MAC layer of some node in the middle and hasn't arrived at X yet. -Yougu On Monday 08 July 2002 18:52, Sumeeth Nagaraj wrote: > Hi, > > NET_TRAVERSAL_TIME = 2* 35*40 milliseconds, In the scenario described > below, I think the source would generate a new RREQ and each time a new > RREQ ID is used so when X receives a new RREQ before it can hear from Y > then it would discard the RREQ from Y right. I think still no loops are > formed. > > I think I understand the problem in case I am wrong please let me know. > > Regards, > Sumeeth > > > ----- Original Message ----- > From: "Yougu Yuan" > To: "Charles E. Perkins" > Cc: ; "Xiaowen (Jason) Liu" > Sent: Monday, July 08, 2002 2:02 PM > Subject: Re: [manet] MAC queuing delay > > > Hi, Prof. Perkins, > > > > Let me explain in detail how a loop can be formed within AODV if the > > assumption about the one hop delay is broken. > > > > I will use AODV draft 10 in the example. I haven't read draft 11 very > > carefully yet, but I think it won't change much on the result. In AODV, > > the > > > one hop round trip delay (NODE_TRAVERSAL_TIME) is by default 40 ms, and > > the > > > PATH_DISCOVERY_TIME is computed to 4.2 second with NET_DIAMETER 35. > > > > After an RREQ has been received, a node will keep a record of its > > originator and its rreq id for PATH_DISCOVERY_TIME, ignoring any > > rreq with the same values in this period of time. So far so good. > > > > Here comes the scenario, in which I will exagerate the MAC queuing delay > > a little bit more to make the story shorter. > > > > 1) Node S sended out a request for Node D with rreq ID i: RREQ(D, i), and > > after some hops, it's picked up and forwarded by Node X. X created its > > reverse route to S and kept the rreq record as specified. Unfortunately, > > the > > > request sent out by X is delayed in the MAC layer a lot, say, for 2.5 > > second. > > > 2) Then Node Y received this forwarded request RREQ(D, i). Y did the same > > thing as X, put a reverse route **Y->S (through X)** in its table and > > forwarded the request, really bad luck, it's again delayed in the MAC > > layer > > > for 2.5 second. > > > > 3) So after 5 seconds, X received this RREQ(D,i) again, but this time > > from > > Y. > > > If X were to ignore this old RREQ from Y, everything would be fine. > > However, > > > at this moment, the PATH_DISCOVERY_TIME has been exceeded, X has > > discarded the record for the previous RREQ(D, i), and the reverse route > > to S has > > been > > > invalidated because its lifetime expired. Given all above conditions, X > > would > > > update its reverse route to S: **X->S (through Y)**, and this created a > > loop > > > because the route to S in Y was still active, and it used X as the next > > hop. > > > -Yougu > > > > On Monday 08 July 2002 15:08, Charles E. Perkins wrote: > > > Hello Yougu and Jason, > > > > > > This is something that needs to be fixed. I am not yet > > > understanding how the route loops form as a result of the > > > variable per-node delay setting. Could one of you be > > > specific about the kinds of loops that occur, in order > > > that we can try to devise a solution. With queues as > > > long as 100 packets, it may be unreasonable to set that > > > parameter to be as long as the maximum time for waiting > > > in the queue. Then it could be that sometimes a new > > > RREQ is transmitted by the source prematurely. But I > > > don't see that causing any route loops. There must be > > > something else! > > > > > > Thanks for any more information you can provide... > > > > > > Regards, > > > Charlie P. > > > > > > Yougu Yuan wrote: > > > > Hi, all, > > > > > > > > I'm doing validation of a wireless network simulation testbed, and > > have > > > > > some problem regarding MAC 802.11. > > > > > > > > With somewhat "heavy" traffic (100 nodes, 100 sessions, 2 512 byte > > > > packets per second per session) , we noticed that the MAC layer > > queuing > > > > > delay in our simulation could be several hundred of millisecond or > > even > > > > > a couple of seconds. This will break some assumptions of routing > > > > protocols and cause problems like route loops. > > > > > > > > A little bit more about the setup: in the experiment, the maximum > > queue > > > > > length for the MAC is set to 100 packets, and the routing packets and > > > > normal packets use separate queues. A distance-fading radio > > propagation > > > > > model is used by the physical layer. > > > > > > > > Is there some work about the MAC layer delay statistics that one can > > > > expect? If any, can someone give me a reference for that? Another > > > > related question is, if the assumption of hop-by-hop delay is > > > > broken, does any known routing protocol has a way to detect/adjust, > > > > or it > > just > > > > > has to live with the situation? > > > > > > > > If you can spot any obvious problem with the delay we observed, > > > > please also let me know. > > > > > > > > Thanks in advance. > > > > > > > > -Yougu > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > Yougu Yuan > > > > ---------------------------------------------------- > > Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu > > Dept. of Computer Science, Dartmouth College > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet -- Yougu Yuan ---------------------------------------------------- Office Phone 603-646-0679 yuanyg@cs.dartmouth.edu Dept. of Computer Science, Dartmouth College _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 01:23:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03262 for ; Tue, 9 Jul 2002 01:23:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23972; Tue, 9 Jul 2002 01:00:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23933 for ; Tue, 9 Jul 2002 01:00:37 -0400 (EDT) Received: from sina.com (sina35-249.sina.com.cn [202.108.35.249] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02702 for ; Tue, 9 Jul 2002 00:59:37 -0400 (EDT) Received: (qmail 27718 invoked by uid 99); 9 Jul 2002 04:52:34 -0000 Message-ID: <20020709045234.27717.qmail@sina.com> From: wht_slh_bao To: manet@ietf.org MIME-Version: 1.0 Date: Tue, 09 Jul 2002 12:52:34 +0800 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Subject: [manet] ns implementation question? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear everyone: I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc.Can anyone tell me some implement details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? By the way, I know we can set txpower or rxpower in mobilenode, but how to set the transmission distance of moblie node in ns? How to add policer, such as tokentbucker, and queue management and schedulers, such as RIO and WFQ directly to nodes or mobile nodes directly. Please tell me, had better give me some examples? Thanks in advance. Best regard£¡ hait song ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 01:23:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03268 for ; Tue, 9 Jul 2002 01:23:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA03822 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 01:24:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23972; Tue, 9 Jul 2002 01:00:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23933 for ; Tue, 9 Jul 2002 01:00:37 -0400 (EDT) Received: from sina.com (sina35-249.sina.com.cn [202.108.35.249] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02702 for ; Tue, 9 Jul 2002 00:59:37 -0400 (EDT) Received: (qmail 27718 invoked by uid 99); 9 Jul 2002 04:52:34 -0000 Message-ID: <20020709045234.27717.qmail@sina.com> From: wht_slh_bao To: manet@ietf.org MIME-Version: 1.0 Date: Tue, 09 Jul 2002 12:52:34 +0800 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Subject: [manet] ns implementation question? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear everyone: I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc.Can anyone tell me some implement details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? By the way, I know we can set txpower or rxpower in mobilenode, but how to set the transmission distance of moblie node in ns? How to add policer, such as tokentbucker, and queue management and schedulers, such as RIO and WFQ directly to nodes or mobile nodes directly. Please tell me, had better give me some examples? Thanks in advance. Best regard£¡ hait song ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 01:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03619 for ; Tue, 9 Jul 2002 01:42:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28382; Tue, 9 Jul 2002 01:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28274 for ; Tue, 9 Jul 2002 01:09:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02919 for ; Tue, 9 Jul 2002 01:08:06 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-331.cisco.com [10.21.97.75]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6957nhJ025423; Mon, 8 Jul 2002 22:07:53 -0700 (PDT) Message-Id: <5.1.1.6.2.20020708144909.024c5198@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 08 Jul 2002 18:23:56 -0700 To: John Peter Tapsell From: Fred Baker Subject: Re: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org, Hi@cs.man.ac.uk In-Reply-To: <18137_2404_1025182433_1@ug002> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 01:53 PM 6/27/2002 +0100, John Peter Tapsell wrote: > I'm trying to find any information on whether I could get QoS over an > Ad-Hoc network. Sorry I'm looking into this late. As someone mentioned, QoS in any network has issues, and in an ad hoc network there are more. It is largely a question of what you want, what radio technologies you are looking at, and what information you have available. Someone said that diffserv gives you N layers of priority and that's it. That is incorrect, from a number of perspectives, and reflects a complete misunderstanding of diffserv. If you're looking at diffserv as an architecture, I'd suggest that you look at RFC 2474/2475 for a good understanding. For a proposed generalized diffserv configuration, you might take a look at http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-00.txt, for which there is an update at ftp://ftpeng.cisco.com/fred/ieprep/Marking.html You will notice that there is only one place where we use priority in a diffserv configuration: where the application requires management of latency or jitter; the key applications for this are in voice and perhaps video. Elastic applications, especially those that use short sessions (a large percentage) don't require that; they require rate management, not jitter management. Probably the most important single question is your radio environment. If you are using a radio technology in which the speakers must vie for access, there are interesting questions of whether two stations that cannot hear each other can interfere from the perspective of a third station. Most radio technologies have interesting problems in transmission physics - water, dirt, and stone can materially get in the way, and often appear to do so randomly. So your most fundamental QoS issues are not issues of message ordering, and cannot be solved by changing that ordering. Of those that can in fact be changed by message ordering, it seems to me that the difficult ones are exacerbated by a radio technology that treats the radio as a shared medium like an Ethernet. The problem there is that in a shared environment, the bandwidth or latency guarantees that one seeks to make are dependent not only on the availability of bandwidth and my own use of it (which is fairly trivial to solve), but on the behavior of others. Even if everyone was only allowed to send one message per time unit, there is no guarantee that they won't all do so just at the instant that I need to be first in line. The way to solve that, generally, involves some form of central scheduler which knows the specific needs of every application running on every device, and also of the transit traffic, and doles out permission as needed. Think deeply about what the words "mobile" and "ad hoc" mean, and I think you'll agree that this is a non-starter in this kind of network. All of which is *not* to say that guarantees of bandwidth, latency, or reliability are impossible, but to say that they are truly difficult in the general case, and even in specific cases have issues. You might find Charlie Perkins QoS-on-AODV draft interesting reading. It has a couple of issues, which I have advised him of in private mail - notably, it has the originator say that he wants a certain bandwidth with a certain worst case delay, but conveys no sense of what the interval is over which the rate is measured. Parekh and Gallager indicate that to perform the calculation of the worst case delay that a data stream will experience end to end, one needs to know both the rate and the burst size of the data stream, and then it is only predictable if the application injects at most that rate *and* each hop en route does something predictable with the packet stream. But it at least allows us to characterize the feasibility of a path. It has the same scaling issues that RFC 2205 RSVP has. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 01:42:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03633 for ; Tue, 9 Jul 2002 01:42:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA05067 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 01:43:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28382; Tue, 9 Jul 2002 01:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28274 for ; Tue, 9 Jul 2002 01:09:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02919 for ; Tue, 9 Jul 2002 01:08:06 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn1-331.cisco.com [10.21.97.75]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6957nhJ025423; Mon, 8 Jul 2002 22:07:53 -0700 (PDT) Message-Id: <5.1.1.6.2.20020708144909.024c5198@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 08 Jul 2002 18:23:56 -0700 To: John Peter Tapsell From: Fred Baker Subject: Re: [manet] QoS over a wireless Ad Hoc network Cc: manet@ietf.org, Hi@cs.man.ac.uk In-Reply-To: <18137_2404_1025182433_1@ug002> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 01:53 PM 6/27/2002 +0100, John Peter Tapsell wrote: > I'm trying to find any information on whether I could get QoS over an > Ad-Hoc network. Sorry I'm looking into this late. As someone mentioned, QoS in any network has issues, and in an ad hoc network there are more. It is largely a question of what you want, what radio technologies you are looking at, and what information you have available. Someone said that diffserv gives you N layers of priority and that's it. That is incorrect, from a number of perspectives, and reflects a complete misunderstanding of diffserv. If you're looking at diffserv as an architecture, I'd suggest that you look at RFC 2474/2475 for a good understanding. For a proposed generalized diffserv configuration, you might take a look at http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-00.txt, for which there is an update at ftp://ftpeng.cisco.com/fred/ieprep/Marking.html You will notice that there is only one place where we use priority in a diffserv configuration: where the application requires management of latency or jitter; the key applications for this are in voice and perhaps video. Elastic applications, especially those that use short sessions (a large percentage) don't require that; they require rate management, not jitter management. Probably the most important single question is your radio environment. If you are using a radio technology in which the speakers must vie for access, there are interesting questions of whether two stations that cannot hear each other can interfere from the perspective of a third station. Most radio technologies have interesting problems in transmission physics - water, dirt, and stone can materially get in the way, and often appear to do so randomly. So your most fundamental QoS issues are not issues of message ordering, and cannot be solved by changing that ordering. Of those that can in fact be changed by message ordering, it seems to me that the difficult ones are exacerbated by a radio technology that treats the radio as a shared medium like an Ethernet. The problem there is that in a shared environment, the bandwidth or latency guarantees that one seeks to make are dependent not only on the availability of bandwidth and my own use of it (which is fairly trivial to solve), but on the behavior of others. Even if everyone was only allowed to send one message per time unit, there is no guarantee that they won't all do so just at the instant that I need to be first in line. The way to solve that, generally, involves some form of central scheduler which knows the specific needs of every application running on every device, and also of the transit traffic, and doles out permission as needed. Think deeply about what the words "mobile" and "ad hoc" mean, and I think you'll agree that this is a non-starter in this kind of network. All of which is *not* to say that guarantees of bandwidth, latency, or reliability are impossible, but to say that they are truly difficult in the general case, and even in specific cases have issues. You might find Charlie Perkins QoS-on-AODV draft interesting reading. It has a couple of issues, which I have advised him of in private mail - notably, it has the originator say that he wants a certain bandwidth with a certain worst case delay, but conveys no sense of what the interval is over which the rate is measured. Parekh and Gallager indicate that to perform the calculation of the worst case delay that a data stream will experience end to end, one needs to know both the rate and the burst size of the data stream, and then it is only predictable if the application injects at most that rate *and* each hop en route does something predictable with the packet stream. But it at least allows us to characterize the feasibility of a path. It has the same scaling issues that RFC 2205 RSVP has. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 05:53:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17934 for ; Tue, 9 Jul 2002 05:53:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17476; Tue, 9 Jul 2002 05:27:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17444 for ; Tue, 9 Jul 2002 05:27:38 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17365 for ; Tue, 9 Jul 2002 05:26:45 -0400 (EDT) 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 LAA29121; Tue, 9 Jul 2002 11:27:17 +0200 (MET DST) Message-ID: <3D2AACC5.2010105@telecom.lth.se> Date: Tue, 09 Jul 2002 11:28:37 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Fredrik Alriksson (EAB)" , MANET mailing list CC: Ryuji Wakikawa References: <1F55F6582266314A85A55F6241509B674180B9@Esealnt863.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------090408020207040003020000" Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------090408020207040003020000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Fredrik! For the solution described in the draft, unsolicited gateway advertisments are not neccessary for the correct operation of the protocol. I see your point and I think that it is question of whether a reactive or a more proactive approach should be used. One of the reasons for not recomending gateway advertisement flooding is when you consider the scenario where some nodes might need internet access, and some might not. When flooding of advertisements is being used, packets are being flooded periodicly over all nodes in the ad hoc network, regardsless of their need for internet connectivity. This is where hop_limit (TTL) considerations becomes important since every advertisement is rebroadcasted as long as allowed by the hop_limit. So, what value for this hop_limit should be used? If we choose a too small value we might not reach all nodes, and choosing a high value will introduce lots of traffic. Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary. In the draft we instead propose that the node itself should initiate this process, the gateway discovery process. In the case where there are multiple gateways, the node should upon receiving these advertisements choose the closest gateway. regards, Anders Fredrik Alriksson (EAB) wrote: >Hi Ryuji, > >In what sense are the gateway advertisements unnecessary? > >In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! > >Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. > >Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently. > >Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet interfaces. Can you please elaborate a bit? > >BR, >Fredrik > >>-----Original Message----- >>From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >>Sent: den 8 juli 2002 18:40 >>To: Fredrik.Alriksson@era.ericsson.se >>Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp; >>jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se; >>manet@ietf.org >>Subject: Re: Gateway Advertisements >> >> >> >>Hello Fredrik. >> >>In the draft, unnecessary packets basically indicates un-necessary >>gateway advertisements. For example, if a gateway generates a route >>advertisement every 1 sec, most of router advertisements are redundant >>for manet nodes which have already had a global address. They may >>update lifetime of their global address, but the interval(1sec) is >>still too short for this operations. >> >>Since flooding packets is easy to cause performance damage in manet, >>our approach tries to reduce a number of packets which are >>flooded over >>manet. I think manet nodes should not wait flooded advertisements from >>gateway, instead manet node should discover gateways on their >>initiative. >> >>It is also difficult for gateways to decide TTL for flooded >>advertisements. Expanding ring search technique can not be applied to >>this situation, because advertisements should reach at the edge of >>manet. It can imagine that unnecessary network-wide dissemination of >>advertisements will occur when a gateway sets larger TTL than manet >>scale. >> >>regards, >>ryuji >> >> >>At Mon, 8 Jul 2002 17:27:19 +0200 , >>Fredrik Alriksson (EAB) wrote: >> >>>Hi All, >>> >>>In draft-wakikawa-manet-globalv6-00.txt you claim that >>> >>sending gateway advertisements peridically would generate >>unnecessary packets in the Manet. Can you please explain how >>you came to that conclusion? Our simulation study on MIPMANET >>from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) >>indicates that it actually can decrease the number of packet >>transmissions in the MANET. >> >>>BR, >>>Fredrik >>> >>>--- >>>Fredrik Alriksson, Ericsson Research >>>Email: fredrik.alriksson@ericsson.com >>> >>> > --------------090408020207040003020000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Fredrik!

For the solution described in the draft, unsolicited gateway advertisments are not neccessary
for the correct operation of the protocol.

I see your point and I think that it is question of whether a reactive or a more proactive approach
should be used. One of the reasons for not recomending gateway advertisement flooding is when you consider the scenario where some nodes might need internet access, and some might not.
When flooding of advertisements is being used,  packets are being flooded periodicly over all
nodes in the ad hoc network, regardsless of their need for internet connectivity. This is where hop_limit (TTL) considerations becomes important since every advertisement is rebroadcasted
as long as allowed by the hop_limit. So, what value for this hop_limit should be used? If we choose
a too small value we might not reach all nodes, and choosing a high value will introduce lots of traffic. Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary.
In the draft we instead propose that the node itself should initiate this process, the gateway discovery process. In the case where there are multiple gateways, the node should upon receiving these advertisements choose the closest gateway.

regards,

Anders

Fredrik Alriksson (EAB) wrote:
Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet 
interfaces. Can you please elaborate a bit?

BR,
Fredrik

-----Original Message-----
From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
Sent: den 8 juli 2002 18:40
To: Fredrik.Alriksson@era.ericsson.se
Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
manet@ietf.org
Subject: Re: Gateway Advertisements



Hello Fred
rik.

In the draft, unnecessary packets basically indicates un-necessary
gateway advertisements. For example, if a gateway generates a route
advertisement every 1 sec, most of router advertisements are redundant
for manet nodes which have already had a global address. They may
update lifetime of their global address, but the interval(1sec) is
still too short for this operations.

Since flooding packets is easy to cause performance damage in manet,
our approach tries to reduce a number of packets which are 
flooded over
manet. I think manet nodes should not wait flooded advertisements from
gateway, instead manet node should discover gateways on their
initiative.

It is also difficult for gateways to decide TTL for flooded
advertisements. Expanding ring search technique can not be applied to
this situation, because advertisements should reach at the edge of
manet. It can imagine that unnecessary network-wide dissemination
 of
advertisements will occur when a gateway sets larger TTL than manet
scale.

regards,
ryuji


At Mon, 8 Jul 2002 17:27:19 +0200 ,
Fredrik Alriksson (EAB) wrote:
Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that 
sending gateway advertisements peridically would generate 
unnecessary packets in the Manet. Can you please explain how 
you came to that conclusion? Our simulation study on MIPMANET 
from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
indicates that it actually can decrease the number of packet 
transmissions in the MANET.
BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email: fredrik.alriksson@ericsson.com




--------------090408020207040003020000-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 05:53:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17942 for ; Tue, 9 Jul 2002 05:53:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19442 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 05:54:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17476; Tue, 9 Jul 2002 05:27:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17444 for ; Tue, 9 Jul 2002 05:27:38 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17365 for ; Tue, 9 Jul 2002 05:26:45 -0400 (EDT) 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 LAA29121; Tue, 9 Jul 2002 11:27:17 +0200 (MET DST) Message-ID: <3D2AACC5.2010105@telecom.lth.se> Date: Tue, 09 Jul 2002 11:28:37 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Fredrik Alriksson (EAB)" , MANET mailing list CC: Ryuji Wakikawa References: <1F55F6582266314A85A55F6241509B674180B9@Esealnt863.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------090408020207040003020000" Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------090408020207040003020000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Fredrik! For the solution described in the draft, unsolicited gateway advertisments are not neccessary for the correct operation of the protocol. I see your point and I think that it is question of whether a reactive or a more proactive approach should be used. One of the reasons for not recomending gateway advertisement flooding is when you consider the scenario where some nodes might need internet access, and some might not. When flooding of advertisements is being used, packets are being flooded periodicly over all nodes in the ad hoc network, regardsless of their need for internet connectivity. This is where hop_limit (TTL) considerations becomes important since every advertisement is rebroadcasted as long as allowed by the hop_limit. So, what value for this hop_limit should be used? If we choose a too small value we might not reach all nodes, and choosing a high value will introduce lots of traffic. Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary. In the draft we instead propose that the node itself should initiate this process, the gateway discovery process. In the case where there are multiple gateways, the node should upon receiving these advertisements choose the closest gateway. regards, Anders Fredrik Alriksson (EAB) wrote: >Hi Ryuji, > >In what sense are the gateway advertisements unnecessary? > >In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! > >Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. > >Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently. > >Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet interfaces. Can you please elaborate a bit? > >BR, >Fredrik > >>-----Original Message----- >>From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >>Sent: den 8 juli 2002 18:40 >>To: Fredrik.Alriksson@era.ericsson.se >>Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp; >>jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se; >>manet@ietf.org >>Subject: Re: Gateway Advertisements >> >> >> >>Hello Fredrik. >> >>In the draft, unnecessary packets basically indicates un-necessary >>gateway advertisements. For example, if a gateway generates a route >>advertisement every 1 sec, most of router advertisements are redundant >>for manet nodes which have already had a global address. They may >>update lifetime of their global address, but the interval(1sec) is >>still too short for this operations. >> >>Since flooding packets is easy to cause performance damage in manet, >>our approach tries to reduce a number of packets which are >>flooded over >>manet. I think manet nodes should not wait flooded advertisements from >>gateway, instead manet node should discover gateways on their >>initiative. >> >>It is also difficult for gateways to decide TTL for flooded >>advertisements. Expanding ring search technique can not be applied to >>this situation, because advertisements should reach at the edge of >>manet. It can imagine that unnecessary network-wide dissemination of >>advertisements will occur when a gateway sets larger TTL than manet >>scale. >> >>regards, >>ryuji >> >> >>At Mon, 8 Jul 2002 17:27:19 +0200 , >>Fredrik Alriksson (EAB) wrote: >> >>>Hi All, >>> >>>In draft-wakikawa-manet-globalv6-00.txt you claim that >>> >>sending gateway advertisements peridically would generate >>unnecessary packets in the Manet. Can you please explain how >>you came to that conclusion? Our simulation study on MIPMANET >>from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) >>indicates that it actually can decrease the number of packet >>transmissions in the MANET. >> >>>BR, >>>Fredrik >>> >>>--- >>>Fredrik Alriksson, Ericsson Research >>>Email: fredrik.alriksson@ericsson.com >>> >>> > --------------090408020207040003020000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Fredrik!

For the solution described in the draft, unsolicited gateway advertisments are not neccessary
for the correct operation of the protocol.

I see your point and I think that it is question of whether a reactive or a more proactive approach
should be used. One of the reasons for not recomending gateway advertisement flooding is when you consider the scenario where some nodes might need internet access, and some might not.
When flooding of advertisements is being used,  packets are being flooded periodicly over all
nodes in the ad hoc network, regardsless of their need for internet connectivity. This is where hop_limit (TTL) considerations becomes important since every advertisement is rebroadcasted
as long as allowed by the hop_limit. So, what value for this hop_limit should be used? If we choose
a too small value we might not reach all nodes, and choosing a high value will introduce lots of traffic. Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary.
In the draft we instead propose that the node itself should initiate this process, the gateway discovery process. In the case where there are multiple gateways, the node should upon receiving these advertisements choose the closest gateway.

regards,

Anders

Fredrik Alriksson (EAB) wrote:
Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet 
interfaces. Can you please elaborate a bit?

BR,
Fredrik

-----Original Message-----
From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
Sent: den 8 juli 2002 18:40
To: Fredrik.Alriksson@era.ericsson.se
Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
manet@ietf.org
Subject: Re: Gateway Advertisements



Hello Fred
rik.

In the draft, unnecessary packets basically indicates un-necessary
gateway advertisements. For example, if a gateway generates a route
advertisement every 1 sec, most of router advertisements are redundant
for manet nodes which have already had a global address. They may
update lifetime of their global address, but the interval(1sec) is
still too short for this operations.

Since flooding packets is easy to cause performance damage in manet,
our approach tries to reduce a number of packets which are 
flooded over
manet. I think manet nodes should not wait flooded advertisements from
gateway, instead manet node should discover gateways on their
initiative.

It is also difficult for gateways to decide TTL for flooded
advertisements. Expanding ring search technique can not be applied to
this situation, because advertisements should reach at the edge of
manet. It can imagine that unnecessary network-wide dissemination
 of
advertisements will occur when a gateway sets larger TTL than manet
scale.

regards,
ryuji


At Mon, 8 Jul 2002 17:27:19 +0200 ,
Fredrik Alriksson (EAB) wrote:
Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that 
sending gateway advertisements peridically would generate 
unnecessary packets in the Manet. Can you please explain how 
you came to that conclusion? Our simulation study on MIPMANET 
from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
indicates that it actually can decrease the number of packet 
transmissions in the MANET.
BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email: fredrik.alriksson@ericsson.com




--------------090408020207040003020000-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 06:24:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18666 for ; Tue, 9 Jul 2002 06:24:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20596; Tue, 9 Jul 2002 06:12:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20558 for ; Tue, 9 Jul 2002 06:12:24 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18347 for ; Tue, 9 Jul 2002 06:11:29 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g69AB8520319; Tue, 9 Jul 2002 12:11:09 +0200 (MEST) Date: Tue, 9 Jul 2002 12:11:09 +0200 (MEST) From: Imad AAD To: Kaixin Xu cc: Yougu Yuan , , "Xiaowen (Jason) Liu" Subject: Re: [manet] MAC queuing delay In-Reply-To: <01a201c226bf$f57b6930$4820b383@mirage> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 8 Jul 2002, Kaixin Xu wrote: > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > you then consider the time the backoff timer is suspended when the node > sensing the media is busy and the time for transmitting the RTS and time > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > delay is not rare. However, if you get delay in several seconds, that should > not be common. Hi, You should also consider the packet retransmissions' effect on delays. long delays are common as long you have several collisions and retransmissions, e.g. your scenario. The average delay a packet observes (in a single hop, can be generalized for multi-hop of course) is: (avrg successful pkt. transmission delay) x (avrg number of pkts in the queue) the average number of packets in the queue is high in your simulations (~100) due to high collisions and retransmissions (+ IFSs + increasing backoffs), the "average successful packet transmission delay" is considerably high too, so it's not weird to observe delays of several seconds. hope it helps, imad _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 06:24:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18671 for ; Tue, 9 Jul 2002 06:24:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21617 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 06:25:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20596; Tue, 9 Jul 2002 06:12:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20558 for ; Tue, 9 Jul 2002 06:12:24 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18347 for ; Tue, 9 Jul 2002 06:11:29 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g69AB8520319; Tue, 9 Jul 2002 12:11:09 +0200 (MEST) Date: Tue, 9 Jul 2002 12:11:09 +0200 (MEST) From: Imad AAD To: Kaixin Xu cc: Yougu Yuan , , "Xiaowen (Jason) Liu" Subject: Re: [manet] MAC queuing delay In-Reply-To: <01a201c226bf$f57b6930$4820b383@mirage> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 8 Jul 2002, Kaixin Xu wrote: > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > you then consider the time the backoff timer is suspended when the node > sensing the media is busy and the time for transmitting the RTS and time > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > delay is not rare. However, if you get delay in several seconds, that should > not be common. Hi, You should also consider the packet retransmissions' effect on delays. long delays are common as long you have several collisions and retransmissions, e.g. your scenario. The average delay a packet observes (in a single hop, can be generalized for multi-hop of course) is: (avrg successful pkt. transmission delay) x (avrg number of pkts in the queue) the average number of packets in the queue is high in your simulations (~100) due to high collisions and retransmissions (+ IFSs + increasing backoffs), the "average successful packet transmission delay" is considerably high too, so it's not weird to observe delays of several seconds. hope it helps, imad _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 11:16:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28843 for ; Tue, 9 Jul 2002 11:16:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09347; Tue, 9 Jul 2002 11:00:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09282 for ; Tue, 9 Jul 2002 11:00:44 -0400 (EDT) Received: from 190-195-35-64.mcttelecom.com (IDENT:root@190-195-35-64.mcttelecom.com [64.35.195.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27935 for ; Tue, 9 Jul 2002 10:59:52 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by 190-195-35-64.mcttelecom.com (8.11.6/8.11.6) with ESMTP id g69F05I02769 for ; Tue, 9 Jul 2002 11:00:06 -0400 Message-ID: <3D2AFA75.8010807@cs.dartmouth.edu> Date: Tue, 09 Jul 2002 11:00:05 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 CC: manet@ietf.org Subject: Re: [manet] MAC queuing delay References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi. I have another question related to MAC queuing delay. The MAC layer maintains a separate queue for each priority. Data packets are normally assigned with a lower priority than control packets from the routing protocols. Is this a common practice? In another word, should it be a requirment in routing protocol specifications or at least a "strong" recommendation? In the simulation, at least in one setup, we observed much smaller delays for routing packets through the MAC layer if we assign a higher prirority to them than to normal packets. I assume smaller delays for routing packets would have nontrivial impact to the throughput, etc. Also, can someone tell me whether broadcast messages are treated the same as unicast messages in 802.11 in terms of queuing? It seems to me broadcast messages should be given higher priority, even if they come from the same routing protocol. Thanks. -jason. Dartmouth College. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 12:01:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00704 for ; Tue, 9 Jul 2002 12:00:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12741; Tue, 9 Jul 2002 11:38:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12712 for ; Tue, 9 Jul 2002 11:38:44 -0400 (EDT) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29492 for ; Tue, 9 Jul 2002 11:37:51 -0400 (EDT) Message-ID: <20020709153843.41378.qmail@web21009.mail.yahoo.com> Received: from [65.88.242.115] by web21009.mail.yahoo.com via HTTP; Tue, 09 Jul 2002 08:38:43 PDT Date: Tue, 9 Jul 2002 08:38:43 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] MAC queuing delay To: "Xiaowen \(Jason\) Liu" Cc: manet@ietf.org In-Reply-To: <3D2AFA75.8010807@cs.dartmouth.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Jason In current IEEE 802.11 standards, there is not priority at all. Only one queue should be used, and all packets (data or control) are FIFO in the queue. MAC should have no knowledge about the important data or non-important data from higher layer, such as "control packets from the routing protocols" will be treated as normal payloads. Regards Yang --- "Xiaowen (Jason) Liu" wrote: > Hi. > > I have another question related to MAC queuing delay. The MAC layer > maintains a separate queue for each priority. Data packets are > normally > assigned with a lower priority than control packets from the routing > protocols. Is this a common practice? In another word, should it be a > > requirment in routing protocol specifications or at least a "strong" > recommendation? In the simulation, at least in one setup, we observed > > much smaller delays for routing packets through the MAC layer if we > assign a higher prirority to them than to normal packets. I assume > smaller delays for routing packets would have nontrivial impact to > the > throughput, etc. > > Also, can someone tell me whether broadcast messages are treated the > same as unicast messages in 802.11 in terms of queuing? It seems to > me > broadcast messages should be given higher priority, even if they come > > from the same routing protocol. > > Thanks. > > -jason. > > Dartmouth College. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 12:01:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00715 for ; Tue, 9 Jul 2002 12:01:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16303 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 12:01:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12741; Tue, 9 Jul 2002 11:38:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12712 for ; Tue, 9 Jul 2002 11:38:44 -0400 (EDT) Received: from web21009.mail.yahoo.com (web21009.mail.yahoo.com [216.136.227.63]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29492 for ; Tue, 9 Jul 2002 11:37:51 -0400 (EDT) Message-ID: <20020709153843.41378.qmail@web21009.mail.yahoo.com> Received: from [65.88.242.115] by web21009.mail.yahoo.com via HTTP; Tue, 09 Jul 2002 08:38:43 PDT Date: Tue, 9 Jul 2002 08:38:43 -0700 (PDT) From: Yang Xiao Reply-To: YangXiao@IEEE.ORG Subject: Re: [manet] MAC queuing delay To: "Xiaowen \(Jason\) Liu" Cc: manet@ietf.org In-Reply-To: <3D2AFA75.8010807@cs.dartmouth.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Jason In current IEEE 802.11 standards, there is not priority at all. Only one queue should be used, and all packets (data or control) are FIFO in the queue. MAC should have no knowledge about the important data or non-important data from higher layer, such as "control packets from the routing protocols" will be treated as normal payloads. Regards Yang --- "Xiaowen (Jason) Liu" wrote: > Hi. > > I have another question related to MAC queuing delay. The MAC layer > maintains a separate queue for each priority. Data packets are > normally > assigned with a lower priority than control packets from the routing > protocols. Is this a common practice? In another word, should it be a > > requirment in routing protocol specifications or at least a "strong" > recommendation? In the simulation, at least in one setup, we observed > > much smaller delays for routing packets through the MAC layer if we > assign a higher prirority to them than to normal packets. I assume > smaller delays for routing packets would have nontrivial impact to > the > throughput, etc. > > Also, can someone tell me whether broadcast messages are treated the > same as unicast messages in 802.11 in terms of queuing? It seems to > me > broadcast messages should be given higher priority, even if they come > > from the same routing protocol. > > Thanks. > > -jason. > > Dartmouth College. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 12:06:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01009 for ; Tue, 9 Jul 2002 12:05:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13362; Tue, 9 Jul 2002 11:44:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13329 for ; Tue, 9 Jul 2002 11:44:23 -0400 (EDT) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29736 for ; Tue, 9 Jul 2002 11:43:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id 7C34668A61; Tue, 9 Jul 2002 10:43:45 -0500 (CDT) Received: from egress.ece.rice.edu (egress.ece.rice.edu [128.42.12.74]) by ece.rice.edu (Postfix) with ESMTP id 2BB1468A5F; Tue, 9 Jul 2002 10:43:44 -0500 (CDT) Received: from localhost (kanodia@localhost) by egress.ece.rice.edu (8.9.3/8.9.3) with ESMTP id KAA11725; Tue, 9 Jul 2002 10:43:44 -0500 X-Authentication-Warning: egress.ece.rice.edu: kanodia owned process doing -bs Date: Tue, 9 Jul 2002 10:43:44 -0500 (CDT) From: Vikram Kanodia X-Sender: kanodia@egress.ece.rice.edu To: Imad AAD Cc: Kaixin Xu , Yougu Yuan , manet@ietf.org, "Xiaowen (Jason) Liu" Subject: Re: [manet] MAC queuing delay In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org delay of couple of seconds in high load scenarios (total offered load ~ 80% capacity, number of nodes > 25) is consistent with what we observed in some of our ns simulations. We traced the cause back to mainly, large number of collissions (in the heavy load case) leading to queue buildup at the interface queue (the queue length was set to a large value in our case to avoid dropping) leading to high delay. -Vikram > > > On Mon, 8 Jul 2002, Kaixin Xu wrote: > > > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > > you then consider the time the backoff timer is suspended when the node > > sensing the media is busy and the time for transmitting the RTS and time > > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > > delay is not rare. However, if you get delay in several seconds, that should > > not be common. > > Hi, > > You should also consider the packet retransmissions' effect on delays. > > long delays are common as long you have several collisions and > retransmissions, e.g. your scenario. > > The average delay a packet observes (in a single hop, can be generalized > for multi-hop of course) is: > (avrg successful pkt. transmission delay) x (avrg number of pkts in the queue) > > the average number of packets in the queue is high in your simulations > (~100) > > due to high collisions and retransmissions (+ IFSs + increasing backoffs), > the "average successful packet transmission delay" is considerably high too, > so it's not weird to observe delays of several seconds. > > hope it helps, > > imad > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 12:06:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01020 for ; Tue, 9 Jul 2002 12:06:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16654 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 12:06:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13362; Tue, 9 Jul 2002 11:44:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13329 for ; Tue, 9 Jul 2002 11:44:23 -0400 (EDT) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29736 for ; Tue, 9 Jul 2002 11:43:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id 7C34668A61; Tue, 9 Jul 2002 10:43:45 -0500 (CDT) Received: from egress.ece.rice.edu (egress.ece.rice.edu [128.42.12.74]) by ece.rice.edu (Postfix) with ESMTP id 2BB1468A5F; Tue, 9 Jul 2002 10:43:44 -0500 (CDT) Received: from localhost (kanodia@localhost) by egress.ece.rice.edu (8.9.3/8.9.3) with ESMTP id KAA11725; Tue, 9 Jul 2002 10:43:44 -0500 X-Authentication-Warning: egress.ece.rice.edu: kanodia owned process doing -bs Date: Tue, 9 Jul 2002 10:43:44 -0500 (CDT) From: Vikram Kanodia X-Sender: kanodia@egress.ece.rice.edu To: Imad AAD Cc: Kaixin Xu , Yougu Yuan , manet@ietf.org, "Xiaowen (Jason) Liu" Subject: Re: [manet] MAC queuing delay In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org delay of couple of seconds in high load scenarios (total offered load ~ 80% capacity, number of nodes > 25) is consistent with what we observed in some of our ns simulations. We traced the cause back to mainly, large number of collissions (in the heavy load case) leading to queue buildup at the interface queue (the queue length was set to a large value in our case to avoid dropping) leading to high delay. -Vikram > > > On Mon, 8 Jul 2002, Kaixin Xu wrote: > > > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > > you then consider the time the backoff timer is suspended when the node > > sensing the media is busy and the time for transmitting the RTS and time > > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > > delay is not rare. However, if you get delay in several seconds, that should > > not be common. > > Hi, > > You should also consider the packet retransmissions' effect on delays. > > long delays are common as long you have several collisions and > retransmissions, e.g. your scenario. > > The average delay a packet observes (in a single hop, can be generalized > for multi-hop of course) is: > (avrg successful pkt. transmission delay) x (avrg number of pkts in the queue) > > the average number of packets in the queue is high in your simulations > (~100) > > due to high collisions and retransmissions (+ IFSs + increasing backoffs), > the "average successful packet transmission delay" is considerably high too, > so it's not weird to observe delays of several seconds. > > hope it helps, > > imad > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 12:10:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28849 for ; Tue, 9 Jul 2002 11:16:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10944 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 11:17:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09347; Tue, 9 Jul 2002 11:00:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09282 for ; Tue, 9 Jul 2002 11:00:44 -0400 (EDT) Received: from 190-195-35-64.mcttelecom.com (IDENT:root@190-195-35-64.mcttelecom.com [64.35.195.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27935 for ; Tue, 9 Jul 2002 10:59:52 -0400 (EDT) Received: from cs.dartmouth.edu (IDENT:xjliux@localhost.localdomain [127.0.0.1]) by 190-195-35-64.mcttelecom.com (8.11.6/8.11.6) with ESMTP id g69F05I02769 for ; Tue, 9 Jul 2002 11:00:06 -0400 Message-ID: <3D2AFA75.8010807@cs.dartmouth.edu> Date: Tue, 09 Jul 2002 11:00:05 -0400 From: "Xiaowen (Jason) Liu" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us, zh-cn, zh-tw MIME-Version: 1.0 CC: manet@ietf.org Subject: Re: [manet] MAC queuing delay References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi. I have another question related to MAC queuing delay. The MAC layer maintains a separate queue for each priority. Data packets are normally assigned with a lower priority than control packets from the routing protocols. Is this a common practice? In another word, should it be a requirment in routing protocol specifications or at least a "strong" recommendation? In the simulation, at least in one setup, we observed much smaller delays for routing packets through the MAC layer if we assign a higher prirority to them than to normal packets. I assume smaller delays for routing packets would have nontrivial impact to the throughput, etc. Also, can someone tell me whether broadcast messages are treated the same as unicast messages in 802.11 in terms of queuing? It seems to me broadcast messages should be given higher priority, even if they come from the same routing protocol. Thanks. -jason. Dartmouth College. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 12:53:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02969 for ; Tue, 9 Jul 2002 12:53:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17611; Tue, 9 Jul 2002 12:24:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17484 for ; Tue, 9 Jul 2002 12:24:31 -0400 (EDT) Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01784 for ; Tue, 9 Jul 2002 12:23:38 -0400 (EDT) Received: from gatekeeper.ececs.uc.edu (gatekeeper.ececs.uc.edu [10.63.3.227]) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g69GNtn9020614 for ; Tue, 9 Jul 2002 12:23:55 -0400 (EDT) Received: from localhost (jains@localhost) by gatekeeper.ececs.uc.edu (8.10.2+Sun/8.9.1) with ESMTP id g69GNtK29132 for ; Tue, 9 Jul 2002 12:23:55 -0400 (EDT) X-Authentication-Warning: gatekeeper.ececs.uc.edu: jains owned process doing -bs Date: Tue, 9 Jul 2002 12:23:54 -0400 (EDT) From: Saurabh Jain To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] 802.11 implementation in ns-2 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi! There was a discussion some time back that the CMU/Monarch implementation of 802.11 in ns-2 is dated. It is based on older 900Mhz radios, not 802.11b or 802.11a. The paper "Effects of Wireless Physical Layer Modelling in Mobile Ad Hoc Networks" from UCLA also discusses this. Has anyone developed a better 802.11b ns-2 MAC layer since then? If not, would anyone be interested in helping me create one? Thanks Saurabh Jain -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ saurabh@ee.iitm.ernet.in Home: +1-513-556-7447, Lab: 556-3437 #511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219 SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42 Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 12:53:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02976 for ; Tue, 9 Jul 2002 12:53:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20951 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 12:54:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17611; Tue, 9 Jul 2002 12:24:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17484 for ; Tue, 9 Jul 2002 12:24:31 -0400 (EDT) Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01784 for ; Tue, 9 Jul 2002 12:23:38 -0400 (EDT) Received: from gatekeeper.ececs.uc.edu (gatekeeper.ececs.uc.edu [10.63.3.227]) by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g69GNtn9020614 for ; Tue, 9 Jul 2002 12:23:55 -0400 (EDT) Received: from localhost (jains@localhost) by gatekeeper.ececs.uc.edu (8.10.2+Sun/8.9.1) with ESMTP id g69GNtK29132 for ; Tue, 9 Jul 2002 12:23:55 -0400 (EDT) X-Authentication-Warning: gatekeeper.ececs.uc.edu: jains owned process doing -bs Date: Tue, 9 Jul 2002 12:23:54 -0400 (EDT) From: Saurabh Jain To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] 802.11 implementation in ns-2 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi! There was a discussion some time back that the CMU/Monarch implementation of 802.11 in ns-2 is dated. It is based on older 900Mhz radios, not 802.11b or 802.11a. The paper "Effects of Wireless Physical Layer Modelling in Mobile Ad Hoc Networks" from UCLA also discusses this. Has anyone developed a better 802.11b ns-2 MAC layer since then? If not, would anyone be interested in helping me create one? Thanks Saurabh Jain -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ saurabh@ee.iitm.ernet.in Home: +1-513-556-7447, Lab: 556-3437 #511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219 SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42 Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 13:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03441 for ; Tue, 9 Jul 2002 13:03:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18960; Tue, 9 Jul 2002 12:36:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18908 for ; Tue, 9 Jul 2002 12:36:01 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02186 for ; Tue, 9 Jul 2002 12:35:07 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117124>; Tue, 9 Jul 2002 10:35:52 -0600 Message-Id: <02Jul9.103552mdt.117124@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Vikram Kanodia Cc: manet@ietf.org Subject: RE: [manet] MAC queuing delay Date: Tue, 9 Jul 2002 10:35:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, This is one down side of large queue capacities. Wireless nets will undergo throughput foldover, in which higher loads lead to lower throughput, at high loads, such as you have here. The primary cause is higher rates of data collisions at points of congestion. The large queues permit the load to be stored in the net itself, usually directly upstream of the congestion points. As the packets are retransmitted, the local data collision problem is aggravated, leading to more retransmissions and collisions, etc. The trick to traffic management is to try to avoid this cascading effect of increasing data collisions. If the protocol supports windowing, packets will be held at the source when the system is congested, rather than at the intermediate nodes. This reduces retransmissions by not placing the packets on the web when it is overloaded. In addition, it distributes the packets differently, so many are not immediately upstream of the congestion point. If, in addition, the source nodes employ a priority and urgency system, lower priority and highly urgent messages will time out and never appear on the net. This would be, of course, managed at the higher OSI levels, rather than the MAC layer, though input form the MAC layer may be used. John Mullen -----Original Message----- From: Vikram Kanodia [mailto:kanodia@rice.edu] Sent: Tuesday, July 09, 2002 9:44 AM To: Imad AAD Cc: Kaixin Xu; Yougu Yuan; manet@ietf.org; Xiaowen (Jason) Liu Subject: Re: [manet] MAC queuing delay delay of couple of seconds in high load scenarios (total offered load ~ 80% capacity, number of nodes > 25) is consistent with what we observed in some of our ns simulations. We traced the cause back to mainly, large number of collissions (in the heavy load case) leading to queue buildup at the interface queue (the queue length was set to a large value in our case to avoid dropping) leading to high delay. -Vikram > > > On Mon, 8 Jul 2002, Kaixin Xu wrote: > > > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > > you then consider the time the backoff timer is suspended when the node > > sensing the media is busy and the time for transmitting the RTS and time > > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > > delay is not rare. However, if you get delay in several seconds, that should > > not be common. > > Hi, > > You should also consider the packet retransmissions' effect on delays. > > long delays are common as long you have several collisions and > retransmissions, e.g. your scenario. > > The average delay a packet observes (in a single hop, can be generalized > for multi-hop of course) is: > (avrg successful pkt. transmission delay) x (avrg number of pkts in the queue) > > the average number of packets in the queue is high in your simulations > (~100) > > due to high collisions and retransmissions (+ IFSs + increasing backoffs), > the "average successful packet transmission delay" is considerably high too, > so it's not weird to observe delays of several seconds. > > hope it helps, > > imad > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 13:03:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03451 for ; Tue, 9 Jul 2002 13:03:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22160 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 13:03:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18960; Tue, 9 Jul 2002 12:36:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18908 for ; Tue, 9 Jul 2002 12:36:01 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02186 for ; Tue, 9 Jul 2002 12:35:07 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117124>; Tue, 9 Jul 2002 10:35:52 -0600 Message-Id: <02Jul9.103552mdt.117124@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Vikram Kanodia Cc: manet@ietf.org Subject: RE: [manet] MAC queuing delay Date: Tue, 9 Jul 2002 10:35:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, This is one down side of large queue capacities. Wireless nets will undergo throughput foldover, in which higher loads lead to lower throughput, at high loads, such as you have here. The primary cause is higher rates of data collisions at points of congestion. The large queues permit the load to be stored in the net itself, usually directly upstream of the congestion points. As the packets are retransmitted, the local data collision problem is aggravated, leading to more retransmissions and collisions, etc. The trick to traffic management is to try to avoid this cascading effect of increasing data collisions. If the protocol supports windowing, packets will be held at the source when the system is congested, rather than at the intermediate nodes. This reduces retransmissions by not placing the packets on the web when it is overloaded. In addition, it distributes the packets differently, so many are not immediately upstream of the congestion point. If, in addition, the source nodes employ a priority and urgency system, lower priority and highly urgent messages will time out and never appear on the net. This would be, of course, managed at the higher OSI levels, rather than the MAC layer, though input form the MAC layer may be used. John Mullen -----Original Message----- From: Vikram Kanodia [mailto:kanodia@rice.edu] Sent: Tuesday, July 09, 2002 9:44 AM To: Imad AAD Cc: Kaixin Xu; Yougu Yuan; manet@ietf.org; Xiaowen (Jason) Liu Subject: Re: [manet] MAC queuing delay delay of couple of seconds in high load scenarios (total offered load ~ 80% capacity, number of nodes > 25) is consistent with what we observed in some of our ns simulations. We traced the cause back to mainly, large number of collissions (in the heavy load case) leading to queue buildup at the interface queue (the queue length was set to a large value in our case to avoid dropping) leading to high delay. -Vikram > > > On Mon, 8 Jul 2002, Kaixin Xu wrote: > > > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. If > > you then consider the time the backoff timer is suspended when the node > > sensing the media is busy and the time for transmitting the RTS and time > > for waitting CTS timeout several times, blah, blah. I think hundreds of ms > > delay is not rare. However, if you get delay in several seconds, that should > > not be common. > > Hi, > > You should also consider the packet retransmissions' effect on delays. > > long delays are common as long you have several collisions and > retransmissions, e.g. your scenario. > > The average delay a packet observes (in a single hop, can be generalized > for multi-hop of course) is: > (avrg successful pkt. transmission delay) x (avrg number of pkts in the queue) > > the average number of packets in the queue is high in your simulations > (~100) > > due to high collisions and retransmissions (+ IFSs + increasing backoffs), > the "average successful packet transmission delay" is considerably high too, > so it's not weird to observe delays of several seconds. > > hope it helps, > > imad > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 13:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03533 for ; Tue, 9 Jul 2002 13:05:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20092; Tue, 9 Jul 2002 12:46:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20066 for ; Tue, 9 Jul 2002 12:45:58 -0400 (EDT) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02592 for ; Tue, 9 Jul 2002 12:45:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id C021568A61; Tue, 9 Jul 2002 11:45:26 -0500 (CDT) Received: from egress.ece.rice.edu (egress.ece.rice.edu [128.42.12.74]) by ece.rice.edu (Postfix) with ESMTP id 29D5068A60; Tue, 9 Jul 2002 11:45:23 -0500 (CDT) Received: from localhost (kanodia@localhost) by egress.ece.rice.edu (8.9.3/8.9.3) with ESMTP id LAA12050; Tue, 9 Jul 2002 11:45:23 -0500 X-Authentication-Warning: egress.ece.rice.edu: kanodia owned process doing -bs Date: Tue, 9 Jul 2002 11:45:23 -0500 (CDT) From: Vikram Kanodia X-Sender: kanodia@egress.ece.rice.edu To: "Mullen, John P. (Contractor)" Cc: manet@ietf.org Subject: RE: [manet] MAC queuing delay In-Reply-To: <02Jul9.103552mdt.117124@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org True and well put if I may say so :). Also, some sort of priority scheduling at the MAC layer can help alleviate the problem. More to the point, any scheduling algorithm which can reduce the net number of collisions (and thereby reducing retransmissions) will help. Check out our Mobicom 2001 paper: Distributed Multi-Hop Scheduling with Delay and Throughput Constraints, V. Kanodia, C. Li, A. Sabharwal, B. Sadeghi, and E. Knightly. In Proceedings of ACM MOBICOM 2001, Rome, Italy, July 2001. Also, any sort of queue management (Diffserv? the new proposed E-DCF ? coupled with admission control ?) may help insulate the higher priority flows from queue overload due to bursty/higher-input-load best effort flows. While at this point, can someone tell me what is teh existing status of the IEEE 802.11e working group. Has the proposal for EDCF been finalised ? -Vikram > Hi, > > This is one down side of large queue capacities. Wireless nets will undergo > throughput foldover, in which higher loads lead to lower throughput, at high > loads, such as you have here. The primary cause is higher rates of data > collisions at points of congestion. The large queues permit the load to be > stored in the net itself, usually directly upstream of the congestion > points. As the packets are retransmitted, the local data collision problem > is aggravated, leading to more retransmissions and collisions, etc. The > trick to traffic management is to try to avoid this cascading effect of > increasing data collisions. > > If the protocol supports windowing, packets will be held at the source when > the system is congested, rather than at the intermediate nodes. This > reduces retransmissions by not placing the packets on the web when it is > overloaded. In addition, it distributes the packets differently, so many > are not immediately upstream of the congestion point. If, in addition, the > source nodes employ a priority and urgency system, lower priority and highly > urgent messages will time out and never appear on the net. > > This would be, of course, managed at the higher OSI levels, rather than the > MAC layer, though input form the MAC layer may be used. > > John Mullen > > -----Original Message----- > From: Vikram Kanodia [mailto:kanodia@rice.edu] > Sent: Tuesday, July 09, 2002 9:44 AM > To: Imad AAD > Cc: Kaixin Xu; Yougu Yuan; manet@ietf.org; Xiaowen (Jason) Liu > Subject: Re: [manet] MAC queuing delay > > > > delay of couple of seconds in high load scenarios (total offered load ~ > 80% capacity, number of nodes > 25) is consistent with what we observed in > some of our ns simulations. We traced the cause back to mainly, large > number of collissions (in the heavy load case) leading to queue buildup at > the interface queue (the queue length was set to a large value in our case > to avoid dropping) leading to high delay. > > -Vikram > > > > > > > > On Mon, 8 Jul 2002, Kaixin Xu wrote: > > > > > > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > > > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > > > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > > > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. > If > > > you then consider the time the backoff timer is suspended when the node > > > sensing the media is busy and the time for transmitting the RTS and > time > > > for waitting CTS timeout several times, blah, blah. I think hundreds of > ms > > > delay is not rare. However, if you get delay in several seconds, that > should > > > not be common. > > > > Hi, > > > > You should also consider the packet retransmissions' effect on delays. > > > > long delays are common as long you have several collisions and > > retransmissions, e.g. your scenario. > > > > The average delay a packet observes (in a single hop, can be generalized > > for multi-hop of course) is: > > (avrg successful pkt. transmission delay) x (avrg number of pkts in the > queue) > > > > the average number of packets in the queue is high in your simulations > > (~100) > > > > due to high collisions and retransmissions (+ IFSs + increasing backoffs), > > the "average successful packet transmission delay" is considerably high > too, > > so it's not weird to observe delays of several seconds. > > > > hope it helps, > > > > imad > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 13:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03539 for ; Tue, 9 Jul 2002 13:05:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22229 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 13:05:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20092; Tue, 9 Jul 2002 12:46:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20066 for ; Tue, 9 Jul 2002 12:45:58 -0400 (EDT) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02592 for ; Tue, 9 Jul 2002 12:45:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id C021568A61; Tue, 9 Jul 2002 11:45:26 -0500 (CDT) Received: from egress.ece.rice.edu (egress.ece.rice.edu [128.42.12.74]) by ece.rice.edu (Postfix) with ESMTP id 29D5068A60; Tue, 9 Jul 2002 11:45:23 -0500 (CDT) Received: from localhost (kanodia@localhost) by egress.ece.rice.edu (8.9.3/8.9.3) with ESMTP id LAA12050; Tue, 9 Jul 2002 11:45:23 -0500 X-Authentication-Warning: egress.ece.rice.edu: kanodia owned process doing -bs Date: Tue, 9 Jul 2002 11:45:23 -0500 (CDT) From: Vikram Kanodia X-Sender: kanodia@egress.ece.rice.edu To: "Mullen, John P. (Contractor)" Cc: manet@ietf.org Subject: RE: [manet] MAC queuing delay In-Reply-To: <02Jul9.103552mdt.117124@gw.trac.wsmr.army.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org True and well put if I may say so :). Also, some sort of priority scheduling at the MAC layer can help alleviate the problem. More to the point, any scheduling algorithm which can reduce the net number of collisions (and thereby reducing retransmissions) will help. Check out our Mobicom 2001 paper: Distributed Multi-Hop Scheduling with Delay and Throughput Constraints, V. Kanodia, C. Li, A. Sabharwal, B. Sadeghi, and E. Knightly. In Proceedings of ACM MOBICOM 2001, Rome, Italy, July 2001. Also, any sort of queue management (Diffserv? the new proposed E-DCF ? coupled with admission control ?) may help insulate the higher priority flows from queue overload due to bursty/higher-input-load best effort flows. While at this point, can someone tell me what is teh existing status of the IEEE 802.11e working group. Has the proposal for EDCF been finalised ? -Vikram > Hi, > > This is one down side of large queue capacities. Wireless nets will undergo > throughput foldover, in which higher loads lead to lower throughput, at high > loads, such as you have here. The primary cause is higher rates of data > collisions at points of congestion. The large queues permit the load to be > stored in the net itself, usually directly upstream of the congestion > points. As the packets are retransmitted, the local data collision problem > is aggravated, leading to more retransmissions and collisions, etc. The > trick to traffic management is to try to avoid this cascading effect of > increasing data collisions. > > If the protocol supports windowing, packets will be held at the source when > the system is congested, rather than at the intermediate nodes. This > reduces retransmissions by not placing the packets on the web when it is > overloaded. In addition, it distributes the packets differently, so many > are not immediately upstream of the congestion point. If, in addition, the > source nodes employ a priority and urgency system, lower priority and highly > urgent messages will time out and never appear on the net. > > This would be, of course, managed at the higher OSI levels, rather than the > MAC layer, though input form the MAC layer may be used. > > John Mullen > > -----Original Message----- > From: Vikram Kanodia [mailto:kanodia@rice.edu] > Sent: Tuesday, July 09, 2002 9:44 AM > To: Imad AAD > Cc: Kaixin Xu; Yougu Yuan; manet@ietf.org; Xiaowen (Jason) Liu > Subject: Re: [manet] MAC queuing delay > > > > delay of couple of seconds in high load scenarios (total offered load ~ > 80% capacity, number of nodes > 25) is consistent with what we observed in > some of our ns simulations. We traced the cause back to mainly, large > number of collissions (in the heavy load case) leading to queue buildup at > the interface queue (the queue length was set to a large value in our case > to avoid dropping) leading to high delay. > > -Vikram > > > > > > > > On Mon, 8 Jul 2002, Kaixin Xu wrote: > > > > > > > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The > > > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023 > > > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest > > > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms. > If > > > you then consider the time the backoff timer is suspended when the node > > > sensing the media is busy and the time for transmitting the RTS and > time > > > for waitting CTS timeout several times, blah, blah. I think hundreds of > ms > > > delay is not rare. However, if you get delay in several seconds, that > should > > > not be common. > > > > Hi, > > > > You should also consider the packet retransmissions' effect on delays. > > > > long delays are common as long you have several collisions and > > retransmissions, e.g. your scenario. > > > > The average delay a packet observes (in a single hop, can be generalized > > for multi-hop of course) is: > > (avrg successful pkt. transmission delay) x (avrg number of pkts in the > queue) > > > > the average number of packets in the queue is high in your simulations > > (~100) > > > > due to high collisions and retransmissions (+ IFSs + increasing backoffs), > > the "average successful packet transmission delay" is considerably high > too, > > so it's not weird to observe delays of several seconds. > > > > hope it helps, > > > > imad > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H) WWW: http://www.ece.rice.edu/~kanodia _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 18:01:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19550 for ; Tue, 9 Jul 2002 18:01:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11241; Tue, 9 Jul 2002 17:28:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11219 for ; Tue, 9 Jul 2002 17:28:22 -0400 (EDT) Received: from xmxpita.excite.com (nat8.excitenetwork.com [63.236.75.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18385 for ; Tue, 9 Jul 2002 17:27:27 -0400 (EDT) Received: by xmxpita.excite.com (Postfix, from userid 110) id E14CFF69B; Tue, 9 Jul 2002 17:27:47 -0400 (EDT) To: manet@ietf.org Received: from [204.198.72.206] by xprdmailfe3.nwk.excite.com via HTTP; Tue, 09 Jul 2002 17:27:47 EST Reply-To: jw2000@excite.com From: "Jack Wang" MIME-Version: 1.0 X-Sender: jw2000@excite.com X-Mailer: PHP Importance: High X-Priority: 1 Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7"; Content-Transfer-Encoding: 7bit Message-Id: <20020709212747.E14CFF69B@xmxpita.excite.com> Date: Tue, 9 Jul 2002 17:27:47 -0400 (EDT) Subject: [manet] Interference in ad hoc network Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.
How about ad hoc network? Are there any published papers about it? Thanks.
Regards,
Jack



Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 18:01:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19558 for ; Tue, 9 Jul 2002 18:01:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14399 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 18:02:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11241; Tue, 9 Jul 2002 17:28:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11219 for ; Tue, 9 Jul 2002 17:28:22 -0400 (EDT) Received: from xmxpita.excite.com (nat8.excitenetwork.com [63.236.75.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18385 for ; Tue, 9 Jul 2002 17:27:27 -0400 (EDT) Received: by xmxpita.excite.com (Postfix, from userid 110) id E14CFF69B; Tue, 9 Jul 2002 17:27:47 -0400 (EDT) To: manet@ietf.org Received: from [204.198.72.206] by xprdmailfe3.nwk.excite.com via HTTP; Tue, 09 Jul 2002 17:27:47 EST Reply-To: jw2000@excite.com From: "Jack Wang" MIME-Version: 1.0 X-Sender: jw2000@excite.com X-Mailer: PHP Importance: High X-Priority: 1 Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7"; Content-Transfer-Encoding: 7bit Message-Id: <20020709212747.E14CFF69B@xmxpita.excite.com> Date: Tue, 9 Jul 2002 17:27:47 -0400 (EDT) Subject: [manet] Interference in ad hoc network Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.
How about ad hoc network? Are there any published papers about it? Thanks.
Regards,
Jack



Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 18:21:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20169 for ; Tue, 9 Jul 2002 18:21:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15165; Tue, 9 Jul 2002 18:10:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15134 for ; Tue, 9 Jul 2002 18:10:18 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19823 for ; Tue, 9 Jul 2002 18:09:23 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Tue, 9 Jul 2002 16:10:14 -0600 Message-Id: <02Jul9.161014mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: jw2000@excite.com Cc: manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Date: Tue, 9 Jul 2002 16:10:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Jack, In a MANET, usually all nodes share the same channel. There are exceptions to this, but you can also think of these exceptions as collections of MANETs that are interfaced with one another. The problem is that in order for a node to receive a packet, it must be tuned to the channel of the sender. If a MANET consists of just three nodes, each broadcasting on its own channel, each receiver would have to be tuned to both of the other node's transmit channels to be sure it doesn't miss anything. That means, each node will need two receivers. In general, if there are n nodes, each would need n-1 receivers. This quickly gets out of hand. Frequency hopping is just a scrambled version of the same situation. If there is just one hop pattern, the transmitter and receiver can be synchronized, but if there is more than one hop pattern, then you will need a separate receiver to keep track of each pattern, or one receiver per frequency to monitor all streams and a sequencer for each active hop pattern. There is a cheat on this. If one uses time division multiplexing, then each node can have its own time slices to use. For example, if there are three nodes, the first uses slices 1, 4, 7, and so on, while the second uses 2, 5, 8, ... and the third 3, 6, 9,... In this way, each node just needs one receiver and, if all goes well, there are no data collisions. However, given the narrow bandwidth of wireless channels, this means each node in a n-node network only gets one n-th of the band to work with. If the need to communicate is evenly spread out, this can work, but in most cases, the offered load is too "lumpy" and, as a result, some nodes have far too little bandwidth while others have far too much. You can do the same with frequency division multiplexing and face pretty much the same problem. Nets with centralized control get around this because the controllers can dynamically allocate frequencies and time slices, notifying each node of what is going on. Because these controllers are in direct contact with each node, these changes can be sent quickly and reliably as needed. However, MANETs do not have centralized control and nodes must keep in touch with each other, often by way of relay hops, to know what they have to do to. Hope this helps, John Mullen -----Original Message----- From: Jack Wang [mailto:jw2000@excite.com] Sent: Tuesday, July 09, 2002 3:28 PM To: manet@ietf.org Subject: [manet] Interference in ad hoc network Importance: High --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.
How about ad hoc network? Are there any published papers about it? Thanks.
Regards,
Jack



Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Jul 9 18:23:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20245 for ; Tue, 9 Jul 2002 18:23:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14392; Tue, 9 Jul 2002 18:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14357 for ; Tue, 9 Jul 2002 18:01:56 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19547 for ; Tue, 9 Jul 2002 18:01:01 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA07374; Tue, 9 Jul 2002 15:01:52 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA00096; Tue, 9 Jul 2002 15:01:52 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g69M1o019954; Tue, 9 Jul 2002 15:01:51 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jul 2002 18:01:50 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A03@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'jw2000@excite.com'" , manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Date: Tue, 9 Jul 2002 18:01:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Within a single MANET, the nodes need to contend for channel access, and perhaps even reduce their transmitter power level (this was discussed recently) so as not to interfere with each other. The basic scheme used in IEEE 802.11 is similar to Ethernet CSMA. Since MANET depends on each node acting as a relay station potentially, all nodes must be capable of hearing one another, if within range. This is essential. You do not rely on base stations for coverage, with MANET. But there's no reason why multiple MANETs can't be created in a given geographical area, is there? If you use IEEE 802.11b for the RF solution, for example, you could assign a different DSSS code to different MANETs, so the nodes of different MANETs will not interfere with one another. This is analogous to your Bluetooth example, where different frequency hop sequences are used. Or you could use a simple frequency divided radio scheme for this too. Just assign a different RF frequency band to each MANET in the area, and let these nodes broadcast to all nodes within reach, within their own MANET. If the packets are explicitly routed, this should work fine. If there are clusters of nodes in a given MANET that are very far apart, you could have cases where intra-cluster traffic of these far-apart clusters occurs simultaneously, without causing interference. That would happen naturally, as the clusters move away from one another, and don't need to worry about hearing other traffic from the remote cluster any longer. Bert -----Original Message----- From: Jack Wang [mailto:jw2000@excite.com] Sent: Tuesday, July 09, 2002 5:28 PM To: manet@ietf.org Subject: [manet] Interference in ad hoc network Importance: High How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency. How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 18:23:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20253 for ; Tue, 9 Jul 2002 18:23:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16162 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 18:23:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14392; Tue, 9 Jul 2002 18:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14357 for ; Tue, 9 Jul 2002 18:01:56 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19547 for ; Tue, 9 Jul 2002 18:01:01 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA07374; Tue, 9 Jul 2002 15:01:52 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA00096; Tue, 9 Jul 2002 15:01:52 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g69M1o019954; Tue, 9 Jul 2002 15:01:51 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jul 2002 18:01:50 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A03@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'jw2000@excite.com'" , manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Date: Tue, 9 Jul 2002 18:01:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Within a single MANET, the nodes need to contend for channel access, and perhaps even reduce their transmitter power level (this was discussed recently) so as not to interfere with each other. The basic scheme used in IEEE 802.11 is similar to Ethernet CSMA. Since MANET depends on each node acting as a relay station potentially, all nodes must be capable of hearing one another, if within range. This is essential. You do not rely on base stations for coverage, with MANET. But there's no reason why multiple MANETs can't be created in a given geographical area, is there? If you use IEEE 802.11b for the RF solution, for example, you could assign a different DSSS code to different MANETs, so the nodes of different MANETs will not interfere with one another. This is analogous to your Bluetooth example, where different frequency hop sequences are used. Or you could use a simple frequency divided radio scheme for this too. Just assign a different RF frequency band to each MANET in the area, and let these nodes broadcast to all nodes within reach, within their own MANET. If the packets are explicitly routed, this should work fine. If there are clusters of nodes in a given MANET that are very far apart, you could have cases where intra-cluster traffic of these far-apart clusters occurs simultaneously, without causing interference. That would happen naturally, as the clusters move away from one another, and don't need to worry about hearing other traffic from the remote cluster any longer. Bert -----Original Message----- From: Jack Wang [mailto:jw2000@excite.com] Sent: Tuesday, July 09, 2002 5:28 PM To: manet@ietf.org Subject: [manet] Interference in ad hoc network Importance: High How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency. How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Jul 9 19:10:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20175 for ; Tue, 9 Jul 2002 18:21:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA16086 for manet-archive@odin.ietf.org; Tue, 9 Jul 2002 18:22:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15165; Tue, 9 Jul 2002 18:10:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15134 for ; Tue, 9 Jul 2002 18:10:18 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19823 for ; Tue, 9 Jul 2002 18:09:23 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Tue, 9 Jul 2002 16:10:14 -0600 Message-Id: <02Jul9.161014mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: jw2000@excite.com Cc: manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Date: Tue, 9 Jul 2002 16:10:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Jack, In a MANET, usually all nodes share the same channel. There are exceptions to this, but you can also think of these exceptions as collections of MANETs that are interfaced with one another. The problem is that in order for a node to receive a packet, it must be tuned to the channel of the sender. If a MANET consists of just three nodes, each broadcasting on its own channel, each receiver would have to be tuned to both of the other node's transmit channels to be sure it doesn't miss anything. That means, each node will need two receivers. In general, if there are n nodes, each would need n-1 receivers. This quickly gets out of hand. Frequency hopping is just a scrambled version of the same situation. If there is just one hop pattern, the transmitter and receiver can be synchronized, but if there is more than one hop pattern, then you will need a separate receiver to keep track of each pattern, or one receiver per frequency to monitor all streams and a sequencer for each active hop pattern. There is a cheat on this. If one uses time division multiplexing, then each node can have its own time slices to use. For example, if there are three nodes, the first uses slices 1, 4, 7, and so on, while the second uses 2, 5, 8, ... and the third 3, 6, 9,... In this way, each node just needs one receiver and, if all goes well, there are no data collisions. However, given the narrow bandwidth of wireless channels, this means each node in a n-node network only gets one n-th of the band to work with. If the need to communicate is evenly spread out, this can work, but in most cases, the offered load is too "lumpy" and, as a result, some nodes have far too little bandwidth while others have far too much. You can do the same with frequency division multiplexing and face pretty much the same problem. Nets with centralized control get around this because the controllers can dynamically allocate frequencies and time slices, notifying each node of what is going on. Because these controllers are in direct contact with each node, these changes can be sent quickly and reliably as needed. However, MANETs do not have centralized control and nodes must keep in touch with each other, often by way of relay hops, to know what they have to do to. Hope this helps, John Mullen -----Original Message----- From: Jack Wang [mailto:jw2000@excite.com] Sent: Tuesday, July 09, 2002 3:28 PM To: manet@ietf.org Subject: [manet] Interference in ad hoc network Importance: High --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency.
How about ad hoc network? Are there any published papers about it? Thanks.
Regards,
Jack



Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__8cdb11f6d0157d59e6d70e8083fae3c7-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 00:03:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26763 for ; Wed, 10 Jul 2002 00:03:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00761; Tue, 9 Jul 2002 23:36:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00731 for ; Tue, 9 Jul 2002 23:36:12 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26229 for ; Tue, 9 Jul 2002 23:35:17 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Jul 9 20:35:29 2002 To: "MANET mailing list" , "Anders Nilsson" Date: Tue, 09 Jul 2002 23:35:29 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] QoS over shared media Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good day, In responce to Nilsson's e-mail, I can't help but think of QoS based on transimission over shared media. To make my point clear ckeck this simple example. Assume A, B, C, D, E, & F are nodes geographically positioned as drawn (just for simplicity). If A needs to transfer a high bandwidth stream to E via C, while B needs a low bandwidth transfer to F via D. It is possible to increase the share of link AC of the bandwidth (since link AC & BD share the same media). A ====> C ====> E B ----> D ----> F The problem is that QoS solutions have always been implemented on IP layer. Implementing this kind of solution will require tight marriage with MAC layer. In addition, the dynamics of varying MAC resources based on the need seem to carry lots of difficulties. My question is whether you can point me to any research done on that area? INSIGNIA, and FQMM (not quite sure about SWAN) they all work on IP layer without investigating this kind of otimization. Does Bluetooth, or 802.11b provide any mean to carry over such ideas? Inputs are highly appreciated. Yasser Carleton University _____________________________________________________ Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads and NoTaglines --> LYCOS MAIL PLUS. http://www.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 00:03:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26772 for ; Wed, 10 Jul 2002 00:03:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA02328 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 00:04:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00761; Tue, 9 Jul 2002 23:36:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00731 for ; Tue, 9 Jul 2002 23:36:12 -0400 (EDT) Received: from mailcity.com (fes3.mail.lycos.com [209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26229 for ; Tue, 9 Jul 2002 23:35:17 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Jul 9 20:35:29 2002 To: "MANET mailing list" , "Anders Nilsson" Date: Tue, 09 Jul 2002 23:35:29 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] QoS over shared media Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good day, In responce to Nilsson's e-mail, I can't help but think of QoS based on transimission over shared media. To make my point clear ckeck this simple example. Assume A, B, C, D, E, & F are nodes geographically positioned as drawn (just for simplicity). If A needs to transfer a high bandwidth stream to E via C, while B needs a low bandwidth transfer to F via D. It is possible to increase the share of link AC of the bandwidth (since link AC & BD share the same media). A ====> C ====> E B ----> D ----> F The problem is that QoS solutions have always been implemented on IP layer. Implementing this kind of solution will require tight marriage with MAC layer. In addition, the dynamics of varying MAC resources based on the need seem to carry lots of difficulties. My question is whether you can point me to any research done on that area? INSIGNIA, and FQMM (not quite sure about SWAN) they all work on IP layer without investigating this kind of otimization. Does Bluetooth, or 802.11b provide any mean to carry over such ideas? Inputs are highly appreciated. Yasser Carleton University _____________________________________________________ Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads and NoTaglines --> LYCOS MAIL PLUS. http://www.mail.lycos.com/brandPage.shtml?pageId=plus _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 06:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26500 for ; Wed, 10 Jul 2002 06:01:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10890; Wed, 10 Jul 2002 05:31:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10848 for ; Wed, 10 Jul 2002 05:31:21 -0400 (EDT) Received: from lkn.e-technik.tu-muenchen.de (root@aperol.LKN.E-Technik.TU-Muenchen.DE [129.187.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25795 for ; Wed, 10 Jul 2002 05:30:26 -0400 (EDT) Received: from ei.tum.de ([129.187.222.44]) by lkn.e-technik.tu-muenchen.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g6A9Usa00689; Wed, 10 Jul 2002 11:30:54 +0200 Message-ID: <3D2BFED8.7BD64FB6@ei.tum.de> Date: Wed, 10 Jul 2002 11:31:04 +0200 From: Jin Xi X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Sessinghaus CC: manet@ietf.org Subject: RE:[manet] AODV and Mobile IP References Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello, Michael, We are doing research in the same direction as Ad hoc Internet access, but not restrict the routing algorithm to AODV. The abstract of a paper on this topic can be found in http://www.lkn.ei.tum.de/lkn/mitarbeiter/chris/publications/xi_bettstetter_3gwireless2002.html. Currently we are working on gateway discovery simulation with Glomosim. More information will be available once the simulation is completed. Regards Jane -- Jin Xi Institute of Communication Networks, Munich University of Technology Building 4, Room 0407, Arcisstr. 21, 80290 Munich, Germany Tel.: +49 (0)89/289-25821, Fax: +49 (0)89/289-23523 mailto:Xi@ei.tum.de, WWW: http://www.lkn.ei.tum.de/~jix _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 06:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26507 for ; Wed, 10 Jul 2002 06:01:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13100 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 06:02:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10890; Wed, 10 Jul 2002 05:31:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10848 for ; Wed, 10 Jul 2002 05:31:21 -0400 (EDT) Received: from lkn.e-technik.tu-muenchen.de (root@aperol.LKN.E-Technik.TU-Muenchen.DE [129.187.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25795 for ; Wed, 10 Jul 2002 05:30:26 -0400 (EDT) Received: from ei.tum.de ([129.187.222.44]) by lkn.e-technik.tu-muenchen.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g6A9Usa00689; Wed, 10 Jul 2002 11:30:54 +0200 Message-ID: <3D2BFED8.7BD64FB6@ei.tum.de> Date: Wed, 10 Jul 2002 11:31:04 +0200 From: Jin Xi X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Sessinghaus CC: manet@ietf.org Subject: RE:[manet] AODV and Mobile IP References Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello, Michael, We are doing research in the same direction as Ad hoc Internet access, but not restrict the routing algorithm to AODV. The abstract of a paper on this topic can be found in http://www.lkn.ei.tum.de/lkn/mitarbeiter/chris/publications/xi_bettstetter_3gwireless2002.html. Currently we are working on gateway discovery simulation with Glomosim. More information will be available once the simulation is completed. Regards Jane -- Jin Xi Institute of Communication Networks, Munich University of Technology Building 4, Room 0407, Arcisstr. 21, 80290 Munich, Germany Tel.: +49 (0)89/289-25821, Fax: +49 (0)89/289-23523 mailto:Xi@ei.tum.de, WWW: http://www.lkn.ei.tum.de/~jix _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 09:55:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02748 for ; Wed, 10 Jul 2002 09:55:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22880; Wed, 10 Jul 2002 09:22:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22847 for ; Wed, 10 Jul 2002 09:22:33 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01608 for ; Wed, 10 Jul 2002 09:21:39 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZRV; Wed, 10 Jul 2002 09:22:29 -0400 Message-ID: <006401c22814$d7369250$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Rex Buddenberg" , "Kuldip Singh Pabla" , "Charles E. Perkins" Cc: References: Subject: Re: [manet] IP addresses in MANET Date: Wed, 10 Jul 2002 09:22:29 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Yasser, Sorry I have not responded to this subject sooner, since it is of great interest to me. I have been on vacation for a spell. > Good day everybody, > > I've been following on the IP addressing proplem, and want to contribute some thoughts > 1) I believe ad hoc will adopt IPv6. Since no comercial solution is available for ad-hoc, it makes absolute sense to use > IPv6 for addressing. This solve the problem of "Internet running out of space" and introduce the problem of "Personal IP" > which is global vs local IP Not quite. We (my company) have some commercially (beta) available MANET solutions that are quite friendly to IPv4. Adopting IPv6 in a small, battery driven device is not really all that feasible yet. A small PDA running an ARM processor has to keep its software workload pretty light. Also the "born on" IP addressing scheme you propose is not feasible for the same reason truly permanent phone numbers are not feasible. There is a security issue and a privacy issue here. You could become vulnerable to all kinds of attacks if your "permanent" IP address is known to some crank. > > 2) Assigning "pool of addresses" for an ad-hoc network is so difficult in the absense of central authority. This means that nodes will have to announce an IP address when joining the network, get authenticated (how the authentication could be done is a different issue), then the nodes can move within the same ad-hoc freely by keeping their IP. When a host attaches to the global Internet it becomes part of the global Internet and extends it. The host in all instances should be reachable, i.e. globally addressable if it is an IPv4 or IPv6 host. The only realistic solution today is Mobile IP. This means that a Mobile IP home address can be acquired from an operator that provides mobility service. The MANET system (doesn't really matter if its DSR, AODV, etc) can route using the home address since the most developed MANET algorithms know nothing of hierarchy. Many of these issues are being addressed by the MONET group. NOTE: I would really like to see a stab at a "classless" MANET routing protocol where the concept of a subnet for a MANET is defined and subnet masks are propogated in route updates. M-CIDR??? > > 3) Local traffic (within the same ad-hoc) can be routed easly. Internet traffic will be subject to (gateway address resolution). Since many gateways may work for the same ad-hoc, we need to guarantee consistency between all gateways. > > This way no central authority is needed which is very consistent with the MANET charter. Also, if an individual nodes has a static IP it should be able to use it. The authentication process can elementate the possibility of IP address conflict. > With respect to the MANET charter, it does not preclude one from using MANET algorithms in a heterogeneous fixed infrastructure and mobile environment. In fact we have found it quite desirable to pepper a coverage area with fixed infrastructure (running MANET algorithms) that provide basic coverage and connectivity to the Internet. My feeling is that this will be the most practical large scaled deployment of MANETs. Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 09:55:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02757 for ; Wed, 10 Jul 2002 09:55:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26243 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 09:56:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22880; Wed, 10 Jul 2002 09:22:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22847 for ; Wed, 10 Jul 2002 09:22:33 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01608 for ; Wed, 10 Jul 2002 09:21:39 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZRV; Wed, 10 Jul 2002 09:22:29 -0400 Message-ID: <006401c22814$d7369250$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Rex Buddenberg" , "Kuldip Singh Pabla" , "Charles E. Perkins" Cc: References: Subject: Re: [manet] IP addresses in MANET Date: Wed, 10 Jul 2002 09:22:29 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Yasser, Sorry I have not responded to this subject sooner, since it is of great interest to me. I have been on vacation for a spell. > Good day everybody, > > I've been following on the IP addressing proplem, and want to contribute some thoughts > 1) I believe ad hoc will adopt IPv6. Since no comercial solution is available for ad-hoc, it makes absolute sense to use > IPv6 for addressing. This solve the problem of "Internet running out of space" and introduce the problem of "Personal IP" > which is global vs local IP Not quite. We (my company) have some commercially (beta) available MANET solutions that are quite friendly to IPv4. Adopting IPv6 in a small, battery driven device is not really all that feasible yet. A small PDA running an ARM processor has to keep its software workload pretty light. Also the "born on" IP addressing scheme you propose is not feasible for the same reason truly permanent phone numbers are not feasible. There is a security issue and a privacy issue here. You could become vulnerable to all kinds of attacks if your "permanent" IP address is known to some crank. > > 2) Assigning "pool of addresses" for an ad-hoc network is so difficult in the absense of central authority. This means that nodes will have to announce an IP address when joining the network, get authenticated (how the authentication could be done is a different issue), then the nodes can move within the same ad-hoc freely by keeping their IP. When a host attaches to the global Internet it becomes part of the global Internet and extends it. The host in all instances should be reachable, i.e. globally addressable if it is an IPv4 or IPv6 host. The only realistic solution today is Mobile IP. This means that a Mobile IP home address can be acquired from an operator that provides mobility service. The MANET system (doesn't really matter if its DSR, AODV, etc) can route using the home address since the most developed MANET algorithms know nothing of hierarchy. Many of these issues are being addressed by the MONET group. NOTE: I would really like to see a stab at a "classless" MANET routing protocol where the concept of a subnet for a MANET is defined and subnet masks are propogated in route updates. M-CIDR??? > > 3) Local traffic (within the same ad-hoc) can be routed easly. Internet traffic will be subject to (gateway address resolution). Since many gateways may work for the same ad-hoc, we need to guarantee consistency between all gateways. > > This way no central authority is needed which is very consistent with the MANET charter. Also, if an individual nodes has a static IP it should be able to use it. The authentication process can elementate the possibility of IP address conflict. > With respect to the MANET charter, it does not preclude one from using MANET algorithms in a heterogeneous fixed infrastructure and mobile environment. In fact we have found it quite desirable to pepper a coverage area with fixed infrastructure (running MANET algorithms) that provide basic coverage and connectivity to the Internet. My feeling is that this will be the most practical large scaled deployment of MANETs. Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 10:16:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03716 for ; Wed, 10 Jul 2002 10:16:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25462; Wed, 10 Jul 2002 09:50:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25432 for ; Wed, 10 Jul 2002 09:50:25 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02450 for ; Wed, 10 Jul 2002 09:49:30 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZTJ; Wed, 10 Jul 2002 09:50:14 -0400 Message-ID: <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Mullen, John P. \(Contractor\)" , References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 09:50:14 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi John, > > Why can't the MANET be treated as a local intranet with each of its nodes > having a common Internet subnet mask (augmented by whatever is needed to > affect routing within the MANET, of course.) Because all current MANET algorithms are classful in the sense that the routing algorithm does not propagate subnet bits masks. How do you define a subnet in a MANET? I have pondered this for quite some time. The only reasonable answer I have currently is to elect a subnet leader and make the neighbors of the leader the subnet. Maybe the neighbors neighbors too. When a node gets to far (too many hops away) from a subnet leader and sees a closer one it can acquire that subnet mask. Of course all the MANET protocols would need to change to support mask propagation. This would take some work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 10:16:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03721 for ; Wed, 10 Jul 2002 10:16:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29017 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 10:17:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25462; Wed, 10 Jul 2002 09:50:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25432 for ; Wed, 10 Jul 2002 09:50:25 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02450 for ; Wed, 10 Jul 2002 09:49:30 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZTJ; Wed, 10 Jul 2002 09:50:14 -0400 Message-ID: <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Mullen, John P. \(Contractor\)" , References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 09:50:14 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi John, > > Why can't the MANET be treated as a local intranet with each of its nodes > having a common Internet subnet mask (augmented by whatever is needed to > affect routing within the MANET, of course.) Because all current MANET algorithms are classful in the sense that the routing algorithm does not propagate subnet bits masks. How do you define a subnet in a MANET? I have pondered this for quite some time. The only reasonable answer I have currently is to elect a subnet leader and make the neighbors of the leader the subnet. Maybe the neighbors neighbors too. When a node gets to far (too many hops away) from a subnet leader and sees a closer one it can acquire that subnet mask. Of course all the MANET protocols would need to change to support mask propagation. This would take some work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 10:16:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03764 for ; Wed, 10 Jul 2002 10:16:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25946; Wed, 10 Jul 2002 09:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25845 for ; Wed, 10 Jul 2002 09:54:17 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02620 for ; Wed, 10 Jul 2002 09:53:22 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117124>; Wed, 10 Jul 2002 07:54:05 -0600 Message-Id: <02Jul10.075405mdt.117124@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" , manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Date: Wed, 10 Jul 2002 07:53:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Good points. However, just a couple of wrinkles. There is certainly no reason you cannot have multiple MANETs in the same geographical region, but some mechanism is needed to assure channels are allocated in a way that will avoid interference. Cellular systems use a supercel of seven channels which is repeated as needed to cover the area. The result is much like a honeycomb. The reused channels are separated by two cell diameters so interference is unlikely. Cellular antennas do not move, so, once established, this pattern reliably prevents interference. However, the hosts in MANETs do move, so there is the additional problem of making sure clusters using the same channel stay far enough apart from each other. The alternative is to give each of the MANETs its own channel, but we need to remember there is only so much BW available. If the different MANETs have occasional need to communicate with each other, some hosts will have to be gateways. These will either need two transceivers each or have to drop out of one MANET to communicate with the other. The first solution would be the best to avoid the need to rejoin after every gateway operation. Then, there is the problem of which hosts are to be gateways. If you cannot be sure that the right host will be in the right place, you may need to have two transceivers in every host. There is also the problem that if each MANET has its own channel, the gateways will have to determine which other MANETs are in the area and which one(s) to join. (Of course, if a gateway joins k other MANETS, it will need k additional transceivers). A way around this is to have a single channel solely for communication between MANETs. Then, each gateway only needs to monitor two channels. Of course, there can be contention on the inter-MANET channel and, using the additional channel reduces BW available for the individual MANETs. Looking more deeply into the matter of available bandwidth, if the band is sliced up among different users, then each user will have less bandwidth available. The most efficient use of a shared resource is usually a pooled approach so that whoever needs higher capacity can get it, without limitations caused by subdividing the band. Of course, there could be security reasons or technical limitations for subdividing. For example, one MANET could be for police, one for fire fighters, one for EMT, etc. However, a fixed allocation will limit the BW available for each. A shared channel allows each to use what they need (up to channel limits). Perhaps, a solution could be a dynamic allocation, in which each MANET has a minimal assignment, but there is a pool of BW which any MANET can use, providing there is a need. Sincerely, John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Tuesday, July 09, 2002 4:02 PM To: 'jw2000@excite.com'; manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Within a single MANET, the nodes need to contend for channel access, and perhaps even reduce their transmitter power level (this was discussed recently) so as not to interfere with each other. The basic scheme used in IEEE 802.11 is similar to Ethernet CSMA. Since MANET depends on each node acting as a relay station potentially, all nodes must be capable of hearing one another, if within range. This is essential. You do not rely on base stations for coverage, with MANET. But there's no reason why multiple MANETs can't be created in a given geographical area, is there? If you use IEEE 802.11b for the RF solution, for example, you could assign a different DSSS code to different MANETs, so the nodes of different MANETs will not interfere with one another. This is analogous to your Bluetooth example, where different frequency hop sequences are used. Or you could use a simple frequency divided radio scheme for this too. Just assign a different RF frequency band to each MANET in the area, and let these nodes broadcast to all nodes within reach, within their own MANET. If the packets are explicitly routed, this should work fine. If there are clusters of nodes in a given MANET that are very far apart, you could have cases where intra-cluster traffic of these far-apart clusters occurs simultaneously, without causing interference. That would happen naturally, as the clusters move away from one another, and don't need to worry about hearing other traffic from the remote cluster any longer. Bert -----Original Message----- From: Jack Wang [mailto:jw2000@excite.com] Sent: Tuesday, July 09, 2002 5:28 PM To: manet@ietf.org Subject: [manet] Interference in ad hoc network Importance: High How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency. How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 10:16:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03770 for ; Wed, 10 Jul 2002 10:16:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29038 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 10:17:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25946; Wed, 10 Jul 2002 09:54:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25845 for ; Wed, 10 Jul 2002 09:54:17 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02620 for ; Wed, 10 Jul 2002 09:53:22 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117124>; Wed, 10 Jul 2002 07:54:05 -0600 Message-Id: <02Jul10.075405mdt.117124@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" , manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Date: Wed, 10 Jul 2002 07:53:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, Good points. However, just a couple of wrinkles. There is certainly no reason you cannot have multiple MANETs in the same geographical region, but some mechanism is needed to assure channels are allocated in a way that will avoid interference. Cellular systems use a supercel of seven channels which is repeated as needed to cover the area. The result is much like a honeycomb. The reused channels are separated by two cell diameters so interference is unlikely. Cellular antennas do not move, so, once established, this pattern reliably prevents interference. However, the hosts in MANETs do move, so there is the additional problem of making sure clusters using the same channel stay far enough apart from each other. The alternative is to give each of the MANETs its own channel, but we need to remember there is only so much BW available. If the different MANETs have occasional need to communicate with each other, some hosts will have to be gateways. These will either need two transceivers each or have to drop out of one MANET to communicate with the other. The first solution would be the best to avoid the need to rejoin after every gateway operation. Then, there is the problem of which hosts are to be gateways. If you cannot be sure that the right host will be in the right place, you may need to have two transceivers in every host. There is also the problem that if each MANET has its own channel, the gateways will have to determine which other MANETs are in the area and which one(s) to join. (Of course, if a gateway joins k other MANETS, it will need k additional transceivers). A way around this is to have a single channel solely for communication between MANETs. Then, each gateway only needs to monitor two channels. Of course, there can be contention on the inter-MANET channel and, using the additional channel reduces BW available for the individual MANETs. Looking more deeply into the matter of available bandwidth, if the band is sliced up among different users, then each user will have less bandwidth available. The most efficient use of a shared resource is usually a pooled approach so that whoever needs higher capacity can get it, without limitations caused by subdividing the band. Of course, there could be security reasons or technical limitations for subdividing. For example, one MANET could be for police, one for fire fighters, one for EMT, etc. However, a fixed allocation will limit the BW available for each. A shared channel allows each to use what they need (up to channel limits). Perhaps, a solution could be a dynamic allocation, in which each MANET has a minimal assignment, but there is a pool of BW which any MANET can use, providing there is a need. Sincerely, John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Tuesday, July 09, 2002 4:02 PM To: 'jw2000@excite.com'; manet@ietf.org Subject: RE: [manet] Interference in ad hoc network Within a single MANET, the nodes need to contend for channel access, and perhaps even reduce their transmitter power level (this was discussed recently) so as not to interfere with each other. The basic scheme used in IEEE 802.11 is similar to Ethernet CSMA. Since MANET depends on each node acting as a relay station potentially, all nodes must be capable of hearing one another, if within range. This is essential. You do not rely on base stations for coverage, with MANET. But there's no reason why multiple MANETs can't be created in a given geographical area, is there? If you use IEEE 802.11b for the RF solution, for example, you could assign a different DSSS code to different MANETs, so the nodes of different MANETs will not interfere with one another. This is analogous to your Bluetooth example, where different frequency hop sequences are used. Or you could use a simple frequency divided radio scheme for this too. Just assign a different RF frequency band to each MANET in the area, and let these nodes broadcast to all nodes within reach, within their own MANET. If the packets are explicitly routed, this should work fine. If there are clusters of nodes in a given MANET that are very far apart, you could have cases where intra-cluster traffic of these far-apart clusters occurs simultaneously, without causing interference. That would happen naturally, as the clusters move away from one another, and don't need to worry about hearing other traffic from the remote cluster any longer. Bert -----Original Message----- From: Jack Wang [mailto:jw2000@excite.com] Sent: Tuesday, July 09, 2002 5:28 PM To: manet@ietf.org Subject: [manet] Interference in ad hoc network Importance: High How to prevent interference in ad hoc network? If there are several node within a node's transmission range, they may interfere with each other. In traditional cellular network, this is done by channel allocation. And in bluetooth, frequency hopping is used and master node of a piconet decides the frequency. How about ad hoc network? Are there any published papers about it? Thanks. Regards, Jack Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 10:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04635 for ; Wed, 10 Jul 2002 10:39:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27557; Wed, 10 Jul 2002 10:08:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27528 for ; Wed, 10 Jul 2002 10:08:39 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03118 for ; Wed, 10 Jul 2002 10:07:44 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZ4B; Wed, 10 Jul 2002 10:08:28 -0400 Message-ID: <00d201c2281b$43fd7fb0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Manfredi, Albert E" , "Mullen, John P. \(Contractor\)" Cc: References: Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:08:28 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > > 1) Nodes should be able to roam freely in the network. If a cellular node connected to the cellular network via address xxxx came into accessable range of a bluetooth MANET based network, it might decide to join. Obviously, the node prefer to keep its xxxx address. NOTE: IP addresses are assigned to interfaces not hosts. In the Bluetooth scenario you mention, you would need to have a seperate Care-of-address on the cell phone network and the Bluetooth network. You could of course maintain your home address at all times. The host has to either be multi-homed (in which case it can route over both interfaces) or it must support MIP with either co-located care-of addresses in IPv6 or a FA in IPv4. > > 2) Imagine the situation when you have many MANET networks scaterd in somewhat geographically limited area. Every network will be able to adminstrate itself (ie assign contiguous IP addresses, and subnet mask). NOTE: I know of no MANET algorithm that can "assign" a subnet mask in the true sense. ZRP has zones. CGSR and CBRP have clusters. > 3) The use of anytype of DHCP requires adminstration both at the node level, and centralized level. In addition, centralized management of MANET contradicts it's charter. No, I don't believe it does. The use of infrastructure is really going to be required by practical MANET implementaitons of any scale. People in general will need to get on the global Internet FROM their MANETs. They will also want to be reachable. > > 4) Users are entitled to have thier own IP addresses. Assume my PDA address is yyyy, and it is a static IP that is recognizable throughout the internet. Part of the IPv6 effort is to allow personal IP addresses. Overiding this address contradicts with IPv6 directions. The only feasible static address here is a mobile IP home address. > > However, I understand that having a pool of contiguous addresses may be the common case. Yet, building the network should be based on the more general case. Having a pool of contiguous addresses is no longer common. CIDR and OSPF/BGP allow many tiny little non-contiguous subnets to be in any ISPs pool of allocatable addresses. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 10:41:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04694 for ; Wed, 10 Jul 2002 10:41:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28434; Wed, 10 Jul 2002 10:13:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28393 for ; Wed, 10 Jul 2002 10:13:35 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03429 for ; Wed, 10 Jul 2002 10:12:39 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZ4K; Wed, 10 Jul 2002 10:13:18 -0400 Message-ID: <00d701c2281b$f0a66560$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Mullen, John P. \(Contractor\)" , "Manfredi, Albert E" , "'Charlie Perkins'" Cc: References: <02Jul1.123424mdt.117125@gw.trac.wsmr.army.mil> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:13:18 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi John, > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone system, in which > instead of a backbone of cellular antennas, routers, etc., there is just a > few isolated antennas designed to act as gateways to the internet. Check out www.meshnetworks.com. We have built this system. We call our gateways, Intelligent Access Points (IAPs). > > The question is, how will a user entering the region of a local MANET be > properly identified and make its location known to other hosts, including > those access through the Internet. What we do, is allow the MANET algorithm to extend to the IAPs. The IAPs can route anyway they want on the backside. This bridges our MANETs with the global Internet quite nicely. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area code gives us an > idea of what state the user is in. However, this is just to simplify the > task of finding an entry and has nothing to do with the host's current > association or location. I don't think you really need any kind of special server, unless its a Mobile IP agent!!! Mobile IP does what your suggesting here quite nicely BTW. > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the gateway's own IP. > Then, any host accessing through the Internet, trying to find the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. All it has to do is do a MIP handover between the MANETs. > > Technically, I realize, this is a form of centralized information storage, > but it is for the purpose of locating a particular host that may be on any > one of hundreds of MANETs, or on none. The storage is on the Internet, not > on the MANET. Local MANET routing information would not be forwarded, so > the directory entry would be valid (and useful) as long as the host is in > that particular MANET, even if the route to it within the MANET changes. MIP agents don't have to be centralized, except for the home agent that can be easily be made redundant, i.e. the only stateful host. The FA is eliminated in IPv6 with colocated COA. You are mulling something that has been done for quite some time by MIP! Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 10:41:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04702 for ; Wed, 10 Jul 2002 10:41:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01815 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 10:42:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28434; Wed, 10 Jul 2002 10:13:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28393 for ; Wed, 10 Jul 2002 10:13:35 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03429 for ; Wed, 10 Jul 2002 10:12:39 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZ4K; Wed, 10 Jul 2002 10:13:18 -0400 Message-ID: <00d701c2281b$f0a66560$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Mullen, John P. \(Contractor\)" , "Manfredi, Albert E" , "'Charlie Perkins'" Cc: References: <02Jul1.123424mdt.117125@gw.trac.wsmr.army.mil> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:13:18 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi John, > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone system, in which > instead of a backbone of cellular antennas, routers, etc., there is just a > few isolated antennas designed to act as gateways to the internet. Check out www.meshnetworks.com. We have built this system. We call our gateways, Intelligent Access Points (IAPs). > > The question is, how will a user entering the region of a local MANET be > properly identified and make its location known to other hosts, including > those access through the Internet. What we do, is allow the MANET algorithm to extend to the IAPs. The IAPs can route anyway they want on the backside. This bridges our MANETs with the global Internet quite nicely. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area code gives us an > idea of what state the user is in. However, this is just to simplify the > task of finding an entry and has nothing to do with the host's current > association or location. I don't think you really need any kind of special server, unless its a Mobile IP agent!!! Mobile IP does what your suggesting here quite nicely BTW. > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the gateway's own IP. > Then, any host accessing through the Internet, trying to find the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. All it has to do is do a MIP handover between the MANETs. > > Technically, I realize, this is a form of centralized information storage, > but it is for the purpose of locating a particular host that may be on any > one of hundreds of MANETs, or on none. The storage is on the Internet, not > on the MANET. Local MANET routing information would not be forwarded, so > the directory entry would be valid (and useful) as long as the host is in > that particular MANET, even if the route to it within the MANET changes. MIP agents don't have to be centralized, except for the home agent that can be easily be made redundant, i.e. the only stateful host. The FA is eliminated in IPv6 with colocated COA. You are mulling something that has been done for quite some time by MIP! Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 10:45:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04949 for ; Wed, 10 Jul 2002 10:45:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28060; Wed, 10 Jul 2002 10:12:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28029 for ; Wed, 10 Jul 2002 10:12:46 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03361 for ; Wed, 10 Jul 2002 10:11:48 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 08:12:38 -0600 Message-Id: <02Jul10.081238mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Phil Neumiller , manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 08:12:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil, I've lost the context here, but if I remember right, I was talking about a way to locate a MANET node from within the Internet. Martha Steenstrup discusses several clustering schemes in "Cluster-Based Networks" (Chapter 4 of _Ad Hoc Networking_, by Charles Perkins). Some of these clustering schemes would provide a framework in which subnet masks would work within a MANET. The idea is that a host is assigned an augmented IP dynamically according to its location within a hierarchal clustering framework. This augmented IP consists of a stable part plus an additional part that changes as the node moves within the cluster hierarchy. She describes a couple of schemes that keep track of these changing augmented IP addresses. However, I was not referring to routing within the MANET, but location of the MANET containing a particular node from within the Internet. If the MANET interfaces with the Internet, there will have to be one or more gateways interconnecting the two. One wishing to locate the MANET node will have to find these gateways. By having all nodes, including the gateways, have a common internet mask, then the Internet node can locate the MANET as if it were any other local intranet. The subnet identification would be redundant within the MANET, as is the case with any intranet, but may still be carried as part of the fixed (Internet compatible) portion of the node's IP. As far as MANET protocols go, unless the subnetting plan is to be carried out within the MANET, i.e. as in clustering, there is no need to perpetuate the bits within the MANET. The gateway can append the bits to any IP leaving the MANET for the Internet, but if the bits are the same for all MANET members, there is no need to include them within the MANET. However, I believe most MANET protocols do employ the IP in some way, even if they do not employ subnetting. If that is the case, the common bits will simply be treated as part of the IP, without using any subnet mask. I think so, anyhow. :-) John Mullen -----Original Message----- From: Phil Neumiller [mailto:pneumiller@meshnetworks.com] Sent: Wednesday, July 10, 2002 7:50 AM To: Mullen, John P. (Contractor); manet@ietf.org Subject: Re: [manet] Gateway address resolution Hi John, > > Why can't the MANET be treated as a local intranet with each of its nodes > having a common Internet subnet mask (augmented by whatever is needed to > affect routing within the MANET, of course.) Because all current MANET algorithms are classful in the sense that the routing algorithm does not propagate subnet bits masks. How do you define a subnet in a MANET? I have pondered this for quite some time. The only reasonable answer I have currently is to elect a subnet leader and make the neighbors of the leader the subnet. Maybe the neighbors neighbors too. When a node gets to far (too many hops away) from a subnet leader and sees a closer one it can acquire that subnet mask. Of course all the MANET protocols would need to change to support mask propagation. This would take some work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 10:45:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04962 for ; Wed, 10 Jul 2002 10:45:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02685 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 10:46:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28060; Wed, 10 Jul 2002 10:12:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28029 for ; Wed, 10 Jul 2002 10:12:46 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03361 for ; Wed, 10 Jul 2002 10:11:48 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 08:12:38 -0600 Message-Id: <02Jul10.081238mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Phil Neumiller , manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 08:12:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil, I've lost the context here, but if I remember right, I was talking about a way to locate a MANET node from within the Internet. Martha Steenstrup discusses several clustering schemes in "Cluster-Based Networks" (Chapter 4 of _Ad Hoc Networking_, by Charles Perkins). Some of these clustering schemes would provide a framework in which subnet masks would work within a MANET. The idea is that a host is assigned an augmented IP dynamically according to its location within a hierarchal clustering framework. This augmented IP consists of a stable part plus an additional part that changes as the node moves within the cluster hierarchy. She describes a couple of schemes that keep track of these changing augmented IP addresses. However, I was not referring to routing within the MANET, but location of the MANET containing a particular node from within the Internet. If the MANET interfaces with the Internet, there will have to be one or more gateways interconnecting the two. One wishing to locate the MANET node will have to find these gateways. By having all nodes, including the gateways, have a common internet mask, then the Internet node can locate the MANET as if it were any other local intranet. The subnet identification would be redundant within the MANET, as is the case with any intranet, but may still be carried as part of the fixed (Internet compatible) portion of the node's IP. As far as MANET protocols go, unless the subnetting plan is to be carried out within the MANET, i.e. as in clustering, there is no need to perpetuate the bits within the MANET. The gateway can append the bits to any IP leaving the MANET for the Internet, but if the bits are the same for all MANET members, there is no need to include them within the MANET. However, I believe most MANET protocols do employ the IP in some way, even if they do not employ subnetting. If that is the case, the common bits will simply be treated as part of the IP, without using any subnet mask. I think so, anyhow. :-) John Mullen -----Original Message----- From: Phil Neumiller [mailto:pneumiller@meshnetworks.com] Sent: Wednesday, July 10, 2002 7:50 AM To: Mullen, John P. (Contractor); manet@ietf.org Subject: Re: [manet] Gateway address resolution Hi John, > > Why can't the MANET be treated as a local intranet with each of its nodes > having a common Internet subnet mask (augmented by whatever is needed to > affect routing within the MANET, of course.) Because all current MANET algorithms are classful in the sense that the routing algorithm does not propagate subnet bits masks. How do you define a subnet in a MANET? I have pondered this for quite some time. The only reasonable answer I have currently is to elect a subnet leader and make the neighbors of the leader the subnet. Maybe the neighbors neighbors too. When a node gets to far (too many hops away) from a subnet leader and sees a closer one it can acquire that subnet mask. Of course all the MANET protocols would need to change to support mask propagation. This would take some work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:01:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05602 for ; Wed, 10 Jul 2002 11:01:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00182; Wed, 10 Jul 2002 10:29:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00156 for ; Wed, 10 Jul 2002 10:29:47 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04235 for ; Wed, 10 Jul 2002 10:28:51 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id 9964713A61; Wed, 10 Jul 2002 16:27:58 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 126A513A27; Wed, 10 Jul 2002 16:27:58 +0200 (CEST) To: Phil Neumiller Subject: Re: [manet] Gateway address resolution Message-ID: <1026311278.3d2c446e0b4e6@tc-mail.insa-lyon.fr> Date: Wed, 10 Jul 2002 16:27:58 +0200 (CEST) From: Guillaume Chelius Cc: "Mullen, John P. (Contractor)" , manet@ietf.org References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> In-Reply-To: <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20020300 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello, > > Why can't the MANET be treated as a local intranet with each of its nodes > > having a common Internet subnet mask (augmented by whatever is needed to > > affect routing within the MANET, of course.) > > Because all current MANET algorithms are classful in the sense that the > routing algorithm does not propagate subnet bits masks. How do you define a > subnet in a MANET? It could work with IPv6 since there is no need for subnet propagation. By default, all nodes would use the link-local prefix. If a global prefix is broadcasted, nodes also acquire the global prefix as you describe above. > I have pondered this for quite some time. The only reasonable answer > I have currently is to elect a subnet leader and make the neighbors of > the leader the subnet. Maybe the neighbors neighbors too. When a node gets > to far (too many hops away) from a subnet leader and sees a closer one it can > acquire that subnet mask. Of course all the MANET protocols would need to > change to support mask propagation. This would take some work. ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:01:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05611 for ; Wed, 10 Jul 2002 11:01:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04952 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:02:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00182; Wed, 10 Jul 2002 10:29:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00156 for ; Wed, 10 Jul 2002 10:29:47 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04235 for ; Wed, 10 Jul 2002 10:28:51 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id 9964713A61; Wed, 10 Jul 2002 16:27:58 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 126A513A27; Wed, 10 Jul 2002 16:27:58 +0200 (CEST) To: Phil Neumiller Subject: Re: [manet] Gateway address resolution Message-ID: <1026311278.3d2c446e0b4e6@tc-mail.insa-lyon.fr> Date: Wed, 10 Jul 2002 16:27:58 +0200 (CEST) From: Guillaume Chelius Cc: "Mullen, John P. (Contractor)" , manet@ietf.org References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> In-Reply-To: <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20020300 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello, > > Why can't the MANET be treated as a local intranet with each of its nodes > > having a common Internet subnet mask (augmented by whatever is needed to > > affect routing within the MANET, of course.) > > Because all current MANET algorithms are classful in the sense that the > routing algorithm does not propagate subnet bits masks. How do you define a > subnet in a MANET? It could work with IPv6 since there is no need for subnet propagation. By default, all nodes would use the link-local prefix. If a global prefix is broadcasted, nodes also acquire the global prefix as you describe above. > I have pondered this for quite some time. The only reasonable answer > I have currently is to elect a subnet leader and make the neighbors of > the leader the subnet. Maybe the neighbors neighbors too. When a node gets > to far (too many hops away) from a subnet leader and sees a closer one it can > acquire that subnet mask. Of course all the MANET protocols would need to > change to support mask propagation. This would take some work. ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:06:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05894 for ; Wed, 10 Jul 2002 11:06:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02061; Wed, 10 Jul 2002 10:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02000 for ; Wed, 10 Jul 2002 10:43:09 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04784 for ; Wed, 10 Jul 2002 10:42:13 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA14636; Wed, 10 Jul 2002 07:43:00 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA17630; Wed, 10 Jul 2002 07:42:42 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AEgw011676; Wed, 10 Jul 2002 07:42:58 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 10:42:58 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A04@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:42:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Mullen wrote: > However, I was not referring to routing within the MANET, but > location of > the MANET containing a particular node from within the > Internet. If the > MANET interfaces with the Internet, there will have to be one or more > gateways interconnecting the two. One wishing to locate the > MANET node will > have to find these gateways. By having all nodes, including > the gateways, > have a common internet mask, then the Internet node can > locate the MANET as > if it were any other local intranet. The subnet > identification would be > redundant within the MANET, as is the case with any intranet, > but may still > be carried as part of the fixed (Internet compatible) portion > of the node's > IP. John, I guess the point I was trying to make some time ago is that what the _general_ solution to what you are talking about here is not to depend on some special IP prefix/mask for each MANET host, since this would require some sort of DHCP-like auto configuration service, or static configuration, at the MANET host. Since there is a desire in MANET to allow hosts to keep using their own IP addresses and NOT have to depend on configuration servers, your solution would not be the general one. My initial suggestion was that gateways keep an exhaustive list of every MANET host, treating these hosts' IP addresses as flat addresses (like MAC addresses in a switched Ethernet), and then use an address translation function when going to and from the Internet. The exhaustive list of all MANET hosts would permit gateways to know whether a packet in the MANET was destined to some MANET host, or to the Internet. While this should work in a client-server model, because the client initiates all transactions, Charlie Perkins responded that this would not work if Internet hosts tried to reach a MANET host without prior knowledge. His answer has been to use Mobile IP (MONET). In this case, the MANET-Internet gateway could be the foreign agent. A MANET host coming on line would register with this foreign agent, and the MANET host's home agent keeps track of which foreign agent is currently responsible for reaching that MANET host. See RFC 2002. With this approach, and gateways keeping that list of MANET hosts to know whether packets are to be routed or kept inside the MANET, I think all problems should be solvable. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:06:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05901 for ; Wed, 10 Jul 2002 11:06:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05462 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:07:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02061; Wed, 10 Jul 2002 10:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02000 for ; Wed, 10 Jul 2002 10:43:09 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04784 for ; Wed, 10 Jul 2002 10:42:13 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA14636; Wed, 10 Jul 2002 07:43:00 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA17630; Wed, 10 Jul 2002 07:42:42 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AEgw011676; Wed, 10 Jul 2002 07:42:58 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 10:42:58 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A04@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" , manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:42:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Mullen wrote: > However, I was not referring to routing within the MANET, but > location of > the MANET containing a particular node from within the > Internet. If the > MANET interfaces with the Internet, there will have to be one or more > gateways interconnecting the two. One wishing to locate the > MANET node will > have to find these gateways. By having all nodes, including > the gateways, > have a common internet mask, then the Internet node can > locate the MANET as > if it were any other local intranet. The subnet > identification would be > redundant within the MANET, as is the case with any intranet, > but may still > be carried as part of the fixed (Internet compatible) portion > of the node's > IP. John, I guess the point I was trying to make some time ago is that what the _general_ solution to what you are talking about here is not to depend on some special IP prefix/mask for each MANET host, since this would require some sort of DHCP-like auto configuration service, or static configuration, at the MANET host. Since there is a desire in MANET to allow hosts to keep using their own IP addresses and NOT have to depend on configuration servers, your solution would not be the general one. My initial suggestion was that gateways keep an exhaustive list of every MANET host, treating these hosts' IP addresses as flat addresses (like MAC addresses in a switched Ethernet), and then use an address translation function when going to and from the Internet. The exhaustive list of all MANET hosts would permit gateways to know whether a packet in the MANET was destined to some MANET host, or to the Internet. While this should work in a client-server model, because the client initiates all transactions, Charlie Perkins responded that this would not work if Internet hosts tried to reach a MANET host without prior knowledge. His answer has been to use Mobile IP (MONET). In this case, the MANET-Internet gateway could be the foreign agent. A MANET host coming on line would register with this foreign agent, and the MANET host's home agent keeps track of which foreign agent is currently responsible for reaching that MANET host. See RFC 2002. With this approach, and gateways keeping that list of MANET hosts to know whether packets are to be routed or kept inside the MANET, I think all problems should be solvable. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:09:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06138 for ; Wed, 10 Jul 2002 11:09:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01785; Wed, 10 Jul 2002 10:41:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01750 for ; Wed, 10 Jul 2002 10:41:52 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04682 for ; Wed, 10 Jul 2002 10:40:56 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA17363; Wed, 10 Jul 2002 07:40:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AEef100794; Wed, 10 Jul 2002 07:40:41 -0700 X-mProtect: <200207101440> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiSkq5W; Wed, 10 Jul 2002 07:40:39 PDT Message-ID: <3D2C4711.13D4DC3D@iprg.nokia.com> Date: Wed, 10 Jul 2002 07:39:13 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: "Mullen, John P. (Contractor)" , manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, AODV does support subnet mask propagation. The subnet leader is responsible for coordinating the routability of the subnet. All RREQs for any node on the subnet have to be answered as if the subnet leader were providing the response. Causing the subnet to be formed from random neighbors works better if the neighbors are likely to hang together for a while, and if they don't already have some other addresses they would like to keep. AODV does not support discontiguous ranges of addresses forming a "subnet" (whatever that word would mean). Regards, Charlie P. Phil Neumiller wrote: > Hi John, > > > > > Why can't the MANET be treated as a local intranet with each of its nodes > > having a common Internet subnet mask (augmented by whatever is needed to > > affect routing within the MANET, of course.) > > Because all current MANET algorithms are classful in the sense that the routing > algorithm does not propagate subnet bits masks. How do you define a subnet in > a MANET? I have pondered this for quite some time. The only reasonable answer > I have currently is to elect a subnet leader and make the neighbors of the leader > the subnet. Maybe the neighbors neighbors too. When a node gets to far (too > many hops away) from a subnet leader and sees a closer one it can acquire that > subnet mask. Of course all the MANET protocols would need to change to > support mask propagation. This would take some work. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:09:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06146 for ; Wed, 10 Jul 2002 11:09:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05953 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:10:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01785; Wed, 10 Jul 2002 10:41:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01750 for ; Wed, 10 Jul 2002 10:41:52 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04682 for ; Wed, 10 Jul 2002 10:40:56 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA17363; Wed, 10 Jul 2002 07:40:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AEef100794; Wed, 10 Jul 2002 07:40:41 -0700 X-mProtect: <200207101440> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiSkq5W; Wed, 10 Jul 2002 07:40:39 PDT Message-ID: <3D2C4711.13D4DC3D@iprg.nokia.com> Date: Wed, 10 Jul 2002 07:39:13 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: "Mullen, John P. (Contractor)" , manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, AODV does support subnet mask propagation. The subnet leader is responsible for coordinating the routability of the subnet. All RREQs for any node on the subnet have to be answered as if the subnet leader were providing the response. Causing the subnet to be formed from random neighbors works better if the neighbors are likely to hang together for a while, and if they don't already have some other addresses they would like to keep. AODV does not support discontiguous ranges of addresses forming a "subnet" (whatever that word would mean). Regards, Charlie P. Phil Neumiller wrote: > Hi John, > > > > > Why can't the MANET be treated as a local intranet with each of its nodes > > having a common Internet subnet mask (augmented by whatever is needed to > > affect routing within the MANET, of course.) > > Because all current MANET algorithms are classful in the sense that the routing > algorithm does not propagate subnet bits masks. How do you define a subnet in > a MANET? I have pondered this for quite some time. The only reasonable answer > I have currently is to elect a subnet leader and make the neighbors of the leader > the subnet. Maybe the neighbors neighbors too. When a node gets to far (too > many hops away) from a subnet leader and sees a closer one it can acquire that > subnet mask. Of course all the MANET protocols would need to change to > support mask propagation. This would take some work. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:23:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06666 for ; Wed, 10 Jul 2002 11:23:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03789; Wed, 10 Jul 2002 10:56:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03711 for ; Wed, 10 Jul 2002 10:56:41 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05327 for ; Wed, 10 Jul 2002 10:55:42 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 08:56:21 -0600 Message-Id: <02Jul10.085621mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Phil Neumiller Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 08:56:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil, Thanks for the feedback. A lot of this stuff is new to me and I'm glad to hear my mullings are not completely insane. :-) John Mullen -----Original Message----- From: Phil Neumiller [mailto:pneumiller@meshnetworks.com] Sent: Wednesday, July 10, 2002 8:13 AM To: Mullen, John P. (Contractor); Manfredi, Albert E; 'Charlie Perkins' Cc: manet@ietf.org Subject: Re: [manet] Gateway address resolution Hi John, > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone system, in which > instead of a backbone of cellular antennas, routers, etc., there is just a > few isolated antennas designed to act as gateways to the internet. Check out www.meshnetworks.com. We have built this system. We call our gateways, Intelligent Access Points (IAPs). > > The question is, how will a user entering the region of a local MANET be > properly identified and make its location known to other hosts, including > those access through the Internet. What we do, is allow the MANET algorithm to extend to the IAPs. The IAPs can route anyway they want on the backside. This bridges our MANETs with the global Internet quite nicely. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area code gives us an > idea of what state the user is in. However, this is just to simplify the > task of finding an entry and has nothing to do with the host's current > association or location. I don't think you really need any kind of special server, unless its a Mobile IP agent!!! Mobile IP does what your suggesting here quite nicely BTW. > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the gateway's own IP. > Then, any host accessing through the Internet, trying to find the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. All it has to do is do a MIP handover between the MANETs. > > Technically, I realize, this is a form of centralized information storage, > but it is for the purpose of locating a particular host that may be on any > one of hundreds of MANETs, or on none. The storage is on the Internet, not > on the MANET. Local MANET routing information would not be forwarded, so > the directory entry would be valid (and useful) as long as the host is in > that particular MANET, even if the route to it within the MANET changes. MIP agents don't have to be centralized, except for the home agent that can be easily be made redundant, i.e. the only stateful host. The FA is eliminated in IPv6 with colocated COA. You are mulling something that has been done for quite some time by MIP! Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:23:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06679 for ; Wed, 10 Jul 2002 11:23:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06983 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:24:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03789; Wed, 10 Jul 2002 10:56:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03711 for ; Wed, 10 Jul 2002 10:56:41 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05327 for ; Wed, 10 Jul 2002 10:55:42 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 08:56:21 -0600 Message-Id: <02Jul10.085621mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: Phil Neumiller Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 08:56:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil, Thanks for the feedback. A lot of this stuff is new to me and I'm glad to hear my mullings are not completely insane. :-) John Mullen -----Original Message----- From: Phil Neumiller [mailto:pneumiller@meshnetworks.com] Sent: Wednesday, July 10, 2002 8:13 AM To: Mullen, John P. (Contractor); Manfredi, Albert E; 'Charlie Perkins' Cc: manet@ietf.org Subject: Re: [manet] Gateway address resolution Hi John, > Mulling on this, > > Suppose we had a MANET implementation of a "cellular" phone system, in which > instead of a backbone of cellular antennas, routers, etc., there is just a > few isolated antennas designed to act as gateways to the internet. Check out www.meshnetworks.com. We have built this system. We call our gateways, Intelligent Access Points (IAPs). > > The question is, how will a user entering the region of a local MANET be > properly identified and make its location known to other hosts, including > those access through the Internet. What we do, is allow the MANET algorithm to extend to the IAPs. The IAPs can route anyway they want on the backside. This bridges our MANETs with the global Internet quite nicely. > > My thought is this: > > Suppose there were on the Internet a number of special servers whose > function is to provide directory service for this class of users. Each > mobile host would have a unique identifier (IP?) that would be easily > associated with a subset of these servers, much like area code gives us an > idea of what state the user is in. However, this is just to simplify the > task of finding an entry and has nothing to do with the host's current > association or location. I don't think you really need any kind of special server, unless its a Mobile IP agent!!! Mobile IP does what your suggesting here quite nicely BTW. > Whenever a host comes within range of one of the associated MANETs, it > recognizes, through Hello messages, the proximity of like hosts and > broadcasts its own request to join. Once the local group accepts its > membership, it unicasts a location packet to one of the Internet gateways, > which keeps this information for its own use, but also forwards to the > appropriate directory server the host's IP as well as the gateway's own IP. > Then, any host accessing through the Internet, trying to find the mobile > host in question, would request directory assistance, finding whatever > information it needs to route packets to the gateway. All it has to do is do a MIP handover between the MANETs. > > Technically, I realize, this is a form of centralized information storage, > but it is for the purpose of locating a particular host that may be on any > one of hundreds of MANETs, or on none. The storage is on the Internet, not > on the MANET. Local MANET routing information would not be forwarded, so > the directory entry would be valid (and useful) as long as the host is in > that particular MANET, even if the route to it within the MANET changes. MIP agents don't have to be centralized, except for the home agent that can be easily be made redundant, i.e. the only stateful host. The FA is eliminated in IPv6 with colocated COA. You are mulling something that has been done for quite some time by MIP! Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:29:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06974 for ; Wed, 10 Jul 2002 11:29:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03497; Wed, 10 Jul 2002 10:54:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03463 for ; Wed, 10 Jul 2002 10:54:26 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05259 for ; Wed, 10 Jul 2002 10:53:29 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 08:54:16 -0600 Message-Id: <02Jul10.085416mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 08:54:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, I am concerned, as Charlie is, with the problem of how a node within the Internet locates a host within a MANET, when it knows noting about that host, except its IP (however that is constructed). If a host will only belong to a particular MANET, some sort of subnet address would seem a logical choice, but if that host could belong to any one of numerous MANETs, I can see things are far more complex. The MANETs I work with are of the first type, but, as you point out, this is not the most general case. Thanks for the information. I'm still learning. :-) John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, July 10, 2002 8:43 AM To: 'Mullen, John P. (Contractor)'; manet@ietf.org Subject: RE: [manet] Gateway address resolution John Mullen wrote: > However, I was not referring to routing within the MANET, but > location of > the MANET containing a particular node from within the > Internet. If the > MANET interfaces with the Internet, there will have to be one or more > gateways interconnecting the two. One wishing to locate the > MANET node will > have to find these gateways. By having all nodes, including > the gateways, > have a common internet mask, then the Internet node can > locate the MANET as > if it were any other local intranet. The subnet > identification would be > redundant within the MANET, as is the case with any intranet, > but may still > be carried as part of the fixed (Internet compatible) portion > of the node's > IP. John, I guess the point I was trying to make some time ago is that what the _general_ solution to what you are talking about here is not to depend on some special IP prefix/mask for each MANET host, since this would require some sort of DHCP-like auto configuration service, or static configuration, at the MANET host. Since there is a desire in MANET to allow hosts to keep using their own IP addresses and NOT have to depend on configuration servers, your solution would not be the general one. My initial suggestion was that gateways keep an exhaustive list of every MANET host, treating these hosts' IP addresses as flat addresses (like MAC addresses in a switched Ethernet), and then use an address translation function when going to and from the Internet. The exhaustive list of all MANET hosts would permit gateways to know whether a packet in the MANET was destined to some MANET host, or to the Internet. While this should work in a client-server model, because the client initiates all transactions, Charlie Perkins responded that this would not work if Internet hosts tried to reach a MANET host without prior knowledge. His answer has been to use Mobile IP (MONET). In this case, the MANET-Internet gateway could be the foreign agent. A MANET host coming on line would register with this foreign agent, and the MANET host's home agent keeps track of which foreign agent is currently responsible for reaching that MANET host. See RFC 2002. With this approach, and gateways keeping that list of MANET hosts to know whether packets are to be routed or kept inside the MANET, I think all problems should be solvable. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:29:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06981 for ; Wed, 10 Jul 2002 11:29:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07793 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:30:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03497; Wed, 10 Jul 2002 10:54:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03463 for ; Wed, 10 Jul 2002 10:54:26 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05259 for ; Wed, 10 Jul 2002 10:53:29 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 08:54:16 -0600 Message-Id: <02Jul10.085416mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 08:54:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, I am concerned, as Charlie is, with the problem of how a node within the Internet locates a host within a MANET, when it knows noting about that host, except its IP (however that is constructed). If a host will only belong to a particular MANET, some sort of subnet address would seem a logical choice, but if that host could belong to any one of numerous MANETs, I can see things are far more complex. The MANETs I work with are of the first type, but, as you point out, this is not the most general case. Thanks for the information. I'm still learning. :-) John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, July 10, 2002 8:43 AM To: 'Mullen, John P. (Contractor)'; manet@ietf.org Subject: RE: [manet] Gateway address resolution John Mullen wrote: > However, I was not referring to routing within the MANET, but > location of > the MANET containing a particular node from within the > Internet. If the > MANET interfaces with the Internet, there will have to be one or more > gateways interconnecting the two. One wishing to locate the > MANET node will > have to find these gateways. By having all nodes, including > the gateways, > have a common internet mask, then the Internet node can > locate the MANET as > if it were any other local intranet. The subnet > identification would be > redundant within the MANET, as is the case with any intranet, > but may still > be carried as part of the fixed (Internet compatible) portion > of the node's > IP. John, I guess the point I was trying to make some time ago is that what the _general_ solution to what you are talking about here is not to depend on some special IP prefix/mask for each MANET host, since this would require some sort of DHCP-like auto configuration service, or static configuration, at the MANET host. Since there is a desire in MANET to allow hosts to keep using their own IP addresses and NOT have to depend on configuration servers, your solution would not be the general one. My initial suggestion was that gateways keep an exhaustive list of every MANET host, treating these hosts' IP addresses as flat addresses (like MAC addresses in a switched Ethernet), and then use an address translation function when going to and from the Internet. The exhaustive list of all MANET hosts would permit gateways to know whether a packet in the MANET was destined to some MANET host, or to the Internet. While this should work in a client-server model, because the client initiates all transactions, Charlie Perkins responded that this would not work if Internet hosts tried to reach a MANET host without prior knowledge. His answer has been to use Mobile IP (MONET). In this case, the MANET-Internet gateway could be the foreign agent. A MANET host coming on line would register with this foreign agent, and the MANET host's home agent keeps track of which foreign agent is currently responsible for reaching that MANET host. See RFC 2002. With this approach, and gateways keeping that list of MANET hosts to know whether packets are to be routed or kept inside the MANET, I think all problems should be solvable. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04644 for ; Wed, 10 Jul 2002 10:39:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01618 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 10:40:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27557; Wed, 10 Jul 2002 10:08:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27528 for ; Wed, 10 Jul 2002 10:08:39 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03118 for ; Wed, 10 Jul 2002 10:07:44 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZ4B; Wed, 10 Jul 2002 10:08:28 -0400 Message-ID: <00d201c2281b$43fd7fb0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Manfredi, Albert E" , "Mullen, John P. \(Contractor\)" Cc: References: Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:08:28 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > > 1) Nodes should be able to roam freely in the network. If a cellular node connected to the cellular network via address xxxx came into accessable range of a bluetooth MANET based network, it might decide to join. Obviously, the node prefer to keep its xxxx address. NOTE: IP addresses are assigned to interfaces not hosts. In the Bluetooth scenario you mention, you would need to have a seperate Care-of-address on the cell phone network and the Bluetooth network. You could of course maintain your home address at all times. The host has to either be multi-homed (in which case it can route over both interfaces) or it must support MIP with either co-located care-of addresses in IPv6 or a FA in IPv4. > > 2) Imagine the situation when you have many MANET networks scaterd in somewhat geographically limited area. Every network will be able to adminstrate itself (ie assign contiguous IP addresses, and subnet mask). NOTE: I know of no MANET algorithm that can "assign" a subnet mask in the true sense. ZRP has zones. CGSR and CBRP have clusters. > 3) The use of anytype of DHCP requires adminstration both at the node level, and centralized level. In addition, centralized management of MANET contradicts it's charter. No, I don't believe it does. The use of infrastructure is really going to be required by practical MANET implementaitons of any scale. People in general will need to get on the global Internet FROM their MANETs. They will also want to be reachable. > > 4) Users are entitled to have thier own IP addresses. Assume my PDA address is yyyy, and it is a static IP that is recognizable throughout the internet. Part of the IPv6 effort is to allow personal IP addresses. Overiding this address contradicts with IPv6 directions. The only feasible static address here is a mobile IP home address. > > However, I understand that having a pool of contiguous addresses may be the common case. Yet, building the network should be based on the more general case. Having a pool of contiguous addresses is no longer common. CIDR and OSPF/BGP allow many tiny little non-contiguous subnets to be in any ISPs pool of allocatable addresses. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:38:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07435 for ; Wed, 10 Jul 2002 11:38:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05565; Wed, 10 Jul 2002 11:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05536 for ; Wed, 10 Jul 2002 11:08:23 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05989 for ; Wed, 10 Jul 2002 11:07:27 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZW9; Wed, 10 Jul 2002 11:08:18 -0400 Message-ID: <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charlie Perkins" Cc: "Mullen, John P. \(Contractor\)" , References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 11:08:17 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the past. I see this in the latest draft. I stand [VERY] corrected. Does DSR have plans to follow suit? ----- Original Message ----- From: "Charlie Perkins" To: "Phil Neumiller" Cc: "Mullen, John P. (Contractor)" ; Sent: Wednesday, July 10, 2002 10:39 AM Subject: Re: [manet] Gateway address resolution > > Hello Phil, > > AODV does support subnet mask propagation. > > The subnet leader is responsible for coordinating > the routability of the subnet. All RREQs for any > node on the subnet have to be answered as if the > subnet leader were providing the response. > > Causing the subnet to be formed from random > neighbors works better if the neighbors are likely > to hang together for a while, and if they don't > already have some other addresses they would > like to keep. > > AODV does not support discontiguous ranges > of addresses forming a "subnet" (whatever that > word would mean). > > Regards, > Charlie P. > > > > > Phil Neumiller wrote: > > > Hi John, > > > > > > > > Why can't the MANET be treated as a local intranet with each of its nodes > > > having a common Internet subnet mask (augmented by whatever is needed to > > > affect routing within the MANET, of course.) > > > > Because all current MANET algorithms are classful in the sense that the routing > > algorithm does not propagate subnet bits masks. How do you define a subnet in > > a MANET? I have pondered this for quite some time. The only reasonable answer > > I have currently is to elect a subnet leader and make the neighbors of the leader > > the subnet. Maybe the neighbors neighbors too. When a node gets to far (too > > many hops away) from a subnet leader and sees a closer one it can acquire that > > subnet mask. Of course all the MANET protocols would need to change to > > support mask propagation. This would take some work. > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:38:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07443 for ; Wed, 10 Jul 2002 11:38:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09430 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:39:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05565; Wed, 10 Jul 2002 11:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05536 for ; Wed, 10 Jul 2002 11:08:23 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05989 for ; Wed, 10 Jul 2002 11:07:27 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZW9; Wed, 10 Jul 2002 11:08:18 -0400 Message-ID: <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charlie Perkins" Cc: "Mullen, John P. \(Contractor\)" , References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 11:08:17 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the past. I see this in the latest draft. I stand [VERY] corrected. Does DSR have plans to follow suit? ----- Original Message ----- From: "Charlie Perkins" To: "Phil Neumiller" Cc: "Mullen, John P. (Contractor)" ; Sent: Wednesday, July 10, 2002 10:39 AM Subject: Re: [manet] Gateway address resolution > > Hello Phil, > > AODV does support subnet mask propagation. > > The subnet leader is responsible for coordinating > the routability of the subnet. All RREQs for any > node on the subnet have to be answered as if the > subnet leader were providing the response. > > Causing the subnet to be formed from random > neighbors works better if the neighbors are likely > to hang together for a while, and if they don't > already have some other addresses they would > like to keep. > > AODV does not support discontiguous ranges > of addresses forming a "subnet" (whatever that > word would mean). > > Regards, > Charlie P. > > > > > Phil Neumiller wrote: > > > Hi John, > > > > > > > > Why can't the MANET be treated as a local intranet with each of its nodes > > > having a common Internet subnet mask (augmented by whatever is needed to > > > affect routing within the MANET, of course.) > > > > Because all current MANET algorithms are classful in the sense that the routing > > algorithm does not propagate subnet bits masks. How do you define a subnet in > > a MANET? I have pondered this for quite some time. The only reasonable answer > > I have currently is to elect a subnet leader and make the neighbors of the leader > > the subnet. Maybe the neighbors neighbors too. When a node gets to far (too > > many hops away) from a subnet leader and sees a closer one it can acquire that > > subnet mask. Of course all the MANET protocols would need to change to > > support mask propagation. This would take some work. > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 11:51:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08105 for ; Wed, 10 Jul 2002 11:51:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07165; Wed, 10 Jul 2002 11:25:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07135 for ; Wed, 10 Jul 2002 11:25:25 -0400 (EDT) Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06714 for ; Wed, 10 Jul 2002 11:24:25 -0400 (EDT) Received: from hoffman.INRS-Telecom.UQuebec.CA (hoffman [192.26.211.190]) by ozias.inrs-telecom.uquebec.ca (8.11.3/8.11.3) with ESMTP id g6AFRk319855; Wed, 10 Jul 2002 11:27:46 -0400 (EDT) Received: from hoffman by hoffman.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA13242; Wed, 10 Jul 2002 11:25:04 -0400 (EDT) Message-Id: <200207101525.LAA13242@hoffman.INRS-Telecom.UQuebec.CA> Date: Wed, 10 Jul 2002 11:25:04 -0400 (EDT) From: Jorge Nuevo Reply-To: Jorge Nuevo Subject: Re: [manet] Interference in ad hoc network To: jw2000@excite.com Cc: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: M2hdgaVYJWT8ftiCM8Afrw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Jack: As already said, in a MANET all nodes share the same channel where the choice of medium access scheme is difficult due to the time-varying network topology and the lack of centralized control. Use of TDMA or dynamic assignment of frequency bands is complex since there is no centralized control as in cellular networks, FDMA is inefficient in dense networks, CDMA is difficult to implement due to node mobility and the consequent need to keep track of the frequency hopping patterns and/or spreading codes for nodes in the time-varying neighborhood, so random access appears to be the current favorite. Applicability of the random access schemes are limited by two interference problems: the hidden terminal problem and the exposed terminal problem. In general, the hidden terminal problem reduces the capacity of a network due to the increasing number of collisions, while the exposed terminal problem reduces the network capacity due to the unnecessarily deferring nodes from transmitting. Several attempts have been made in the literature to reduce the effect of these two problems. Protocols based on a RTS/CTS dialogue such as MACA, MACAW and FAMA deal with these problems. Information of these can be found at "MACA - A new channel access method for packet radio", P. Karn, "MACAW: A media access protocol for wireless LAN's", V. Bharghavan and others "Floor acquisition multiple access (FAMA) for packet radio networks", C.L. Fullmer and J.J. Garcia-Luna Aceves Hope it helps Jorge Nuevo nuevo@inrs-telecom.uquebec.ca _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 11:51:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08114 for ; Wed, 10 Jul 2002 11:51:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11121 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 11:52:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07165; Wed, 10 Jul 2002 11:25:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07135 for ; Wed, 10 Jul 2002 11:25:25 -0400 (EDT) Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06714 for ; Wed, 10 Jul 2002 11:24:25 -0400 (EDT) Received: from hoffman.INRS-Telecom.UQuebec.CA (hoffman [192.26.211.190]) by ozias.inrs-telecom.uquebec.ca (8.11.3/8.11.3) with ESMTP id g6AFRk319855; Wed, 10 Jul 2002 11:27:46 -0400 (EDT) Received: from hoffman by hoffman.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4) id LAA13242; Wed, 10 Jul 2002 11:25:04 -0400 (EDT) Message-Id: <200207101525.LAA13242@hoffman.INRS-Telecom.UQuebec.CA> Date: Wed, 10 Jul 2002 11:25:04 -0400 (EDT) From: Jorge Nuevo Reply-To: Jorge Nuevo Subject: Re: [manet] Interference in ad hoc network To: jw2000@excite.com Cc: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: M2hdgaVYJWT8ftiCM8Afrw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Jack: As already said, in a MANET all nodes share the same channel where the choice of medium access scheme is difficult due to the time-varying network topology and the lack of centralized control. Use of TDMA or dynamic assignment of frequency bands is complex since there is no centralized control as in cellular networks, FDMA is inefficient in dense networks, CDMA is difficult to implement due to node mobility and the consequent need to keep track of the frequency hopping patterns and/or spreading codes for nodes in the time-varying neighborhood, so random access appears to be the current favorite. Applicability of the random access schemes are limited by two interference problems: the hidden terminal problem and the exposed terminal problem. In general, the hidden terminal problem reduces the capacity of a network due to the increasing number of collisions, while the exposed terminal problem reduces the network capacity due to the unnecessarily deferring nodes from transmitting. Several attempts have been made in the literature to reduce the effect of these two problems. Protocols based on a RTS/CTS dialogue such as MACA, MACAW and FAMA deal with these problems. Information of these can be found at "MACA - A new channel access method for packet radio", P. Karn, "MACAW: A media access protocol for wireless LAN's", V. Bharghavan and others "Floor acquisition multiple access (FAMA) for packet radio networks", C.L. Fullmer and J.J. Garcia-Luna Aceves Hope it helps Jorge Nuevo nuevo@inrs-telecom.uquebec.ca _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 12:10:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09065 for ; Wed, 10 Jul 2002 12:10:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09556; Wed, 10 Jul 2002 11:41:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09525 for ; Wed, 10 Jul 2002 11:41:21 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07571 for ; Wed, 10 Jul 2002 11:40:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20092; Wed, 10 Jul 2002 08:40:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AFeko20204; Wed, 10 Jul 2002 08:40:46 -0700 X-mProtect: <200207101540> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXTE6Ee; Wed, 10 Jul 2002 08:40:45 PDT Message-ID: <3D2C557D.C3E289C7@iprg.nokia.com> Date: Wed, 10 Jul 2002 08:40:45 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the > past. I see this in the latest draft. The subnet mask propagation has been there for years, but it's easy to miss and hasn't been discussed much within [manet]. I'm puzzling over what percentage of the respondents to this list will recognize your tuna reference... Regards, Charlie P. PS. You can tune a piano, and you can tune a guitar, but you can't tunefs. (screams of agony are blissfully unheard over e-mail) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 12:10:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09072 for ; Wed, 10 Jul 2002 12:10:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15399 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 12:11:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09556; Wed, 10 Jul 2002 11:41:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09525 for ; Wed, 10 Jul 2002 11:41:21 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07571 for ; Wed, 10 Jul 2002 11:40:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20092; Wed, 10 Jul 2002 08:40:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AFeko20204; Wed, 10 Jul 2002 08:40:46 -0700 X-mProtect: <200207101540> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXTE6Ee; Wed, 10 Jul 2002 08:40:45 PDT Message-ID: <3D2C557D.C3E289C7@iprg.nokia.com> Date: Wed, 10 Jul 2002 08:40:45 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the > past. I see this in the latest draft. The subnet mask propagation has been there for years, but it's easy to miss and hasn't been discussed much within [manet]. I'm puzzling over what percentage of the respondents to this list will recognize your tuna reference... Regards, Charlie P. PS. You can tune a piano, and you can tune a guitar, but you can't tunefs. (screams of agony are blissfully unheard over e-mail) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 12:17:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09515 for ; Wed, 10 Jul 2002 12:17:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10514; Wed, 10 Jul 2002 11:48:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10411 for ; Wed, 10 Jul 2002 11:48:24 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07916 for ; Wed, 10 Jul 2002 11:47:29 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA02755; Wed, 10 Jul 2002 10:48:17 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA29990; Wed, 10 Jul 2002 08:47:59 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AFmF011310; Wed, 10 Jul 2002 08:48:15 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 11:48:14 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A05@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 11:48:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Mullen wrote: > Hi Bert, > > I am concerned, as Charlie is, with the problem of how a node > within the > Internet locates a host within a MANET, when it knows noting > about that > host, except its IP (however that is constructed). If a host > will only > belong to a particular MANET, some sort of subnet address would seem a > logical choice, but if that host could belong to any one of > numerous MANETs, > I can see things are far more complex. The MANETs I work > with are of the > first type, but, as you point out, this is not the most general case. This is in RFC 2002. Begin this story with the MANET host, call it Host M, coming on line suddenly in some arbitrary MANET. The first thing Host M does is it figures out if it's home or away. It does so by listening for agent advertisements and/or transmitting agent solicitations. (This protocol is an extensions of the older ICMP router discovery protocol.) Having found that it is away, and that a "foreign agent" is available, host M then registers with its "home agent" through this "foreign agent." The foreign agent acts only as a passive relay to and from the home agent, in this process. Host M's "home agent" authenticates this registration request, and now knows which foreign agent in the Internet is currently entrusted with host M. In our case, this foreign agent would be associated with an Internet-MANET gateway. Or it might be part of the gateway. Let's say an Internet host "I" needs to reach a host M, without knowing where host M is. In general, all host I knows is the address of host M. The IP packet from host I reaches the "home agent" of host M, simply because the IP DA on that packet routes it through that host M home agent. Host M's home agent knows to intercept any packet addressed to host M, and is keeping track of the current foreign agent servicing host M. This home agent then tunnels the packet meant for host M by encapsulating it in an outer wrapper with the foreign agent's address on it. And the foreign agent forwards it to the MANET host. The problem of how to reach the MANET host within the MANET remains, of course, since that is not part of Mobile IP. However, Mobile IP does pretty well answer the question of how an Internet host can initiate a session with a MANET host, without knowing where that MANET host is. I believe that the hosts within the MANET can keep using their own, permanent IP addresses, as we discussed already, as long as the gateways keep a list of every host in their MANET and as long as every MANET packet is routed explicitly, hop by hop, within the MANET (not very scalable, but that's not unusual in MANETs). So I believe that this combination would create a generic solution. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 12:30:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10051 for ; Wed, 10 Jul 2002 12:30:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14758; Wed, 10 Jul 2002 12:07:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14729 for ; Wed, 10 Jul 2002 12:07:00 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08800 for ; Wed, 10 Jul 2002 12:06:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA21203; Wed, 10 Jul 2002 09:06:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AG6SN17885; Wed, 10 Jul 2002 09:06:28 -0700 X-mProtect: <200207101606> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9s6qlh; Wed, 10 Jul 2002 09:06:24 PDT Message-ID: <3D2C5B80.184A9A9@iprg.nokia.com> Date: Wed, 10 Jul 2002 09:06:24 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Guillaume Chelius CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <1026311278.3d2c446e0b4e6@tc-mail.insa-lyon.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Guillaume, Guillaume Chelius wrote: > It could work with IPv6 since there is no need for subnet propagation. By > default, all nodes would use the link-local prefix. If a global prefix is > broadcasted, nodes also acquire the global prefix as you describe above. We use the idea of disseminating the global prefix, but not by broadcast. Using link-local addresses is problematic because no router is supposed to forward them. In our draft, we defined a distinguished site-local address for this purpose. It remains to be seen whether site-local addressing will survive within IPv6. If not, then maybe instead we can define some variant of the link-local addresses that can be forwarded. We could call them "manet-local" addresses, and they would use a distinguished "manet-local" prefix. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 12:30:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10060 for ; Wed, 10 Jul 2002 12:30:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17608 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 12:31:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14758; Wed, 10 Jul 2002 12:07:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14729 for ; Wed, 10 Jul 2002 12:07:00 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08800 for ; Wed, 10 Jul 2002 12:06:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA21203; Wed, 10 Jul 2002 09:06:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AG6SN17885; Wed, 10 Jul 2002 09:06:28 -0700 X-mProtect: <200207101606> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9s6qlh; Wed, 10 Jul 2002 09:06:24 PDT Message-ID: <3D2C5B80.184A9A9@iprg.nokia.com> Date: Wed, 10 Jul 2002 09:06:24 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Guillaume Chelius CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <1026311278.3d2c446e0b4e6@tc-mail.insa-lyon.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Guillaume, Guillaume Chelius wrote: > It could work with IPv6 since there is no need for subnet propagation. By > default, all nodes would use the link-local prefix. If a global prefix is > broadcasted, nodes also acquire the global prefix as you describe above. We use the idea of disseminating the global prefix, but not by broadcast. Using link-local addresses is problematic because no router is supposed to forward them. In our draft, we defined a distinguished site-local address for this purpose. It remains to be seen whether site-local addressing will survive within IPv6. If not, then maybe instead we can define some variant of the link-local addresses that can be forwarded. We could call them "manet-local" addresses, and they would use a distinguished "manet-local" prefix. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 12:30:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10083 for ; Wed, 10 Jul 2002 12:30:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11379; Wed, 10 Jul 2002 11:54:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11348 for ; Wed, 10 Jul 2002 11:54:31 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08209 for ; Wed, 10 Jul 2002 11:53:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20580; Wed, 10 Jul 2002 08:53:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AFrCE01606; Wed, 10 Jul 2002 08:53:12 -0700 X-mProtect: <200207101553> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdetVeQ4; Wed, 10 Jul 2002 08:53:10 PDT Message-ID: <3D2C5A2C.9000109@iprg.nokia.com> Date: Wed, 10 Jul 2002 09:00:44 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <006401c22814$d7369250$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Phil, I generally liked your note, but beg to differ on one minor point: Phil Neumiller wrote: > Adopting IPv6 in a small, battery driven device is not really all that feasible yet. > A small PDA running an ARM processor has to keep its software workload pretty light. I disagree about the feasibility arguement; I've been running IPv6 on PDAs for a long time now and the added code footprint/computational complexity for running IPv6 present no technical challenges. There may be business/marketing related reasons behind the slow adoption of IPv6 on PDAs, but no technical issues that I can think of. Regards, Fred ftemplin@iprg.nokia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 12:30:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10091 for ; Wed, 10 Jul 2002 12:30:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17694 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 12:31:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11379; Wed, 10 Jul 2002 11:54:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11348 for ; Wed, 10 Jul 2002 11:54:31 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08209 for ; Wed, 10 Jul 2002 11:53:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20580; Wed, 10 Jul 2002 08:53:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AFrCE01606; Wed, 10 Jul 2002 08:53:12 -0700 X-mProtect: <200207101553> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdetVeQ4; Wed, 10 Jul 2002 08:53:10 PDT Message-ID: <3D2C5A2C.9000109@iprg.nokia.com> Date: Wed, 10 Jul 2002 09:00:44 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] IP addresses in MANET References: <006401c22814$d7369250$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Phil, I generally liked your note, but beg to differ on one minor point: Phil Neumiller wrote: > Adopting IPv6 in a small, battery driven device is not really all that feasible yet. > A small PDA running an ARM processor has to keep its software workload pretty light. I disagree about the feasibility arguement; I've been running IPv6 on PDAs for a long time now and the added code footprint/computational complexity for running IPv6 present no technical challenges. There may be business/marketing related reasons behind the slow adoption of IPv6 on PDAs, but no technical issues that I can think of. Regards, Fred ftemplin@iprg.nokia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 12:38:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10589 for ; Wed, 10 Jul 2002 12:38:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15544; Wed, 10 Jul 2002 12:11:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15515 for ; Wed, 10 Jul 2002 12:11:13 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09098 for ; Wed, 10 Jul 2002 12:10:18 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 10:11:01 -0600 Message-Id: <02Jul10.101101mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:10:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, While this would work, what goes through my mind is the following scenario. Suppose Alice and Bill are two EEs from UCLA that are at an international conference in Prague. Further suppose, they are trying to communicate with each other while in two local, but distinct, MANETs. When Mary sends a packet to Bill, it will go to his home agent at UCLA, who then wraps it and forwards it to a gateway on MANET-B, which Bill is using. In a similar fashion, packets from Bill also go to UCLA and get forwarded to a gateway on MANET-A, which includes Alice's computer. So, two people a few miles from each other are carrying on a conversation which is being bounced to and from a location half way around the world. I don't think this is very far-fetched. I expect that business and high-tec travelers will want to use MANET connections to maintain connectivity with the Internet (and each other). It also seems logical that their home agents will be located at their home base. It also seems logical that two different hotels might each maintain their own MANETs for the use of their customers. I had suggested the directory server approach earlier because with that approach, the first time Bill sends a message to Alice, his host finds out from the server the location of the current MANET gateway that can reach Alice and sends the message directly to that MANET, which then takes care of getting the message to Alice. I understand that this capability is in the latest versions of MONET protocols. Essentially, the home agent acts as a directory service, rather than a mail forwarder. It would seem to be a better solution. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, July 10, 2002 9:48 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution John Mullen wrote: > Hi Bert, > > I am concerned, as Charlie is, with the problem of how a node > within the > Internet locates a host within a MANET, when it knows noting > about that > host, except its IP (however that is constructed). If a host > will only > belong to a particular MANET, some sort of subnet address would seem a > logical choice, but if that host could belong to any one of > numerous MANETs, > I can see things are far more complex. The MANETs I work > with are of the > first type, but, as you point out, this is not the most general case. This is in RFC 2002. Begin this story with the MANET host, call it Host M, coming on line suddenly in some arbitrary MANET. The first thing Host M does is it figures out if it's home or away. It does so by listening for agent advertisements and/or transmitting agent solicitations. (This protocol is an extensions of the older ICMP router discovery protocol.) Having found that it is away, and that a "foreign agent" is available, host M then registers with its "home agent" through this "foreign agent." The foreign agent acts only as a passive relay to and from the home agent, in this process. Host M's "home agent" authenticates this registration request, and now knows which foreign agent in the Internet is currently entrusted with host M. In our case, this foreign agent would be associated with an Internet-MANET gateway. Or it might be part of the gateway. Let's say an Internet host "I" needs to reach a host M, without knowing where host M is. In general, all host I knows is the address of host M. The IP packet from host I reaches the "home agent" of host M, simply because the IP DA on that packet routes it through that host M home agent. Host M's home agent knows to intercept any packet addressed to host M, and is keeping track of the current foreign agent servicing host M. This home agent then tunnels the packet meant for host M by encapsulating it in an outer wrapper with the foreign agent's address on it. And the foreign agent forwards it to the MANET host. The problem of how to reach the MANET host within the MANET remains, of course, since that is not part of Mobile IP. However, Mobile IP does pretty well answer the question of how an Internet host can initiate a session with a MANET host, without knowing where that MANET host is. I believe that the hosts within the MANET can keep using their own, permanent IP addresses, as we discussed already, as long as the gateways keep a list of every host in their MANET and as long as every MANET packet is routed explicitly, hop by hop, within the MANET (not very scalable, but that's not unusual in MANETs). So I believe that this combination would create a generic solution. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 12:38:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10596 for ; Wed, 10 Jul 2002 12:38:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18793 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 12:39:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15544; Wed, 10 Jul 2002 12:11:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15515 for ; Wed, 10 Jul 2002 12:11:13 -0400 (EDT) Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09098 for ; Wed, 10 Jul 2002 12:10:18 -0400 (EDT) Received: by gw.trac.wsmr.army.mil id <117123>; Wed, 10 Jul 2002 10:11:01 -0600 Message-Id: <02Jul10.101101mdt.117123@gw.trac.wsmr.army.mil> From: "Mullen, John P. (Contractor)" To: "Manfredi, Albert E" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 10:10:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Bert, While this would work, what goes through my mind is the following scenario. Suppose Alice and Bill are two EEs from UCLA that are at an international conference in Prague. Further suppose, they are trying to communicate with each other while in two local, but distinct, MANETs. When Mary sends a packet to Bill, it will go to his home agent at UCLA, who then wraps it and forwards it to a gateway on MANET-B, which Bill is using. In a similar fashion, packets from Bill also go to UCLA and get forwarded to a gateway on MANET-A, which includes Alice's computer. So, two people a few miles from each other are carrying on a conversation which is being bounced to and from a location half way around the world. I don't think this is very far-fetched. I expect that business and high-tec travelers will want to use MANET connections to maintain connectivity with the Internet (and each other). It also seems logical that their home agents will be located at their home base. It also seems logical that two different hotels might each maintain their own MANETs for the use of their customers. I had suggested the directory server approach earlier because with that approach, the first time Bill sends a message to Alice, his host finds out from the server the location of the current MANET gateway that can reach Alice and sends the message directly to that MANET, which then takes care of getting the message to Alice. I understand that this capability is in the latest versions of MONET protocols. Essentially, the home agent acts as a directory service, rather than a mail forwarder. It would seem to be a better solution. John Mullen -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Wednesday, July 10, 2002 9:48 AM To: 'Mullen, John P. (Contractor)' Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution John Mullen wrote: > Hi Bert, > > I am concerned, as Charlie is, with the problem of how a node > within the > Internet locates a host within a MANET, when it knows noting > about that > host, except its IP (however that is constructed). If a host > will only > belong to a particular MANET, some sort of subnet address would seem a > logical choice, but if that host could belong to any one of > numerous MANETs, > I can see things are far more complex. The MANETs I work > with are of the > first type, but, as you point out, this is not the most general case. This is in RFC 2002. Begin this story with the MANET host, call it Host M, coming on line suddenly in some arbitrary MANET. The first thing Host M does is it figures out if it's home or away. It does so by listening for agent advertisements and/or transmitting agent solicitations. (This protocol is an extensions of the older ICMP router discovery protocol.) Having found that it is away, and that a "foreign agent" is available, host M then registers with its "home agent" through this "foreign agent." The foreign agent acts only as a passive relay to and from the home agent, in this process. Host M's "home agent" authenticates this registration request, and now knows which foreign agent in the Internet is currently entrusted with host M. In our case, this foreign agent would be associated with an Internet-MANET gateway. Or it might be part of the gateway. Let's say an Internet host "I" needs to reach a host M, without knowing where host M is. In general, all host I knows is the address of host M. The IP packet from host I reaches the "home agent" of host M, simply because the IP DA on that packet routes it through that host M home agent. Host M's home agent knows to intercept any packet addressed to host M, and is keeping track of the current foreign agent servicing host M. This home agent then tunnels the packet meant for host M by encapsulating it in an outer wrapper with the foreign agent's address on it. And the foreign agent forwards it to the MANET host. The problem of how to reach the MANET host within the MANET remains, of course, since that is not part of Mobile IP. However, Mobile IP does pretty well answer the question of how an Internet host can initiate a session with a MANET host, without knowing where that MANET host is. I believe that the hosts within the MANET can keep using their own, permanent IP addresses, as we discussed already, as long as the gateways keep a list of every host in their MANET and as long as every MANET packet is routed explicitly, hop by hop, within the MANET (not very scalable, but that's not unusual in MANETs). So I believe that this combination would create a generic solution. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 13:02:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11257 for ; Wed, 10 Jul 2002 13:02:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18206; Wed, 10 Jul 2002 12:35:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18172 for ; Wed, 10 Jul 2002 12:35:33 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10289 for ; Wed, 10 Jul 2002 12:34:38 -0400 (EDT) Received: from slb-av-02.boeing.com ([129.172.13.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA11953; Wed, 10 Jul 2002 11:35:28 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA27897; Wed, 10 Jul 2002 09:35:27 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AGZQ014161; Wed, 10 Jul 2002 09:35:26 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 12:35:25 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A06@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 12:35:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Mullen wrote: > Suppose Alice and Bill are two EEs from UCLA that are at an > international > conference in Prague. Further suppose, they are trying to > communicate with > each other while in two local, but distinct, MANETs. When > Mary sends a > packet to Bill, it will go to his home agent at UCLA, who > then wraps it and > forwards it to a gateway on MANET-B, which Bill is using. There used to be an I-D addressing this problem, but I don't see it or an RFC that covers this, in a brief inspection of the Mobile IP wg, and obviously that I-D would have expired long ago. Maybe someone knows what happened to it. One solution would be for the Bill's home agent to respond back to Alice, or to Alice's default router, when first receiving a packet destined to Bill's host, with Bill's "care-of" address. That way, Alice could transmit packets directly to Bill's current foreign agent. These shortcuts could equally be relayed back to Alice's own foreign agent, if she is also on the road. > I had suggested the directory server approach earlier because > with that > approach, the first time Bill sends a message to Alice, his > host finds out > from the server the location of the current MANET gateway > that can reach > Alice and sends the message directly to that MANET, which > then takes care of > getting the message to Alice. I understand that this > capability is in the > latest versions of MONET protocols. I thought it was, but just now I didn't find it. Maybe I should look harder. Anyway, it is doable, I believe, within the context of MONET. This problem was also covered in the wireless ATM wg of the ATMF, years ago. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 13:02:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11265 for ; Wed, 10 Jul 2002 13:02:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21061 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 13:03:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18206; Wed, 10 Jul 2002 12:35:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18172 for ; Wed, 10 Jul 2002 12:35:33 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10289 for ; Wed, 10 Jul 2002 12:34:38 -0400 (EDT) Received: from slb-av-02.boeing.com ([129.172.13.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA11953; Wed, 10 Jul 2002 11:35:28 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA27897; Wed, 10 Jul 2002 09:35:27 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AGZQ014161; Wed, 10 Jul 2002 09:35:26 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 12:35:25 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A06@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 12:35:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Mullen wrote: > Suppose Alice and Bill are two EEs from UCLA that are at an > international > conference in Prague. Further suppose, they are trying to > communicate with > each other while in two local, but distinct, MANETs. When > Mary sends a > packet to Bill, it will go to his home agent at UCLA, who > then wraps it and > forwards it to a gateway on MANET-B, which Bill is using. There used to be an I-D addressing this problem, but I don't see it or an RFC that covers this, in a brief inspection of the Mobile IP wg, and obviously that I-D would have expired long ago. Maybe someone knows what happened to it. One solution would be for the Bill's home agent to respond back to Alice, or to Alice's default router, when first receiving a packet destined to Bill's host, with Bill's "care-of" address. That way, Alice could transmit packets directly to Bill's current foreign agent. These shortcuts could equally be relayed back to Alice's own foreign agent, if she is also on the road. > I had suggested the directory server approach earlier because > with that > approach, the first time Bill sends a message to Alice, his > host finds out > from the server the location of the current MANET gateway > that can reach > Alice and sends the message directly to that MANET, which > then takes care of > getting the message to Alice. I understand that this > capability is in the > latest versions of MONET protocols. I thought it was, but just now I didn't find it. Maybe I should look harder. Anyway, it is doable, I believe, within the context of MONET. This problem was also covered in the wireless ATM wg of the ATMF, years ago. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 13:10:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09521 for ; Wed, 10 Jul 2002 12:17:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16348 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 12:18:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10514; Wed, 10 Jul 2002 11:48:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10411 for ; Wed, 10 Jul 2002 11:48:24 -0400 (EDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07916 for ; Wed, 10 Jul 2002 11:47:29 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA02755; Wed, 10 Jul 2002 10:48:17 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA29990; Wed, 10 Jul 2002 08:47:59 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AFmF011310; Wed, 10 Jul 2002 08:48:15 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 11:48:14 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A05@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Mullen, John P. (Contractor)'" Cc: manet@ietf.org Subject: RE: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 11:48:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org John Mullen wrote: > Hi Bert, > > I am concerned, as Charlie is, with the problem of how a node > within the > Internet locates a host within a MANET, when it knows noting > about that > host, except its IP (however that is constructed). If a host > will only > belong to a particular MANET, some sort of subnet address would seem a > logical choice, but if that host could belong to any one of > numerous MANETs, > I can see things are far more complex. The MANETs I work > with are of the > first type, but, as you point out, this is not the most general case. This is in RFC 2002. Begin this story with the MANET host, call it Host M, coming on line suddenly in some arbitrary MANET. The first thing Host M does is it figures out if it's home or away. It does so by listening for agent advertisements and/or transmitting agent solicitations. (This protocol is an extensions of the older ICMP router discovery protocol.) Having found that it is away, and that a "foreign agent" is available, host M then registers with its "home agent" through this "foreign agent." The foreign agent acts only as a passive relay to and from the home agent, in this process. Host M's "home agent" authenticates this registration request, and now knows which foreign agent in the Internet is currently entrusted with host M. In our case, this foreign agent would be associated with an Internet-MANET gateway. Or it might be part of the gateway. Let's say an Internet host "I" needs to reach a host M, without knowing where host M is. In general, all host I knows is the address of host M. The IP packet from host I reaches the "home agent" of host M, simply because the IP DA on that packet routes it through that host M home agent. Host M's home agent knows to intercept any packet addressed to host M, and is keeping track of the current foreign agent servicing host M. This home agent then tunnels the packet meant for host M by encapsulating it in an outer wrapper with the foreign agent's address on it. And the foreign agent forwards it to the MANET host. The problem of how to reach the MANET host within the MANET remains, of course, since that is not part of Mobile IP. However, Mobile IP does pretty well answer the question of how an Internet host can initiate a session with a MANET host, without knowing where that MANET host is. I believe that the hosts within the MANET can keep using their own, permanent IP addresses, as we discussed already, as long as the gateways keep a list of every host in their MANET and as long as every MANET packet is routed explicitly, hop by hop, within the MANET (not very scalable, but that's not unusual in MANETs). So I believe that this combination would create a generic solution. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 14:04:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13460 for ; Wed, 10 Jul 2002 14:04:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12714; Wed, 10 Jul 2002 12:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12319 for ; Wed, 10 Jul 2002 12:00:19 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08438 for ; Wed, 10 Jul 2002 11:59:22 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.1.176]) with ESMTP; Wed, 10 Jul 2002 09:00:38 -0700 Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g6AFof4Y002471; Wed, 10 Jul 2002 08:50:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: References: Date: Wed, 10 Jul 2002 08:51:17 -0700 To: yasser.lotfy@lycos.com, "MANET mailing list" , "Anders Nilsson" From: Rex Buddenberg Subject: Re: [manet] QoS over shared media Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 11:35 PM -0400 7/9/02, Yasser A. Lotfy wrote: >Good day, > >In responce to Nilsson's e-mail, I can't help but think of QoS based >on transimission over shared media. To make my point clear ckeck >this simple example. Assume A, B, C, D, E, & F are nodes >geographically positioned as drawn (just for simplicity). If A needs >to transfer a high bandwidth stream to E via C, while B needs a low >bandwidth transfer to F via D. It is possible to increase the share >of link AC of the bandwidth (since link AC & BD share the same >media). > >A ====> C ====> E >B ----> D ----> F Yasser, let's make one of your assumptions explicit: high bandwidth (as you used the term) = high priority. In which case your logic is ok. But a lot of the high precedence traffic is fairly small chunks of data. Consider a chem/bio warning system that we implement over the Internet (with or without MANET segments in it). The sensors in the system are scattered around sniffing for Bad Stuff. When they sniff such, they push out a datagram (probably to multiple addresses) announcing that fact -- should only take a few dozen bytes to say everything possibly useful. That traffic needs to be able to push aside some streaming VTCs that are using the same plumbing. In other words, 'low bandwidth' now equates to high priority. > >The problem is that QoS solutions have always been implemented on IP >layer. Implementing this kind of solution will require tight >marriage with MAC layer. In addition, the dynamics of varying MAC >resources based on the need seem to carry lots of difficulties. You are on target here -- both the multicast and QoS (e.g. diff-serv DSCP) characteristics need to be reflected through from network to datalink layer. A quickie would be to mirror the DSCP data through from IP datagrams to MAC layer frames. In a lot of cases, the primitives are there, but the linkages are not -- for instance, FDDI supports 8 layers of priority but there are no general purpose ways (i.e. vendor-neutral standardization) to get the TOS bits copied from datagram to frame. > >My question is whether you can point me to any research done on that >area? INSIGNIA, and FQMM (not quite sure about SWAN) they all work >on IP layer without investigating this kind of otimization. Does >Bluetooth, or 802.11b provide any mean to carry over such ideas? So far, all work that I know of is media-specific. Phil Neumiller's underbelly discussion on this list is aimed at generalizing some of this ... Phil et al, correct and adjust my take. > >Inputs are highly appreciated. > >Yasser >Carleton University > > > >_____________________________________________________ >Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads >and NoTaglines --> LYCOS MAIL PLUS. >http://www.mail.lycos.com/brandPage.shtml?pageId=plus > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 14:04:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13467 for ; Wed, 10 Jul 2002 14:04:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26346 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 14:05:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12714; Wed, 10 Jul 2002 12:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12319 for ; Wed, 10 Jul 2002 12:00:19 -0400 (EDT) Received: from [140.32.132.66] (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08438 for ; Wed, 10 Jul 2002 11:59:22 -0400 (EDT) Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.1.176]) with ESMTP; Wed, 10 Jul 2002 09:00:38 -0700 Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g6AFof4Y002471; Wed, 10 Jul 2002 08:50:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@essex.ad.nps.navy.mil Message-Id: In-Reply-To: References: Date: Wed, 10 Jul 2002 08:51:17 -0700 To: yasser.lotfy@lycos.com, "MANET mailing list" , "Anders Nilsson" From: Rex Buddenberg Subject: Re: [manet] QoS over shared media Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 11:35 PM -0400 7/9/02, Yasser A. Lotfy wrote: >Good day, > >In responce to Nilsson's e-mail, I can't help but think of QoS based >on transimission over shared media. To make my point clear ckeck >this simple example. Assume A, B, C, D, E, & F are nodes >geographically positioned as drawn (just for simplicity). If A needs >to transfer a high bandwidth stream to E via C, while B needs a low >bandwidth transfer to F via D. It is possible to increase the share >of link AC of the bandwidth (since link AC & BD share the same >media). > >A ====> C ====> E >B ----> D ----> F Yasser, let's make one of your assumptions explicit: high bandwidth (as you used the term) = high priority. In which case your logic is ok. But a lot of the high precedence traffic is fairly small chunks of data. Consider a chem/bio warning system that we implement over the Internet (with or without MANET segments in it). The sensors in the system are scattered around sniffing for Bad Stuff. When they sniff such, they push out a datagram (probably to multiple addresses) announcing that fact -- should only take a few dozen bytes to say everything possibly useful. That traffic needs to be able to push aside some streaming VTCs that are using the same plumbing. In other words, 'low bandwidth' now equates to high priority. > >The problem is that QoS solutions have always been implemented on IP >layer. Implementing this kind of solution will require tight >marriage with MAC layer. In addition, the dynamics of varying MAC >resources based on the need seem to carry lots of difficulties. You are on target here -- both the multicast and QoS (e.g. diff-serv DSCP) characteristics need to be reflected through from network to datalink layer. A quickie would be to mirror the DSCP data through from IP datagrams to MAC layer frames. In a lot of cases, the primitives are there, but the linkages are not -- for instance, FDDI supports 8 layers of priority but there are no general purpose ways (i.e. vendor-neutral standardization) to get the TOS bits copied from datagram to frame. > >My question is whether you can point me to any research done on that >area? INSIGNIA, and FQMM (not quite sure about SWAN) they all work >on IP layer without investigating this kind of otimization. Does >Bluetooth, or 802.11b provide any mean to carry over such ideas? So far, all work that I know of is media-specific. Phil Neumiller's underbelly discussion on this list is aimed at generalizing some of this ... Phil et al, correct and adjust my take. > >Inputs are highly appreciated. > >Yasser >Carleton University > > > >_____________________________________________________ >Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads >and NoTaglines --> LYCOS MAIL PLUS. >http://www.mail.lycos.com/brandPage.shtml?pageId=plus > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 14:19:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14169 for ; Wed, 10 Jul 2002 14:19:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24936; Wed, 10 Jul 2002 13:53:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24908 for ; Wed, 10 Jul 2002 13:53:04 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13036 for ; Wed, 10 Jul 2002 13:52:11 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZ0H; Wed, 10 Jul 2002 13:52:57 -0400 Message-ID: <01de01c2283a$9ed29410$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> <3D2C557D.C3E289C7@iprg.nokia.com> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 13:52:55 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit For the inquiring minds... "Sorry Charlie, Starfish doesn't want Tuna with good taste, Starfish wants Tuna that taste good!" Is an old TV commercial slogan from Starfish [canned] Tuna company which was played over and over again during episodes of Leave it to Beaver and Gilligan's Island.... I have re-read this section 6 and 7 and I have the following questions about it (now that I been conked upside the head with it). 1). Don't MANET nodes that use mobile IP have to route on their static home addresses? 2). If the "bunch of mobiles" that are to be aggregated, are random mobiles from a large variety of different home networks, how can a subnet of consequitive addresses be formed? 3). The definition of "subnet" that is introduced in section 6 sounds much looser, more like a MONET to me. 4). Why couldn't every node in the "subnet" as defined, proxy for all others in the RREP? i.e. why do other subnet nodes need to FORWARD RREQs to the subnet leader? That seems to be a point of vulnerability. It seems that any entity in the subnet blob should be able to answer for the subnet blob - in case the subnet leader fails. 5). Why would we not want all nodes to be advertising reachability? It seems that the subnet leader could easily be out of range from mobile nodes wishing to communicate with the subnet. Or is this just because they would end up relaying each others gratuitous RREPs w/ subnet bits and that would be redundant. 6). Do all nodes in the subnet have to be one hop away from the subnet leader? i.e. have a closed bi-directional link to the leader? If not, how many hops away can they be. Thanks, Phil ----- Original Message ----- From: "Charles E. Perkins" To: "Phil Neumiller" Cc: Sent: Wednesday, July 10, 2002 11:40 AM Subject: Re: [manet] Gateway address resolution > > Hello Phil, > > Phil Neumiller wrote: > > > Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the > > past. I see this in the latest draft. > > The subnet mask propagation has been there for years, but it's > easy to miss and hasn't been discussed much within [manet]. > > I'm puzzling over what percentage of the respondents to > this list will recognize your tuna reference... > > Regards, > Charlie P. > > PS. You can tune a piano, and you can tune a guitar, but you can't tunefs. > (screams of agony are blissfully unheard over e-mail) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 14:19:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14175 for ; Wed, 10 Jul 2002 14:19:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27312 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 14:19:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24936; Wed, 10 Jul 2002 13:53:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24908 for ; Wed, 10 Jul 2002 13:53:04 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13036 for ; Wed, 10 Jul 2002 13:52:11 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9KZ0H; Wed, 10 Jul 2002 13:52:57 -0400 Message-ID: <01de01c2283a$9ed29410$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> <3D2C557D.C3E289C7@iprg.nokia.com> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 13:52:55 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit For the inquiring minds... "Sorry Charlie, Starfish doesn't want Tuna with good taste, Starfish wants Tuna that taste good!" Is an old TV commercial slogan from Starfish [canned] Tuna company which was played over and over again during episodes of Leave it to Beaver and Gilligan's Island.... I have re-read this section 6 and 7 and I have the following questions about it (now that I been conked upside the head with it). 1). Don't MANET nodes that use mobile IP have to route on their static home addresses? 2). If the "bunch of mobiles" that are to be aggregated, are random mobiles from a large variety of different home networks, how can a subnet of consequitive addresses be formed? 3). The definition of "subnet" that is introduced in section 6 sounds much looser, more like a MONET to me. 4). Why couldn't every node in the "subnet" as defined, proxy for all others in the RREP? i.e. why do other subnet nodes need to FORWARD RREQs to the subnet leader? That seems to be a point of vulnerability. It seems that any entity in the subnet blob should be able to answer for the subnet blob - in case the subnet leader fails. 5). Why would we not want all nodes to be advertising reachability? It seems that the subnet leader could easily be out of range from mobile nodes wishing to communicate with the subnet. Or is this just because they would end up relaying each others gratuitous RREPs w/ subnet bits and that would be redundant. 6). Do all nodes in the subnet have to be one hop away from the subnet leader? i.e. have a closed bi-directional link to the leader? If not, how many hops away can they be. Thanks, Phil ----- Original Message ----- From: "Charles E. Perkins" To: "Phil Neumiller" Cc: Sent: Wednesday, July 10, 2002 11:40 AM Subject: Re: [manet] Gateway address resolution > > Hello Phil, > > Phil Neumiller wrote: > > > Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the > > past. I see this in the latest draft. > > The subnet mask propagation has been there for years, but it's > easy to miss and hasn't been discussed much within [manet]. > > I'm puzzling over what percentage of the respondents to > this list will recognize your tuna reference... > > Regards, > Charlie P. > > PS. You can tune a piano, and you can tune a guitar, but you can't tunefs. > (screams of agony are blissfully unheard over e-mail) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 14:49:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15251 for ; Wed, 10 Jul 2002 14:49:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26821; Wed, 10 Jul 2002 14:15:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26790 for ; Wed, 10 Jul 2002 14:15:35 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13934 for ; Wed, 10 Jul 2002 14:14:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29269; Wed, 10 Jul 2002 11:15:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AIF2S06119; Wed, 10 Jul 2002 11:15:02 -0700 X-mProtect: <200207101815> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdp90Xm6; Wed, 10 Jul 2002 11:15:00 PDT Message-ID: <3D2C79A4.CAD5FDF7@iprg.nokia.com> Date: Wed, 10 Jul 2002 11:15:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> <3D2C557D.C3E289C7@iprg.nokia.com> <01de01c2283a$9ed29410$ab Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > I have re-read this section 6 and 7 and I have the following questions about it > (now that I been conked upside the head with it). > > 1). Don't MANET nodes that use mobile IP have to route on their static home addresses? A node "should" be able to use Mobile IP for any address it owns, and for which there is a home agent (or maybe not even that for the experimental "homeless" variants). > 2). If the "bunch of mobiles" that are to be aggregated, are random mobiles > from a large variety of different home networks, how can a subnet of > consequitive addresses be formed? If nodes are using random addresses, then it can't. On the other hand, can you tell me what it means to have a subnet of non-consecutive addresses? Maybe somebody here has horror stories about using the "more flexible" subnet masks of old versions of BSD Unix. > 3). The definition of "subnet" that is introduced in section 6 sounds much > looser, more like a MONET to me. It includes only the features needed by AODV. But those are hard requirements, as far as I know. > 4). Why couldn't every node in the "subnet" as defined, proxy for > all others in the RREP? They could, as long as they keep the sequence number consistent. > i.e. why do other subnet nodes need to FORWARD RREQs to the subnet leader? > That seems to be a point of vulnerability. It seems that any entity in the > subnet blob should be able to answer for the subnet blob - in case the > subnet leader fails. This is a special case of a much more general problem, though. How does any system function, if the central control point fails? Usually, by redundancy and distribution of failover data. You'll have to weigh the benefits vs. the cost for each instance. For the case of the subnet in an ad hoc network, one would have to write the protocol for maintaining subnet semantics. I reckon it would resemble what you would do for an anycast group. > 5). Why would we not want all nodes to be advertising reachability? It seems that > the subnet leader could easily be out of range from mobile nodes wishing to > communicate with the subnet. Or is this just because they would end up > relaying each others gratuitous RREPs w/ subnet bits and that would be > redundant. Nodes outside the subnet need to have some useful sequence number assignable to the route towards the subnet. As long as you can have all the nodes advertising consistent sequence number information, it will work. For example, they could advertise the SAME sequence number, but other solutions are also possible. > 6). Do all nodes in the subnet have to be one hop away from the subnet leader? No. > If not, how many hops away can they be. As many as your system design can manage, within the constraint of obeying subnet semantics. Regards, Charlie P. > ----- Original Message ----- > From: "Charles E. Perkins" > To: "Phil Neumiller" > Cc: > Sent: Wednesday, July 10, 2002 11:40 AM > Subject: Re: [manet] Gateway address resolution > > > > > Hello Phil, > > > > Phil Neumiller wrote: > > > > > Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the > > > past. I see this in the latest draft. > > > > The subnet mask propagation has been there for years, but it's > > easy to miss and hasn't been discussed much within [manet]. > > > > I'm puzzling over what percentage of the respondents to > > this list will recognize your tuna reference... > > > > Regards, > > Charlie P. > > > > PS. You can tune a piano, and you can tune a guitar, but you can't tunefs. > > (screams of agony are blissfully unheard over e-mail) > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 14:49:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15269 for ; Wed, 10 Jul 2002 14:49:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29383 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 14:50:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26821; Wed, 10 Jul 2002 14:15:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26790 for ; Wed, 10 Jul 2002 14:15:35 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13934 for ; Wed, 10 Jul 2002 14:14:41 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29269; Wed, 10 Jul 2002 11:15:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AIF2S06119; Wed, 10 Jul 2002 11:15:02 -0700 X-mProtect: <200207101815> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdp90Xm6; Wed, 10 Jul 2002 11:15:00 PDT Message-ID: <3D2C79A4.CAD5FDF7@iprg.nokia.com> Date: Wed, 10 Jul 2002 11:15:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Gateway address resolution References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> <3D2C557D.C3E289C7@iprg.nokia.com> <01de01c2283a$9ed29410$ab Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > I have re-read this section 6 and 7 and I have the following questions about it > (now that I been conked upside the head with it). > > 1). Don't MANET nodes that use mobile IP have to route on their static home addresses? A node "should" be able to use Mobile IP for any address it owns, and for which there is a home agent (or maybe not even that for the experimental "homeless" variants). > 2). If the "bunch of mobiles" that are to be aggregated, are random mobiles > from a large variety of different home networks, how can a subnet of > consequitive addresses be formed? If nodes are using random addresses, then it can't. On the other hand, can you tell me what it means to have a subnet of non-consecutive addresses? Maybe somebody here has horror stories about using the "more flexible" subnet masks of old versions of BSD Unix. > 3). The definition of "subnet" that is introduced in section 6 sounds much > looser, more like a MONET to me. It includes only the features needed by AODV. But those are hard requirements, as far as I know. > 4). Why couldn't every node in the "subnet" as defined, proxy for > all others in the RREP? They could, as long as they keep the sequence number consistent. > i.e. why do other subnet nodes need to FORWARD RREQs to the subnet leader? > That seems to be a point of vulnerability. It seems that any entity in the > subnet blob should be able to answer for the subnet blob - in case the > subnet leader fails. This is a special case of a much more general problem, though. How does any system function, if the central control point fails? Usually, by redundancy and distribution of failover data. You'll have to weigh the benefits vs. the cost for each instance. For the case of the subnet in an ad hoc network, one would have to write the protocol for maintaining subnet semantics. I reckon it would resemble what you would do for an anycast group. > 5). Why would we not want all nodes to be advertising reachability? It seems that > the subnet leader could easily be out of range from mobile nodes wishing to > communicate with the subnet. Or is this just because they would end up > relaying each others gratuitous RREPs w/ subnet bits and that would be > redundant. Nodes outside the subnet need to have some useful sequence number assignable to the route towards the subnet. As long as you can have all the nodes advertising consistent sequence number information, it will work. For example, they could advertise the SAME sequence number, but other solutions are also possible. > 6). Do all nodes in the subnet have to be one hop away from the subnet leader? No. > If not, how many hops away can they be. As many as your system design can manage, within the constraint of obeying subnet semantics. Regards, Charlie P. > ----- Original Message ----- > From: "Charles E. Perkins" > To: "Phil Neumiller" > Cc: > Sent: Wednesday, July 10, 2002 11:40 AM > Subject: Re: [manet] Gateway address resolution > > > > > Hello Phil, > > > > Phil Neumiller wrote: > > > > > Ouch! Sorry Charlie (tuna that tastes bad or something). I must be stuck in the > > > past. I see this in the latest draft. > > > > The subnet mask propagation has been there for years, but it's > > easy to miss and hasn't been discussed much within [manet]. > > > > I'm puzzling over what percentage of the respondents to > > this list will recognize your tuna reference... > > > > Regards, > > Charlie P. > > > > PS. You can tune a piano, and you can tune a guitar, but you can't tunefs. > > (screams of agony are blissfully unheard over e-mail) > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 15:02:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15648 for ; Wed, 10 Jul 2002 15:02:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28622; Wed, 10 Jul 2002 14:35:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28593 for ; Wed, 10 Jul 2002 14:35:13 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14724 for ; Wed, 10 Jul 2002 14:34:19 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9K5CN; Wed, 10 Jul 2002 14:35:10 -0400 Message-ID: <003f01c22840$84d6c1c0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Neumiller" , "Charles E. Perkins" Cc: References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> <3D2C557D.C3E289C7@iprg.nokia.com> <01de01c2283a$9ed29410$ab0110ac@meshnetworks.com> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 14:35:09 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit I stand corrected again. It was "Starkist Tuna" not Starfish Tuna! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 15:02:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15655 for ; Wed, 10 Jul 2002 15:02:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00395 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 15:03:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28622; Wed, 10 Jul 2002 14:35:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28593 for ; Wed, 10 Jul 2002 14:35:13 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14724 for ; Wed, 10 Jul 2002 14:34:19 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9K5CN; Wed, 10 Jul 2002 14:35:10 -0400 Message-ID: <003f01c22840$84d6c1c0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Neumiller" , "Charles E. Perkins" Cc: References: <02Jul1.074737mdt.117122@gw.trac.wsmr.army.mil> <00bb01c22818$b7bba790$ab0110ac@meshnetworks.com> <3D2C4711.13D4DC3D@iprg.nokia.com> <014b01c22823$9f45bfb0$ab0110ac@meshnetworks.com> <3D2C557D.C3E289C7@iprg.nokia.com> <01de01c2283a$9ed29410$ab0110ac@meshnetworks.com> Subject: Re: [manet] Gateway address resolution Date: Wed, 10 Jul 2002 14:35:09 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit I stand corrected again. It was "Starkist Tuna" not Starfish Tuna! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 16:39:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18925 for ; Wed, 10 Jul 2002 16:39:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04825; Wed, 10 Jul 2002 16:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04797 for ; Wed, 10 Jul 2002 16:18:17 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18069 for ; Wed, 10 Jul 2002 16:17:22 -0400 (EDT) From: "Xiaoning He" To: Date: Wed, 10 Jul 2002 13:15:43 -0700 Message-ID: <000101c2284e$91bfee30$106015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA04798 Subject: [manet] Mobile Ad-hoc Network in the 4G system Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi all I have a few questions regarding the role of the Mobile ad-hoc network in the 4G wireless system. Whether or not the ad-hoc type of network will play an important role in the 4G system? If it will, what's the killer app for the mobile ad-hoc network in 4G? It seems to me that currently the mobile ad-hoc network is important for military, disaster relief etc. But for daily personal life, I am not sure. I am not sure whether it is the right place to raise question. Anyway, please feel free to comment. Regards Xiaoning He, Ph.D Research Engineer 181 Metro Drive, Suite 300 San Jose, CA 95110 Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax : +1 (408) 573-1090 **********************Confidentiality Note********************** Privileged/Confidential Information may be contained in this e-mail and any attachment to it and may be covered by existing non-disclosure or confidentiality agreements. If you are not the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone any information contained in this e-mail.  If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete it from your system. Thank you very much. ************************************************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 16:39:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18932 for ; Wed, 10 Jul 2002 16:39:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07344 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 16:40:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04825; Wed, 10 Jul 2002 16:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04797 for ; Wed, 10 Jul 2002 16:18:17 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18069 for ; Wed, 10 Jul 2002 16:17:22 -0400 (EDT) From: "Xiaoning He" To: Date: Wed, 10 Jul 2002 13:15:43 -0700 Message-ID: <000101c2284e$91bfee30$106015ac@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA04798 Subject: [manet] Mobile Ad-hoc Network in the 4G system Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi all I have a few questions regarding the role of the Mobile ad-hoc network in the 4G wireless system. Whether or not the ad-hoc type of network will play an important role in the 4G system? If it will, what's the killer app for the mobile ad-hoc network in 4G? It seems to me that currently the mobile ad-hoc network is important for military, disaster relief etc. But for daily personal life, I am not sure. I am not sure whether it is the right place to raise question. Anyway, please feel free to comment. Regards Xiaoning He, Ph.D Research Engineer 181 Metro Drive, Suite 300 San Jose, CA 95110 Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax : +1 (408) 573-1090 **********************Confidentiality Note********************** Privileged/Confidential Information may be contained in this e-mail and any attachment to it and may be covered by existing non-disclosure or confidentiality agreements. If you are not the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone any information contained in this e-mail.  If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete it from your system. Thank you very much. ************************************************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 17:02:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19432 for ; Wed, 10 Jul 2002 17:02:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06364; Wed, 10 Jul 2002 16:35:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06332 for ; Wed, 10 Jul 2002 16:35:13 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18715 for ; Wed, 10 Jul 2002 16:34:19 -0400 (EDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9K5K2; Wed, 10 Jul 2002 16:35:10 -0400 Message-ID: <007501c22851$484d4240$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Xiaoning He" , References: <000101c2284e$91bfee30$106015ac@VAIO> Subject: Re: [manet] Mobile Ad-hoc Network in the 4G system Date: Wed, 10 Jul 2002 16:35:08 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Xiaoning, ----- Original Message ----- From: "Xiaoning He" I have a few questions regarding the role of the Mobile ad-hoc network in the 4G wireless system. Whether or not the ad-hoc type of network will play an important role in the 4G system? If it will, what's the killer app for the mobile ad-hoc network in 4G? pdn>How do you define 4G systems? That is a buzzword used by marketing pdn>types at this time, and could mean almost anything. pdn> pdn>3G systems have real SDOs, i.e. 3GPP, and 3GPP2, etc. If I knew what pdn>the killer app was I certainly would not discuss it on a public mail list would I? It seems to me that currently the mobile ad-hoc network is important for military, disaster relief etc. But for daily personal life, I am not sure. pdn>Think outside the norm. Why do you want to be restricted to backhaul that pdn>carriers (like your company) provide. Why not put the ability to "carry" traffic into pdn>the people's hands. This has worked for the PC, and then the Web; where pdn>people could define their own networks with hyperlinks. As far as I can tell pdn>the PC and the Web were pretty successful. Don't you think that empowering pdn>people to build their own self-forming mesh networks will be a huge success? pdn>IMHO, whenever a technology is moved out of the glass house and put into pdn>people's hands, it becomes wildly succesful. This is NOT what a carrier pdn>wants to hear though! :-) I am not sure whether it is the right place to raise question. Anyway, please feel free to comment. pdn> BTW, your signature below violates the IETF policy on IPR. pdn>Best regards, pdn> pdn>Phil Neumiller Regards Xiaoning He, Ph.D Research Engineer 181 Metro Drive, Suite 300 San Jose, CA 95110 Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax : +1 (408) 573-1090 **********************Confidentiality Note********************** Privileged/Confidential Information may be contained in this e-mail and any attachment to it and may be covered by existing non-disclosure or confidentiality agreements. If you are not the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone any information contained in this e-mail. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete it from your system. Thank you very much. ************************************************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 17:02:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19437 for ; Wed, 10 Jul 2002 17:02:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09531 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 17:02:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06364; Wed, 10 Jul 2002 16:35:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06332 for ; Wed, 10 Jul 2002 16:35:13 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18715 for ; Wed, 10 Jul 2002 16:34:19 -0400 (EDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RD9K5K2; Wed, 10 Jul 2002 16:35:10 -0400 Message-ID: <007501c22851$484d4240$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Xiaoning He" , References: <000101c2284e$91bfee30$106015ac@VAIO> Subject: Re: [manet] Mobile Ad-hoc Network in the 4G system Date: Wed, 10 Jul 2002 16:35:08 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Xiaoning, ----- Original Message ----- From: "Xiaoning He" I have a few questions regarding the role of the Mobile ad-hoc network in the 4G wireless system. Whether or not the ad-hoc type of network will play an important role in the 4G system? If it will, what's the killer app for the mobile ad-hoc network in 4G? pdn>How do you define 4G systems? That is a buzzword used by marketing pdn>types at this time, and could mean almost anything. pdn> pdn>3G systems have real SDOs, i.e. 3GPP, and 3GPP2, etc. If I knew what pdn>the killer app was I certainly would not discuss it on a public mail list would I? It seems to me that currently the mobile ad-hoc network is important for military, disaster relief etc. But for daily personal life, I am not sure. pdn>Think outside the norm. Why do you want to be restricted to backhaul that pdn>carriers (like your company) provide. Why not put the ability to "carry" traffic into pdn>the people's hands. This has worked for the PC, and then the Web; where pdn>people could define their own networks with hyperlinks. As far as I can tell pdn>the PC and the Web were pretty successful. Don't you think that empowering pdn>people to build their own self-forming mesh networks will be a huge success? pdn>IMHO, whenever a technology is moved out of the glass house and put into pdn>people's hands, it becomes wildly succesful. This is NOT what a carrier pdn>wants to hear though! :-) I am not sure whether it is the right place to raise question. Anyway, please feel free to comment. pdn> BTW, your signature below violates the IETF policy on IPR. pdn>Best regards, pdn> pdn>Phil Neumiller Regards Xiaoning He, Ph.D Research Engineer 181 Metro Drive, Suite 300 San Jose, CA 95110 Email: xiaoning@docomolabs-usa.com Phone: +1 (408) 451-4737 Fax : +1 (408) 573-1090 **********************Confidentiality Note********************** Privileged/Confidential Information may be contained in this e-mail and any attachment to it and may be covered by existing non-disclosure or confidentiality agreements. If you are not the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone any information contained in this e-mail. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete it from your system. Thank you very much. ************************************************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 17:16:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20140 for ; Wed, 10 Jul 2002 17:16:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07818; Wed, 10 Jul 2002 16:53:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07785 for ; Wed, 10 Jul 2002 16:53:17 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19177 for ; Wed, 10 Jul 2002 16:52:21 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA22915; Wed, 10 Jul 2002 13:53:10 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA28737; Wed, 10 Jul 2002 15:53:02 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AKr8016872; Wed, 10 Jul 2002 13:53:08 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 16:53:07 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A09@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Xiaoning He'" , manet@ietf.org Subject: RE: [manet] Mobile Ad-hoc Network in the 4G system Date: Wed, 10 Jul 2002 16:53:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Xiaoning, My reactions would be: 1. What is 4G? Specifically, other than bandwidth (the modulation scheme in the wireless links), how does it differ from 3G? 2. If 4G is basically an extension of the wired network, depends on geographically fixed base stations for packet routing and access to mobile hosts, the wireless link is a point-to-point link to individual mobile hosts, then clearly it is not the problem MANET is out to solve. 3. However, of course, a MANET could be made to connect to a 4G, or 3G, or Internet, wired networks. Bert > -----Original Message----- > From: Xiaoning He [mailto:xiaoning@docomolabs-usa.com] > Sent: Wednesday, July 10, 2002 4:16 PM > To: manet@ietf.org > Subject: [manet] Mobile Ad-hoc Network in the 4G system > > > Hi all > > I have a few questions regarding the role of the Mobile ad-hoc network > in the 4G wireless system. Whether or not the ad-hoc type of network > will play an important role in the 4G system? If it will, what's the > killer app for the mobile ad-hoc network in 4G? > > It seems to me that currently the mobile ad-hoc network is > important for > military, disaster relief etc. But for daily personal life, I am not > sure. > > I am not sure whether it is the right place to raise question. Anyway, > please feel free to comment. > > Regards > > Xiaoning He, Ph.D > Research Engineer > 181 Metro Drive, Suite 300 > San Jose, CA 95110 > > Email: xiaoning@docomolabs-usa.com > Phone: +1 (408) 451-4737 > Fax : +1 (408) 573-1090 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 17:16:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20146 for ; Wed, 10 Jul 2002 17:16:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10284 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 17:17:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07818; Wed, 10 Jul 2002 16:53:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07785 for ; Wed, 10 Jul 2002 16:53:17 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19177 for ; Wed, 10 Jul 2002 16:52:21 -0400 (EDT) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA22915; Wed, 10 Jul 2002 13:53:10 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id PAA28737; Wed, 10 Jul 2002 15:53:02 -0500 (CDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6AKr8016872; Wed, 10 Jul 2002 13:53:08 -0700 (PDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jul 2002 16:53:07 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A09@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Xiaoning He'" , manet@ietf.org Subject: RE: [manet] Mobile Ad-hoc Network in the 4G system Date: Wed, 10 Jul 2002 16:53:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Xiaoning, My reactions would be: 1. What is 4G? Specifically, other than bandwidth (the modulation scheme in the wireless links), how does it differ from 3G? 2. If 4G is basically an extension of the wired network, depends on geographically fixed base stations for packet routing and access to mobile hosts, the wireless link is a point-to-point link to individual mobile hosts, then clearly it is not the problem MANET is out to solve. 3. However, of course, a MANET could be made to connect to a 4G, or 3G, or Internet, wired networks. Bert > -----Original Message----- > From: Xiaoning He [mailto:xiaoning@docomolabs-usa.com] > Sent: Wednesday, July 10, 2002 4:16 PM > To: manet@ietf.org > Subject: [manet] Mobile Ad-hoc Network in the 4G system > > > Hi all > > I have a few questions regarding the role of the Mobile ad-hoc network > in the 4G wireless system. Whether or not the ad-hoc type of network > will play an important role in the 4G system? If it will, what's the > killer app for the mobile ad-hoc network in 4G? > > It seems to me that currently the mobile ad-hoc network is > important for > military, disaster relief etc. But for daily personal life, I am not > sure. > > I am not sure whether it is the right place to raise question. Anyway, > please feel free to comment. > > Regards > > Xiaoning He, Ph.D > Research Engineer > 181 Metro Drive, Suite 300 > San Jose, CA 95110 > > Email: xiaoning@docomolabs-usa.com > Phone: +1 (408) 451-4737 > Fax : +1 (408) 573-1090 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 20:07:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24039 for ; Wed, 10 Jul 2002 20:07:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17711; Wed, 10 Jul 2002 19:47:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17662 for ; Wed, 10 Jul 2002 19:47:38 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23539 for ; Wed, 10 Jul 2002 19:46:43 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-224.sfc.wide.ad.jp [203.178.143.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6ANkofg013881; Thu, 11 Jul 2002 08:46:51 +0900 Date: Thu, 11 Jul 2002 09:38:11 +0900 Message-ID: From: Ryuji Wakikawa To: Fredrik.Alriksson@era.ericsson.se Cc: ryuji@sfc.wide.ad.jp, charliep@iprg.nokia.com, jmalinen@ipgr.nokia.com, ajtuomin@tml.hut.fi, andersn@telecom.lth.se, manet@ietf.org In-Reply-To: <1F55F6582266314A85A55F6241509B674180B9@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B674180B9@Esealnt863.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Fredrik I am catching up now, but let me reply to this first. At Tue, 9 Jul 2002 09:46:15 +0200 , Fredrik Alriksson (EAB) wrote: > > Hi Ryuji, > > In what sense are the gateway advertisements unnecessary? I did not say all RAs which are periodically advertising are un-necessary. If gateway advertise RAs periodically, some of RAs are not processed by any nodes. And these RAs are flooded over manet network untill TTL is expired. > In case there are multiple gateways, the flooding of gateway > advertisements may actually _decrease_ the total number of packet > transmissions (control and user data transmissions) in the MANET! > > Flooding gateway advertisements can enable manet nodes which already > have a global address to select a _closer_ gateway. This means that > the average distance between gateway and manet node can be > decreased. This in turn decreases the number of packet transmissions > required to deliver user data between the gateways and the manet > nodes. Depending on the user activity, this reduction can be larger > than the increase in control packet transmissions. > > Other benefits are that the average user data delay decreases, and > that the manet nodes loose contact with their gateway less > frequently. The draft said that once manet node gets global info from a GW, it can update the info by unicasting request message to the GW. Manet node may change the GW to closer one any time by re-selecting an appropriate GW from the node's GW lists or by re-flooding requests to discover closer depending on some events like topology change. GW lists is node introduced in the draft, but let's say it is the lists of GWs which are replyig to node's gateway discovery. In appendix A, we explain how to use the most appropriate GW with a routing header. I think the draft can be adapted to your above situation. What do you think? --Snip from the drat Using a routing header is also preferable if there are more than two Internet-gateways, because the node then have the ability to decide which Internet-gateway is the best, by distance in hops, or by some other priority. By assign a priority number for each Internet-gateway, the route reply message and the Manet Router Advertisement messages could be extended to support a candidate Internet-gateway option in it. ----- I think we should clarify much more about situations when multiple GWs are located. # Can you explain more about simulated unicast situation. Can a manet node receive RA from only associated GW? Didn't you use solicited request from the manet node? If not, GW will discover the manet node route, when it sends RA to the node and can not find fresh route for the node. This does not happen to our solution. > Regarding TTL, I don't see the problem, unless advertisements were > forwarded on non-manet interfaces. Can you please elaborate a bit? In your thesis, you mentioned "Limited TTL". This is almost what I want to explain here. If there is a single GW in manet, RA should be flooded over whole manet. You can not use optimization like expanding ring search for flooding. If Manet nodes can not get RAs sent with limited TTL by GW, it has to discover GW by solicited requests. best regards, ryuji > BR, > Fredrik > > > -----Original Message----- > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > Sent: den 8 juli 2002 18:40 > > To: Fredrik.Alriksson@era.ericsson.se > > Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp; > > jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se; > > manet@ietf.org > > Subject: Re: Gateway Advertisements > > > > > > > > Hello Fredrik. > > > > In the draft, unnecessary packets basically indicates un-necessary > > gateway advertisements. For example, if a gateway generates a route > > advertisement every 1 sec, most of router advertisements are redundant > > for manet nodes which have already had a global address. They may > > update lifetime of their global address, but the interval(1sec) is > > still too short for this operations. > > > > Since flooding packets is easy to cause performance damage in manet, > > our approach tries to reduce a number of packets which are > > flooded over > > manet. I think manet nodes should not wait flooded advertisements from > > gateway, instead manet node should discover gateways on their > > initiative. > > > > It is also difficult for gateways to decide TTL for flooded > > advertisements. Expanding ring search technique can not be applied to > > this situation, because advertisements should reach at the edge of > > manet. It can imagine that unnecessary network-wide dissemination of > > advertisements will occur when a gateway sets larger TTL than manet > > scale. > > > > regards, > > ryuji > > > > > > At Mon, 8 Jul 2002 17:27:19 +0200 , > > Fredrik Alriksson (EAB) wrote: > > > > > > Hi All, > > > > > > In draft-wakikawa-manet-globalv6-00.txt you claim that > > sending gateway advertisements peridically would generate > > unnecessary packets in the Manet. Can you please explain how > > you came to that conclusion? Our simulation study on MIPMANET > > from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) > > indicates that it actually can decrease the number of packet > > transmissions in the MANET. > > > > > > BR, > > > Fredrik > > > > > > --- > > > Fredrik Alriksson, Ericsson Research > > > Email: fredrik.alriksson@ericsson.com > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 20:07:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24047 for ; Wed, 10 Jul 2002 20:07:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA18979 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 20:08:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17711; Wed, 10 Jul 2002 19:47:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17662 for ; Wed, 10 Jul 2002 19:47:38 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23539 for ; Wed, 10 Jul 2002 19:46:43 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-224.sfc.wide.ad.jp [203.178.143.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6ANkofg013881; Thu, 11 Jul 2002 08:46:51 +0900 Date: Thu, 11 Jul 2002 09:38:11 +0900 Message-ID: From: Ryuji Wakikawa To: Fredrik.Alriksson@era.ericsson.se Cc: ryuji@sfc.wide.ad.jp, charliep@iprg.nokia.com, jmalinen@ipgr.nokia.com, ajtuomin@tml.hut.fi, andersn@telecom.lth.se, manet@ietf.org In-Reply-To: <1F55F6582266314A85A55F6241509B674180B9@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B674180B9@Esealnt863.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Fredrik I am catching up now, but let me reply to this first. At Tue, 9 Jul 2002 09:46:15 +0200 , Fredrik Alriksson (EAB) wrote: > > Hi Ryuji, > > In what sense are the gateway advertisements unnecessary? I did not say all RAs which are periodically advertising are un-necessary. If gateway advertise RAs periodically, some of RAs are not processed by any nodes. And these RAs are flooded over manet network untill TTL is expired. > In case there are multiple gateways, the flooding of gateway > advertisements may actually _decrease_ the total number of packet > transmissions (control and user data transmissions) in the MANET! > > Flooding gateway advertisements can enable manet nodes which already > have a global address to select a _closer_ gateway. This means that > the average distance between gateway and manet node can be > decreased. This in turn decreases the number of packet transmissions > required to deliver user data between the gateways and the manet > nodes. Depending on the user activity, this reduction can be larger > than the increase in control packet transmissions. > > Other benefits are that the average user data delay decreases, and > that the manet nodes loose contact with their gateway less > frequently. The draft said that once manet node gets global info from a GW, it can update the info by unicasting request message to the GW. Manet node may change the GW to closer one any time by re-selecting an appropriate GW from the node's GW lists or by re-flooding requests to discover closer depending on some events like topology change. GW lists is node introduced in the draft, but let's say it is the lists of GWs which are replyig to node's gateway discovery. In appendix A, we explain how to use the most appropriate GW with a routing header. I think the draft can be adapted to your above situation. What do you think? --Snip from the drat Using a routing header is also preferable if there are more than two Internet-gateways, because the node then have the ability to decide which Internet-gateway is the best, by distance in hops, or by some other priority. By assign a priority number for each Internet-gateway, the route reply message and the Manet Router Advertisement messages could be extended to support a candidate Internet-gateway option in it. ----- I think we should clarify much more about situations when multiple GWs are located. # Can you explain more about simulated unicast situation. Can a manet node receive RA from only associated GW? Didn't you use solicited request from the manet node? If not, GW will discover the manet node route, when it sends RA to the node and can not find fresh route for the node. This does not happen to our solution. > Regarding TTL, I don't see the problem, unless advertisements were > forwarded on non-manet interfaces. Can you please elaborate a bit? In your thesis, you mentioned "Limited TTL". This is almost what I want to explain here. If there is a single GW in manet, RA should be flooded over whole manet. You can not use optimization like expanding ring search for flooding. If Manet nodes can not get RAs sent with limited TTL by GW, it has to discover GW by solicited requests. best regards, ryuji > BR, > Fredrik > > > -----Original Message----- > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > > Sent: den 8 juli 2002 18:40 > > To: Fredrik.Alriksson@era.ericsson.se > > Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp; > > jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se; > > manet@ietf.org > > Subject: Re: Gateway Advertisements > > > > > > > > Hello Fredrik. > > > > In the draft, unnecessary packets basically indicates un-necessary > > gateway advertisements. For example, if a gateway generates a route > > advertisement every 1 sec, most of router advertisements are redundant > > for manet nodes which have already had a global address. They may > > update lifetime of their global address, but the interval(1sec) is > > still too short for this operations. > > > > Since flooding packets is easy to cause performance damage in manet, > > our approach tries to reduce a number of packets which are > > flooded over > > manet. I think manet nodes should not wait flooded advertisements from > > gateway, instead manet node should discover gateways on their > > initiative. > > > > It is also difficult for gateways to decide TTL for flooded > > advertisements. Expanding ring search technique can not be applied to > > this situation, because advertisements should reach at the edge of > > manet. It can imagine that unnecessary network-wide dissemination of > > advertisements will occur when a gateway sets larger TTL than manet > > scale. > > > > regards, > > ryuji > > > > > > At Mon, 8 Jul 2002 17:27:19 +0200 , > > Fredrik Alriksson (EAB) wrote: > > > > > > Hi All, > > > > > > In draft-wakikawa-manet-globalv6-00.txt you claim that > > sending gateway advertisements peridically would generate > > unnecessary packets in the Manet. Can you please explain how > > you came to that conclusion? Our simulation study on MIPMANET > > from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) > > indicates that it actually can decrease the number of packet > > transmissions in the MANET. > > > > > > BR, > > > Fredrik > > > > > > --- > > > Fredrik Alriksson, Ericsson Research > > > Email: fredrik.alriksson@ericsson.com > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Jul 10 20:36:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24678 for ; Wed, 10 Jul 2002 20:36:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19255; Wed, 10 Jul 2002 20:16:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19156 for ; Wed, 10 Jul 2002 20:16:16 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24246 for ; Wed, 10 Jul 2002 20:15:21 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-224.sfc.wide.ad.jp [203.178.143.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6B0Fefg013956; Thu, 11 Jul 2002 09:15:40 +0900 Date: Thu, 11 Jul 2002 10:11:20 +0900 Message-ID: From: Ryuji Wakikawa To: Fredrik.Alriksson@era.ericsson.se Cc: andersn@telecom.lth.se, manet@ietf.org, ryuji@sfc.wide.ad.jp In-Reply-To: <1F55F6582266314A85A55F6241509B674180BA@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B674180BA@Esealnt863.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello again Fredrik and Thanks Anders. At Tue, 9 Jul 2002 13:08:24 +0200 , Fredrik Alriksson (EAB) wrote: > > For the solution described in the draft, unsolicited gateway > advertisements are not neccessary for the correct operation of the > protocol. > > [Fredrik Alriksson] I never questioned that. You state that "Sending > them (advertisements) periodically would generate unnecessary > packets in the Manet", but as I've said in previous emails _not_ > sending them periodically may generate _more_ traffic in the Manet. Can you elaborate what is the most reason for generating more traffic when GW does not flood advertisements. > I see your point and I think that it is question of whether a reactive or a more proactive approach > should be used. > > [Fredrik Alriksson] Perhaps a combination is preferable? Does it depend on network topology? (a number of manet nodes, a number of GWs, size of manet) > > One of the reasons for not recomending gateway advertisement > flooding is when you consider the scenario where some nodes might > need internet access, and some might not. > > [Fredrik Alriksson] Well, the nodes which do not need internet > access may still benefit from the periodic floodings, since they > probably are involved in the communication between the gateways and > the manet nodes what do need internet access. Decreasing the total > number of packet transmissions does not only benefit the nodes that > need internet access! We assume that base manet protocol supports next hop forwarding like AODV. And if some base manet protocols do not support it (like DSR), we recommend to the use of routing header. When a node sends packets to the Internet, a node put a GW address into a routing header. During packet routing inside manet, the destination is the GW addressed in the routing header, therefore intermediate nodes routes packets to GW according to base manet operation. The route is maintained by base manet protocol because GW can be seen as a normal manet node from the nodes which do not need Internet access. The route towards the GW is basically constructed when the node requests advertisements. What I want to say here is that intermediate nodes just forward/route packets to the GW and this is the operations of general manet protocol. Intermediate nodes may create routes while some node set up global connectivity, but they are basically nothing to do with the operation of internet connectivity. > When flooding of advertisements is being used, packets are being > flooded periodicly over all nodes in the ad hoc network, regardsless > of their need for internet connectivity. This is where hop_limit > (TTL) considerations becomes important since every advertisement is > rebroadcasted as long as allowed by the hop_limit. So, what value > for this hop_limit should be used? If we choose a too small value we > might not reach all nodes, and choosing a high value will introduce > lots of traffic. > > [Fredrik Alriksson] Can't a node that does not get the periodic > advertisments send solicitations? > > > Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary. > > [Fredrik Alriksson] Even though the advertisements are not > _necessary_ for the non-internet connected nodes, they may still > benefit from the periodic advertisments indirectly, since the total > number of packets that they have to forward (including both the > advertisements _and_ the user data) may decrease! Sorry, I can not see your point in last sentence. Why may the total number of packets decrease? > In the draft we instead propose that the node itself should initiate > this process, the gateway discovery process. In the case where there > are multiple gateways, the node should upon receiving these > advertisements choose the closest gateway. > > [Fredrik Alriksson] Aren't we talking about _mobile_ ad hoc > networks? For how long will the chosen gateway remain the closest > gateway? Yes, talking about manet :-) Best Regards, ryuji > regards, > > Anders > > > [Fredrik Alriksson] BR, Fredrik > > > > Fredrik Alriksson (EAB) wrote: > > Hi Ryuji, > > In what sense are the gateway advertisements unnecessary? > > In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! > > Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. > > Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently. > > Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet > interfaces. Can you please elaborate a bit? > > BR, > Fredrik > > > > -----Original Message----- > From: Ryuji Wakikawa [ mailto:ryuji@sfc.wide.ad.jp ] > Sent: den 8 juli 2002 18:40 > To: Fredrik.Alriksson@era.ericsson.se > Cc: charliep@iprg.nokia.com ; ryuji@sfc.wide.ad.jp ; > jmalinen@ipgr.nokia.com ; ajtuomin@tml.hut.fi ; andersn@telecom.lth.se ; > manet@ietf.org > Subject: Re: Gateway Advertisements > > > > Hello Fred > rik. > > In the draft, unnecessary packets basically indicates un-necessary > gateway advertisements. For example, if a gateway generates a route > advertisement every 1 sec, most of router advertisements are redundant > for manet nodes which have already had a global address. They may > update lifetime of their global address, but the interval(1sec) is > still too short for this operations. > > Since flooding packets is easy to cause performance damage in manet, > our approach tries to reduce a number of packets which are > flooded over > manet. I think manet nodes should not wait flooded advertisements from > gateway, instead manet node should discover gateways on their > initiative. > > It is also difficult for gateways to decide TTL for flooded > advertisements. Expanding ring search technique can not be applied to > this situation, because advertisements should reach at the edge of > manet. It can imagine that unnecessary network-wide dissemination of > advertisements will occur when a gateway sets larger TTL than manet > scale. > > regards, > ryuji > > > At Mon, 8 Jul 2002 17:27:19 +0200 , > Fredrik Alriksson (EAB) wrote: > > > Hi All, > > In draft-wakikawa-manet-globalv6-00.txt you claim that > > sending gateway advertisements peridically would generate > unnecessary packets in the Manet. Can you please explain how > you came to that conclusion? Our simulation study on MIPMANET > from '99 ( http://www.e.kth.se/~e94_fal/mipmanet.pdf ) > indicates that it actually can decrease the number of packet > transmissions in the MANET. > > BR, > Fredrik > > --- > Fredrik Alriksson, Ericsson Research > Email: fredrik.alriksson@ericsson.com > > > > > > > > > [2 ] > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Jul 10 20:36:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24685 for ; Wed, 10 Jul 2002 20:36:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA20628 for manet-archive@odin.ietf.org; Wed, 10 Jul 2002 20:36:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19255; Wed, 10 Jul 2002 20:16:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19156 for ; Wed, 10 Jul 2002 20:16:16 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24246 for ; Wed, 10 Jul 2002 20:15:21 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (dhcp-143-224.sfc.wide.ad.jp [203.178.143.224]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6B0Fefg013956; Thu, 11 Jul 2002 09:15:40 +0900 Date: Thu, 11 Jul 2002 10:11:20 +0900 Message-ID: From: Ryuji Wakikawa To: Fredrik.Alriksson@era.ericsson.se Cc: andersn@telecom.lth.se, manet@ietf.org, ryuji@sfc.wide.ad.jp In-Reply-To: <1F55F6582266314A85A55F6241509B674180BA@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B674180BA@Esealnt863.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: [manet] Re: Gateway Advertisements Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello again Fredrik and Thanks Anders. At Tue, 9 Jul 2002 13:08:24 +0200 , Fredrik Alriksson (EAB) wrote: > > For the solution described in the draft, unsolicited gateway > advertisements are not neccessary for the correct operation of the > protocol. > > [Fredrik Alriksson] I never questioned that. You state that "Sending > them (advertisements) periodically would generate unnecessary > packets in the Manet", but as I've said in previous emails _not_ > sending them periodically may generate _more_ traffic in the Manet. Can you elaborate what is the most reason for generating more traffic when GW does not flood advertisements. > I see your point and I think that it is question of whether a reactive or a more proactive approach > should be used. > > [Fredrik Alriksson] Perhaps a combination is preferable? Does it depend on network topology? (a number of manet nodes, a number of GWs, size of manet) > > One of the reasons for not recomending gateway advertisement > flooding is when you consider the scenario where some nodes might > need internet access, and some might not. > > [Fredrik Alriksson] Well, the nodes which do not need internet > access may still benefit from the periodic floodings, since they > probably are involved in the communication between the gateways and > the manet nodes what do need internet access. Decreasing the total > number of packet transmissions does not only benefit the nodes that > need internet access! We assume that base manet protocol supports next hop forwarding like AODV. And if some base manet protocols do not support it (like DSR), we recommend to the use of routing header. When a node sends packets to the Internet, a node put a GW address into a routing header. During packet routing inside manet, the destination is the GW addressed in the routing header, therefore intermediate nodes routes packets to GW according to base manet operation. The route is maintained by base manet protocol because GW can be seen as a normal manet node from the nodes which do not need Internet access. The route towards the GW is basically constructed when the node requests advertisements. What I want to say here is that intermediate nodes just forward/route packets to the GW and this is the operations of general manet protocol. Intermediate nodes may create routes while some node set up global connectivity, but they are basically nothing to do with the operation of internet connectivity. > When flooding of advertisements is being used, packets are being > flooded periodicly over all nodes in the ad hoc network, regardsless > of their need for internet connectivity. This is where hop_limit > (TTL) considerations becomes important since every advertisement is > rebroadcasted as long as allowed by the hop_limit. So, what value > for this hop_limit should be used? If we choose a too small value we > might not reach all nodes, and choosing a high value will introduce > lots of traffic. > > [Fredrik Alriksson] Can't a node that does not get the periodic > advertisments send solicitations? > > > Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary. > > [Fredrik Alriksson] Even though the advertisements are not > _necessary_ for the non-internet connected nodes, they may still > benefit from the periodic advertisments indirectly, since the total > number of packets that they have to forward (including both the > advertisements _and_ the user data) may decrease! Sorry, I can not see your point in last sentence. Why may the total number of packets decrease? > In the draft we instead propose that the node itself should initiate > this process, the gateway discovery process. In the case where there > are multiple gateways, the node should upon receiving these > advertisements choose the closest gateway. > > [Fredrik Alriksson] Aren't we talking about _mobile_ ad hoc > networks? For how long will the chosen gateway remain the closest > gateway? Yes, talking about manet :-) Best Regards, ryuji > regards, > > Anders > > > [Fredrik Alriksson] BR, Fredrik > > > > Fredrik Alriksson (EAB) wrote: > > Hi Ryuji, > > In what sense are the gateway advertisements unnecessary? > > In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! > > Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. > > Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently. > > Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet > interfaces. Can you please elaborate a bit? > > BR, > Fredrik > > > > -----Original Message----- > From: Ryuji Wakikawa [ mailto:ryuji@sfc.wide.ad.jp ] > Sent: den 8 juli 2002 18:40 > To: Fredrik.Alriksson@era.ericsson.se > Cc: charliep@iprg.nokia.com ; ryuji@sfc.wide.ad.jp ; > jmalinen@ipgr.nokia.com ; ajtuomin@tml.hut.fi ; andersn@telecom.lth.se ; > manet@ietf.org > Subject: Re: Gateway Advertisements > > > > Hello Fred > rik. > > In the draft, unnecessary packets basically indicates un-necessary > gateway advertisements. For example, if a gateway generates a route > advertisement every 1 sec, most of router advertisements are redundant > for manet nodes which have already had a global address. They may > update lifetime of their global address, but the interval(1sec) is > still too short for this operations. > > Since flooding packets is easy to cause performance damage in manet, > our approach tries to reduce a number of packets which are > flooded over > manet. I think manet nodes should not wait flooded advertisements from > gateway, instead manet node should discover gateways on their > initiative. > > It is also difficult for gateways to decide TTL for flooded > advertisements. Expanding ring search technique can not be applied to > this situation, because advertisements should reach at the edge of > manet. It can imagine that unnecessary network-wide dissemination of > advertisements will occur when a gateway sets larger TTL than manet > scale. > > regards, > ryuji > > > At Mon, 8 Jul 2002 17:27:19 +0200 , > Fredrik Alriksson (EAB) wrote: > > > Hi All, > > In draft-wakikawa-manet-globalv6-00.txt you claim that > > sending gateway advertisements peridically would generate > unnecessary packets in the Manet. Can you please explain how > you came to that conclusion? Our simulation study on MIPMANET > from '99 ( http://www.e.kth.se/~e94_fal/mipmanet.pdf ) > indicates that it actually can decrease the number of packet > transmissions in the MANET. > > BR, > Fredrik > > --- > Fredrik Alriksson, Ericsson Research > Email: fredrik.alriksson@ericsson.com > > > > > > > > > [2 ] > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jul 11 04:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12837 for ; Thu, 11 Jul 2002 04:25:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20385; Thu, 11 Jul 2002 04:10:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20348 for ; Thu, 11 Jul 2002 04:10:13 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12465 for ; Thu, 11 Jul 2002 04:09:16 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id KAA06826 for ; Thu, 11 Jul 2002 10:08:00 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] Mobile Ad-hoc Network in the 4G system Date: Thu, 11 Jul 2002 10:14:38 +0200 X-Mailer: KMail [version 1.2] References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A09@xch-ne-02.ne.nos.boeing.com> In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A09@xch-ne-02.ne.nos.boeing.com> MIME-Version: 1.0 Message-Id: <02071110135800.00402@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Xiaoning, I think I wouldn't think too much to 3G or 4G... I imagine MANET technologies within the context of pervasive and ubiquitous computing. I think that MANETs will allow the advent of new kind of technologies and applications. I suggest you to give a look to http://www.computer.org/pervasive/ regards Dario Il 22:53, mercoledì 10 luglio 2002, hai scritto: > Hi Xiaoning, > > My reactions would be: > > 1. What is 4G? Specifically, other than bandwidth (the modulation scheme in > the wireless links), how does it differ from 3G? > > 2. If 4G is basically an extension of the wired network, depends on > geographically fixed base stations for packet routing and access to mobile > hosts, the wireless link is a point-to-point link to individual mobile > hosts, then clearly it is not the problem MANET is out to solve. > > 3. However, of course, a MANET could be made to connect to a 4G, or 3G, or > Internet, wired networks. > > Bert > > > -----Original Message----- > > From: Xiaoning He [mailto:xiaoning@docomolabs-usa.com] > > Sent: Wednesday, July 10, 2002 4:16 PM > > To: manet@ietf.org > > Subject: [manet] Mobile Ad-hoc Network in the 4G system > > > > > > Hi all > > > > I have a few questions regarding the role of the Mobile ad-hoc network > > in the 4G wireless system. Whether or not the ad-hoc type of network > > will play an important role in the 4G system? If it will, what's the > > killer app for the mobile ad-hoc network in 4G? > > > > It seems to me that currently the mobile ad-hoc network is > > important for > > military, disaster relief etc. But for daily personal life, I am not > > sure. > > > > I am not sure whether it is the right place to raise question. Anyway, > > please feel free to comment. > > > > Regards > > > > Xiaoning He, Ph.D > > Research Engineer > > 181 Metro Drive, Suite 300 > > San Jose, CA 95110 > > > > Email: xiaoning@docomolabs-usa.com > > Phone: +1 (408) 451-4737 > > Fax : +1 (408) 573-1090 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Jul 11 04:25:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12843 for ; Thu, 11 Jul 2002 04:25:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21495 for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 04:26:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20385; Thu, 11 Jul 2002 04:10:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20348 for ; Thu, 11 Jul 2002 04:10:13 -0400 (EDT) Received: from promet2.deis.unibo.it (promet2.deis.unibo.it [137.204.59.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12465 for ; Thu, 11 Jul 2002 04:09:16 -0400 (EDT) Received: from manson (edu204.deis.unibo.it [137.204.45.204]) by promet2.deis.unibo.it (8.9.3+Sun/8.9.1) with SMTP id KAA06826 for ; Thu, 11 Jul 2002 10:08:00 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Dario Bottazzi To: manet@ietf.org Subject: Re: [manet] Mobile Ad-hoc Network in the 4G system Date: Thu, 11 Jul 2002 10:14:38 +0200 X-Mailer: KMail [version 1.2] References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A09@xch-ne-02.ne.nos.boeing.com> In-Reply-To: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A09@xch-ne-02.ne.nos.boeing.com> MIME-Version: 1.0 Message-Id: <02071110135800.00402@manson> Content-Transfer-Encoding: 8bit Organization: deis Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Xiaoning, I think I wouldn't think too much to 3G or 4G... I imagine MANET technologies within the context of pervasive and ubiquitous computing. I think that MANETs will allow the advent of new kind of technologies and applications. I suggest you to give a look to http://www.computer.org/pervasive/ regards Dario Il 22:53, mercoledì 10 luglio 2002, hai scritto: > Hi Xiaoning, > > My reactions would be: > > 1. What is 4G? Specifically, other than bandwidth (the modulation scheme in > the wireless links), how does it differ from 3G? > > 2. If 4G is basically an extension of the wired network, depends on > geographically fixed base stations for packet routing and access to mobile > hosts, the wireless link is a point-to-point link to individual mobile > hosts, then clearly it is not the problem MANET is out to solve. > > 3. However, of course, a MANET could be made to connect to a 4G, or 3G, or > Internet, wired networks. > > Bert > > > -----Original Message----- > > From: Xiaoning He [mailto:xiaoning@docomolabs-usa.com] > > Sent: Wednesday, July 10, 2002 4:16 PM > > To: manet@ietf.org > > Subject: [manet] Mobile Ad-hoc Network in the 4G system > > > > > > Hi all > > > > I have a few questions regarding the role of the Mobile ad-hoc network > > in the 4G wireless system. Whether or not the ad-hoc type of network > > will play an important role in the 4G system? If it will, what's the > > killer app for the mobile ad-hoc network in 4G? > > > > It seems to me that currently the mobile ad-hoc network is > > important for > > military, disaster relief etc. But for daily personal life, I am not > > sure. > > > > I am not sure whether it is the right place to raise question. Anyway, > > please feel free to comment. > > > > Regards > > > > Xiaoning He, Ph.D > > Research Engineer > > 181 Metro Drive, Suite 300 > > San Jose, CA 95110 > > > > Email: xiaoning@docomolabs-usa.com > > Phone: +1 (408) 451-4737 > > Fax : +1 (408) 573-1090 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Jul 11 10:47:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19612 for ; Thu, 11 Jul 2002 10:47:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10614; Thu, 11 Jul 2002 10:29:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10591 for ; Thu, 11 Jul 2002 10:28:59 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19015 for ; Thu, 11 Jul 2002 10:28:05 -0400 (EDT) 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 QAA05061; Thu, 11 Jul 2002 16:28:36 +0200 (MET DST) Message-ID: <3D2D9667.8090701@telecom.lth.se> Date: Thu, 11 Jul 2002 16:29:59 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Fredrik Alriksson (EAB)" CC: MANET mailing list , Ryuji Wakikawa Subject: Re: [manet] Re: Gateway Advertisements References: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------070403030005040402090808" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------070403030005040402090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Fredrik! > >But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all! > You are absolutely right. This is always what you should try to optimize when you have an proactive approach , like yours. Our approach is more reactive. So for the real question; is a proactive, a reactive or a hybrid solution the best one? I think the answer depends on several factors, such as network size, mobility rate, traffic load, but also on battery life, routing protocol, security etc. I think I can agree on that your proposal is better in some situations and scenarios, but that our solution is better in some. I think that these are questions that needs to be more thoroughly simulated. > >For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? >How does the Manet node know when to re-flood the request? >How large fraction of all relevant topology changes will the Manet node detect? > >My conclusion is still: it is better to let the GW flood periodically. > Are you absolutely sure that this will be the optimal solution in all situations? > > >>In appendix A, we explain how to use the most appropriate GW with a >>routing header. I think the draft can be adapted to your above >>situation. What do you think? >> >>--Snip from the drat >> Using a routing header is also preferable if there are >>more than two >>Internet-gateways, because the node then have the ability to decide >>which Internet-gateway is the best, by distance in hops, or by some >>other priority. By assign a priority number for each >>Internet-gateway, >>the route reply message and the Manet Router Advertisement messages >>could be extended to support a candidate Internet-gateway >>option in it. >>----- >> > >I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not? > He describes how the gateway selection process can be implemented. > >Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct. > >Furthermore, if using flooding, how often should Manet nodes flood the solicitations? > ... needs more testing... >>>Regarding TTL, I don't see the problem, unless advertisements were >>>forwarded on non-manet interfaces. Can you please elaborate a bit? >>> >>In your thesis, you mentioned "Limited TTL". This is almost what I >>want to explain here. If there is a single GW in manet, RA should be >>flooded over whole manet. You can not use optimization like expanding >>ring search for flooding. If Manet nodes can not get RAs sent with >>limited TTL by GW, it has to discover GW by solicited requests. >> > >Sure, but is that really a problem? > No, and I think that it could be a good hybrid solution. [and in your previous mail:] Can you elaborate what is the most reason for generating more traffic > when GW does not flood advertisements. >The average hop count between the GW and the Manet node increases, >since the probability that a Manet node will use a sub-optimal > GW increases. >Then I think I didn't express myself clearly enough. My point is >that using a 4-hop route between Manet node and GW1 consumes more >resources in the Manet as a whole than using a 2-hop route between the >same Manet node and GW2. Thus being able to select the closest gateway >is a concern for all nodes in the Manet, including those that do not >use internet connectivity. But minimizing the hop count is, of course, also the purpose of our solution. The question is whether it really does differ in average hop, or whether it really is more costful. Flooding could be very costful for battery sensitive devices. As for choosing the closest gateway, this should always be the ambition. The node could either rerequest gateway information, or maybe we could piggyback this information somewhere, in case a "handover"is needed. best regards, Anders --------------070403030005040402090808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Fredrik!


But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!
You are absolutely right. This is always what you should try to optimize when you have an proactive approach , like yours. Our approach is more reactive. So for the real question; is a proactive, a reactive or a hybrid
solution the best one? I think the answer depends on several factors, such as network size, mobility
rate, traffic load, but also on battery life, routing protocol, security etc. I think I can agree on that your proposal is better in some situations and scenarios, but that our solution is better in some. I think that these are questions that needs to be more thoroughly simulated. 

For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
How does the Manet node know when to re-flood the request?
How large fraction of all relevant topology changes will the Manet node detect?

My conclusion is still: it is better to let the GW flood periodically.
Are you absolutely sure that this will be the optimal solution in all situations?


In appendix A, we explain how to use the most appropriate GW with a
routing header. I think the draft can be adapted to your above
situation. What do you think?

--Snip from the drat
   Using a routing header is also preferable if there are 
more than two
Internet-gateways, because the node then have the ability to decide
which Internet-gateway is the best, by distance in hops, or by some
other priority.  By assign a priority number for each 
Internet-gateway,
the route reply message and the Manet Router Advertisement messages
could be extended to support a candidate Internet-gateway 
option in it.
-----

I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?
He describes how the gateway selection process can be implemented. 

Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.

Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
... needs more testing... 

            

            

              

                

                  
Regarding TTL, I don't see the problem, unless advertisements were
forwarded on non-manet interfaces. Can you please elaborate a bit?

                  

                  
In your thesis, you mentioned "Limited TTL". This is almost what I
want to explain here. If there is a single GW in manet, RA should be
flooded over whole manet. You can not use optimization like expanding
ring search for flooding. If Manet nodes can not get RAs sent with
limited TTL by GW, it has to discover GW by solicited requests.

                  

                  

Sure, but is that really a problem?

                  

                  
No, and I think that it could be a good hybrid solution.

                  
[and in your previous mail:] Can you elaborate what is the most reason for generating more traffic
> when GW does not flood advertisements.

>The average hop count between the GW and the Manet node increases, 
>since the probability that a Manet node will use a sub-optimal 
> GW increases.


>Then I think I didn't express myself clearly enough. My point is 
>that using a 4-hop route between Manet node and GW1 consumes more 
>resources in the Manet as a whole than using a 2-hop route between the 
>same Manet node and GW2. Thus being able to select the closest gateway 
>is a concern for all nodes in the Manet, including those that do not 
>use internet connectivity.

But minimizing the hop count is, of course, also the purpose of our
solution. The question is whether it really

does differ in average hop, or whether it really is more costful. Flooding
could be very costful for battery sensitive devices. As for choosing the
closest gateway, this should always be the ambition. The node could either
rerequest gateway information, or maybe we could piggyback this information
somewhere, in case a "handover"is needed.

                  

best regards,

                  

Anders 

                  

                  

                  

                  

                  
                  

--------------070403030005040402090808--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Thu Jul 11 11:20:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20769
	for ; Thu, 11 Jul 2002 11:20:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13258;
	Thu, 11 Jul 2002 10:57:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13226
	for ; Thu, 11 Jul 2002 10:57:42 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19923
	for ; Thu, 11 Jul 2002 10:56:48 -0400 (EDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g6BEvc3Z008391;
	Thu, 11 Jul 2002 07:57:39 -0700 (PDT)
Received: from njain.qualcomm.com (vpn-5k-client-10141278.qualcomm.com [10.14.12.78])
	by magus.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g6BEvZZd014588;
	Thu, 11 Jul 2002 07:57:36 -0700 (PDT)
Message-Id: <5.1.0.14.2.20020711075609.026a9d70@illyana.qualcomm.com>
X-Sender: njain@illyana.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 11 Jul 2002 07:57:35 -0700
To: "Mullen, John P. (Contractor)" ,
        "Manfredi, Albert E" , manet@ietf.org
From: Nikhil Jain 
Subject: RE: [manet] Interference in ad hoc network
In-Reply-To: <02Jul10.075405mdt.117124@gw.trac.wsmr.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

I would recommend that we think about using CDMA. In CDMA we use a reuse of 
1. Which means that the same channel is used in all the cells. Ofcourse the 
moving users present new issues that have to be solved.

At 07:53 AM 7/10/2002 -0600, Mullen, John P. (Contractor) wrote:
>Hi Bert,
>
>Good points.  However, just a couple of wrinkles.
>
>There is certainly no reason you cannot have multiple MANETs in the same
>geographical region, but some mechanism is needed to assure channels are
>allocated in a way that will avoid interference.  Cellular systems use a
>supercel of seven channels which is repeated as needed to cover the area.
>The result is much like a honeycomb.  The reused channels are separated by
>two cell diameters so interference is unlikely.  Cellular antennas do not
>move, so, once established, this pattern reliably prevents interference.
>However, the hosts in MANETs do move, so there is the additional problem of
>making sure clusters using the same channel stay far enough apart from each
>other.  The alternative is to give each of the MANETs its own channel, but
>we need to remember there is only so much BW available.
>
>If the different MANETs have occasional need to communicate with each other,
>some hosts will have to be gateways.  These will either need two
>transceivers each or have to drop out of one MANET to communicate with the
>other.  The first solution would be the best to avoid the need to rejoin
>after every gateway operation.  Then, there is the problem of which hosts
>are to be gateways.  If you cannot be sure that the right host will be in
>the right place, you may need to have two transceivers in every host.  There
>is also the problem that if each MANET has its own channel, the gateways
>will have to determine which other MANETs are in the area and which one(s)
>to join.  (Of course, if a gateway joins k other MANETS, it will need k
>additional transceivers).  A way around this is to have a single channel
>solely for communication between MANETs.  Then, each gateway only needs to
>monitor two channels.  Of course, there can be contention on the inter-MANET
>channel and, using the additional channel reduces BW available for the
>individual MANETs.
>
>Looking more deeply into the matter of available bandwidth, if the band is
>sliced up among different users, then each user will have less bandwidth
>available.  The most efficient use of a shared resource is usually a pooled
>approach so that whoever needs higher capacity can get it, without
>limitations caused by subdividing the band.  Of course, there could be
>security reasons or technical limitations for subdividing.  For example, one
>MANET could be for police, one for fire fighters, one for EMT, etc.
>However, a fixed allocation will limit the BW available for each.  A shared
>channel allows each to use what they need (up to channel limits).
>
>Perhaps, a solution could be a dynamic allocation, in which each MANET has a
>minimal assignment, but there is a pool of BW which any MANET can use,
>providing there is a need.
>
>Sincerely,
>
>John Mullen
>
>-----Original Message-----
>From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
>Sent: Tuesday, July 09, 2002 4:02 PM
>To: 'jw2000@excite.com'; manet@ietf.org
>Subject: RE: [manet] Interference in ad hoc network
>
>
>Within a single MANET, the nodes need to contend for channel access, and
>perhaps even reduce their transmitter power level (this was discussed
>recently) so as not to interfere with each other. The basic scheme used in
>IEEE 802.11 is similar to Ethernet CSMA. Since MANET depends on each node
>acting as a relay station potentially, all nodes must be capable of hearing
>one another, if within range. This is essential. You do not rely on base
>stations for coverage, with MANET.
>
>But there's no reason why multiple MANETs can't be created in a given
>geographical area, is there? If you use IEEE 802.11b for the RF solution,
>for example, you could assign a different DSSS code to different MANETs, so
>the nodes of different MANETs will not interfere with one another. This is
>analogous to your Bluetooth example, where different frequency hop sequences
>are used.
>
>Or you could use a simple frequency divided radio scheme for this too. Just
>assign a different RF frequency band to each MANET in the area, and let
>these nodes broadcast to all nodes within reach, within their own MANET.
>
>If the packets are explicitly routed, this should work fine.
>
>If there are clusters of nodes in a given MANET that are very far apart, you
>could have cases where intra-cluster traffic of these far-apart clusters
>occurs simultaneously, without causing interference. That would happen
>naturally, as the clusters move away from one another, and don't need to
>worry about hearing other traffic from the remote cluster any longer.
>
>Bert
>
>-----Original Message-----
>From: Jack Wang [mailto:jw2000@excite.com]
>Sent: Tuesday, July 09, 2002 5:28 PM
>To: manet@ietf.org
>Subject: [manet] Interference in ad hoc network
>Importance: High
>
>
>How to prevent interference in ad hoc network? If there are several node
>within a node's transmission range, they may interfere with each other. In
>traditional cellular network, this is done by channel allocation. And in
>bluetooth, frequency hopping is used and master node of a piconet decides
>the frequency.
>How about ad hoc network? Are there any published papers about it? Thanks.
>Regards,
>Jack
>
>
>
>
>
>
>
>Join Excite! - http://www.excite.com
>The most personalized portal on the Web!
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet



--
Nikhil Jain
Office Location L-503E
Phone (858) 658-4501
Fax (858) 658-1033
email: nikhil@qualcomm.com
email: njain@qualcomm.com


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 11:20:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20777
	for ; Thu, 11 Jul 2002 11:20:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA15167
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 11:21:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13258;
	Thu, 11 Jul 2002 10:57:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13226
	for ; Thu, 11 Jul 2002 10:57:42 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19923
	for ; Thu, 11 Jul 2002 10:56:48 -0400 (EDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g6BEvc3Z008391;
	Thu, 11 Jul 2002 07:57:39 -0700 (PDT)
Received: from njain.qualcomm.com (vpn-5k-client-10141278.qualcomm.com [10.14.12.78])
	by magus.qualcomm.com (8.12.3/8.12.3/1.0) with ESMTP id g6BEvZZd014588;
	Thu, 11 Jul 2002 07:57:36 -0700 (PDT)
Message-Id: <5.1.0.14.2.20020711075609.026a9d70@illyana.qualcomm.com>
X-Sender: njain@illyana.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 11 Jul 2002 07:57:35 -0700
To: "Mullen, John P. (Contractor)" ,
        "Manfredi, Albert E" , manet@ietf.org
From: Nikhil Jain 
Subject: RE: [manet] Interference in ad hoc network
In-Reply-To: <02Jul10.075405mdt.117124@gw.trac.wsmr.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

I would recommend that we think about using CDMA. In CDMA we use a reuse of 
1. Which means that the same channel is used in all the cells. Ofcourse the 
moving users present new issues that have to be solved.

At 07:53 AM 7/10/2002 -0600, Mullen, John P. (Contractor) wrote:
>Hi Bert,
>
>Good points.  However, just a couple of wrinkles.
>
>There is certainly no reason you cannot have multiple MANETs in the same
>geographical region, but some mechanism is needed to assure channels are
>allocated in a way that will avoid interference.  Cellular systems use a
>supercel of seven channels which is repeated as needed to cover the area.
>The result is much like a honeycomb.  The reused channels are separated by
>two cell diameters so interference is unlikely.  Cellular antennas do not
>move, so, once established, this pattern reliably prevents interference.
>However, the hosts in MANETs do move, so there is the additional problem of
>making sure clusters using the same channel stay far enough apart from each
>other.  The alternative is to give each of the MANETs its own channel, but
>we need to remember there is only so much BW available.
>
>If the different MANETs have occasional need to communicate with each other,
>some hosts will have to be gateways.  These will either need two
>transceivers each or have to drop out of one MANET to communicate with the
>other.  The first solution would be the best to avoid the need to rejoin
>after every gateway operation.  Then, there is the problem of which hosts
>are to be gateways.  If you cannot be sure that the right host will be in
>the right place, you may need to have two transceivers in every host.  There
>is also the problem that if each MANET has its own channel, the gateways
>will have to determine which other MANETs are in the area and which one(s)
>to join.  (Of course, if a gateway joins k other MANETS, it will need k
>additional transceivers).  A way around this is to have a single channel
>solely for communication between MANETs.  Then, each gateway only needs to
>monitor two channels.  Of course, there can be contention on the inter-MANET
>channel and, using the additional channel reduces BW available for the
>individual MANETs.
>
>Looking more deeply into the matter of available bandwidth, if the band is
>sliced up among different users, then each user will have less bandwidth
>available.  The most efficient use of a shared resource is usually a pooled
>approach so that whoever needs higher capacity can get it, without
>limitations caused by subdividing the band.  Of course, there could be
>security reasons or technical limitations for subdividing.  For example, one
>MANET could be for police, one for fire fighters, one for EMT, etc.
>However, a fixed allocation will limit the BW available for each.  A shared
>channel allows each to use what they need (up to channel limits).
>
>Perhaps, a solution could be a dynamic allocation, in which each MANET has a
>minimal assignment, but there is a pool of BW which any MANET can use,
>providing there is a need.
>
>Sincerely,
>
>John Mullen
>
>-----Original Message-----
>From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
>Sent: Tuesday, July 09, 2002 4:02 PM
>To: 'jw2000@excite.com'; manet@ietf.org
>Subject: RE: [manet] Interference in ad hoc network
>
>
>Within a single MANET, the nodes need to contend for channel access, and
>perhaps even reduce their transmitter power level (this was discussed
>recently) so as not to interfere with each other. The basic scheme used in
>IEEE 802.11 is similar to Ethernet CSMA. Since MANET depends on each node
>acting as a relay station potentially, all nodes must be capable of hearing
>one another, if within range. This is essential. You do not rely on base
>stations for coverage, with MANET.
>
>But there's no reason why multiple MANETs can't be created in a given
>geographical area, is there? If you use IEEE 802.11b for the RF solution,
>for example, you could assign a different DSSS code to different MANETs, so
>the nodes of different MANETs will not interfere with one another. This is
>analogous to your Bluetooth example, where different frequency hop sequences
>are used.
>
>Or you could use a simple frequency divided radio scheme for this too. Just
>assign a different RF frequency band to each MANET in the area, and let
>these nodes broadcast to all nodes within reach, within their own MANET.
>
>If the packets are explicitly routed, this should work fine.
>
>If there are clusters of nodes in a given MANET that are very far apart, you
>could have cases where intra-cluster traffic of these far-apart clusters
>occurs simultaneously, without causing interference. That would happen
>naturally, as the clusters move away from one another, and don't need to
>worry about hearing other traffic from the remote cluster any longer.
>
>Bert
>
>-----Original Message-----
>From: Jack Wang [mailto:jw2000@excite.com]
>Sent: Tuesday, July 09, 2002 5:28 PM
>To: manet@ietf.org
>Subject: [manet] Interference in ad hoc network
>Importance: High
>
>
>How to prevent interference in ad hoc network? If there are several node
>within a node's transmission range, they may interfere with each other. In
>traditional cellular network, this is done by channel allocation. And in
>bluetooth, frequency hopping is used and master node of a piconet decides
>the frequency.
>How about ad hoc network? Are there any published papers about it? Thanks.
>Regards,
>Jack
>
>
>
>
>
>
>
>Join Excite! - http://www.excite.com
>The most personalized portal on the Web!
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet



--
Nikhil Jain
Office Location L-503E
Phone (858) 658-4501
Fax (858) 658-1033
email: nikhil@qualcomm.com
email: njain@qualcomm.com


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Thu Jul 11 11:40:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19619
	for ; Thu, 11 Jul 2002 10:47:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA12514
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 10:48:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10614;
	Thu, 11 Jul 2002 10:29:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10591
	for ; Thu, 11 Jul 2002 10:28:59 -0400 (EDT)
Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19015
	for ; Thu, 11 Jul 2002 10:28:05 -0400 (EDT)
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 QAA05061;
	Thu, 11 Jul 2002 16:28:36 +0200 (MET DST)
Message-ID: <3D2D9667.8090701@telecom.lth.se>
Date: Thu, 11 Jul 2002 16:29:59 +0200
From: Anders Nilsson 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Fredrik Alriksson (EAB)" 
CC: MANET mailing list , Ryuji Wakikawa 
Subject: Re: [manet] Re: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------070403030005040402090808"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


--------------070403030005040402090808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Fredrik!

>
>But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!
>
You are absolutely right. This is always what you should try to optimize 
when you have an proactive approach , like yours. Our approach is more 
reactive. So for the real question; is a proactive, a reactive or a hybrid
solution the best one? I think the answer depends on several factors, 
such as network size, mobility
rate, traffic load, but also on battery life, routing protocol, security 
etc. I think I can agree on that your proposal is better in some 
situations and scenarios, but that our solution is better in some. I 
think that these are questions that needs to be more thoroughly simulated.

>
>For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
>How does the Manet node know when to re-flood the request?
>How large fraction of all relevant topology changes will the Manet node detect?
>
>My conclusion is still: it is better to let the GW flood periodically.
>
Are you absolutely sure that this will be the optimal solution in all 
situations?

>
>
>>In appendix A, we explain how to use the most appropriate GW with a
>>routing header. I think the draft can be adapted to your above
>>situation. What do you think?
>>
>>--Snip from the drat
>>   Using a routing header is also preferable if there are 
>>more than two
>>Internet-gateways, because the node then have the ability to decide
>>which Internet-gateway is the best, by distance in hops, or by some
>>other priority.  By assign a priority number for each 
>>Internet-gateway,
>>the route reply message and the Manet Router Advertisement messages
>>could be extended to support a candidate Internet-gateway 
>>option in it.
>>-----
>>
>
>I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?
>
He describes how the gateway selection process can be implemented.

>
>Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.
>
>Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
>
... needs more testing...

>>>Regarding TTL, I don't see the problem, unless advertisements were
>>>forwarded on non-manet interfaces. Can you please elaborate a bit?
>>>
>>In your thesis, you mentioned "Limited TTL". This is almost what I
>>want to explain here. If there is a single GW in manet, RA should be
>>flooded over whole manet. You can not use optimization like expanding
>>ring search for flooding. If Manet nodes can not get RAs sent with
>>limited TTL by GW, it has to discover GW by solicited requests.
>>
>
>Sure, but is that really a problem?
>
No, and I think that it could be a good hybrid solution.

[and in your previous mail:] Can you elaborate what is the most reason for generating more traffic
> when GW does not flood advertisements.

>The average hop count between the GW and the Manet node increases, 
>since the probability that a Manet node will use a sub-optimal 
> GW increases.


>Then I think I didn't express myself clearly enough. My point is 
>that using a 4-hop route between Manet node and GW1 consumes more 
>resources in the Manet as a whole than using a 2-hop route between the 
>same Manet node and GW2. Thus being able to select the closest gateway 
>is a concern for all nodes in the Manet, including those that do not 
>use internet connectivity.

But minimizing the hop count is, of course, also the purpose of our 
solution. The question is whether it really
does differ in average hop, or whether it really is more costful. 
Flooding could be very costful for battery sensitive devices. As for 
choosing the closest gateway, this should always be the ambition. The 
node could either rerequest gateway information, or maybe we could 
piggyback this information somewhere, in case a "handover"is needed.

best regards,

Anders





--------------070403030005040402090808
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Hello Fredrik!





  

But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!

  

You are absolutely right. This is always what you should try to optimize
when you have an proactive approach , like yours. Our approach is more reactive.
So for the real question; is a proactive, a reactive or a hybrid

solution the best one? I think the answer depends on several factors, such
as network size, mobility

rate, traffic load, but also on battery life, routing protocol, security
etc. I think I can agree on that your proposal is better in some situations
and scenarios, but that our solution is better in some. I think that these
are questions that needs to be more thoroughly simulated.
  

    

For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
How does the Manet node know when to re-flood the request?
How large fraction of all relevant topology changes will the Manet node detect?

My conclusion is still: it is better to let the GW flood periodically.

    

Are you absolutely sure that this will be the optimal solution in all situations?

    

      



      

        
In appendix A, we explain how to use the most appropriate GW with a
routing header. I think the draft can be adapted to your above
situation. What do you think?

--Snip from the drat
   Using a routing header is also preferable if there are 
more than two
Internet-gateways, because the node then have the ability to decide
which Internet-gateway is the best, by distance in hops, or by some
other priority.  By assign a priority number for each 
Internet-gateway,
the route reply message and the Manet Router Advertisement messages
could be extended to support a candidate Internet-gateway 
option in it.
-----

        

        

I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?

        

He describes how the gateway selection process can be implemented.
        

          

Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.

Furthermore, if using flooding, how often should Manet nodes flood the solicitations?

          

... needs more testing...
          

            

            

            

              

                

                  
Regarding TTL, I don't see the problem, unless advertisements were
forwarded on non-manet interfaces. Can you please elaborate a bit?

                  

                  
In your thesis, you mentioned "Limited TTL". This is almost what I
want to explain here. If there is a single GW in manet, RA should be
flooded over whole manet. You can not use optimization like expanding
ring search for flooding. If Manet nodes can not get RAs sent with
limited TTL by GW, it has to discover GW by solicited requests.

                  

                  

Sure, but is that really a problem?

                  

                  
No, and I think that it could be a good hybrid solution.

                  
[and in your previous mail:] Can you elaborate what is the most reason for generating more traffic
> when GW does not flood advertisements.

>The average hop count between the GW and the Manet node increases, 
>since the probability that a Manet node will use a sub-optimal 
> GW increases.


>Then I think I didn't express myself clearly enough. My point is 
>that using a 4-hop route between Manet node and GW1 consumes more 
>resources in the Manet as a whole than using a 2-hop route between the 
>same Manet node and GW2. Thus being able to select the closest gateway 
>is a concern for all nodes in the Manet, including those that do not 
>use internet connectivity.

But minimizing the hop count is, of course, also the purpose of our
solution. The question is whether it really

does differ in average hop, or whether it really is more costful. Flooding
could be very costful for battery sensitive devices. As for choosing the
closest gateway, this should always be the ambition. The node could either
rerequest gateway information, or maybe we could piggyback this information
somewhere, in case a "handover"is needed.

                  

best regards,

                  

Anders 

                  

                  

                  

                  

                  
                  

--------------070403030005040402090808--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 12:04:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22717
	for ; Thu, 11 Jul 2002 12:04:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16978;
	Thu, 11 Jul 2002 11:43:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16953
	for ; Thu, 11 Jul 2002 11:43:28 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21687
	for ; Thu, 11 Jul 2002 11:42:32 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA21987;
	Thu, 11 Jul 2002 08:42:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BFgtk15815;
	Thu, 11 Jul 2002 08:42:55 -0700
X-mProtect: <200207111542> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdeCL8Mf; Thu, 11 Jul 2002 08:42:53 PDT
Message-ID: <3D2DA77D.D5E439D7@iprg.nokia.com>
Date: Thu, 11 Jul 2002 08:42:53 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fredrik Alriksson (EAB)" 
CC: manet@ietf.org
Subject: Re: [manet] Re: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Fredrik,

Anders has already replied, but I wanted to make
additional discussion about one part of your exchange...

"Fredrik Alriksson (EAB)" wrote:

> For how long is the metrics about the GWs in the GW list valid (e.g. hop count)?

This answer is the same as for the metric field in any other
AODV destination route.  Due to route repairs, the metric
may not represent the actual hop count to a destination,
and yet the destination remains reachable.

> How does the Manet node know when to re-flood the request?

When the manet node needs a route to a node in the Internet,
and it does not have a default route, it will re-flood
the request.  Is this your concern?

> How large fraction of all relevant topology changes will the Manet node detect?

The best case would be for it to detect _none_ of the topology
changes, and yet retain routability to all of its communication
partners.

> My conclusion is still: it is better to let the GW flood periodically.

I think the argument for periodic advertisement is the same
as for any other manet-wide advertisement.  The decision about
whether to go for periodic vs. reactive depends on traffic
patterns in either case.

Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 12:04:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22732
	for ; Thu, 11 Jul 2002 12:04:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA20609
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:05:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16978;
	Thu, 11 Jul 2002 11:43:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16953
	for ; Thu, 11 Jul 2002 11:43:28 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21687
	for ; Thu, 11 Jul 2002 11:42:32 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA21987;
	Thu, 11 Jul 2002 08:42:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BFgtk15815;
	Thu, 11 Jul 2002 08:42:55 -0700
X-mProtect: <200207111542> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdeCL8Mf; Thu, 11 Jul 2002 08:42:53 PDT
Message-ID: <3D2DA77D.D5E439D7@iprg.nokia.com>
Date: Thu, 11 Jul 2002 08:42:53 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fredrik Alriksson (EAB)" 
CC: manet@ietf.org
Subject: Re: [manet] Re: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Fredrik,

Anders has already replied, but I wanted to make
additional discussion about one part of your exchange...

"Fredrik Alriksson (EAB)" wrote:

> For how long is the metrics about the GWs in the GW list valid (e.g. hop count)?

This answer is the same as for the metric field in any other
AODV destination route.  Due to route repairs, the metric
may not represent the actual hop count to a destination,
and yet the destination remains reachable.

> How does the Manet node know when to re-flood the request?

When the manet node needs a route to a node in the Internet,
and it does not have a default route, it will re-flood
the request.  Is this your concern?

> How large fraction of all relevant topology changes will the Manet node detect?

The best case would be for it to detect _none_ of the topology
changes, and yet retain routability to all of its communication
partners.

> My conclusion is still: it is better to let the GW flood periodically.

I think the argument for periodic advertisement is the same
as for any other manet-wide advertisement.  The decision about
whether to go for periodic vs. reactive depends on traffic
patterns in either case.

Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 12:04:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22750
	for ; Thu, 11 Jul 2002 12:04:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17521;
	Thu, 11 Jul 2002 11:47:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17490
	for ; Thu, 11 Jul 2002 11:47:44 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21887
	for ; Thu, 11 Jul 2002 11:46:50 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA08598;
	Thu, 11 Jul 2002 10:47:42 -0500 (CDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA09919;
	Thu, 11 Jul 2002 08:47:41 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BFle001197;
	Thu, 11 Jul 2002 08:47:40 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 11:47:40 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A0D@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Nikhil Jain'" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 11:47:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Nikhil Jain [mailto:njain@qualcomm.com] wrote:

> I would recommend that we think about using CDMA. In CDMA we 
> use a reuse of 
> 1. Which means that the same channel is used in all the 
> cells. Ofcourse the 
> moving users present new issues that have to be solved.

I must be missing something in this thread.

IEEE 802.11b uses DSSS: direct sequence spread spectrum. Is this not the foundation of CDMA? I know 802.11b doesn't need all the bells and whistles that cellular CDMA uses to set up channels, but the basics are the same, yes?

For a single ad-hoc network, be it just IEEE 802.11 link layer ad-hoc, or MANET, all mobile hosts in the ad-hoc net have to share the same channel. That is, the same code of DSSS is used. (This is obviously different from cellular CDMA, where each RF link is merely a point-to-point link between one mobile host and the base station.) In ad-hoc nets, mobile hosts are used as hops. They must share the channel. So in 802.11b, you don't have to worry about mobile hosts being told in real time what code to use, or to adjust their power levels, or all the other intricacies of cellular telephone CDMA. In effect, you have a bunch of mobile hosts all sharing one CDMA channel.

If we used frequency hopping (FHSS), the same basic concept applies. In this case, it would be the same sequence of frequency hops, rather than the same code in a DSSS example, used by any given ad-hoc network.

If we used plain old frequency division, the same concept applies. The hosts of one ad-hoc net would have to share one frequency band.

In all of the above, different ad-hoc networks could coexist in the same geographical area simply be using a different channel.

The issues with moving users must be managed at higher layers than the physical layer, because they are fundamental to the routing of ad-hoc network data frames.

I guess what I'm saying is that interference between different ad-hoc nets is managed at the physical layer, by doing whatever the RF technique requires to separate channels, but within an ad-hoc net, you _want_ the hosts to hear each other.

How great the coverage of each host is creates interesting tradeoffs of number of hops required between A and B, vs. number of potential collisions experienced by MANET hosts when trying to transmit something. Not clear to me that the optimal solution is obvious. Low power = lots of hops = lots of contentions for the channel, but fewer hosts contending each time.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 12:04:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22756
	for ; Thu, 11 Jul 2002 12:04:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA20655
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:05:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17521;
	Thu, 11 Jul 2002 11:47:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17490
	for ; Thu, 11 Jul 2002 11:47:44 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21887
	for ; Thu, 11 Jul 2002 11:46:50 -0400 (EDT)
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA08598;
	Thu, 11 Jul 2002 10:47:42 -0500 (CDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA09919;
	Thu, 11 Jul 2002 08:47:41 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BFle001197;
	Thu, 11 Jul 2002 08:47:40 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 11:47:40 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A0D@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Nikhil Jain'" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 11:47:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Nikhil Jain [mailto:njain@qualcomm.com] wrote:

> I would recommend that we think about using CDMA. In CDMA we 
> use a reuse of 
> 1. Which means that the same channel is used in all the 
> cells. Ofcourse the 
> moving users present new issues that have to be solved.

I must be missing something in this thread.

IEEE 802.11b uses DSSS: direct sequence spread spectrum. Is this not the foundation of CDMA? I know 802.11b doesn't need all the bells and whistles that cellular CDMA uses to set up channels, but the basics are the same, yes?

For a single ad-hoc network, be it just IEEE 802.11 link layer ad-hoc, or MANET, all mobile hosts in the ad-hoc net have to share the same channel. That is, the same code of DSSS is used. (This is obviously different from cellular CDMA, where each RF link is merely a point-to-point link between one mobile host and the base station.) In ad-hoc nets, mobile hosts are used as hops. They must share the channel. So in 802.11b, you don't have to worry about mobile hosts being told in real time what code to use, or to adjust their power levels, or all the other intricacies of cellular telephone CDMA. In effect, you have a bunch of mobile hosts all sharing one CDMA channel.

If we used frequency hopping (FHSS), the same basic concept applies. In this case, it would be the same sequence of frequency hops, rather than the same code in a DSSS example, used by any given ad-hoc network.

If we used plain old frequency division, the same concept applies. The hosts of one ad-hoc net would have to share one frequency band.

In all of the above, different ad-hoc networks could coexist in the same geographical area simply be using a different channel.

The issues with moving users must be managed at higher layers than the physical layer, because they are fundamental to the routing of ad-hoc network data frames.

I guess what I'm saying is that interference between different ad-hoc nets is managed at the physical layer, by doing whatever the RF technique requires to separate channels, but within an ad-hoc net, you _want_ the hosts to hear each other.

How great the coverage of each host is creates interesting tradeoffs of number of hops required between A and B, vs. number of potential collisions experienced by MANET hosts when trying to transmit something. Not clear to me that the optimal solution is obvious. Low power = lots of hops = lots of contentions for the channel, but fewer hosts contending each time.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Thu Jul 11 12:27:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23944
	for ; Thu, 11 Jul 2002 12:27:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA23692
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:27:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20973;
	Thu, 11 Jul 2002 12:08:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20948
	for ; Thu, 11 Jul 2002 12:08:16 -0400 (EDT)
Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22885
	for ; Thu, 11 Jul 2002 12:07:21 -0400 (EDT)
Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddd37e.tkyoac00.ap.so-net.ne.jp [218.221.211.126])
	(authenticated bits=0)
	by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6BG7ffg019808;
	Fri, 12 Jul 2002 01:07:41 +0900
Date: Fri, 12 Jul 2002 00:59:10 +0900
Message-ID: 
From: Ryuji Wakikawa
To: Fredrik.Alriksson@era.ericsson.se
Cc: andersn@telecom.lth.se, manet@ietf.org, ryuji@sfc.wide.ad.jp
Subject: Re: [manet] Re: Gateway Advertisements
In-Reply-To: <1F55F6582266314A85A55F6241509B674180D4@Esealnt863.al.sw.ericsson.se>
References: <1F55F6582266314A85A55F6241509B674180D4@Esealnt863.al.sw.ericsson.se>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd)
 MULE/4.1 (AOI)
Organization: Keio University
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi again

At Thu, 11 Jul 2002 16:57:57 +0200,
Fredrik Alriksson (EAB) wrote:
> 
> 
> [Fredrik Alriksson] Then I think we agree; I originally started this
> thread since you in the draft claim that a proactive approach SHOULD
> NOT be used, but now you say that it depends and that we don't
> really know. Will that be reflected in the draft as well?

Yes, I want to consider proactive way. 
By the way, will you come IETF Yokohama in next week?


> For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
> How does the Manet node know when to re-flood the request?
> How large fraction of all relevant topology changes will the Manet node detect?
> 
> My conclusion is still: it is better to let the GW flood periodically.
> 
> Are you absolutely sure that this will be the optimal solution in all situations?
> 
> 
> [Fredrik Alriksson] No, not in all situations. Isn't that a general
> 'feature' with MANETs, no single solution will ever be optimal for
> all MANETs ;-)
> 

I agree:-)

> 
> 
> In appendix A, we explain how to use the most appropriate GW with a
> routing header. I think the draft can be adapted to your above
> situation. What do you think?
> 
> --Snip from the drat
>    Using a routing header is also preferable if there are 
> more than two
> Internet-gateways, because the node then have the ability to decide
> which Internet-gateway is the best, by distance in hops, or by some
> other priority.  By assign a priority number for each 
> Internet-gateway,
> the route reply message and the Manet Router Advertisement messages
> could be extended to support a candidate Internet-gateway 
> option in it.
> -----
> 
> 
> I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?
> 
> He describes how the gateway selection process can be implemented. 
> 
> 
> [Fredrik Alriksson] ...which is somewhat independent from how the advertisements are distributed...right?

I just wanted to explain reactive way can select closer one (if it
maybe inefficient). We have already considered hop limits to GW and
unfortunantely our solutions seems not enough...


> Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.
> 
> Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
> 
> ... needs more testing... 
> 
> 
> [Fredrik Alriksson] The reason for asking is this: assume a MANET
> with 2 GWs and 10 manet nodes using these 2 GWs for Internet
> access. What is the overhead with proactive vs. reactive? Assuming
> that the periodicity is the same: reactive: 10 floodings, proactive:
> 2 floodings.
> 

I do not know if this example is good enough, because we can get
another results depending on topology changes, measurements periods:-)

After first discovery, reactive stop flooding and start unicasting instead.
So the result will change after first discovery.
For 10 sec: reactive: 0 floodings, proactive 10 floodings.
Well this is best case for reactive, another result can be expected, of
course!

> 
> >Then I think I didn't express myself clearly enough. My point is 
> >that using a 4-hop route between Manet node and GW1 consumes more 
> >resources in the Manet as a whole than using a 2-hop route between the 
> >same Manet node and GW2. Thus being able to select the closest gateway 
> >is a concern for all nodes in the Manet, including those that do not 
> >use internet connectivity.
> But minimizing the hop count is, of course, also the purpose of our solution. The question is whether it really
> does differ in average hop, or whether it really is more costful. Flooding could be very costful for battery sensitive devices. As for choosing the closest gateway, this should always be the ambition. The node could either rerequest gateway information, or maybe we could piggyback this information somewhere, in case a "handover"is needed.
> 
> 
> [Fredrik Alriksson] The question with a reactive approach is how to
> detect that a reaction is needed. Could you please describe that
> again?

Actually, the use of multiple GW is not considered enough yet, we just
mention our rough idea in the draft.  So I don't know if I have good
answer for this.

regards,
ryuji

> BR,
> Fredrik
> 
>  
> 
> best regards,
> 
> Anders 
> 
> 
> 
> 
> 
> 
> [2  ]
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 12:30:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24156
	for ; Thu, 11 Jul 2002 12:30:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20584;
	Thu, 11 Jul 2002 12:04:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20552
	for ; Thu, 11 Jul 2002 12:04:32 -0400 (EDT)
Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22691
	for ; Thu, 11 Jul 2002 12:03:37 -0400 (EDT)
Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddd37e.tkyoac00.ap.so-net.ne.jp [218.221.211.126])
	(authenticated bits=0)
	by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6BG3rfg019797;
	Fri, 12 Jul 2002 01:03:54 +0900
Date: Fri, 12 Jul 2002 00:56:02 +0900
Message-ID: 
From: Ryuji Wakikawa
To: Fredrik.Alriksson@era.ericsson.se
Cc: ryuji@sfc.wide.ad.jp, charliep@iprg.nokia.com, jmalinen@iprg.nokia.com,
        ajtuomin@tml.hut.fi, andersn@telecom.lth.se, manet@ietf.org
Subject: Re: [manet] Re: Gateway Advertisements
In-Reply-To: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
References: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd)
 MULE/4.1 (AOI)
Organization: Keio University
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi Fredrik.

Fredrik Alriksson (EAB) wrote:
> 
> But you can't know which of the advertisements that are
> "unnecessary" beforehand. I would say that sending the periodic
> advertisements too frequently creates unnecessary overhead, and that
> the problem is to define an "optimal" period. This is not at all the
> same as to say that periodic advertisements SHOULD NOT be used at
> all!
> 

I need more consideration for this. I will try to leave out the
sentence about "SHOULD NOT" and put more texts about this.
I will ask you comments when I write this.

> 
> For how long is the metrics about the GWs in the GW list valid
> (e.g. hop count)?  

Manet node does not keep a hop count which is known by advertisements from GW.
Hop count is alway updated during maintenance of the route path to GW by a manet protocol.
But if the route is expired, manet node have to discover the route again.

> How does the Manet node know when to re-flood the request?  

We haven't specified yet. maybe when hop count change, movements
detection, receiving RERR.

> How large fraction of all relevant topology changes will the Manet node detect?

It depends on a base manet protocol. For example, the manet node may not
know the changes since AODV has local repair functions.


> > I think we should clarify much more about situations when multiple GWs
> > are located.
> > 
> > # Can you explain more about simulated unicast situation.  Can a manet
> >   node receive RA from only associated GW? Didn't you use solicited
> >   request from the manet node? If not, GW will discover the manet node
> >   route, when it sends RA to the node and can not find fresh route for
> >   the node. 
> 
> I think you have a good point here; we did use RA's but perhaps not optimally.
> 
> > This does not happen to our solution.
> 
> Well, it does if the Manet node unicasts the solicitation, which use
> list as one alternative if I understand the draft correct.

You are right.
But this happens once. not periodically. During being using the gateway,
the Manet node can maintain route path by manet protocol.
I think this is not exact same as the problem of proactive, 
although it still depends on many situations.

> Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
>  
> > > Regarding TTL, I don't see the problem, unless advertisements were
> > > forwarded on non-manet interfaces. Can you please elaborate a bit?
> > 
> > In your thesis, you mentioned "Limited TTL". This is almost what I
> > want to explain here. If there is a single GW in manet, RA should be
> > flooded over whole manet. You can not use optimization like expanding
> > ring search for flooding. If Manet nodes can not get RAs sent with
> > limited TTL by GW, it has to discover GW by solicited requests.
> 
> Sure, but is that really a problem?

I think Anders replied to this question.

regards,
ryuji

> BR,
> Fredrik
> 
> > best regards,
> > ryuji
> > 
> > > BR,
> > > Fredrik
> > > 
> > > > -----Original Message-----
> > > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> > > > Sent: den 8 juli 2002 18:40
> > > > To: Fredrik.Alriksson@era.ericsson.se
> > > > Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
> > > > jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; 
> > andersn@telecom.lth.se;
> > > > manet@ietf.org
> > > > Subject: Re: Gateway Advertisements
> > > > 
> > > > 
> > > > 
> > > > Hello Fredrik.
> > > > 
> > > > In the draft, unnecessary packets basically indicates un-necessary
> > > > gateway advertisements. For example, if a gateway 
> > generates a route
> > > > advertisement every 1 sec, most of router advertisements 
> > are redundant
> > > > for manet nodes which have already had a global address. They may
> > > > update lifetime of their global address, but the interval(1sec) is
> > > > still too short for this operations.
> > > > 
> > > > Since flooding packets is easy to cause performance 
> > damage in manet,
> > > > our approach tries to reduce a number of packets which are 
> > > > flooded over
> > > > manet. I think manet nodes should not wait flooded 
> > advertisements from
> > > > gateway, instead manet node should discover gateways on their
> > > > initiative.
> > > > 
> > > > It is also difficult for gateways to decide TTL for flooded
> > > > advertisements. Expanding ring search technique can not 
> > be applied to
> > > > this situation, because advertisements should reach at the edge of
> > > > manet. It can imagine that unnecessary network-wide 
> > dissemination of
> > > > advertisements will occur when a gateway sets larger TTL 
> > than manet
> > > > scale.
> > > > 
> > > > regards,
> > > > r
> > > > 
> > > > 
> > > > At Mon, 8 Jul 2002 17:27:19 +0200 ,
> > > > Fredrik Alriksson (EAB) wrote:
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> > > > sending gateway advertisements peridically would generate 
> > > > unnecessary packets in the Manet. Can you please explain how 
> > > > you came to that conclusion? Our simulation study on MIPMANET 
> > > > from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
> > > > indicates that it actually can decrease the number of packet 
> > > > transmissions in the MANET.
> > > > > 
> > > > > BR,
> > > > > Fredrik
> > > > > 
> > > > > ---
> > > > > Fredrik Alriksson, Ericsson Research
> > > > > Email: fredrik.alriksson@ericsson.com
> > > > > 
> > > > > 
> > > > 
> > 
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> > 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 12:30:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24170
	for ; Thu, 11 Jul 2002 12:30:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA24646
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:31:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20584;
	Thu, 11 Jul 2002 12:04:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20552
	for ; Thu, 11 Jul 2002 12:04:32 -0400 (EDT)
Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22691
	for ; Thu, 11 Jul 2002 12:03:37 -0400 (EDT)
Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddd37e.tkyoac00.ap.so-net.ne.jp [218.221.211.126])
	(authenticated bits=0)
	by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6BG3rfg019797;
	Fri, 12 Jul 2002 01:03:54 +0900
Date: Fri, 12 Jul 2002 00:56:02 +0900
Message-ID: 
From: Ryuji Wakikawa
To: Fredrik.Alriksson@era.ericsson.se
Cc: ryuji@sfc.wide.ad.jp, charliep@iprg.nokia.com, jmalinen@iprg.nokia.com,
        ajtuomin@tml.hut.fi, andersn@telecom.lth.se, manet@ietf.org
Subject: Re: [manet] Re: Gateway Advertisements
In-Reply-To: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
References: <1F55F6582266314A85A55F6241509B674180CA@Esealnt863.al.sw.ericsson.se>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd)
 MULE/4.1 (AOI)
Organization: Keio University
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi Fredrik.

Fredrik Alriksson (EAB) wrote:
> 
> But you can't know which of the advertisements that are
> "unnecessary" beforehand. I would say that sending the periodic
> advertisements too frequently creates unnecessary overhead, and that
> the problem is to define an "optimal" period. This is not at all the
> same as to say that periodic advertisements SHOULD NOT be used at
> all!
> 

I need more consideration for this. I will try to leave out the
sentence about "SHOULD NOT" and put more texts about this.
I will ask you comments when I write this.

> 
> For how long is the metrics about the GWs in the GW list valid
> (e.g. hop count)?  

Manet node does not keep a hop count which is known by advertisements from GW.
Hop count is alway updated during maintenance of the route path to GW by a manet protocol.
But if the route is expired, manet node have to discover the route again.

> How does the Manet node know when to re-flood the request?  

We haven't specified yet. maybe when hop count change, movements
detection, receiving RERR.

> How large fraction of all relevant topology changes will the Manet node detect?

It depends on a base manet protocol. For example, the manet node may not
know the changes since AODV has local repair functions.


> > I think we should clarify much more about situations when multiple GWs
> > are located.
> > 
> > # Can you explain more about simulated unicast situation.  Can a manet
> >   node receive RA from only associated GW? Didn't you use solicited
> >   request from the manet node? If not, GW will discover the manet node
> >   route, when it sends RA to the node and can not find fresh route for
> >   the node. 
> 
> I think you have a good point here; we did use RA's but perhaps not optimally.
> 
> > This does not happen to our solution.
> 
> Well, it does if the Manet node unicasts the solicitation, which use
> list as one alternative if I understand the draft correct.

You are right.
But this happens once. not periodically. During being using the gateway,
the Manet node can maintain route path by manet protocol.
I think this is not exact same as the problem of proactive, 
although it still depends on many situations.

> Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
>  
> > > Regarding TTL, I don't see the problem, unless advertisements were
> > > forwarded on non-manet interfaces. Can you please elaborate a bit?
> > 
> > In your thesis, you mentioned "Limited TTL". This is almost what I
> > want to explain here. If there is a single GW in manet, RA should be
> > flooded over whole manet. You can not use optimization like expanding
> > ring search for flooding. If Manet nodes can not get RAs sent with
> > limited TTL by GW, it has to discover GW by solicited requests.
> 
> Sure, but is that really a problem?

I think Anders replied to this question.

regards,
ryuji

> BR,
> Fredrik
> 
> > best regards,
> > ryuji
> > 
> > > BR,
> > > Fredrik
> > > 
> > > > -----Original Message-----
> > > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> > > > Sent: den 8 juli 2002 18:40
> > > > To: Fredrik.Alriksson@era.ericsson.se
> > > > Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
> > > > jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; 
> > andersn@telecom.lth.se;
> > > > manet@ietf.org
> > > > Subject: Re: Gateway Advertisements
> > > > 
> > > > 
> > > > 
> > > > Hello Fredrik.
> > > > 
> > > > In the draft, unnecessary packets basically indicates un-necessary
> > > > gateway advertisements. For example, if a gateway 
> > generates a route
> > > > advertisement every 1 sec, most of router advertisements 
> > are redundant
> > > > for manet nodes which have already had a global address. They may
> > > > update lifetime of their global address, but the interval(1sec) is
> > > > still too short for this operations.
> > > > 
> > > > Since flooding packets is easy to cause performance 
> > damage in manet,
> > > > our approach tries to reduce a number of packets which are 
> > > > flooded over
> > > > manet. I think manet nodes should not wait flooded 
> > advertisements from
> > > > gateway, instead manet node should discover gateways on their
> > > > initiative.
> > > > 
> > > > It is also difficult for gateways to decide TTL for flooded
> > > > advertisements. Expanding ring search technique can not 
> > be applied to
> > > > this situation, because advertisements should reach at the edge of
> > > > manet. It can imagine that unnecessary network-wide 
> > dissemination of
> > > > advertisements will occur when a gateway sets larger TTL 
> > than manet
> > > > scale.
> > > > 
> > > > regards,
> > > > r
> > > > 
> > > > 
> > > > At Mon, 8 Jul 2002 17:27:19 +0200 ,
> > > > Fredrik Alriksson (EAB) wrote:
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> > > > sending gateway advertisements peridically would generate 
> > > > unnecessary packets in the Manet. Can you please explain how 
> > > > you came to that conclusion? Our simulation study on MIPMANET 
> > > > from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
> > > > indicates that it actually can decrease the number of packet 
> > > > transmissions in the MANET.
> > > > > 
> > > > > BR,
> > > > > Fredrik
> > > > > 
> > > > > ---
> > > > > Fredrik Alriksson, Ericsson Research
> > > > > Email: fredrik.alriksson@ericsson.com
> > > > > 
> > > > > 
> > > > 
> > 
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> > 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 12:40:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24624
	for ; Thu, 11 Jul 2002 12:40:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22956;
	Thu, 11 Jul 2002 12:22:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22925
	for ; Thu, 11 Jul 2002 12:22:46 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23646
	for ; Thu, 11 Jul 2002 12:21:50 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117125>; Thu, 11 Jul 2002 10:22:34 -0600
Message-Id: <02Jul11.102234mdt.117125@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "Manfredi, Albert E" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Thu, 11 Jul 2002 10:22:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

Well, if you are missing something, I don't see it.

Just one thing, though.  As you point out, the choice of many low-power hops
vs. a few high-power hops is not obvious.  I would like to add that the
preferred strategy might differ as one goes from region to region within a
single MANET.  That is, the final answer might be a protocol that can decide
which option to employ locally based on local conditions, but able to
operate seamlessly with other parts of the MANET, even if they are using
different strategies.

John Mullen

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Thursday, July 11, 2002 9:48 AM
To: 'Nikhil Jain'; manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network


Nikhil Jain [mailto:njain@qualcomm.com] wrote:

> I would recommend that we think about using CDMA. In CDMA we 
> use a reuse of 
> 1. Which means that the same channel is used in all the 
> cells. Ofcourse the 
> moving users present new issues that have to be solved.

I must be missing something in this thread.

IEEE 802.11b uses DSSS: direct sequence spread spectrum. Is this not the
foundation of CDMA? I know 802.11b doesn't need all the bells and whistles
that cellular CDMA uses to set up channels, but the basics are the same,
yes?

For a single ad-hoc network, be it just IEEE 802.11 link layer ad-hoc, or
MANET, all mobile hosts in the ad-hoc net have to share the same channel.
That is, the same code of DSSS is used. (This is obviously different from
cellular CDMA, where each RF link is merely a point-to-point link between
one mobile host and the base station.) In ad-hoc nets, mobile hosts are used
as hops. They must share the channel. So in 802.11b, you don't have to worry
about mobile hosts being told in real time what code to use, or to adjust
their power levels, or all the other intricacies of cellular telephone CDMA.
In effect, you have a bunch of mobile hosts all sharing one CDMA channel.

If we used frequency hopping (FHSS), the same basic concept applies. In this
case, it would be the same sequence of frequency hops, rather than the same
code in a DSSS example, used by any given ad-hoc network.

If we used plain old frequency division, the same concept applies. The hosts
of one ad-hoc net would have to share one frequency band.

In all of the above, different ad-hoc networks could coexist in the same
geographical area simply be using a different channel.

The issues with moving users must be managed at higher layers than the
physical layer, because they are fundamental to the routing of ad-hoc
network data frames.

I guess what I'm saying is that interference between different ad-hoc nets
is managed at the physical layer, by doing whatever the RF technique
requires to separate channels, but within an ad-hoc net, you _want_ the
hosts to hear each other.

How great the coverage of each host is creates interesting tradeoffs of
number of hops required between A and B, vs. number of potential collisions
experienced by MANET hosts when trying to transmit something. Not clear to
me that the optimal solution is obvious. Low power = lots of hops = lots of
contentions for the channel, but fewer hosts contending each time.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 12:40:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24631
	for ; Thu, 11 Jul 2002 12:40:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA25760
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:41:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22956;
	Thu, 11 Jul 2002 12:22:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22925
	for ; Thu, 11 Jul 2002 12:22:46 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23646
	for ; Thu, 11 Jul 2002 12:21:50 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117125>; Thu, 11 Jul 2002 10:22:34 -0600
Message-Id: <02Jul11.102234mdt.117125@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "Manfredi, Albert E" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Thu, 11 Jul 2002 10:22:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

Well, if you are missing something, I don't see it.

Just one thing, though.  As you point out, the choice of many low-power hops
vs. a few high-power hops is not obvious.  I would like to add that the
preferred strategy might differ as one goes from region to region within a
single MANET.  That is, the final answer might be a protocol that can decide
which option to employ locally based on local conditions, but able to
operate seamlessly with other parts of the MANET, even if they are using
different strategies.

John Mullen

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Thursday, July 11, 2002 9:48 AM
To: 'Nikhil Jain'; manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network


Nikhil Jain [mailto:njain@qualcomm.com] wrote:

> I would recommend that we think about using CDMA. In CDMA we 
> use a reuse of 
> 1. Which means that the same channel is used in all the 
> cells. Ofcourse the 
> moving users present new issues that have to be solved.

I must be missing something in this thread.

IEEE 802.11b uses DSSS: direct sequence spread spectrum. Is this not the
foundation of CDMA? I know 802.11b doesn't need all the bells and whistles
that cellular CDMA uses to set up channels, but the basics are the same,
yes?

For a single ad-hoc network, be it just IEEE 802.11 link layer ad-hoc, or
MANET, all mobile hosts in the ad-hoc net have to share the same channel.
That is, the same code of DSSS is used. (This is obviously different from
cellular CDMA, where each RF link is merely a point-to-point link between
one mobile host and the base station.) In ad-hoc nets, mobile hosts are used
as hops. They must share the channel. So in 802.11b, you don't have to worry
about mobile hosts being told in real time what code to use, or to adjust
their power levels, or all the other intricacies of cellular telephone CDMA.
In effect, you have a bunch of mobile hosts all sharing one CDMA channel.

If we used frequency hopping (FHSS), the same basic concept applies. In this
case, it would be the same sequence of frequency hops, rather than the same
code in a DSSS example, used by any given ad-hoc network.

If we used plain old frequency division, the same concept applies. The hosts
of one ad-hoc net would have to share one frequency band.

In all of the above, different ad-hoc networks could coexist in the same
geographical area simply be using a different channel.

The issues with moving users must be managed at higher layers than the
physical layer, because they are fundamental to the routing of ad-hoc
network data frames.

I guess what I'm saying is that interference between different ad-hoc nets
is managed at the physical layer, by doing whatever the RF technique
requires to separate channels, but within an ad-hoc net, you _want_ the
hosts to hear each other.

How great the coverage of each host is creates interesting tradeoffs of
number of hops required between A and B, vs. number of potential collisions
experienced by MANET hosts when trying to transmit something. Not clear to
me that the optimal solution is obvious. Low power = lots of hops = lots of
contentions for the channel, but fewer hosts contending each time.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 12:40:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24665
	for ; Thu, 11 Jul 2002 12:40:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21128;
	Thu, 11 Jul 2002 12:09:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21096
	for ; Thu, 11 Jul 2002 12:09:18 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22933
	for ; Thu, 11 Jul 2002 12:08:18 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 3RD9K6FX; Thu, 11 Jul 2002 12:09:04 -0400
Message-ID: <015401c228f5$47464000$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Mullen, John P. \(Contractor\)" ,
        "Manfredi, Albert E" , ,
        "Nikhil Jain" 
References: <5.1.0.14.2.20020711075609.026a9d70@illyana.qualcomm.com>
Subject: Re: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 12:09:04 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a version that
is suitable for ad hoc networks.  The Qualcomm type (3G type) has asymetric
channel structure, i.e. the reverse and forward links are structured differently at
the phy and link layers.  This poses problems for a peer-to-peer network like a
MANET.  There is also a lot of intelligence in the IS-94A/B/C (3G) BTS that
you would not want to replicate in an inexpensive ad hoc radio.  Our MAC
is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
all simultaneously.

----- Original Message -----
From: "Nikhil Jain" 
To: "Mullen, John P. (Contractor)" ; "Manfredi, Albert E" ;

Sent: Thursday, July 11, 2002 10:57 AM
Subject: RE: [manet] Interference in ad hoc network


> I would recommend that we think about using CDMA. In CDMA we use a reuse of
> 1. Which means that the same channel is used in all the cells. Ofcourse the
> moving users present new issues that have to be solved.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 12:40:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24675
	for ; Thu, 11 Jul 2002 12:40:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA25786
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:41:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21128;
	Thu, 11 Jul 2002 12:09:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21096
	for ; Thu, 11 Jul 2002 12:09:18 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22933
	for ; Thu, 11 Jul 2002 12:08:18 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 3RD9K6FX; Thu, 11 Jul 2002 12:09:04 -0400
Message-ID: <015401c228f5$47464000$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Mullen, John P. \(Contractor\)" ,
        "Manfredi, Albert E" , ,
        "Nikhil Jain" 
References: <5.1.0.14.2.20020711075609.026a9d70@illyana.qualcomm.com>
Subject: Re: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 12:09:04 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a version that
is suitable for ad hoc networks.  The Qualcomm type (3G type) has asymetric
channel structure, i.e. the reverse and forward links are structured differently at
the phy and link layers.  This poses problems for a peer-to-peer network like a
MANET.  There is also a lot of intelligence in the IS-94A/B/C (3G) BTS that
you would not want to replicate in an inexpensive ad hoc radio.  Our MAC
is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
all simultaneously.

----- Original Message -----
From: "Nikhil Jain" 
To: "Mullen, John P. (Contractor)" ; "Manfredi, Albert E" ;

Sent: Thursday, July 11, 2002 10:57 AM
Subject: RE: [manet] Interference in ad hoc network


> I would recommend that we think about using CDMA. In CDMA we use a reuse of
> 1. Which means that the same channel is used in all the cells. Ofcourse the
> moving users present new issues that have to be solved.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 12:45:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24884
	for ; Thu, 11 Jul 2002 12:45:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22384;
	Thu, 11 Jul 2002 12:20:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22355
	for ; Thu, 11 Jul 2002 12:20:16 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23499
	for ; Thu, 11 Jul 2002 12:19:21 -0400 (EDT)
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA12046;
	Thu, 11 Jul 2002 09:20:13 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA21380;
	Thu, 11 Jul 2002 09:19:53 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BGKC000834;
	Thu, 11 Jul 2002 09:20:12 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 12:20:11 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A0F@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Phil Neumiller'" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 12:20:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Good point about asymmetry not required or desirable in an ad-hoc net, Phil. I forgot about that. With base stations, asymmetry helps.

I have a suggestion on a transmitter power rule of thumb. If the typical path of MANET data packets covers a large area of the MANET, then high power is good because it reduces the number of hops required for each packet, reducing the busyness of every host.

If the typical data path is short, mostly between adjacent hosts, then the transmitter power is best kept low, because this permits different clusters to transmit packets among their own hosts simultaneous to other clusters doing the same. More aggregate throughput.

Bert


> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Thursday, July 11, 2002 12:09 PM
> To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;
> Nikhil Jain
> Subject: Re: [manet] Interference in ad hoc network
> 
> 
> MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a 
> version that
> is suitable for ad hoc networks.  The Qualcomm type (3G type) 
> has asymetric
> channel structure, i.e. the reverse and forward links are 
> structured differently at
> the phy and link layers.  This poses problems for a 
> peer-to-peer network like a
> MANET.  There is also a lot of intelligence in the IS-94A/B/C 
> (3G) BTS that
> you would not want to replicate in an inexpensive ad hoc 
> radio.  Our MAC
> is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
> all simultaneously.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 12:45:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24890
	for ; Thu, 11 Jul 2002 12:45:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA26505
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 12:46:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22384;
	Thu, 11 Jul 2002 12:20:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22355
	for ; Thu, 11 Jul 2002 12:20:16 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23499
	for ; Thu, 11 Jul 2002 12:19:21 -0400 (EDT)
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA12046;
	Thu, 11 Jul 2002 09:20:13 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA21380;
	Thu, 11 Jul 2002 09:19:53 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BGKC000834;
	Thu, 11 Jul 2002 09:20:12 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 12:20:11 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A0F@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Phil Neumiller'" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 12:20:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Good point about asymmetry not required or desirable in an ad-hoc net, Phil. I forgot about that. With base stations, asymmetry helps.

I have a suggestion on a transmitter power rule of thumb. If the typical path of MANET data packets covers a large area of the MANET, then high power is good because it reduces the number of hops required for each packet, reducing the busyness of every host.

If the typical data path is short, mostly between adjacent hosts, then the transmitter power is best kept low, because this permits different clusters to transmit packets among their own hosts simultaneous to other clusters doing the same. More aggregate throughput.

Bert


> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Thursday, July 11, 2002 12:09 PM
> To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;
> Nikhil Jain
> Subject: Re: [manet] Interference in ad hoc network
> 
> 
> MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a 
> version that
> is suitable for ad hoc networks.  The Qualcomm type (3G type) 
> has asymetric
> channel structure, i.e. the reverse and forward links are 
> structured differently at
> the phy and link layers.  This poses problems for a 
> peer-to-peer network like a
> MANET.  There is also a lot of intelligence in the IS-94A/B/C 
> (3G) BTS that
> you would not want to replicate in an inexpensive ad hoc 
> radio.  Our MAC
> is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
> all simultaneously.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 13:04:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25836
	for ; Thu, 11 Jul 2002 13:04:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26583;
	Thu, 11 Jul 2002 12:47:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26552
	for ; Thu, 11 Jul 2002 12:47:17 -0400 (EDT)
Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24938
	for ; Thu, 11 Jul 2002 12:46:23 -0400 (EDT)
From: "Xiaoning He" 
To: 
Subject: RE: [manet] Mobile Ad-hoc Network in the 4G system
Date: Thu, 11 Jul 2002 09:44:43 -0700
Message-ID: <001d01c228fa$424505f0$106015ac@VAIO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
In-Reply-To: <02071110135800.00402@manson>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA26553
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi all

Thanks for all the comments. I agree that the from carrier's point of
view, MANET may cause some troubles. 

Also thanks for the pointers. 

Regards

Xiaoning

-----Original Message-----
From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of
Dario Bottazzi
Sent: Thursday, July 11, 2002 1:15 AM
To: manet@ietf.org
Subject: Re: [manet] Mobile Ad-hoc Network in the 4G system

Hi Xiaoning,
        I think I wouldn't think too much to 3G or 4G... I imagine MANET

technologies within the context of pervasive and ubiquitous computing. I

think that MANETs will allow the advent of new kind of technologies and 
applications. I suggest you to give a look to 

 http://www.computer.org/pervasive/ 

regards 
     Dario


Il 22:53, mercoledì 10 luglio 2002, hai scritto:
> Hi Xiaoning,
>
> My reactions would be:
>
> 1. What is 4G? Specifically, other than bandwidth (the modulation
scheme in
> the wireless links), how does it differ from 3G?
>
> 2. If 4G is basically an extension of the wired network, depends on
> geographically fixed base stations for packet routing and access to
mobile
> hosts, the wireless link is a point-to-point link to individual mobile
> hosts, then clearly it is not the problem MANET is out to solve.
>
> 3. However, of course, a MANET could be made to connect to a 4G, or
3G, or
> Internet, wired networks.
>
> Bert
>
> > -----Original Message-----
> > From: Xiaoning He [mailto:xiaoning@docomolabs-usa.com]
> > Sent: Wednesday, July 10, 2002 4:16 PM
> > To: manet@ietf.org
> > Subject: [manet] Mobile Ad-hoc Network in the 4G system
> >
> >
> > Hi all
> >
> > I have a few questions regarding the role of the Mobile ad-hoc
network
> > in the 4G wireless system. Whether or not the ad-hoc type of network
> > will play an important role in the 4G system? If it will, what's the
> > killer app for the mobile ad-hoc network in 4G?
> >
> > It seems to me that currently the mobile ad-hoc network is
> > important for
> > military, disaster relief etc. But for daily personal life, I am not
> > sure.
> >
> > I am not sure whether it is the right place to raise question.
Anyway,
> > please feel free to comment.
> >
> > Regards
> >
> > Xiaoning He, Ph.D
> > Research Engineer
> > 181 Metro Drive, Suite 300
> > San Jose, CA 95110
> >
> > Email: xiaoning@docomolabs-usa.com
> > Phone: +1 (408) 451-4737
> > Fax  : +1 (408) 573-1090
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 13:04:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25844
	for ; Thu, 11 Jul 2002 13:04:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA29265
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 13:05:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26583;
	Thu, 11 Jul 2002 12:47:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26552
	for ; Thu, 11 Jul 2002 12:47:17 -0400 (EDT)
Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24938
	for ; Thu, 11 Jul 2002 12:46:23 -0400 (EDT)
From: "Xiaoning He" 
To: 
Subject: RE: [manet] Mobile Ad-hoc Network in the 4G system
Date: Thu, 11 Jul 2002 09:44:43 -0700
Message-ID: <001d01c228fa$424505f0$106015ac@VAIO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
In-Reply-To: <02071110135800.00402@manson>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA26553
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi all

Thanks for all the comments. I agree that the from carrier's point of
view, MANET may cause some troubles. 

Also thanks for the pointers. 

Regards

Xiaoning

-----Original Message-----
From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of
Dario Bottazzi
Sent: Thursday, July 11, 2002 1:15 AM
To: manet@ietf.org
Subject: Re: [manet] Mobile Ad-hoc Network in the 4G system

Hi Xiaoning,
        I think I wouldn't think too much to 3G or 4G... I imagine MANET

technologies within the context of pervasive and ubiquitous computing. I

think that MANETs will allow the advent of new kind of technologies and 
applications. I suggest you to give a look to 

 http://www.computer.org/pervasive/ 

regards 
     Dario


Il 22:53, mercoledì 10 luglio 2002, hai scritto:
> Hi Xiaoning,
>
> My reactions would be:
>
> 1. What is 4G? Specifically, other than bandwidth (the modulation
scheme in
> the wireless links), how does it differ from 3G?
>
> 2. If 4G is basically an extension of the wired network, depends on
> geographically fixed base stations for packet routing and access to
mobile
> hosts, the wireless link is a point-to-point link to individual mobile
> hosts, then clearly it is not the problem MANET is out to solve.
>
> 3. However, of course, a MANET could be made to connect to a 4G, or
3G, or
> Internet, wired networks.
>
> Bert
>
> > -----Original Message-----
> > From: Xiaoning He [mailto:xiaoning@docomolabs-usa.com]
> > Sent: Wednesday, July 10, 2002 4:16 PM
> > To: manet@ietf.org
> > Subject: [manet] Mobile Ad-hoc Network in the 4G system
> >
> >
> > Hi all
> >
> > I have a few questions regarding the role of the Mobile ad-hoc
network
> > in the 4G wireless system. Whether or not the ad-hoc type of network
> > will play an important role in the 4G system? If it will, what's the
> > killer app for the mobile ad-hoc network in 4G?
> >
> > It seems to me that currently the mobile ad-hoc network is
> > important for
> > military, disaster relief etc. But for daily personal life, I am not
> > sure.
> >
> > I am not sure whether it is the right place to raise question.
Anyway,
> > please feel free to comment.
> >
> > Regards
> >
> > Xiaoning He, Ph.D
> > Research Engineer
> > 181 Metro Drive, Suite 300
> > San Jose, CA 95110
> >
> > Email: xiaoning@docomolabs-usa.com
> > Phone: +1 (408) 451-4737
> > Fax  : +1 (408) 573-1090
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 13:15:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26236
	for ; Thu, 11 Jul 2002 13:15:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27453;
	Thu, 11 Jul 2002 12:55:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27422
	for ; Thu, 11 Jul 2002 12:55:02 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25275
	for ; Thu, 11 Jul 2002 12:54:07 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117122>; Thu, 11 Jul 2002 10:54:53 -0600
Message-Id: <02Jul11.105453mdt.117122@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "Manfredi, Albert E" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Thu, 11 Jul 2002 10:54:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

I agree on the short path, but on long paths, it is not so clear.  If there
are many hosts within the broadcast range that are not involved in the
interchange, they cannot use the channel  for other interchanges during the
transmission.  If low power is used, fewer hosts are affected at each hop
and some may not be affected at all.  There could be several low-power hops,
each involving different messages, at the same time without interference, as
long as they are far enough from each other.

The preferred strategy would depend on how many uninvolved hosts are
impacted by each transmission, as well as the topology of the situation.
For example, if the hosts are clustered near the sender and the receiver is
a great distance away, the high power hop would be better since a
transmission from any of the clustered hosts powerful enough to reach the
destination will affect all the other clustered hosts anyhow.  

John Mullen

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Thursday, July 11, 2002 10:20 AM
To: 'Phil Neumiller'; manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network


Good point about asymmetry not required or desirable in an ad-hoc net, Phil.
I forgot about that. With base stations, asymmetry helps.

I have a suggestion on a transmitter power rule of thumb. If the typical
path of MANET data packets covers a large area of the MANET, then high power
is good because it reduces the number of hops required for each packet,
reducing the busyness of every host.

If the typical data path is short, mostly between adjacent hosts, then the
transmitter power is best kept low, because this permits different clusters
to transmit packets among their own hosts simultaneous to other clusters
doing the same. More aggregate throughput.

Bert


> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Thursday, July 11, 2002 12:09 PM
> To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;
> Nikhil Jain
> Subject: Re: [manet] Interference in ad hoc network
> 
> 
> MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a 
> version that
> is suitable for ad hoc networks.  The Qualcomm type (3G type) 
> has asymetric
> channel structure, i.e. the reverse and forward links are 
> structured differently at
> the phy and link layers.  This poses problems for a 
> peer-to-peer network like a
> MANET.  There is also a lot of intelligence in the IS-94A/B/C 
> (3G) BTS that
> you would not want to replicate in an inexpensive ad hoc 
> radio.  Our MAC
> is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
> all simultaneously.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 13:15:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26242
	for ; Thu, 11 Jul 2002 13:15:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA29944
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 13:16:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27453;
	Thu, 11 Jul 2002 12:55:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27422
	for ; Thu, 11 Jul 2002 12:55:02 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25275
	for ; Thu, 11 Jul 2002 12:54:07 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117122>; Thu, 11 Jul 2002 10:54:53 -0600
Message-Id: <02Jul11.105453mdt.117122@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "Manfredi, Albert E" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Thu, 11 Jul 2002 10:54:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

I agree on the short path, but on long paths, it is not so clear.  If there
are many hosts within the broadcast range that are not involved in the
interchange, they cannot use the channel  for other interchanges during the
transmission.  If low power is used, fewer hosts are affected at each hop
and some may not be affected at all.  There could be several low-power hops,
each involving different messages, at the same time without interference, as
long as they are far enough from each other.

The preferred strategy would depend on how many uninvolved hosts are
impacted by each transmission, as well as the topology of the situation.
For example, if the hosts are clustered near the sender and the receiver is
a great distance away, the high power hop would be better since a
transmission from any of the clustered hosts powerful enough to reach the
destination will affect all the other clustered hosts anyhow.  

John Mullen

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Thursday, July 11, 2002 10:20 AM
To: 'Phil Neumiller'; manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network


Good point about asymmetry not required or desirable in an ad-hoc net, Phil.
I forgot about that. With base stations, asymmetry helps.

I have a suggestion on a transmitter power rule of thumb. If the typical
path of MANET data packets covers a large area of the MANET, then high power
is good because it reduces the number of hops required for each packet,
reducing the busyness of every host.

If the typical data path is short, mostly between adjacent hosts, then the
transmitter power is best kept low, because this permits different clusters
to transmit packets among their own hosts simultaneous to other clusters
doing the same. More aggregate throughput.

Bert


> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Thursday, July 11, 2002 12:09 PM
> To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;
> Nikhil Jain
> Subject: Re: [manet] Interference in ad hoc network
> 
> 
> MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a 
> version that
> is suitable for ad hoc networks.  The Qualcomm type (3G type) 
> has asymetric
> channel structure, i.e. the reverse and forward links are 
> structured differently at
> the phy and link layers.  This poses problems for a 
> peer-to-peer network like a
> MANET.  There is also a lot of intelligence in the IS-94A/B/C 
> (3G) BTS that
> you would not want to replicate in an inexpensive ad hoc 
> radio.  Our MAC
> is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
> all simultaneously.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 13:25:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23930
	for ; Thu, 11 Jul 2002 12:27:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20973;
	Thu, 11 Jul 2002 12:08:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20948
	for ; Thu, 11 Jul 2002 12:08:16 -0400 (EDT)
Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22885
	for ; Thu, 11 Jul 2002 12:07:21 -0400 (EDT)
Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddd37e.tkyoac00.ap.so-net.ne.jp [218.221.211.126])
	(authenticated bits=0)
	by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6BG7ffg019808;
	Fri, 12 Jul 2002 01:07:41 +0900
Date: Fri, 12 Jul 2002 00:59:10 +0900
Message-ID: 
From: Ryuji Wakikawa
To: Fredrik.Alriksson@era.ericsson.se
Cc: andersn@telecom.lth.se, manet@ietf.org, ryuji@sfc.wide.ad.jp
Subject: Re: [manet] Re: Gateway Advertisements
In-Reply-To: <1F55F6582266314A85A55F6241509B674180D4@Esealnt863.al.sw.ericsson.se>
References: <1F55F6582266314A85A55F6241509B674180D4@Esealnt863.al.sw.ericsson.se>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd)
 MULE/4.1 (AOI)
Organization: Keio University
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi again

At Thu, 11 Jul 2002 16:57:57 +0200,
Fredrik Alriksson (EAB) wrote:
> 
> 
> [Fredrik Alriksson] Then I think we agree; I originally started this
> thread since you in the draft claim that a proactive approach SHOULD
> NOT be used, but now you say that it depends and that we don't
> really know. Will that be reflected in the draft as well?

Yes, I want to consider proactive way. 
By the way, will you come IETF Yokohama in next week?


> For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
> How does the Manet node know when to re-flood the request?
> How large fraction of all relevant topology changes will the Manet node detect?
> 
> My conclusion is still: it is better to let the GW flood periodically.
> 
> Are you absolutely sure that this will be the optimal solution in all situations?
> 
> 
> [Fredrik Alriksson] No, not in all situations. Isn't that a general
> 'feature' with MANETs, no single solution will ever be optimal for
> all MANETs ;-)
> 

I agree:-)

> 
> 
> In appendix A, we explain how to use the most appropriate GW with a
> routing header. I think the draft can be adapted to your above
> situation. What do you think?
> 
> --Snip from the drat
>    Using a routing header is also preferable if there are 
> more than two
> Internet-gateways, because the node then have the ability to decide
> which Internet-gateway is the best, by distance in hops, or by some
> other priority.  By assign a priority number for each 
> Internet-gateway,
> the route reply message and the Manet Router Advertisement messages
> could be extended to support a candidate Internet-gateway 
> option in it.
> -----
> 
> 
> I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?
> 
> He describes how the gateway selection process can be implemented. 
> 
> 
> [Fredrik Alriksson] ...which is somewhat independent from how the advertisements are distributed...right?

I just wanted to explain reactive way can select closer one (if it
maybe inefficient). We have already considered hop limits to GW and
unfortunantely our solutions seems not enough...


> Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.
> 
> Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
> 
> ... needs more testing... 
> 
> 
> [Fredrik Alriksson] The reason for asking is this: assume a MANET
> with 2 GWs and 10 manet nodes using these 2 GWs for Internet
> access. What is the overhead with proactive vs. reactive? Assuming
> that the periodicity is the same: reactive: 10 floodings, proactive:
> 2 floodings.
> 

I do not know if this example is good enough, because we can get
another results depending on topology changes, measurements periods:-)

After first discovery, reactive stop flooding and start unicasting instead.
So the result will change after first discovery.
For 10 sec: reactive: 0 floodings, proactive 10 floodings.
Well this is best case for reactive, another result can be expected, of
course!

> 
> >Then I think I didn't express myself clearly enough. My point is 
> >that using a 4-hop route between Manet node and GW1 consumes more 
> >resources in the Manet as a whole than using a 2-hop route between the 
> >same Manet node and GW2. Thus being able to select the closest gateway 
> >is a concern for all nodes in the Manet, including those that do not 
> >use internet connectivity.
> But minimizing the hop count is, of course, also the purpose of our solution. The question is whether it really
> does differ in average hop, or whether it really is more costful. Flooding could be very costful for battery sensitive devices. As for choosing the closest gateway, this should always be the ambition. The node could either rerequest gateway information, or maybe we could piggyback this information somewhere, in case a "handover"is needed.
> 
> 
> [Fredrik Alriksson] The question with a reactive approach is how to
> detect that a reaction is needed. Could you please describe that
> again?

Actually, the use of multiple GW is not considered enough yet, we just
mention our rough idea in the draft.  So I don't know if I have good
answer for this.

regards,
ryuji

> BR,
> Fredrik
> 
>  
> 
> best regards,
> 
> Anders 
> 
> 
> 
> 
> 
> 
> [2  ]
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Thu Jul 11 13:45:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27548
	for ; Thu, 11 Jul 2002 13:45:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00670;
	Thu, 11 Jul 2002 13:27:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00639
	for ; Thu, 11 Jul 2002 13:27:10 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26660
	for ; Thu, 11 Jul 2002 13:26:15 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27972;
	Thu, 11 Jul 2002 10:26:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BHQbK27762;
	Thu, 11 Jul 2002 10:26:37 -0700
X-mProtect: <200207111726> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdWEobeg; Thu, 11 Jul 2002 10:26:36 PDT
Message-ID: <3D2DBFCD.4DECBE2D@iprg.nokia.com>
Date: Thu, 11 Jul 2002 10:26:37 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fredrik Alriksson (EAB)" 
CC: manet@ietf.org
Subject: Re: [manet] Re: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180D5@Esealnt863.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Fredrik,

"Fredrik Alriksson (EAB)" wrote:

> My concern is that a Manet node that is communicating via a GW
> will stick to this GW even if better GW's become available in
> the Manet. Someone commented that the Manet node can re-flood
> requests whenever they want to find better GWs; in response
> to that I wonder how the Manet node can know that there is a
> better GW available and that it thus should re-flood a request.
> The answer is of course that in many cases it cannot know.

I basically agree with your statements in this paragraph.
A mobile might use a default route even when a better route
is available.  This, however, might become true for any
destination, as you can quickly verify.  In fact, the
difference from optimal (lowest) can change from an arbitrarily
high value to even 1 without the mobile node's awareness.
These are properties across all periodic vs. reactive
approaches.  The fact that this one instance has to do
with Internet Gateways doesn't change the nature of the
basic phenomenon.

>> The best case would be for it to detect _none_ of the topology
>> changes, and yet retain routability to all of its communication
>> partners.
> 
> Even if the total traffic load, mean delay, etc. are higher?

These are the tradeoffs that have to be made.  As has been
mentioned, it's not very clearly understood about the
scenarios which favor reactive, and yet it seems that
reactive _typically_ offers advantages on total traffic
load, and disadvantages for mean delay.

> Regarding traffic patterns: I suspect that the traffic
> patterns will be quite different in an Internet connected
> Manet than in a standalone Manet (which is the most common
> scenario in previous simulation studies).

Agreed, and yet for many natural traffic patterns
I expect that a reactive approach will provide
good service.  In our approach, we suggest that
each node can be a default router, as well as a
next hop for aspecific destination.   A next-hop
node would agree to serve as a default router if
it had a a default route itself, and so on
until some node nearby the gateway had use of
the gateway as a default router.

In this scenario, the default router can easily
change direction from one gateway to another
gateway, either by route repairs, or the natural
progress of various route discovery operations.

Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 13:45:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27556
	for ; Thu, 11 Jul 2002 13:45:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA02844
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 13:46:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00670;
	Thu, 11 Jul 2002 13:27:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00639
	for ; Thu, 11 Jul 2002 13:27:10 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26660
	for ; Thu, 11 Jul 2002 13:26:15 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27972;
	Thu, 11 Jul 2002 10:26:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6BHQbK27762;
	Thu, 11 Jul 2002 10:26:37 -0700
X-mProtect: <200207111726> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdWEobeg; Thu, 11 Jul 2002 10:26:36 PDT
Message-ID: <3D2DBFCD.4DECBE2D@iprg.nokia.com>
Date: Thu, 11 Jul 2002 10:26:37 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fredrik Alriksson (EAB)" 
CC: manet@ietf.org
Subject: Re: [manet] Re: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180D5@Esealnt863.al.sw.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Fredrik,

"Fredrik Alriksson (EAB)" wrote:

> My concern is that a Manet node that is communicating via a GW
> will stick to this GW even if better GW's become available in
> the Manet. Someone commented that the Manet node can re-flood
> requests whenever they want to find better GWs; in response
> to that I wonder how the Manet node can know that there is a
> better GW available and that it thus should re-flood a request.
> The answer is of course that in many cases it cannot know.

I basically agree with your statements in this paragraph.
A mobile might use a default route even when a better route
is available.  This, however, might become true for any
destination, as you can quickly verify.  In fact, the
difference from optimal (lowest) can change from an arbitrarily
high value to even 1 without the mobile node's awareness.
These are properties across all periodic vs. reactive
approaches.  The fact that this one instance has to do
with Internet Gateways doesn't change the nature of the
basic phenomenon.

>> The best case would be for it to detect _none_ of the topology
>> changes, and yet retain routability to all of its communication
>> partners.
> 
> Even if the total traffic load, mean delay, etc. are higher?

These are the tradeoffs that have to be made.  As has been
mentioned, it's not very clearly understood about the
scenarios which favor reactive, and yet it seems that
reactive _typically_ offers advantages on total traffic
load, and disadvantages for mean delay.

> Regarding traffic patterns: I suspect that the traffic
> patterns will be quite different in an Internet connected
> Manet than in a standalone Manet (which is the most common
> scenario in previous simulation studies).

Agreed, and yet for many natural traffic patterns
I expect that a reactive approach will provide
good service.  In our approach, we suggest that
each node can be a default router, as well as a
next hop for aspecific destination.   A next-hop
node would agree to serve as a default router if
it had a a default route itself, and so on
until some node nearby the gateway had use of
the gateway as a default router.

In this scenario, the default router can easily
change direction from one gateway to another
gateway, either by route repairs, or the natural
progress of various route discovery operations.

Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 13:55:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28056
	for ; Thu, 11 Jul 2002 13:55:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02529;
	Thu, 11 Jul 2002 13:43:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02424
	for ; Thu, 11 Jul 2002 13:43:14 -0400 (EDT)
Received: from mailhost2.malibunetworks.com (malibunetworks.com [158.222.96.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27364
	for ; Thu, 11 Jul 2002 13:42:19 -0400 (EDT)
Received: by mailhost2.malibunetworks.com with Internet Mail Service (5.5.2653.19)
	id <3S0PZFD4>; Thu, 11 Jul 2002 10:48:11 -0700
Message-ID: <337F6EC31C8FD3119A10009027D63D874AD87B@mailhost2.malibunetworks.com>
From: Ken Peirce 
To: "'Phil Neumiller'" ,
        "Mullen, John P. (Contractor)" ,
        "Manfredi, Albert E" , manet@ietf.org,
        Nikhil Jain 
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 10:48:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22903.1F53EDF0"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C22903.1F53EDF0
Content-Type: text/plain;
	charset="iso-8859-1"

Phil,
Let me be indelicate and ask if this version of CDMA is encumbered by patents?
Cheers,
Ken

-----Original Message-----
From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
Sent: Thursday, July 11, 2002 9:09 AM
To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;
Nikhil Jain
Subject: Re: [manet] Interference in ad hoc network


MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a version that
is suitable for ad hoc networks.  The Qualcomm type (3G type) has asymetric
channel structure, i.e. the reverse and forward links are structured differently at
the phy and link layers.  This poses problems for a peer-to-peer network like a
MANET.  There is also a lot of intelligence in the IS-94A/B/C (3G) BTS that
you would not want to replicate in an inexpensive ad hoc radio.  Our MAC
is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
all simultaneously.

----- Original Message -----
From: "Nikhil Jain" 
To: "Mullen, John P. (Contractor)" ; "Manfredi, Albert E" ;

Sent: Thursday, July 11, 2002 10:57 AM
Subject: RE: [manet] Interference in ad hoc network


> I would recommend that we think about using CDMA. In CDMA we use a reuse of
> 1. Which means that the same channel is used in all the cells. Ofcourse the
> moving users present new issues that have to be solved.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------_=_NextPart_001_01C22903.1F53EDF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [manet] Interference in ad hoc network




Phil,

Let me be indelicate and ask if this version of CDMA =
is encumbered by patents?

Cheers,

Ken




-----Original Message-----

From: Phil Neumiller [mailto:pneumiller@meshnetwor=
ks.com]

Sent: Thursday, July 11, 2002 9:09 AM

To: Mullen, John P. (Contractor); Manfredi, Albert =
E; manet@ietf.org;

Nikhil Jain

Subject: Re: [manet] Interference in ad hoc =
network






MeshNetworks uses CDMA, but not the Qualcomm =
type.  Rather, a version that

is suitable for ad hoc networks.  The Qualcomm =
type (3G type) has asymetric

channel structure, i.e. the reverse and forward =
links are structured differently at

the phy and link layers.  This poses problems =
for a peer-to-peer network like a

MANET.  There is also a lot of intelligence in =
the IS-94A/B/C (3G) BTS that

you would not want to replicate in an inexpensive ad =
hoc radio.  Our MAC

is called QDMA.  It supports aspects of CDMA, =
TDMA, FDMA, and CSMA

all simultaneously.




----- Original Message -----

From: "Nikhil Jain" =
<njain@qualcomm.com>

To: "Mullen, John P. (Contractor)" =
<mullenjp.contractor@trac.wsmr.army.mil>; "Manfredi, Albert =
E" <albert.e.manfredi@boeing.com>;



<manet@ietf.org>

Sent: Thursday, July 11, 2002 10:57 AM

Subject: RE: [manet] Interference in ad hoc =
network






> I would recommend that we think about using =
CDMA. In CDMA we use a reuse of

> 1. Which means that the same channel is used in =
all the cells. Ofcourse the

> moving users present new issues that have to be =
solved.








_______________________________________________

manet mailing list

manet@ietf.org

https://www1.ietf.org/mailman/listinfo/manet





------_=_NextPart_001_01C22903.1F53EDF0--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 13:55:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28063
	for ; Thu, 11 Jul 2002 13:55:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA03993
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 13:56:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02529;
	Thu, 11 Jul 2002 13:43:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02424
	for ; Thu, 11 Jul 2002 13:43:14 -0400 (EDT)
Received: from mailhost2.malibunetworks.com (malibunetworks.com [158.222.96.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27364
	for ; Thu, 11 Jul 2002 13:42:19 -0400 (EDT)
Received: by mailhost2.malibunetworks.com with Internet Mail Service (5.5.2653.19)
	id <3S0PZFD4>; Thu, 11 Jul 2002 10:48:11 -0700
Message-ID: <337F6EC31C8FD3119A10009027D63D874AD87B@mailhost2.malibunetworks.com>
From: Ken Peirce 
To: "'Phil Neumiller'" ,
        "Mullen, John P. (Contractor)" ,
        "Manfredi, Albert E" , manet@ietf.org,
        Nikhil Jain 
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 10:48:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22903.1F53EDF0"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C22903.1F53EDF0
Content-Type: text/plain;
	charset="iso-8859-1"

Phil,
Let me be indelicate and ask if this version of CDMA is encumbered by patents?
Cheers,
Ken

-----Original Message-----
From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
Sent: Thursday, July 11, 2002 9:09 AM
To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;
Nikhil Jain
Subject: Re: [manet] Interference in ad hoc network


MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a version that
is suitable for ad hoc networks.  The Qualcomm type (3G type) has asymetric
channel structure, i.e. the reverse and forward links are structured differently at
the phy and link layers.  This poses problems for a peer-to-peer network like a
MANET.  There is also a lot of intelligence in the IS-94A/B/C (3G) BTS that
you would not want to replicate in an inexpensive ad hoc radio.  Our MAC
is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA
all simultaneously.

----- Original Message -----
From: "Nikhil Jain" 
To: "Mullen, John P. (Contractor)" ; "Manfredi, Albert E" ;

Sent: Thursday, July 11, 2002 10:57 AM
Subject: RE: [manet] Interference in ad hoc network


> I would recommend that we think about using CDMA. In CDMA we use a reuse of
> 1. Which means that the same channel is used in all the cells. Ofcourse the
> moving users present new issues that have to be solved.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

------_=_NextPart_001_01C22903.1F53EDF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [manet] Interference in ad hoc network




Phil,

Let me be indelicate and ask if this version of CDMA =
is encumbered by patents?

Cheers,

Ken




-----Original Message-----

From: Phil Neumiller [mailto:pneumiller@meshnetwor=
ks.com]

Sent: Thursday, July 11, 2002 9:09 AM

To: Mullen, John P. (Contractor); Manfredi, Albert =
E; manet@ietf.org;

Nikhil Jain

Subject: Re: [manet] Interference in ad hoc =
network






MeshNetworks uses CDMA, but not the Qualcomm =
type.  Rather, a version that

is suitable for ad hoc networks.  The Qualcomm =
type (3G type) has asymetric

channel structure, i.e. the reverse and forward =
links are structured differently at

the phy and link layers.  This poses problems =
for a peer-to-peer network like a

MANET.  There is also a lot of intelligence in =
the IS-94A/B/C (3G) BTS that

you would not want to replicate in an inexpensive ad =
hoc radio.  Our MAC

is called QDMA.  It supports aspects of CDMA, =
TDMA, FDMA, and CSMA

all simultaneously.




----- Original Message -----

From: "Nikhil Jain" =
<njain@qualcomm.com>

To: "Mullen, John P. (Contractor)" =
<mullenjp.contractor@trac.wsmr.army.mil>; "Manfredi, Albert =
E" <albert.e.manfredi@boeing.com>;



<manet@ietf.org>

Sent: Thursday, July 11, 2002 10:57 AM

Subject: RE: [manet] Interference in ad hoc =
network






> I would recommend that we think about using =
CDMA. In CDMA we use a reuse of

> 1. Which means that the same channel is used in =
all the cells. Ofcourse the

> moving users present new issues that have to be =
solved.








_______________________________________________

manet mailing list

manet@ietf.org

https://www1.ietf.org/mailman/listinfo/manet





------_=_NextPart_001_01C22903.1F53EDF0--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 13:57:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28205
	for ; Thu, 11 Jul 2002 13:57:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02941;
	Thu, 11 Jul 2002 13:47:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02905
	for ; Thu, 11 Jul 2002 13:47:14 -0400 (EDT)
Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27620
	for ; Thu, 11 Jul 2002 13:46:19 -0400 (EDT)
Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205])
	by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g6BHlCkO024583;
	Thu, 11 Jul 2002 13:47:12 -0400
Message-Id: <200207111747.g6BHlCkO024583@cs.dartmouth.edu>
Content-Type: text/plain;
  charset="koi8-r"
From: Yougu Yuan 
Reply-To: yuanyg@cs.dartmouth.edu
Organization: Dept. of Computer Science, Dartmouth College
To: manet@ietf.org
Date: Thu, 11 Jul 2002 13:47:06 -0400
X-Mailer: KMail [version 1.3.2]
Cc: jasonliu@cs.dartmouth.edu
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [manet] MAC sequence number
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi, all. Maybe it is a little bit off topic to send this question to manet, 
but I have a question about the MAC802.11 packet sequence number.

In the MAC802.11 header, there is a sequence number. In ad-hoc network, when 
two nodes meet, how do the negotiate the sequence number pair? Is there a 
special bit in the header that says "reset the sequence number of me to the 
sequence number in this packet"? I'm reading the 802.11 standard, but it's 
too thick for a quick answer.

Thanks in advance.

-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
Dept. of Computer Science, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 13:57:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28210
	for ; Thu, 11 Jul 2002 13:57:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA04280
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 13:58:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02941;
	Thu, 11 Jul 2002 13:47:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02905
	for ; Thu, 11 Jul 2002 13:47:14 -0400 (EDT)
Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27620
	for ; Thu, 11 Jul 2002 13:46:19 -0400 (EDT)
Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205])
	by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g6BHlCkO024583;
	Thu, 11 Jul 2002 13:47:12 -0400
Message-Id: <200207111747.g6BHlCkO024583@cs.dartmouth.edu>
Content-Type: text/plain;
  charset="koi8-r"
From: Yougu Yuan 
Reply-To: yuanyg@cs.dartmouth.edu
Organization: Dept. of Computer Science, Dartmouth College
To: manet@ietf.org
Date: Thu, 11 Jul 2002 13:47:06 -0400
X-Mailer: KMail [version 1.3.2]
Cc: jasonliu@cs.dartmouth.edu
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [manet] MAC sequence number
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi, all. Maybe it is a little bit off topic to send this question to manet, 
but I have a question about the MAC802.11 packet sequence number.

In the MAC802.11 header, there is a sequence number. In ad-hoc network, when 
two nodes meet, how do the negotiate the sequence number pair? Is there a 
special bit in the header that says "reset the sequence number of me to the 
sequence number in this packet"? I'm reading the 802.11 standard, but it's 
too thick for a quick answer.

Thanks in advance.

-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
Dept. of Computer Science, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 14:31:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29995
	for ; Thu, 11 Jul 2002 14:31:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06261;
	Thu, 11 Jul 2002 14:09:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06230
	for ; Thu, 11 Jul 2002 14:09:56 -0400 (EDT)
Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28911
	for ; Thu, 11 Jul 2002 14:09:02 -0400 (EDT)
Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205])
	by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g6BI9rkO025145;
	Thu, 11 Jul 2002 14:09:53 -0400
Message-Id: <200207111809.g6BI9rkO025145@cs.dartmouth.edu>
Content-Type: text/plain;
  charset="koi8-r"
From: Yougu Yuan 
Reply-To: yuanyg@cs.dartmouth.edu
Organization: Dept. of Computer Science, Dartmouth College
To: manet@ietf.org
Date: Thu, 11 Jul 2002 14:09:47 -0400
X-Mailer: KMail [version 1.3.2]
Cc: jasonliu@cs.dartmouth.edu
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [manet] Re: MAC sequence number
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

I think I should make my question more clear. I read some part of the 
standard. It didn't say clearly that there is anything like handshaking. 

If two nodes, A and B, just meet, they can set the sequence numbers from 
their first exchanged packets, that's ok. But if after a while, A reboots, 
coming back with a clean cache, while B still keeps the old sequence number 
cache, there is a clear mismatch that will cause them to drop packets from 
each other unless they can settle down on a new sequnce number. I'm wondering 
how this is done. Does it depends on a timer of the sequence number cache? Or 
some field in the MAC header?


On Thursday 11 July 2002 13:47, Yougu Yuan wrote:
> Hi, all. Maybe it is a little bit off topic to send this question to manet,
> but I have a question about the MAC802.11 packet sequence number.
>
> In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> when two nodes meet, how do the negotiate the sequence number pair? Is
> there a special bit in the header that says "reset the sequence number of
> me to the sequence number in this packet"? I'm reading the 802.11 standard,
> but it's too thick for a quick answer.
>
> Thanks in advance.

-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
Dept. of Computer Science, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 14:31:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00021
	for ; Thu, 11 Jul 2002 14:31:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA08496
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 14:31:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06261;
	Thu, 11 Jul 2002 14:09:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06230
	for ; Thu, 11 Jul 2002 14:09:56 -0400 (EDT)
Received: from cs.dartmouth.edu (cs.dartmouth.edu [129.170.212.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28911
	for ; Thu, 11 Jul 2002 14:09:02 -0400 (EDT)
Received: from there (dhcp105.ISTS.dartmouth.edu [129.170.249.205])
	by cs.dartmouth.edu (8.12.1/8.11.4) with SMTP id g6BI9rkO025145;
	Thu, 11 Jul 2002 14:09:53 -0400
Message-Id: <200207111809.g6BI9rkO025145@cs.dartmouth.edu>
Content-Type: text/plain;
  charset="koi8-r"
From: Yougu Yuan 
Reply-To: yuanyg@cs.dartmouth.edu
Organization: Dept. of Computer Science, Dartmouth College
To: manet@ietf.org
Date: Thu, 11 Jul 2002 14:09:47 -0400
X-Mailer: KMail [version 1.3.2]
Cc: jasonliu@cs.dartmouth.edu
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [manet] Re: MAC sequence number
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

I think I should make my question more clear. I read some part of the 
standard. It didn't say clearly that there is anything like handshaking. 

If two nodes, A and B, just meet, they can set the sequence numbers from 
their first exchanged packets, that's ok. But if after a while, A reboots, 
coming back with a clean cache, while B still keeps the old sequence number 
cache, there is a clear mismatch that will cause them to drop packets from 
each other unless they can settle down on a new sequnce number. I'm wondering 
how this is done. Does it depends on a timer of the sequence number cache? Or 
some field in the MAC header?


On Thursday 11 July 2002 13:47, Yougu Yuan wrote:
> Hi, all. Maybe it is a little bit off topic to send this question to manet,
> but I have a question about the MAC802.11 packet sequence number.
>
> In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> when two nodes meet, how do the negotiate the sequence number pair? Is
> there a special bit in the header that says "reset the sequence number of
> me to the sequence number in this packet"? I'm reading the 802.11 standard,
> but it's too thick for a quick answer.
>
> Thanks in advance.

-- 
Yougu Yuan

----------------------------------------------------
Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
Dept. of Computer Science, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 15:11:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01558
	for ; Thu, 11 Jul 2002 15:11:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09025;
	Thu, 11 Jul 2002 14:43:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09000
	for ; Thu, 11 Jul 2002 14:43:46 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00552
	for ; Thu, 11 Jul 2002 14:42:52 -0400 (EDT)
Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 3RD9K63G; Thu, 11 Jul 2002 14:43:44 -0400
Message-ID: <001d01c2290a$e2432c20$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Ken Peirce" ,
        "Mullen, John P. \(Contractor\)" ,
        "Manfredi, Albert E" , ,
        "Nikhil Jain" 
References: <337F6EC31C8FD3119A10009027D63D874AD87B@mailhost2.malibunetworks.com>
Subject: Re: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 14:43:44 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001A_01C228E9.5B25A540"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C228E9.5B25A540
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [manet] Interference in ad hoc networkYes and No.  It depends on =
what somebody wants to do.  We do have IPR that was assigned to
us by one of our parent companies, ITT industries (no secrets here), =
dealing specifically with CDMA
for ad hoc networks.  But our system works over a variety of air =
interfaces and the licensing
agreements vary.

  ----- Original Message -----=20
  From: Ken Peirce=20
  To: 'Phil Neumiller' ; Mullen, John P. (Contractor) ; Manfredi, Albert =
E ; manet@ietf.org ; Nikhil Jain=20
  Sent: Thursday, July 11, 2002 1:48 PM
  Subject: RE: [manet] Interference in ad hoc network


  Phil,=20
  Let me be indelicate and ask if this version of CDMA is encumbered by =
patents?=20
  Cheers,=20
  Ken=20

  -----Original Message-----=20
  From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]=20
  Sent: Thursday, July 11, 2002 9:09 AM=20
  To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;=20
  Nikhil Jain=20
  Subject: Re: [manet] Interference in ad hoc network=20



  MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a version =
that=20
  is suitable for ad hoc networks.  The Qualcomm type (3G type) has =
asymetric=20
  channel structure, i.e. the reverse and forward links are structured =
differently at=20
  the phy and link layers.  This poses problems for a peer-to-peer =
network like a=20
  MANET.  There is also a lot of intelligence in the IS-94A/B/C (3G) BTS =
that=20
  you would not want to replicate in an inexpensive ad hoc radio.  Our =
MAC=20
  is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA=20
  all simultaneously.=20

  ----- Original Message -----=20
  From: "Nikhil Jain" =20
  To: "Mullen, John P. (Contractor)" =
; "Manfredi, Albert E" =
;

  =20
  Sent: Thursday, July 11, 2002 10:57 AM=20
  Subject: RE: [manet] Interference in ad hoc network=20



  > I would recommend that we think about using CDMA. In CDMA we use a =
reuse of=20
  > 1. Which means that the same channel is used in all the cells. =
Ofcourse the=20
  > moving users present new issues that have to be solved.=20




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


------=_NextPart_000_001A_01C228E9.5B25A540
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: [manet] Interference in ad hoc network






Yes and No.  It depends on what =
somebody wants=20
to do.  We do have IPR that was assigned to


us by one of our parent companies, ITT =
industries=20
(no secrets here), dealing specifically with CDMA


for ad hoc networks.  But our =
system works=20
over a variety of air interfaces and =
the=20
licensing


agreements vary.


 



  
----- Original Message ----- 

  From:=20
  Ken=20
  Peirce 
  
To: 'Phil Neumiller' ; Mullen, John P. =

  (Contractor) ; Manfredi, Albert E ; =
manet@ietf.org ; Nikhil =
Jain=20
  

  
Sent: Thursday, July 11, 2002 =
1:48=20
  PM

  
Subject: RE: [manet] =
Interference in ad=20
  hoc network

  


  
Phil, 
Let me be indelicate =
and ask if=20
  this version of CDMA is encumbered by patents? 
Cheers, 
Ken 

  
-----Original Message----- 
From: Phil=20
  Neumiller [mailto:pneumiller@meshnetwork=
s.com]=20
  
Sent: Thursday, July 11, 2002 9:09 AM =

To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org; 
Nikhil Jain 
Subject: Re: [manet] =
Interference=20
  in ad hoc network 


  
MeshNetworks uses CDMA, but not the Qualcomm =
type. =20
  Rather, a version that 
is suitable for ad =
hoc=20
  networks.  The Qualcomm type (3G type) has asymetric =

channel structure, i.e. the reverse and forward links are =
structured=20
  differently at 
the phy and link =
layers.  This=20
  poses problems for a peer-to-peer network like a 
MANET.  There is also a lot of intelligence in the =
IS-94A/B/C (3G)=20
  BTS that 
you would not want to replicate in =
an=20
  inexpensive ad hoc radio.  Our MAC 
is =
called=20
  QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA =

all simultaneously. 

  
----- Original Message ----- 
From:=20
  "Nikhil Jain" <njain@qualcomm.com> 
To: =
"Mullen,=20
  John P. (Contractor)" <mullenjp.contractor@trac.wsmr.army.mil>;=20
  "Manfredi, Albert E" <albert.e.manfredi@boeing.com>;

  
<manet@ietf.org> 
Sent: Thursday,=20
  July 11, 2002 10:57 AM 
Subject: RE: [manet]=20
  Interference in ad hoc network 


  
> I would recommend that we think about using =
CDMA. In CDMA=20
  we use a reuse of 
> 1. Which means that =
the same=20
  channel is used in all the cells. Ofcourse the 
>=20
  moving users present new issues that have to be solved. =




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



------=_NextPart_000_001A_01C228E9.5B25A540--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 15:11:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01568
	for ; Thu, 11 Jul 2002 15:11:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10670
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 15:12:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09025;
	Thu, 11 Jul 2002 14:43:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09000
	for ; Thu, 11 Jul 2002 14:43:46 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00552
	for ; Thu, 11 Jul 2002 14:42:52 -0400 (EDT)
Received: from neumillersimul (neumiller-simul.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 3RD9K63G; Thu, 11 Jul 2002 14:43:44 -0400
Message-ID: <001d01c2290a$e2432c20$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Ken Peirce" ,
        "Mullen, John P. \(Contractor\)" ,
        "Manfredi, Albert E" , ,
        "Nikhil Jain" 
References: <337F6EC31C8FD3119A10009027D63D874AD87B@mailhost2.malibunetworks.com>
Subject: Re: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 14:43:44 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001A_01C228E9.5B25A540"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C228E9.5B25A540
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [manet] Interference in ad hoc networkYes and No.  It depends on =
what somebody wants to do.  We do have IPR that was assigned to
us by one of our parent companies, ITT industries (no secrets here), =
dealing specifically with CDMA
for ad hoc networks.  But our system works over a variety of air =
interfaces and the licensing
agreements vary.

  ----- Original Message -----=20
  From: Ken Peirce=20
  To: 'Phil Neumiller' ; Mullen, John P. (Contractor) ; Manfredi, Albert =
E ; manet@ietf.org ; Nikhil Jain=20
  Sent: Thursday, July 11, 2002 1:48 PM
  Subject: RE: [manet] Interference in ad hoc network


  Phil,=20
  Let me be indelicate and ask if this version of CDMA is encumbered by =
patents?=20
  Cheers,=20
  Ken=20

  -----Original Message-----=20
  From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]=20
  Sent: Thursday, July 11, 2002 9:09 AM=20
  To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org;=20
  Nikhil Jain=20
  Subject: Re: [manet] Interference in ad hoc network=20



  MeshNetworks uses CDMA, but not the Qualcomm type.  Rather, a version =
that=20
  is suitable for ad hoc networks.  The Qualcomm type (3G type) has =
asymetric=20
  channel structure, i.e. the reverse and forward links are structured =
differently at=20
  the phy and link layers.  This poses problems for a peer-to-peer =
network like a=20
  MANET.  There is also a lot of intelligence in the IS-94A/B/C (3G) BTS =
that=20
  you would not want to replicate in an inexpensive ad hoc radio.  Our =
MAC=20
  is called QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA=20
  all simultaneously.=20

  ----- Original Message -----=20
  From: "Nikhil Jain" =20
  To: "Mullen, John P. (Contractor)" =
; "Manfredi, Albert E" =
;

  =20
  Sent: Thursday, July 11, 2002 10:57 AM=20
  Subject: RE: [manet] Interference in ad hoc network=20



  > I would recommend that we think about using CDMA. In CDMA we use a =
reuse of=20
  > 1. Which means that the same channel is used in all the cells. =
Ofcourse the=20
  > moving users present new issues that have to be solved.=20




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


------=_NextPart_000_001A_01C228E9.5B25A540
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: [manet] Interference in ad hoc network






Yes and No.  It depends on what =
somebody wants=20
to do.  We do have IPR that was assigned to


us by one of our parent companies, ITT =
industries=20
(no secrets here), dealing specifically with CDMA


for ad hoc networks.  But our =
system works=20
over a variety of air interfaces and =
the=20
licensing


agreements vary.


 



  
----- Original Message ----- 

  From:=20
  Ken=20
  Peirce 
  
To: 'Phil Neumiller' ; Mullen, John P. =

  (Contractor) ; Manfredi, Albert E ; =
manet@ietf.org ; Nikhil =
Jain=20
  

  
Sent: Thursday, July 11, 2002 =
1:48=20
  PM

  
Subject: RE: [manet] =
Interference in ad=20
  hoc network

  


  
Phil, 
Let me be indelicate =
and ask if=20
  this version of CDMA is encumbered by patents? 
Cheers, 
Ken 

  
-----Original Message----- 
From: Phil=20
  Neumiller [mailto:pneumiller@meshnetwork=
s.com]=20
  
Sent: Thursday, July 11, 2002 9:09 AM =

To: Mullen, John P. (Contractor); Manfredi, Albert E; manet@ietf.org; 
Nikhil Jain 
Subject: Re: [manet] =
Interference=20
  in ad hoc network 


  
MeshNetworks uses CDMA, but not the Qualcomm =
type. =20
  Rather, a version that 
is suitable for ad =
hoc=20
  networks.  The Qualcomm type (3G type) has asymetric =

channel structure, i.e. the reverse and forward links are =
structured=20
  differently at 
the phy and link =
layers.  This=20
  poses problems for a peer-to-peer network like a 
MANET.  There is also a lot of intelligence in the =
IS-94A/B/C (3G)=20
  BTS that 
you would not want to replicate in =
an=20
  inexpensive ad hoc radio.  Our MAC 
is =
called=20
  QDMA.  It supports aspects of CDMA, TDMA, FDMA, and CSMA =

all simultaneously. 

  
----- Original Message ----- 
From:=20
  "Nikhil Jain" <njain@qualcomm.com> 
To: =
"Mullen,=20
  John P. (Contractor)" <mullenjp.contractor@trac.wsmr.army.mil>;=20
  "Manfredi, Albert E" <albert.e.manfredi@boeing.com>;

  
<manet@ietf.org> 
Sent: Thursday,=20
  July 11, 2002 10:57 AM 
Subject: RE: [manet]=20
  Interference in ad hoc network 


  
> I would recommend that we think about using =
CDMA. In CDMA=20
  we use a reuse of 
> 1. Which means that =
the same=20
  channel is used in all the cells. Ofcourse the 
>=20
  moving users present new issues that have to be solved. =




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



------=_NextPart_000_001A_01C228E9.5B25A540--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 17:54:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08271
	for ; Thu, 11 Jul 2002 17:54:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18128;
	Thu, 11 Jul 2002 17:26:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18096
	for ; Thu, 11 Jul 2002 17:25:59 -0400 (EDT)
Received: from dagger.nd.edu (dagger.nd.edu [129.74.250.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06872
	for ; Thu, 11 Jul 2002 17:25:04 -0400 (EDT)
Received: from mshield (shield2.cc.nd.edu [129.74.250.49])
	by dagger.nd.edu (8.12.2/8.12.2) with SMTP id g6BLPvcw018881
	for ; Thu, 11 Jul 2002 16:25:57 -0500 (EST)
Received: FROM nd.edu BY mshield ; Thu Jul 11 16:18:47 2002 -0500
Message-ID: <3D2DF903.8010303@nd.edu>
Date: Thu, 11 Jul 2002 16:30:43 -0500
From: Martin Haenggi 
Organization: University of Notre Dame
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Manfredi, Albert E" 
CC: manet@ietf.org
Subject: Re: [manet] Interference in ad hoc network
References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A03@xch-ne-02.ne.nos.boeing.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Bert,

Manfredi, Albert E wrote:

> Within a single MANET, the nodes need to contend for channel access,

> and perhaps even reduce their transmitter power level (this was discussed recently)

> so as not to interfere with each other. 


One comment on that: if all nodes use the same power level, then the
effect of the interference is completely independent of that power level,
since the signal-to-interference ratio remains constant.
So, a (global) reduction of the power level does not help alleviate the
interference problem.

Regards,
Martin


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 17:54:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08279
	for ; Thu, 11 Jul 2002 17:54:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20673
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 17:55:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18128;
	Thu, 11 Jul 2002 17:26:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18096
	for ; Thu, 11 Jul 2002 17:25:59 -0400 (EDT)
Received: from dagger.nd.edu (dagger.nd.edu [129.74.250.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06872
	for ; Thu, 11 Jul 2002 17:25:04 -0400 (EDT)
Received: from mshield (shield2.cc.nd.edu [129.74.250.49])
	by dagger.nd.edu (8.12.2/8.12.2) with SMTP id g6BLPvcw018881
	for ; Thu, 11 Jul 2002 16:25:57 -0500 (EST)
Received: FROM nd.edu BY mshield ; Thu Jul 11 16:18:47 2002 -0500
Message-ID: <3D2DF903.8010303@nd.edu>
Date: Thu, 11 Jul 2002 16:30:43 -0500
From: Martin Haenggi 
Organization: University of Notre Dame
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Manfredi, Albert E" 
CC: manet@ietf.org
Subject: Re: [manet] Interference in ad hoc network
References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A03@xch-ne-02.ne.nos.boeing.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Bert,

Manfredi, Albert E wrote:

> Within a single MANET, the nodes need to contend for channel access,

> and perhaps even reduce their transmitter power level (this was discussed recently)

> so as not to interfere with each other. 


One comment on that: if all nodes use the same power level, then the
effect of the interference is completely independent of that power level,
since the signal-to-interference ratio remains constant.
So, a (global) reduction of the power level does not help alleviate the
interference problem.

Regards,
Martin


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 18:06:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08807
	for ; Thu, 11 Jul 2002 18:06:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19916;
	Thu, 11 Jul 2002 17:47:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19887
	for ; Thu, 11 Jul 2002 17:47:07 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07798
	for ; Thu, 11 Jul 2002 17:46:11 -0400 (EDT)
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA25718;
	Thu, 11 Jul 2002 14:47:04 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA16186;
	Thu, 11 Jul 2002 14:46:52 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BLl2602149;
	Thu, 11 Jul 2002 14:47:02 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 17:47:01 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A13@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Martin Haenggi'" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 17:46:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Martin Haenggi wrote:

> > Within a single MANET, the nodes need to contend for channel access,
> 
> > and perhaps even reduce their transmitter power level (this 
> was discussed recently)
> 
> > so as not to interfere with each other. 
> 
> 
> One comment on that: if all nodes use the same power level, then the
> effect of the interference is completely independent of that 
> power level,
> since the signal-to-interference ratio remains constant.
> So, a (global) reduction of the power level does not help 
> alleviate the
> interference problem.

Hi Martin,

Hmmm. If the distance between hosts remains the same, receiver sensitivity remains the same, and the power level is reduced for all hosts in the MANET, then each host will detect fewer neighbors. This causes whatever routing algorithm is being used to have to create more hops between any random A and B host in the MANET, on average.

I guess I'm saying that the ratio that matters here is S/(N+I), not just S/I?

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 18:07:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08839
	for ; Thu, 11 Jul 2002 18:07:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA21707
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 18:07:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19916;
	Thu, 11 Jul 2002 17:47:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19887
	for ; Thu, 11 Jul 2002 17:47:07 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07798
	for ; Thu, 11 Jul 2002 17:46:11 -0400 (EDT)
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA25718;
	Thu, 11 Jul 2002 14:47:04 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA16186;
	Thu, 11 Jul 2002 14:46:52 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BLl2602149;
	Thu, 11 Jul 2002 14:47:02 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 17:47:01 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A13@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Martin Haenggi'" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 17:46:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Martin Haenggi wrote:

> > Within a single MANET, the nodes need to contend for channel access,
> 
> > and perhaps even reduce their transmitter power level (this 
> was discussed recently)
> 
> > so as not to interfere with each other. 
> 
> 
> One comment on that: if all nodes use the same power level, then the
> effect of the interference is completely independent of that 
> power level,
> since the signal-to-interference ratio remains constant.
> So, a (global) reduction of the power level does not help 
> alleviate the
> interference problem.

Hi Martin,

Hmmm. If the distance between hosts remains the same, receiver sensitivity remains the same, and the power level is reduced for all hosts in the MANET, then each host will detect fewer neighbors. This causes whatever routing algorithm is being used to have to create more hops between any random A and B host in the MANET, on average.

I guess I'm saying that the ratio that matters here is S/(N+I), not just S/I?

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 18:43:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10791
	for ; Thu, 11 Jul 2002 18:43:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22288;
	Thu, 11 Jul 2002 18:23:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22248
	for ; Thu, 11 Jul 2002 18:23:05 -0400 (EDT)
Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09599
	for ; Thu, 11 Jul 2002 18:22:10 -0400 (EDT)
Received: from D7KQ4P01 ("port 3803"@maxwell-6.ece.usu.edu [129.123.85.141])
 by cc.usu.edu (PMDF V5.2-32 #39089)
 with SMTP id <01KJZ3W1PRCOADCEJ9@cc.usu.edu> for manet@ietf.org; Thu,
 11 Jul 2002 16:22:50 MST
Date: Thu, 11 Jul 2002 16:26:53 -0600
From: Sumeeth Nagaraj 
Subject: Re: [manet] Interference in ad hoc network
To: Martin Haenggi ,
        "Manfredi, Albert E" 
Cc: manet@ietf.org
Message-id: <010401c2292a$0ef815e0$8d557b81@D7KQ4P01>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: 
 <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A03@xch-ne-02.ne.nos.boeing.com>
 <3D2DF903.8010303@nd.edu>
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Martin



> Hi Bert,
>
> Manfredi, Albert E wrote:
>
> > Within a single MANET, the nodes need to contend for channel access,
>
> > and perhaps even reduce their transmitter power level (this was
discussed recently)
>
> > so as not to interfere with each other.
>
>
> One comment on that: if all nodes use the same power level, then the
> effect of the interference is completely independent of that power level,
> since the signal-to-interference ratio remains constant.
> So, a (global) reduction of the power level does not help alleviate the
> interference problem.

you are right but I I think it was in the context of  less number of nodes
hearing the signal and thereby less interference from other nodes while
contending for a channel. on the other hand if a large number of nodes are
able to hear the signal then comes the problem of interference while all the
nodes contend to access the channel.

Regards,
Sumeeth


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 18:43:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10799
	for ; Thu, 11 Jul 2002 18:43:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA24133
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 18:44:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22288;
	Thu, 11 Jul 2002 18:23:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22248
	for ; Thu, 11 Jul 2002 18:23:05 -0400 (EDT)
Received: from grumpy.usu.edu (grumpy.usu.edu [129.123.1.86])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09599
	for ; Thu, 11 Jul 2002 18:22:10 -0400 (EDT)
Received: from D7KQ4P01 ("port 3803"@maxwell-6.ece.usu.edu [129.123.85.141])
 by cc.usu.edu (PMDF V5.2-32 #39089)
 with SMTP id <01KJZ3W1PRCOADCEJ9@cc.usu.edu> for manet@ietf.org; Thu,
 11 Jul 2002 16:22:50 MST
Date: Thu, 11 Jul 2002 16:26:53 -0600
From: Sumeeth Nagaraj 
Subject: Re: [manet] Interference in ad hoc network
To: Martin Haenggi ,
        "Manfredi, Albert E" 
Cc: manet@ietf.org
Message-id: <010401c2292a$0ef815e0$8d557b81@D7KQ4P01>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: 
 <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A03@xch-ne-02.ne.nos.boeing.com>
 <3D2DF903.8010303@nd.edu>
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Martin



> Hi Bert,
>
> Manfredi, Albert E wrote:
>
> > Within a single MANET, the nodes need to contend for channel access,
>
> > and perhaps even reduce their transmitter power level (this was
discussed recently)
>
> > so as not to interfere with each other.
>
>
> One comment on that: if all nodes use the same power level, then the
> effect of the interference is completely independent of that power level,
> since the signal-to-interference ratio remains constant.
> So, a (global) reduction of the power level does not help alleviate the
> interference problem.

you are right but I I think it was in the context of  less number of nodes
hearing the signal and thereby less interference from other nodes while
contending for a channel. on the other hand if a large number of nodes are
able to hear the signal then comes the problem of interference while all the
nodes contend to access the channel.

Regards,
Sumeeth


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 18:59:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11638
	for ; Thu, 11 Jul 2002 18:59:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22255;
	Thu, 11 Jul 2002 18:23:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22209
	for ; Thu, 11 Jul 2002 18:23:00 -0400 (EDT)
Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09596
	for ; Thu, 11 Jul 2002 18:22:04 -0400 (EDT)
Received: from mirage (Miracle.CS.UCLA.EDU [131.179.136.76])
	by cheetah.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with SMTP id g6BMLj215413;
	Thu, 11 Jul 2002 15:21:45 -0700 (PDT)
Message-ID: <01bc01c22929$cb394040$4c88b383@mirage>
From: "Kaixin Xu" 
To: "Manfredi, Albert E" ,
        "'Martin Haenggi'" 
Cc: 
References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A13@xch-ne-02.ne.nos.boeing.com>
Subject: Re: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 15:24:59 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Just want to say a complement point. I remember that Prof. Kumar at UIUC has
one paper saying that reducing the transmission power will reduce the
interference among nodes. However, to maintain the connectivity, there is a
minimal power level. Thus, from my point of view, reducing transmission
power is equivalent to reducing the node density. So I agree with Haenggi
that global reduction of the power level cannot help reducing interference.
It's just a optimization between the node density and transmission range.
What really matter are how fast the signal decays and the
transmitter-receiver distance. An interesting thing I have found is that
interference range is usually 1.7 times the transmitter-receiver distance.
Large interference range is harmful since RTS-CTS can only handle
interference nodes within transmission range.

Kaixin

----- Original Message -----
From: "Manfredi, Albert E" 
To: "'Martin Haenggi'" 
Cc: 
Sent: Thursday, July 11, 2002 2:46 PM
Subject: RE: [manet] Interference in ad hoc network


> Martin Haenggi wrote:
>
> > > Within a single MANET, the nodes need to contend for channel access,
> >
> > > and perhaps even reduce their transmitter power level (this
> > was discussed recently)
> >
> > > so as not to interfere with each other.
> >
> >
> > One comment on that: if all nodes use the same power level, then the
> > effect of the interference is completely independent of that
> > power level,
> > since the signal-to-interference ratio remains constant.
> > So, a (global) reduction of the power level does not help
> > alleviate the
> > interference problem.
>
> Hi Martin,
>
> Hmmm. If the distance between hosts remains the same, receiver sensitivity
remains the same, and the power level is reduced for all hosts in the MANET,
then each host will detect fewer neighbors. This causes whatever routing
algorithm is being used to have to create more hops between any random A and
B host in the MANET, on average.
>
> I guess I'm saying that the ratio that matters here is S/(N+I), not just
S/I?
>
> Bert
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 18:59:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11646
	for ; Thu, 11 Jul 2002 18:59:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA25088
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 18:59:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22255;
	Thu, 11 Jul 2002 18:23:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22209
	for ; Thu, 11 Jul 2002 18:23:00 -0400 (EDT)
Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09596
	for ; Thu, 11 Jul 2002 18:22:04 -0400 (EDT)
Received: from mirage (Miracle.CS.UCLA.EDU [131.179.136.76])
	by cheetah.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with SMTP id g6BMLj215413;
	Thu, 11 Jul 2002 15:21:45 -0700 (PDT)
Message-ID: <01bc01c22929$cb394040$4c88b383@mirage>
From: "Kaixin Xu" 
To: "Manfredi, Albert E" ,
        "'Martin Haenggi'" 
Cc: 
References: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A13@xch-ne-02.ne.nos.boeing.com>
Subject: Re: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 15:24:59 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Just want to say a complement point. I remember that Prof. Kumar at UIUC has
one paper saying that reducing the transmission power will reduce the
interference among nodes. However, to maintain the connectivity, there is a
minimal power level. Thus, from my point of view, reducing transmission
power is equivalent to reducing the node density. So I agree with Haenggi
that global reduction of the power level cannot help reducing interference.
It's just a optimization between the node density and transmission range.
What really matter are how fast the signal decays and the
transmitter-receiver distance. An interesting thing I have found is that
interference range is usually 1.7 times the transmitter-receiver distance.
Large interference range is harmful since RTS-CTS can only handle
interference nodes within transmission range.

Kaixin

----- Original Message -----
From: "Manfredi, Albert E" 
To: "'Martin Haenggi'" 
Cc: 
Sent: Thursday, July 11, 2002 2:46 PM
Subject: RE: [manet] Interference in ad hoc network


> Martin Haenggi wrote:
>
> > > Within a single MANET, the nodes need to contend for channel access,
> >
> > > and perhaps even reduce their transmitter power level (this
> > was discussed recently)
> >
> > > so as not to interfere with each other.
> >
> >
> > One comment on that: if all nodes use the same power level, then the
> > effect of the interference is completely independent of that
> > power level,
> > since the signal-to-interference ratio remains constant.
> > So, a (global) reduction of the power level does not help
> > alleviate the
> > interference problem.
>
> Hi Martin,
>
> Hmmm. If the distance between hosts remains the same, receiver sensitivity
remains the same, and the power level is reduced for all hosts in the MANET,
then each host will detect fewer neighbors. This causes whatever routing
algorithm is being used to have to create more hops between any random A and
B host in the MANET, on average.
>
> I guess I'm saying that the ratio that matters here is S/(N+I), not just
S/I?
>
> Bert
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 19:14:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12519
	for ; Thu, 11 Jul 2002 19:14:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23919;
	Thu, 11 Jul 2002 18:40:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23890
	for ; Thu, 11 Jul 2002 18:40:33 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10557
	for ; Thu, 11 Jul 2002 18:39:37 -0400 (EDT)
Received: from stl-av-02.boeing.com ([192.76.190.7])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA21349;
	Thu, 11 Jul 2002 17:40:30 -0500 (CDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id RAA09316;
	Thu, 11 Jul 2002 17:40:22 -0500 (CDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BMeR611084;
	Thu, 11 Jul 2002 15:40:27 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 18:40:27 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A16@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Kaixin Xu'" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 18:40:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Kaixin Xu wrote:

> Just want to say a complement point. I remember that Prof. 
> Kumar at UIUC has
> one paper saying that reducing the transmission power will reduce the
> interference among nodes. However, to maintain the 
> connectivity, there is a
> minimal power level. Thus, from my point of view, reducing 
> transmission
> power is equivalent to reducing the node density.

I agree. And this is because receivers can only receive signals above a given C/N, or C/(N+I), or C/(N+I+echo) margin. As power levels go down, transmitters that were once receivable drop out of sight. All else being equal, this effectively reduces node density.

> So I agree 
> with Haenggi
> that global reduction of the power level cannot help reducing 
> interference.

This seems like a non-sequitur to me. We just finished saying that many transmitters drop out of sight, so by defintion, we must have reduced interference. Ultimately, as power levels go to 0, there will be no interference at all.

> It's just a optimization between the node density and 
> transmission range.

Yes, I agree here too. It's an optimization problem with no universal optimal solution. Depends on traffic characteristics in the MANET. Perhaps I just don't understand how the term "interference" is being used here.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 19:14:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12524
	for ; Thu, 11 Jul 2002 19:14:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA26392
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 19:15:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23919;
	Thu, 11 Jul 2002 18:40:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23890
	for ; Thu, 11 Jul 2002 18:40:33 -0400 (EDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10557
	for ; Thu, 11 Jul 2002 18:39:37 -0400 (EDT)
Received: from stl-av-02.boeing.com ([192.76.190.7])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA21349;
	Thu, 11 Jul 2002 17:40:30 -0500 (CDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id RAA09316;
	Thu, 11 Jul 2002 17:40:22 -0500 (CDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6BMeR611084;
	Thu, 11 Jul 2002 15:40:27 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 11 Jul 2002 18:40:27 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A16@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Kaixin Xu'" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Thu, 11 Jul 2002 18:40:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Kaixin Xu wrote:

> Just want to say a complement point. I remember that Prof. 
> Kumar at UIUC has
> one paper saying that reducing the transmission power will reduce the
> interference among nodes. However, to maintain the 
> connectivity, there is a
> minimal power level. Thus, from my point of view, reducing 
> transmission
> power is equivalent to reducing the node density.

I agree. And this is because receivers can only receive signals above a given C/N, or C/(N+I), or C/(N+I+echo) margin. As power levels go down, transmitters that were once receivable drop out of sight. All else being equal, this effectively reduces node density.

> So I agree 
> with Haenggi
> that global reduction of the power level cannot help reducing 
> interference.

This seems like a non-sequitur to me. We just finished saying that many transmitters drop out of sight, so by defintion, we must have reduced interference. Ultimately, as power levels go to 0, there will be no interference at all.

> It's just a optimization between the node density and 
> transmission range.

Yes, I agree here too. It's an optimization problem with no universal optimal solution. Depends on traffic characteristics in the MANET. Perhaps I just don't understand how the term "interference" is being used here.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 11 19:20:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12844
	for ; Thu, 11 Jul 2002 19:20:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24795;
	Thu, 11 Jul 2002 18:57:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24760
	for ; Thu, 11 Jul 2002 18:57:51 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11479
	for ; Thu, 11 Jul 2002 18:56:57 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117123>; Thu, 11 Jul 2002 16:57:41 -0600
Message-Id: <02Jul11.165741mdt.117123@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: Kaixin Xu 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Thu, 11 Jul 2002 16:57:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Kaixin,

Although the ratio of signal to interference is constant, receivers work on
the ratio of signal to noise + interference.  As Sumeeth points out in
another email, each node will be able to receive from (and be interfered
with) by fewer nodes.  This serves to localize the impact of the
interference.  It also reduces the number of nodes that can receive the
signal, but that is why you need more hops.

If power reduction were not able to reduce interference, it would be
impossible to reuse channels in cellular systems and even low power systems
would interfere with each other.  The management of output power is a key
element of reducing interference in broadcast AM radio.  Once the signal
gets down into the grass, it is essentially background noise to the receiver
and ceases to be interference.

That 1.7 factor is interesting.  It sounds about right, but might be band
sensitive, since the inverse square law is overly optimistic for some bands.

John Mullen

-----Original Message-----
From: Kaixin Xu [mailto:xkx@cs.ucla.edu]
Sent: Thursday, July 11, 2002 4:25 PM
To: Manfredi, Albert E; 'Martin Haenggi'
Cc: manet@ietf.org
Subject: Re: [manet] Interference in ad hoc network


Just want to say a complement point. I remember that Prof. Kumar at UIUC has
one paper saying that reducing the transmission power will reduce the
interference among nodes. However, to maintain the connectivity, there is a
minimal power level. Thus, from my point of view, reducing transmission
power is equivalent to reducing the node density. So I agree with Haenggi
that global reduction of the power level cannot help reducing interference.
It's just a optimization between the node density and transmission range.
What really matter are how fast the signal decays and the
transmitter-receiver distance. An interesting thing I have found is that
interference range is usually 1.7 times the transmitter-receiver distance.
Large interference range is harmful since RTS-CTS can only handle
interference nodes within transmission range.

Kaixin

----- Original Message -----
From: "Manfredi, Albert E" 
To: "'Martin Haenggi'" 
Cc: 
Sent: Thursday, July 11, 2002 2:46 PM
Subject: RE: [manet] Interference in ad hoc network


> Martin Haenggi wrote:
>
> > > Within a single MANET, the nodes need to contend for channel access,
> >
> > > and perhaps even reduce their transmitter power level (this
> > was discussed recently)
> >
> > > so as not to interfere with each other.
> >
> >
> > One comment on that: if all nodes use the same power level, then the
> > effect of the interference is completely independent of that
> > power level,
> > since the signal-to-interference ratio remains constant.
> > So, a (global) reduction of the power level does not help
> > alleviate the
> > interference problem.
>
> Hi Martin,
>
> Hmmm. If the distance between hosts remains the same, receiver sensitivity
remains the same, and the power level is reduced for all hosts in the MANET,
then each host will detect fewer neighbors. This causes whatever routing
algorithm is being used to have to create more hops between any random A and
B host in the MANET, on average.
>
> I guess I'm saying that the ratio that matters here is S/(N+I), not just
S/I?
>
> Bert
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 11 19:20:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12852
	for ; Thu, 11 Jul 2002 19:20:59 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA26669
	for manet-archive@odin.ietf.org; Thu, 11 Jul 2002 19:21:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24795;
	Thu, 11 Jul 2002 18:57:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24760
	for ; Thu, 11 Jul 2002 18:57:51 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11479
	for ; Thu, 11 Jul 2002 18:56:57 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117123>; Thu, 11 Jul 2002 16:57:41 -0600
Message-Id: <02Jul11.165741mdt.117123@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: Kaixin Xu 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Thu, 11 Jul 2002 16:57:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Kaixin,

Although the ratio of signal to interference is constant, receivers work on
the ratio of signal to noise + interference.  As Sumeeth points out in
another email, each node will be able to receive from (and be interfered
with) by fewer nodes.  This serves to localize the impact of the
interference.  It also reduces the number of nodes that can receive the
signal, but that is why you need more hops.

If power reduction were not able to reduce interference, it would be
impossible to reuse channels in cellular systems and even low power systems
would interfere with each other.  The management of output power is a key
element of reducing interference in broadcast AM radio.  Once the signal
gets down into the grass, it is essentially background noise to the receiver
and ceases to be interference.

That 1.7 factor is interesting.  It sounds about right, but might be band
sensitive, since the inverse square law is overly optimistic for some bands.

John Mullen

-----Original Message-----
From: Kaixin Xu [mailto:xkx@cs.ucla.edu]
Sent: Thursday, July 11, 2002 4:25 PM
To: Manfredi, Albert E; 'Martin Haenggi'
Cc: manet@ietf.org
Subject: Re: [manet] Interference in ad hoc network


Just want to say a complement point. I remember that Prof. Kumar at UIUC has
one paper saying that reducing the transmission power will reduce the
interference among nodes. However, to maintain the connectivity, there is a
minimal power level. Thus, from my point of view, reducing transmission
power is equivalent to reducing the node density. So I agree with Haenggi
that global reduction of the power level cannot help reducing interference.
It's just a optimization between the node density and transmission range.
What really matter are how fast the signal decays and the
transmitter-receiver distance. An interesting thing I have found is that
interference range is usually 1.7 times the transmitter-receiver distance.
Large interference range is harmful since RTS-CTS can only handle
interference nodes within transmission range.

Kaixin

----- Original Message -----
From: "Manfredi, Albert E" 
To: "'Martin Haenggi'" 
Cc: 
Sent: Thursday, July 11, 2002 2:46 PM
Subject: RE: [manet] Interference in ad hoc network


> Martin Haenggi wrote:
>
> > > Within a single MANET, the nodes need to contend for channel access,
> >
> > > and perhaps even reduce their transmitter power level (this
> > was discussed recently)
> >
> > > so as not to interfere with each other.
> >
> >
> > One comment on that: if all nodes use the same power level, then the
> > effect of the interference is completely independent of that
> > power level,
> > since the signal-to-interference ratio remains constant.
> > So, a (global) reduction of the power level does not help
> > alleviate the
> > interference problem.
>
> Hi Martin,
>
> Hmmm. If the distance between hosts remains the same, receiver sensitivity
remains the same, and the power level is reduced for all hosts in the MANET,
then each host will detect fewer neighbors. This causes whatever routing
algorithm is being used to have to create more hops between any random A and
B host in the MANET, on average.
>
> I guess I'm saying that the ratio that matters here is S/(N+I), not just
S/I?
>
> Bert
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 04:59:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12167
	for ; Fri, 12 Jul 2002 04:59:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01333;
	Fri, 12 Jul 2002 04:44:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01244
	for ; Fri, 12 Jul 2002 04:43:58 -0400 (EDT)
Received: from sina.com (sina35-249.sina.com.cn [202.108.35.249] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11551
	for ; Fri, 12 Jul 2002 04:43:01 -0400 (EDT)
Received: (qmail 7307 invoked by uid 99); 12 Jul 2002 08:35:51 -0000
Message-ID: <20020712083551.7306.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Fri, 12 Jul 2002 16:35:51 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] a question about ns implementation?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dear everyone:
   I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc. Can anyone tell me some implementation details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? Particularly, How to add policer(such as tokentbucker)and queue management and schedulers( such as RIO and WFQ) directly to nodes or mobile nodes directly. I think we can achieve object not suing write c++, only need modify or add some tcl. If anyone has some thoughts on this, Please tell me, had better give me some tcl examples? Thanks in advance.
    Best regard£¡
                             
                                   hait song
______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 04:59:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12180
	for ; Fri, 12 Jul 2002 04:59:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA02728
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 05:00:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01333;
	Fri, 12 Jul 2002 04:44:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01244
	for ; Fri, 12 Jul 2002 04:43:58 -0400 (EDT)
Received: from sina.com (sina35-249.sina.com.cn [202.108.35.249] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11551
	for ; Fri, 12 Jul 2002 04:43:01 -0400 (EDT)
Received: (qmail 7307 invoked by uid 99); 12 Jul 2002 08:35:51 -0000
Message-ID: <20020712083551.7306.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Fri, 12 Jul 2002 16:35:51 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] a question about ns implementation?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dear everyone:
   I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc. Can anyone tell me some implementation details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? Particularly, How to add policer(such as tokentbucker)and queue management and schedulers( such as RIO and WFQ) directly to nodes or mobile nodes directly. I think we can achieve object not suing write c++, only need modify or add some tcl. If anyone has some thoughts on this, Please tell me, had better give me some tcl examples? Thanks in advance.
    Best regard£¡
                             
                                   hait song
______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 05:00:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12251
	for ; Fri, 12 Jul 2002 05:00:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01117;
	Fri, 12 Jul 2002 04:42:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01087
	for ; Fri, 12 Jul 2002 04:42:44 -0400 (EDT)
Received: from sina.com (sina35-233.sina.com.cn [202.108.35.233] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11501
	for ; Fri, 12 Jul 2002 04:41:47 -0400 (EDT)
Received: (qmail 13360 invoked by uid 99); 12 Jul 2002 08:32:00 -0000
Message-ID: <20020712083200.13359.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Fri, 12 Jul 2002 16:32:00 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] a question about ns implementation?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dear everyone:
   I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc. Can anyone tell me some implementation details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? Particularly, How to add policer(such as tokentbucker)and queue management and schedulers( such as RIO and WFQ) directly to nodes or mobile nodes directly. I think we can achieve object not suing write c++, only need modify or add some tcl. If anyone has some thoughts on this, Please tell me, had better give me some tcl examples? Thanks in advance.
    Best regard£¡
                             
                                   hait song
______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 05:00:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12267
	for ; Fri, 12 Jul 2002 05:00:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03058
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 05:01:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01117;
	Fri, 12 Jul 2002 04:42:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01087
	for ; Fri, 12 Jul 2002 04:42:44 -0400 (EDT)
Received: from sina.com (sina35-233.sina.com.cn [202.108.35.233] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11501
	for ; Fri, 12 Jul 2002 04:41:47 -0400 (EDT)
Received: (qmail 13360 invoked by uid 99); 12 Jul 2002 08:32:00 -0000
Message-ID: <20020712083200.13359.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Fri, 12 Jul 2002 16:32:00 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] a question about ns implementation?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dear everyone:
   I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc. Can anyone tell me some implementation details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? Particularly, How to add policer(such as tokentbucker)and queue management and schedulers( such as RIO and WFQ) directly to nodes or mobile nodes directly. I think we can achieve object not suing write c++, only need modify or add some tcl. If anyone has some thoughts on this, Please tell me, had better give me some tcl examples? Thanks in advance.
    Best regard£¡
                             
                                   hait song
______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 05:07:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12569
	for ; Fri, 12 Jul 2002 05:07:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02137;
	Fri, 12 Jul 2002 04:53:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02106
	for ; Fri, 12 Jul 2002 04:53:43 -0400 (EDT)
Received: from sina.com (sina35-235.sina.com.cn [202.108.35.235] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11955
	for ; Fri, 12 Jul 2002 04:52:45 -0400 (EDT)
Received: (qmail 774 invoked by uid 99); 12 Jul 2002 08:46:29 -0000
Message-ID: <20020712084629.772.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Fri, 12 Jul 2002 16:46:29 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] how to implement diffserv in ad hoc?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dear everyone:
   I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc. Can anyone tell me some implementation details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? Particularly, How to add policer(such as tokentbucker)and queue management and schedulers( such as RIO and WFQ) directly to nodes or mobile nodes directly. I think we can achieve this object not suing write c++, only needing modify or add some tcl, can we? If anyone has some thoughts on this, Please tell me, had better give me some tcl examples? Thanks in advance.
    Best regard£¡
                             
                                   hait song

______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 05:07:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12575
	for ; Fri, 12 Jul 2002 05:07:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03623
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 05:08:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02137;
	Fri, 12 Jul 2002 04:53:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02106
	for ; Fri, 12 Jul 2002 04:53:43 -0400 (EDT)
Received: from sina.com (sina35-235.sina.com.cn [202.108.35.235] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11955
	for ; Fri, 12 Jul 2002 04:52:45 -0400 (EDT)
Received: (qmail 774 invoked by uid 99); 12 Jul 2002 08:46:29 -0000
Message-ID: <20020712084629.772.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Fri, 12 Jul 2002 16:46:29 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] how to implement diffserv in ad hoc?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dear everyone:
   I am very interested in implementing DiffServ Framework for QoS in Mobile Ad Hoc Networks. but I don not know how to modify existent diffserv in ns for mobile ad hoc. Can anyone tell me some implementation details? or even more, can someone share me with you some useful ns script fo implementing DiffServ in MANET? Particularly, How to add policer(such as tokentbucker)and queue management and schedulers( such as RIO and WFQ) directly to nodes or mobile nodes directly. I think we can achieve this object not suing write c++, only needing modify or add some tcl, can we? If anyone has some thoughts on this, Please tell me, had better give me some tcl examples? Thanks in advance.
    Best regard£¡
                             
                                   hait song

______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 09:55:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22645
	for ; Fri, 12 Jul 2002 09:55:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17130;
	Fri, 12 Jul 2002 09:38:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17100
	for ; Fri, 12 Jul 2002 09:38:03 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21865
	for ; Fri, 12 Jul 2002 09:37:08 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117125>; Fri, 12 Jul 2002 07:37:52 -0600
Message-Id: <02Jul12.073752mdt.117125@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: manet@ietf.org
Date:  Fri, 12 Jul 2002 07:37:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] List of comments
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I have read draft 11 of the AODV Protocol description and wish to submit
some comments.  However, I'd like to see what comments have been made
already to avoid duplication and can't figure out how to use the archive.
Can someone lend a hand?

Thanks,

John P. Mullen, 
Contractor

Mail to:
    Director
    USATRAC-WSMR
    Attn: ATRC-WBC (John Mullen)
    White Sands Missile Range, NM  88002-5502

Phone:  
    (505) 678-5275
    DSN 258-5275


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 09:55:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22651
	for ; Fri, 12 Jul 2002 09:55:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA18176
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 09:55:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17130;
	Fri, 12 Jul 2002 09:38:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17100
	for ; Fri, 12 Jul 2002 09:38:03 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21865
	for ; Fri, 12 Jul 2002 09:37:08 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117125>; Fri, 12 Jul 2002 07:37:52 -0600
Message-Id: <02Jul12.073752mdt.117125@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: manet@ietf.org
Date:  Fri, 12 Jul 2002 07:37:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] List of comments
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I have read draft 11 of the AODV Protocol description and wish to submit
some comments.  However, I'd like to see what comments have been made
already to avoid duplication and can't figure out how to use the archive.
Can someone lend a hand?

Thanks,

John P. Mullen, 
Contractor

Mail to:
    Director
    USATRAC-WSMR
    Attn: ATRC-WBC (John Mullen)
    White Sands Missile Range, NM  88002-5502

Phone:  
    (505) 678-5275
    DSN 258-5275


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 10:22:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24102
	for ; Fri, 12 Jul 2002 10:22:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19642;
	Fri, 12 Jul 2002 10:07:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19611
	for ; Fri, 12 Jul 2002 10:07:48 -0400 (EDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23194
	for ; Fri, 12 Jul 2002 10:06:53 -0400 (EDT)
Received: from gwialo (camelot.antd.nist.gov [129.6.50.51])
	by email.nist.gov (8.12.2/8.12.2) with SMTP id g6CE7kEu005636;
	Fri, 12 Jul 2002 10:07:46 -0400 (EDT)
From: "Luke Klein-Berndt" 
To: "Mullen, John P. \(Contractor\)" ,
        
Subject: RE: [manet] List of comments
Date: Fri, 12 Jul 2002 10:07:46 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <02Jul12.073752mdt.117125@gw.trac.wsmr.army.mil>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi John,
I would take a look at the AODV Mailing list archive. There have been a few
post on it recently.

https://lists.sourceforge.net/lists/listinfo/aodvimpl-public

-Luke Klein-Berndt

> -----Original Message-----
> From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of
> Mullen, John P. (Contractor)
> Sent: Friday, July 12, 2002 9:38 AM
> To: manet@ietf.org
> Subject: [manet] List of comments
>
>
> Hi,
>
> I have read draft 11 of the AODV Protocol description and wish to submit
> some comments.  However, I'd like to see what comments have been made
> already to avoid duplication and can't figure out how to use the archive.
> Can someone lend a hand?
>
> Thanks,
>
> John P. Mullen,
> Contractor
>
> Mail to:
>     Director
>     USATRAC-WSMR
>     Attn: ATRC-WBC (John Mullen)
>     White Sands Missile Range, NM  88002-5502
>
> Phone:
>     (505) 678-5275
>     DSN 258-5275
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
>
>


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 10:22:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24109
	for ; Fri, 12 Jul 2002 10:22:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA20802
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 10:23:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19642;
	Fri, 12 Jul 2002 10:07:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19611
	for ; Fri, 12 Jul 2002 10:07:48 -0400 (EDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23194
	for ; Fri, 12 Jul 2002 10:06:53 -0400 (EDT)
Received: from gwialo (camelot.antd.nist.gov [129.6.50.51])
	by email.nist.gov (8.12.2/8.12.2) with SMTP id g6CE7kEu005636;
	Fri, 12 Jul 2002 10:07:46 -0400 (EDT)
From: "Luke Klein-Berndt" 
To: "Mullen, John P. \(Contractor\)" ,
        
Subject: RE: [manet] List of comments
Date: Fri, 12 Jul 2002 10:07:46 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <02Jul12.073752mdt.117125@gw.trac.wsmr.army.mil>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi John,
I would take a look at the AODV Mailing list archive. There have been a few
post on it recently.

https://lists.sourceforge.net/lists/listinfo/aodvimpl-public

-Luke Klein-Berndt

> -----Original Message-----
> From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of
> Mullen, John P. (Contractor)
> Sent: Friday, July 12, 2002 9:38 AM
> To: manet@ietf.org
> Subject: [manet] List of comments
>
>
> Hi,
>
> I have read draft 11 of the AODV Protocol description and wish to submit
> some comments.  However, I'd like to see what comments have been made
> already to avoid duplication and can't figure out how to use the archive.
> Can someone lend a hand?
>
> Thanks,
>
> John P. Mullen,
> Contractor
>
> Mail to:
>     Director
>     USATRAC-WSMR
>     Attn: ATRC-WBC (John Mullen)
>     White Sands Missile Range, NM  88002-5502
>
> Phone:
>     (505) 678-5275
>     DSN 258-5275
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
>
>


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 12:26:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01810
	for ; Fri, 12 Jul 2002 12:26:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00902;
	Fri, 12 Jul 2002 12:07:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00872
	for ; Fri, 12 Jul 2002 12:07:17 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00281
	for ; Fri, 12 Jul 2002 12:06:22 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 12 Jul 2002 10:07:06 -0600
Message-Id: <02Jul12.100706mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: manet@ietf.org
Date:  Fri, 12 Jul 2002 10:07:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] Rollover in AODV, Draft 11.
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I understand that this topic has been discussed before, but I believe there
is a potential glitch in the manner in which sequence number rollovers are
detected in Draft 11 of AODV.  I also have a very simple solution.

The problem is that if the current counter value is very large and the
stored copy is very small, the result of a 2's complement subtraction will
falsely indicate that rollover has occurred.  For example, if the current
counter value is 4294967200 and the stored copy is 200, the result of a 2's
complement subtraction will cause the unsigned difference of 4294967000 to
be misinterpreted as -296, which according to the middle paragraph on page
10 of draft 11, would falsely indicate rollover has occurred.  A similar
problem exists in that if the current value is very small (say 200) and the
stored value very large (say 4294967200), the difference will be
misinterpreted as a positive number (296 in this case) and the code will
assume no rollover has taken place.

Now, it is unlikely that such a difference would come up, but as Murphy
would say, it is always best to assume that a potential problem will someday
be realized.  Also, in this case, there is an easy fix.

Instead of using 2's complement subtraction, I would recommend that one
simply do a logical comparison.  If the current and stored counters are
properly typed as long unsigned integers, the logical test will reliably
indicate whether the stored value is larger than the current value,
indicating rollover.  Moreover, since this is a hardware operation, the
logic test will execute much more rapidly and require less object code than
the subtraction and subsequent sign test.

To check this out, I've written a simple C++ program to show what happens
for different values of the sequence number and stored values.  If anyone is
interested, I can send it to them.

John P. Mullen,  Ph.D.
Contractor at TRAC/WSMR while on sabbatical from New Mexico State University

Mail to:
    Director
    USATRAC-WSMR
    Attn: ATRC-WBC (John Mullen)
    White Sands Missile Range, NM  88002-5502

Phone:  
    (505) 678-5275
    DSN 258-5275

After 12/31/02
   Tel: (505) 646-2958
   Email: jomullen@nmsu.edu


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 12:26:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01815
	for ; Fri, 12 Jul 2002 12:26:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA02521
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 12:27:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00902;
	Fri, 12 Jul 2002 12:07:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00872
	for ; Fri, 12 Jul 2002 12:07:17 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00281
	for ; Fri, 12 Jul 2002 12:06:22 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 12 Jul 2002 10:07:06 -0600
Message-Id: <02Jul12.100706mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: manet@ietf.org
Date:  Fri, 12 Jul 2002 10:07:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] Rollover in AODV, Draft 11.
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I understand that this topic has been discussed before, but I believe there
is a potential glitch in the manner in which sequence number rollovers are
detected in Draft 11 of AODV.  I also have a very simple solution.

The problem is that if the current counter value is very large and the
stored copy is very small, the result of a 2's complement subtraction will
falsely indicate that rollover has occurred.  For example, if the current
counter value is 4294967200 and the stored copy is 200, the result of a 2's
complement subtraction will cause the unsigned difference of 4294967000 to
be misinterpreted as -296, which according to the middle paragraph on page
10 of draft 11, would falsely indicate rollover has occurred.  A similar
problem exists in that if the current value is very small (say 200) and the
stored value very large (say 4294967200), the difference will be
misinterpreted as a positive number (296 in this case) and the code will
assume no rollover has taken place.

Now, it is unlikely that such a difference would come up, but as Murphy
would say, it is always best to assume that a potential problem will someday
be realized.  Also, in this case, there is an easy fix.

Instead of using 2's complement subtraction, I would recommend that one
simply do a logical comparison.  If the current and stored counters are
properly typed as long unsigned integers, the logical test will reliably
indicate whether the stored value is larger than the current value,
indicating rollover.  Moreover, since this is a hardware operation, the
logic test will execute much more rapidly and require less object code than
the subtraction and subsequent sign test.

To check this out, I've written a simple C++ program to show what happens
for different values of the sequence number and stored values.  If anyone is
interested, I can send it to them.

John P. Mullen,  Ph.D.
Contractor at TRAC/WSMR while on sabbatical from New Mexico State University

Mail to:
    Director
    USATRAC-WSMR
    Attn: ATRC-WBC (John Mullen)
    White Sands Missile Range, NM  88002-5502

Phone:  
    (505) 678-5275
    DSN 258-5275

After 12/31/02
   Tel: (505) 646-2958
   Email: jomullen@nmsu.edu


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 14:52:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08654
	for ; Fri, 12 Jul 2002 14:52:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09335;
	Fri, 12 Jul 2002 14:20:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09304
	for ; Fri, 12 Jul 2002 14:20:14 -0400 (EDT)
Received: from fw01.rockwellcollins.com (firewall-user@fw01.rockwellcollins.com [205.175.225.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06973
	for ; Fri, 12 Jul 2002 14:19:13 -0400 (EDT)
From: jasteven@rockwellcollins.com
Received: by fw01.rockwellcollins.com; id NAA16599; Fri, 12 Jul 2002 13:20:00 -0500 (CDT)
Received: from nodnsquery(131.198.169.66) by fw01.collins.rockwell.com via smap (V5.5)
	id xma016165; Fri, 12 Jul 02 13:18:50 -0500
Received: from crnotes2.rockwellcollins.com (unverified) by smtpgw01.rockwellcollins.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id  for ;
 Fri, 12 Jul 2002 13:18:49 -0500
To: manet@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
Date: Fri, 12 Jul 2002 13:18:48 -0500
X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release
 5.0.10 |March 22, 2002) at 07/12/2002 01:18:49 PM
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Subject: [manet] Re:Interference in RF networks - advantages of low power transmissions
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


All,

Just joined the MANET discussion list this month & saw several threads
relating to transmit power & whether many large hops or more shorter hops
is better.

FYI, I thought I would present some of the things I have seen in the ad hoc
networks we have worked on here at Rockwell Collins.

As part of the DARPA Survivable Adaptive Radio Networks (SURAN) program in
the 1980s [itself a follow-on to the DARPA Packet Radio (PR) program in the
1970s], we looked at this issue.   I developed a routing protocol called
Least Interference Routing (LIR) and documented it in a paper called
"Spatial Reuse Through Dynamic Power and Routing Control in Common-Channel
Random-Access Packet Radio Networks" that I published as my PhD
dissertation at the University of Texas at Dallas in Aug 1988.  Included in
the paper are simulation results showing the increase total network
throughput and reduced average end-to-end delay arising from reducing total
interference across the network.  (The paper was also released to DTIC as a
SURAN Technial Note (SRNTN) and some early results were published as a
MILCONM paper.)

Since then, we at Rockwell Collins have gone through several generations of
packet radio type networks (most of which has not been published).  We have
seen the same results also for adaptive dyanmic TDMA networks as well as
for random access networks.  I have analyzed the performance under a
variety of traffic and topology scenarios out to 2000 nodes and see an
advantage to reducing interference.  A large advantage comes from the
increased frequency reuse in large networks.  In addition, because you
usually (but not always) lower your transmit power to reduce total network
interference, you also see an increase in average nodal battery life due to
the use of more numerous, but on average lower power tranmissions.

Jim Stevens
Principal Systems Engineer
JTRS Networks
Rockwell Collins
jasteven@rockwellcollins.com




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 14:52:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08662
	for ; Fri, 12 Jul 2002 14:52:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA11837
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 14:53:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09335;
	Fri, 12 Jul 2002 14:20:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09304
	for ; Fri, 12 Jul 2002 14:20:14 -0400 (EDT)
Received: from fw01.rockwellcollins.com (firewall-user@fw01.rockwellcollins.com [205.175.225.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06973
	for ; Fri, 12 Jul 2002 14:19:13 -0400 (EDT)
From: jasteven@rockwellcollins.com
Received: by fw01.rockwellcollins.com; id NAA16599; Fri, 12 Jul 2002 13:20:00 -0500 (CDT)
Received: from nodnsquery(131.198.169.66) by fw01.collins.rockwell.com via smap (V5.5)
	id xma016165; Fri, 12 Jul 02 13:18:50 -0500
Received: from crnotes2.rockwellcollins.com (unverified) by smtpgw01.rockwellcollins.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id  for ;
 Fri, 12 Jul 2002 13:18:49 -0500
To: manet@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
Date: Fri, 12 Jul 2002 13:18:48 -0500
X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release
 5.0.10 |March 22, 2002) at 07/12/2002 01:18:49 PM
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Subject: [manet] Re:Interference in RF networks - advantages of low power transmissions
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


All,

Just joined the MANET discussion list this month & saw several threads
relating to transmit power & whether many large hops or more shorter hops
is better.

FYI, I thought I would present some of the things I have seen in the ad hoc
networks we have worked on here at Rockwell Collins.

As part of the DARPA Survivable Adaptive Radio Networks (SURAN) program in
the 1980s [itself a follow-on to the DARPA Packet Radio (PR) program in the
1970s], we looked at this issue.   I developed a routing protocol called
Least Interference Routing (LIR) and documented it in a paper called
"Spatial Reuse Through Dynamic Power and Routing Control in Common-Channel
Random-Access Packet Radio Networks" that I published as my PhD
dissertation at the University of Texas at Dallas in Aug 1988.  Included in
the paper are simulation results showing the increase total network
throughput and reduced average end-to-end delay arising from reducing total
interference across the network.  (The paper was also released to DTIC as a
SURAN Technial Note (SRNTN) and some early results were published as a
MILCONM paper.)

Since then, we at Rockwell Collins have gone through several generations of
packet radio type networks (most of which has not been published).  We have
seen the same results also for adaptive dyanmic TDMA networks as well as
for random access networks.  I have analyzed the performance under a
variety of traffic and topology scenarios out to 2000 nodes and see an
advantage to reducing interference.  A large advantage comes from the
increased frequency reuse in large networks.  In addition, because you
usually (but not always) lower your transmit power to reduce total network
interference, you also see an increase in average nodal battery life due to
the use of more numerous, but on average lower power tranmissions.

Jim Stevens
Principal Systems Engineer
JTRS Networks
Rockwell Collins
jasteven@rockwellcollins.com




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 14:54:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08785
	for ; Fri, 12 Jul 2002 14:54:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09821;
	Fri, 12 Jul 2002 14:29:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09792
	for ; Fri, 12 Jul 2002 14:28:59 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07313
	for ; Fri, 12 Jul 2002 14:28:03 -0400 (EDT)
Received: from chip.bbn.com (dhcp069-024.bbn.com [128.89.69.24])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28755;
	Fri, 12 Jul 2002 14:29:28 -0400 (EDT)
Message-Id: <5.0.2.1.2.20020712141841.01caeb60@pop3.norton.antivirus>
X-Sender: celliott/po2.bbn.com@pop3.norton.antivirus
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 12 Jul 2002 14:28:19 -0400
To: "Mullen, John P. (Contractor)" ,
        manet@ietf.org
From: Chip Elliott 
Subject: Re: [manet] Rollover in AODV, Draft 11.
In-Reply-To: <02Jul12.100706mdt.117121@gw.trac.wsmr.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Just a quick note that there's "the usual way" of handling
sequence numbers and rollover, which is used in OSPF,
IS-IS, and so forth. I think this way should also be used
in the MANET protocols, because other ways have
various odd failure modes.

Radia Perlman's "Interconnections" book, pp 216-219,
describes the time the ARPANET failed spectacularly
due to a flipped bit in the memory of one of the routers.
It accidently made it so that 3 different sequence numbers
were all "less than" each other, ie, A < B < C < A. As she
points out, once a network gets into such a state, there is
no way for it to recover.

(The next section in her book describe's today's scheme
as used in OSPF etc, with rationale. She's talking link
state but the same basic issues arise in reactive protocols.)

If we're going to use a "not so good" sequence number
scheme, this should be a conscious decision and should be
discussed as such in the document. I have no particular
axe to grind here, just to point out there's been a lot
of rather subtle thought in this area already.

cheers,

-- Chip



At 12:07 PM 7/12/02, Mullen, John P. (Contractor) wrote:
>Hi,
>
>I understand that this topic has been discussed before, but I believe there
>is a potential glitch in the manner in which sequence number rollovers are
>detected in Draft 11 of AODV.  I also have a very simple solution.
>
>The problem is that if the current counter value is very large and the
>stored copy is very small, the result of a 2's complement subtraction will
>falsely indicate that rollover has occurred.  For example, if the current
>counter value is 4294967200 and the stored copy is 200, the result of a 2's
>complement subtraction will cause the unsigned difference of 4294967000 to
>be misinterpreted as -296, which according to the middle paragraph on page
>10 of draft 11, would falsely indicate rollover has occurred.  A similar
>problem exists in that if the current value is very small (say 200) and the
>stored value very large (say 4294967200), the difference will be
>misinterpreted as a positive number (296 in this case) and the code will
>assume no rollover has taken place.
>
>Now, it is unlikely that such a difference would come up, but as Murphy
>would say, it is always best to assume that a potential problem will someday
>be realized.  Also, in this case, there is an easy fix.
>
>Instead of using 2's complement subtraction, I would recommend that one
>simply do a logical comparison.  If the current and stored counters are
>properly typed as long unsigned integers, the logical test will reliably
>indicate whether the stored value is larger than the current value,
>indicating rollover.  Moreover, since this is a hardware operation, the
>logic test will execute much more rapidly and require less object code than
>the subtraction and subsequent sign test.
>
>To check this out, I've written a simple C++ program to show what happens
>for different values of the sequence number and stored values.  If anyone is
>interested, I can send it to them.
>
>John P. Mullen,  Ph.D.
>Contractor at TRAC/WSMR while on sabbatical from New Mexico State University
>
>Mail to:
>     Director
>     USATRAC-WSMR
>     Attn: ATRC-WBC (John Mullen)
>     White Sands Missile Range, NM  88002-5502
>
>Phone:
>     (505) 678-5275
>     DSN 258-5275
>
>After 12/31/02
>    Tel: (505) 646-2958
>    Email: jomullen@nmsu.edu
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 14:54:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08792
	for ; Fri, 12 Jul 2002 14:54:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA12048
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 14:55:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09821;
	Fri, 12 Jul 2002 14:29:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09792
	for ; Fri, 12 Jul 2002 14:28:59 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07313
	for ; Fri, 12 Jul 2002 14:28:03 -0400 (EDT)
Received: from chip.bbn.com (dhcp069-024.bbn.com [128.89.69.24])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28755;
	Fri, 12 Jul 2002 14:29:28 -0400 (EDT)
Message-Id: <5.0.2.1.2.20020712141841.01caeb60@pop3.norton.antivirus>
X-Sender: celliott/po2.bbn.com@pop3.norton.antivirus
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 12 Jul 2002 14:28:19 -0400
To: "Mullen, John P. (Contractor)" ,
        manet@ietf.org
From: Chip Elliott 
Subject: Re: [manet] Rollover in AODV, Draft 11.
In-Reply-To: <02Jul12.100706mdt.117121@gw.trac.wsmr.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Just a quick note that there's "the usual way" of handling
sequence numbers and rollover, which is used in OSPF,
IS-IS, and so forth. I think this way should also be used
in the MANET protocols, because other ways have
various odd failure modes.

Radia Perlman's "Interconnections" book, pp 216-219,
describes the time the ARPANET failed spectacularly
due to a flipped bit in the memory of one of the routers.
It accidently made it so that 3 different sequence numbers
were all "less than" each other, ie, A < B < C < A. As she
points out, once a network gets into such a state, there is
no way for it to recover.

(The next section in her book describe's today's scheme
as used in OSPF etc, with rationale. She's talking link
state but the same basic issues arise in reactive protocols.)

If we're going to use a "not so good" sequence number
scheme, this should be a conscious decision and should be
discussed as such in the document. I have no particular
axe to grind here, just to point out there's been a lot
of rather subtle thought in this area already.

cheers,

-- Chip



At 12:07 PM 7/12/02, Mullen, John P. (Contractor) wrote:
>Hi,
>
>I understand that this topic has been discussed before, but I believe there
>is a potential glitch in the manner in which sequence number rollovers are
>detected in Draft 11 of AODV.  I also have a very simple solution.
>
>The problem is that if the current counter value is very large and the
>stored copy is very small, the result of a 2's complement subtraction will
>falsely indicate that rollover has occurred.  For example, if the current
>counter value is 4294967200 and the stored copy is 200, the result of a 2's
>complement subtraction will cause the unsigned difference of 4294967000 to
>be misinterpreted as -296, which according to the middle paragraph on page
>10 of draft 11, would falsely indicate rollover has occurred.  A similar
>problem exists in that if the current value is very small (say 200) and the
>stored value very large (say 4294967200), the difference will be
>misinterpreted as a positive number (296 in this case) and the code will
>assume no rollover has taken place.
>
>Now, it is unlikely that such a difference would come up, but as Murphy
>would say, it is always best to assume that a potential problem will someday
>be realized.  Also, in this case, there is an easy fix.
>
>Instead of using 2's complement subtraction, I would recommend that one
>simply do a logical comparison.  If the current and stored counters are
>properly typed as long unsigned integers, the logical test will reliably
>indicate whether the stored value is larger than the current value,
>indicating rollover.  Moreover, since this is a hardware operation, the
>logic test will execute much more rapidly and require less object code than
>the subtraction and subsequent sign test.
>
>To check this out, I've written a simple C++ program to show what happens
>for different values of the sequence number and stored values.  If anyone is
>interested, I can send it to them.
>
>John P. Mullen,  Ph.D.
>Contractor at TRAC/WSMR while on sabbatical from New Mexico State University
>
>Mail to:
>     Director
>     USATRAC-WSMR
>     Attn: ATRC-WBC (John Mullen)
>     White Sands Missile Range, NM  88002-5502
>
>Phone:
>     (505) 678-5275
>     DSN 258-5275
>
>After 12/31/02
>    Tel: (505) 646-2958
>    Email: jomullen@nmsu.edu
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 14:56:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08881
	for ; Fri, 12 Jul 2002 14:56:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10718;
	Fri, 12 Jul 2002 14:35:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10688
	for ; Fri, 12 Jul 2002 14:35:43 -0400 (EDT)
Received: from fw01.rockwellcollins.com (firewall-user@fw01.rockwellcollins.com [205.175.225.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07704
	for ; Fri, 12 Jul 2002 14:34:47 -0400 (EDT)
From: jasteven@rockwellcollins.com
Received: by fw01.rockwellcollins.com; id NAA23790; Fri, 12 Jul 2002 13:35:41 -0500 (CDT)
Received: from nodnsquery(131.198.169.67) by fw01.collins.rockwell.com via smap (V5.5)
	id xma023500; Fri, 12 Jul 02 13:35:16 -0500
Received: from crnotes2.rockwellcollins.com (unverified) by smtpgw02.rockwellcollins.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id  for ;
 Fri, 12 Jul 2002 13:35:16 -0500
To: manet@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
Date: Fri, 12 Jul 2002 13:35:15 -0500
X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release
 5.0.10 |March 22, 2002) at 07/12/2002 01:35:16 PM
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Subject: [manet] Interference range
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


2 more comments:

1.  Kaixin Xu wrote that he has found "that interference range is usually
1.7 times the transmitter-receiver distance."  From working with a variety
of different signals-in-space (modulation waveform types), this is about
the average of what we have seen as well, although the actual ratios have
ranged from less than 1 to greater than 3 times the transmitter-receiver
distances in actual fielded networks depending upon the type of
signals-in-space used.

2.  Martin Haenggi wrote that "if all nodes use the same power level, then
the effect of the interference is completely independent of that power
level, since the signal-to-interference ratio remains constant.  So, a
(global) reduction of the power level does not help alleviate the
interference problem."  Yes, but why should all nodes use the same power
level instead of adaptively using different power levels depending upon
which neighbor node (or set of neighbor nodes) they are trying to talk to.
Also, by reducing transmit power across the network, frequency reuse goes
up, which increases total network throughput.

Jim Stevens
JTRS Network Engineering Gruop
Rockwell Collins
jasteven@rockwellcollins.com




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 14:56:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08886
	for ; Fri, 12 Jul 2002 14:56:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA12155
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 14:57:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10718;
	Fri, 12 Jul 2002 14:35:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10688
	for ; Fri, 12 Jul 2002 14:35:43 -0400 (EDT)
Received: from fw01.rockwellcollins.com (firewall-user@fw01.rockwellcollins.com [205.175.225.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07704
	for ; Fri, 12 Jul 2002 14:34:47 -0400 (EDT)
From: jasteven@rockwellcollins.com
Received: by fw01.rockwellcollins.com; id NAA23790; Fri, 12 Jul 2002 13:35:41 -0500 (CDT)
Received: from nodnsquery(131.198.169.67) by fw01.collins.rockwell.com via smap (V5.5)
	id xma023500; Fri, 12 Jul 02 13:35:16 -0500
Received: from crnotes2.rockwellcollins.com (unverified) by smtpgw02.rockwellcollins.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id  for ;
 Fri, 12 Jul 2002 13:35:16 -0500
To: manet@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
Date: Fri, 12 Jul 2002 13:35:15 -0500
X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release
 5.0.10 |March 22, 2002) at 07/12/2002 01:35:16 PM
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Subject: [manet] Interference range
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


2 more comments:

1.  Kaixin Xu wrote that he has found "that interference range is usually
1.7 times the transmitter-receiver distance."  From working with a variety
of different signals-in-space (modulation waveform types), this is about
the average of what we have seen as well, although the actual ratios have
ranged from less than 1 to greater than 3 times the transmitter-receiver
distances in actual fielded networks depending upon the type of
signals-in-space used.

2.  Martin Haenggi wrote that "if all nodes use the same power level, then
the effect of the interference is completely independent of that power
level, since the signal-to-interference ratio remains constant.  So, a
(global) reduction of the power level does not help alleviate the
interference problem."  Yes, but why should all nodes use the same power
level instead of adaptively using different power levels depending upon
which neighbor node (or set of neighbor nodes) they are trying to talk to.
Also, by reducing transmit power across the network, frequency reuse goes
up, which increases total network throughput.

Jim Stevens
JTRS Network Engineering Gruop
Rockwell Collins
jasteven@rockwellcollins.com




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 15:46:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11664
	for ; Fri, 12 Jul 2002 15:46:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13803;
	Fri, 12 Jul 2002 15:15:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13772
	for ; Fri, 12 Jul 2002 15:15:26 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09999
	for ; Fri, 12 Jul 2002 15:14:31 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 12 Jul 2002 13:15:17 -0600
Message-Id: <02Jul12.131517mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: jasteven@rockwellcollins.com, manet@ietf.org
Subject: RE: [manet] Interference range
Date:  Fri, 12 Jul 2002 13:15:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Jim,

You got me thinking on this a bit more.

One problem that MANETs face is that there is no assurance that there will
be sufficient nodes in an area to provide end-to-end connectivity.  At the
other extreme, if node density is too high, many nodes end up receiving
packets that do not concern them and they often need to wait for the channel
to become idle because someone else is using it.

A MANET radio that has the ability to adjust its output power essentially
has the ability to modify the local topology of the MANET.  If there are
many nodes, it can use a low power mode, which reduces the number of nodes
it will interfere with as well as the number it can directly link to.  In a
topological sense, it has changed the local metric to make these nodes
appear to be further away.

On the other hand, a radio normally using low power may find itself in a
situation in which no other nodes can receive it.  By increasing power, the
node is more likely to be able to connect to a "near by" node.  Again, it
has changed the local metric so that the distant nodes appear to be nearer.
There will be an increase in interference, but only so much as necessary to
assure connectivity.

Of course, this is not all free.  For example, if an isolated node uses
higher power to reach a member of a distant cluster, that member will also
have to use high power to reply, causing a higher level of interference
among the nodes nearby.  However, on the average ...

What this means is that transmitter power can "tweak" to local conditions
somewhat to reduce the variability in link capacity and connectivity.  This
could probably be handled at Layer 2 and below without the higher levels
being aware of what is going on.  However, in order to fully exploit the
advantages of such an approach, there needs to be some interaction with the
MANET protocol.

What it also means is that some current systems that are stub nets might
perform better if they used variable power output together with MANET
technology.

John Mullen

-----Original Message-----
From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com]
Sent: Friday, July 12, 2002 12:35 PM
To: manet@ietf.org
Subject: [manet] Interference range



2 more comments:

1.  Kaixin Xu wrote that he has found "that interference range is usually
1.7 times the transmitter-receiver distance."  From working with a variety
of different signals-in-space (modulation waveform types), this is about
the average of what we have seen as well, although the actual ratios have
ranged from less than 1 to greater than 3 times the transmitter-receiver
distances in actual fielded networks depending upon the type of
signals-in-space used.

2.  Martin Haenggi wrote that "if all nodes use the same power level, then
the effect of the interference is completely independent of that power
level, since the signal-to-interference ratio remains constant.  So, a
(global) reduction of the power level does not help alleviate the
interference problem."  Yes, but why should all nodes use the same power
level instead of adaptively using different power levels depending upon
which neighbor node (or set of neighbor nodes) they are trying to talk to.
Also, by reducing transmit power across the network, frequency reuse goes
up, which increases total network throughput.

Jim Stevens
JTRS Network Engineering Gruop
Rockwell Collins
jasteven@rockwellcollins.com




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 15:46:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11670
	for ; Fri, 12 Jul 2002 15:46:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA15757
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 15:47:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13803;
	Fri, 12 Jul 2002 15:15:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13772
	for ; Fri, 12 Jul 2002 15:15:26 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09999
	for ; Fri, 12 Jul 2002 15:14:31 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Fri, 12 Jul 2002 13:15:17 -0600
Message-Id: <02Jul12.131517mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: jasteven@rockwellcollins.com, manet@ietf.org
Subject: RE: [manet] Interference range
Date:  Fri, 12 Jul 2002 13:15:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Jim,

You got me thinking on this a bit more.

One problem that MANETs face is that there is no assurance that there will
be sufficient nodes in an area to provide end-to-end connectivity.  At the
other extreme, if node density is too high, many nodes end up receiving
packets that do not concern them and they often need to wait for the channel
to become idle because someone else is using it.

A MANET radio that has the ability to adjust its output power essentially
has the ability to modify the local topology of the MANET.  If there are
many nodes, it can use a low power mode, which reduces the number of nodes
it will interfere with as well as the number it can directly link to.  In a
topological sense, it has changed the local metric to make these nodes
appear to be further away.

On the other hand, a radio normally using low power may find itself in a
situation in which no other nodes can receive it.  By increasing power, the
node is more likely to be able to connect to a "near by" node.  Again, it
has changed the local metric so that the distant nodes appear to be nearer.
There will be an increase in interference, but only so much as necessary to
assure connectivity.

Of course, this is not all free.  For example, if an isolated node uses
higher power to reach a member of a distant cluster, that member will also
have to use high power to reply, causing a higher level of interference
among the nodes nearby.  However, on the average ...

What this means is that transmitter power can "tweak" to local conditions
somewhat to reduce the variability in link capacity and connectivity.  This
could probably be handled at Layer 2 and below without the higher levels
being aware of what is going on.  However, in order to fully exploit the
advantages of such an approach, there needs to be some interaction with the
MANET protocol.

What it also means is that some current systems that are stub nets might
perform better if they used variable power output together with MANET
technology.

John Mullen

-----Original Message-----
From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com]
Sent: Friday, July 12, 2002 12:35 PM
To: manet@ietf.org
Subject: [manet] Interference range



2 more comments:

1.  Kaixin Xu wrote that he has found "that interference range is usually
1.7 times the transmitter-receiver distance."  From working with a variety
of different signals-in-space (modulation waveform types), this is about
the average of what we have seen as well, although the actual ratios have
ranged from less than 1 to greater than 3 times the transmitter-receiver
distances in actual fielded networks depending upon the type of
signals-in-space used.

2.  Martin Haenggi wrote that "if all nodes use the same power level, then
the effect of the interference is completely independent of that power
level, since the signal-to-interference ratio remains constant.  So, a
(global) reduction of the power level does not help alleviate the
interference problem."  Yes, but why should all nodes use the same power
level instead of adaptively using different power levels depending upon
which neighbor node (or set of neighbor nodes) they are trying to talk to.
Also, by reducing transmit power across the network, frequency reuse goes
up, which increases total network throughput.

Jim Stevens
JTRS Network Engineering Gruop
Rockwell Collins
jasteven@rockwellcollins.com




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 16:01:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12495
	for ; Fri, 12 Jul 2002 16:01:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14960;
	Fri, 12 Jul 2002 15:31:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14901
	for ; Fri, 12 Jul 2002 15:31:13 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10876
	for ; Fri, 12 Jul 2002 15:30:18 -0400 (EDT)
Received: from chip.bbn.com (dhcp069-024.bbn.com [128.89.69.24])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19098;
	Fri, 12 Jul 2002 15:31:31 -0400 (EDT)
Message-Id: <5.0.2.1.2.20020712152856.01ccdc90@pop3.norton.antivirus>
X-Sender: celliott/po2.bbn.com@pop3.norton.antivirus
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 12 Jul 2002 15:30:20 -0400
To: "Mullen, John P. (Contractor)" ,
        jasteven@rockwellcollins.com, manet@ietf.org
From: Chip Elliott 
Subject: RE: [manet] Interference range
In-Reply-To: <02Jul12.131517mdt.117121@gw.trac.wsmr.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Ram Ramanathan led some nice DARPA work in this area a few
years ago. For overview, architecture, & details, check out:

http://www.ir.bbn.com/projects/dawn/dawn-index.html

Cheers,

-- Chip


At 03:15 PM 7/12/02, Mullen, John P. (Contractor) wrote:
>Hi Jim,
>
>You got me thinking on this a bit more.
>
>One problem that MANETs face is that there is no assurance that there will
>be sufficient nodes in an area to provide end-to-end connectivity.  At the
>other extreme, if node density is too high, many nodes end up receiving
>packets that do not concern them and they often need to wait for the channel
>to become idle because someone else is using it.
>
>A MANET radio that has the ability to adjust its output power essentially
>has the ability to modify the local topology of the MANET.  If there are
>many nodes, it can use a low power mode, which reduces the number of nodes
>it will interfere with as well as the number it can directly link to.  In a
>topological sense, it has changed the local metric to make these nodes
>appear to be further away.
>
>On the other hand, a radio normally using low power may find itself in a
>situation in which no other nodes can receive it.  By increasing power, the
>node is more likely to be able to connect to a "near by" node.  Again, it
>has changed the local metric so that the distant nodes appear to be nearer.
>There will be an increase in interference, but only so much as necessary to
>assure connectivity.
>
>Of course, this is not all free.  For example, if an isolated node uses
>higher power to reach a member of a distant cluster, that member will also
>have to use high power to reply, causing a higher level of interference
>among the nodes nearby.  However, on the average ...
>
>What this means is that transmitter power can "tweak" to local conditions
>somewhat to reduce the variability in link capacity and connectivity.  This
>could probably be handled at Layer 2 and below without the higher levels
>being aware of what is going on.  However, in order to fully exploit the
>advantages of such an approach, there needs to be some interaction with the
>MANET protocol.
>
>What it also means is that some current systems that are stub nets might
>perform better if they used variable power output together with MANET
>technology.
>
>John Mullen
>
>-----Original Message-----
>From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com]
>Sent: Friday, July 12, 2002 12:35 PM
>To: manet@ietf.org
>Subject: [manet] Interference range
>
>
>
>2 more comments:
>
>1.  Kaixin Xu wrote that he has found "that interference range is usually
>1.7 times the transmitter-receiver distance."  From working with a variety
>of different signals-in-space (modulation waveform types), this is about
>the average of what we have seen as well, although the actual ratios have
>ranged from less than 1 to greater than 3 times the transmitter-receiver
>distances in actual fielded networks depending upon the type of
>signals-in-space used.
>
>2.  Martin Haenggi wrote that "if all nodes use the same power level, then
>the effect of the interference is completely independent of that power
>level, since the signal-to-interference ratio remains constant.  So, a
>(global) reduction of the power level does not help alleviate the
>interference problem."  Yes, but why should all nodes use the same power
>level instead of adaptively using different power levels depending upon
>which neighbor node (or set of neighbor nodes) they are trying to talk to.
>Also, by reducing transmit power across the network, frequency reuse goes
>up, which increases total network throughput.
>
>Jim Stevens
>JTRS Network Engineering Gruop
>Rockwell Collins
>jasteven@rockwellcollins.com
>
>
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 16:01:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12503
	for ; Fri, 12 Jul 2002 16:01:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA16717
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 16:02:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14960;
	Fri, 12 Jul 2002 15:31:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14901
	for ; Fri, 12 Jul 2002 15:31:13 -0400 (EDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10876
	for ; Fri, 12 Jul 2002 15:30:18 -0400 (EDT)
Received: from chip.bbn.com (dhcp069-024.bbn.com [128.89.69.24])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19098;
	Fri, 12 Jul 2002 15:31:31 -0400 (EDT)
Message-Id: <5.0.2.1.2.20020712152856.01ccdc90@pop3.norton.antivirus>
X-Sender: celliott/po2.bbn.com@pop3.norton.antivirus
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 12 Jul 2002 15:30:20 -0400
To: "Mullen, John P. (Contractor)" ,
        jasteven@rockwellcollins.com, manet@ietf.org
From: Chip Elliott 
Subject: RE: [manet] Interference range
In-Reply-To: <02Jul12.131517mdt.117121@gw.trac.wsmr.army.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Ram Ramanathan led some nice DARPA work in this area a few
years ago. For overview, architecture, & details, check out:

http://www.ir.bbn.com/projects/dawn/dawn-index.html

Cheers,

-- Chip


At 03:15 PM 7/12/02, Mullen, John P. (Contractor) wrote:
>Hi Jim,
>
>You got me thinking on this a bit more.
>
>One problem that MANETs face is that there is no assurance that there will
>be sufficient nodes in an area to provide end-to-end connectivity.  At the
>other extreme, if node density is too high, many nodes end up receiving
>packets that do not concern them and they often need to wait for the channel
>to become idle because someone else is using it.
>
>A MANET radio that has the ability to adjust its output power essentially
>has the ability to modify the local topology of the MANET.  If there are
>many nodes, it can use a low power mode, which reduces the number of nodes
>it will interfere with as well as the number it can directly link to.  In a
>topological sense, it has changed the local metric to make these nodes
>appear to be further away.
>
>On the other hand, a radio normally using low power may find itself in a
>situation in which no other nodes can receive it.  By increasing power, the
>node is more likely to be able to connect to a "near by" node.  Again, it
>has changed the local metric so that the distant nodes appear to be nearer.
>There will be an increase in interference, but only so much as necessary to
>assure connectivity.
>
>Of course, this is not all free.  For example, if an isolated node uses
>higher power to reach a member of a distant cluster, that member will also
>have to use high power to reply, causing a higher level of interference
>among the nodes nearby.  However, on the average ...
>
>What this means is that transmitter power can "tweak" to local conditions
>somewhat to reduce the variability in link capacity and connectivity.  This
>could probably be handled at Layer 2 and below without the higher levels
>being aware of what is going on.  However, in order to fully exploit the
>advantages of such an approach, there needs to be some interaction with the
>MANET protocol.
>
>What it also means is that some current systems that are stub nets might
>perform better if they used variable power output together with MANET
>technology.
>
>John Mullen
>
>-----Original Message-----
>From: jasteven@rockwellcollins.com [mailto:jasteven@rockwellcollins.com]
>Sent: Friday, July 12, 2002 12:35 PM
>To: manet@ietf.org
>Subject: [manet] Interference range
>
>
>
>2 more comments:
>
>1.  Kaixin Xu wrote that he has found "that interference range is usually
>1.7 times the transmitter-receiver distance."  From working with a variety
>of different signals-in-space (modulation waveform types), this is about
>the average of what we have seen as well, although the actual ratios have
>ranged from less than 1 to greater than 3 times the transmitter-receiver
>distances in actual fielded networks depending upon the type of
>signals-in-space used.
>
>2.  Martin Haenggi wrote that "if all nodes use the same power level, then
>the effect of the interference is completely independent of that power
>level, since the signal-to-interference ratio remains constant.  So, a
>(global) reduction of the power level does not help alleviate the
>interference problem."  Yes, but why should all nodes use the same power
>level instead of adaptively using different power levels depending upon
>which neighbor node (or set of neighbor nodes) they are trying to talk to.
>Also, by reducing transmit power across the network, frequency reuse goes
>up, which increases total network throughput.
>
>Jim Stevens
>JTRS Network Engineering Gruop
>Rockwell Collins
>jasteven@rockwellcollins.com
>
>
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 12 20:12:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20950
	for ; Fri, 12 Jul 2002 20:12:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26678;
	Fri, 12 Jul 2002 19:51:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26649
	for ; Fri, 12 Jul 2002 19:51:26 -0400 (EDT)
Received: from einstmob (Einstmob.CS.UCLA.EDU [131.179.136.73])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20271
	for ; Fri, 12 Jul 2002 19:50:29 -0400 (EDT)
Received: from einstmob ([127.0.0.1])
	by einstmob (Kerio MailServer 5.0.5)
	for manet@ietf.org;
	Fri, 12 Jul 2002 16:50:35 -0700
From: "Giovanni Pau" 
To: 
Date: Fri, 12 Jul 2002 16:50:35 -0700
Organization: University of California Los Angeles - USA
Message-ID: <003e01c229fe$ea8964e0$4988b383@einstmob>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA26650
Subject: [manet] FW:  Med-Hoc-Net DEADLINE ESTENSION TO **  July 15th  ** - NEW WEB SITE
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit



Due problems reported in accessing our WEB server the deadline for  

***** Med-Hoc-Net 2002 *****

has been extended. The New deadline IS 

********  J U L Y   15th  *************

NEW WEB SITE 
*********************

http://www-rp.lip6.fr/medhocnet/


*********************

The First Annual Mediterranean Ad Hoc Networking Workshop,Med-hoc-Net
2002, sponsored by IFIP, will take place in Hotel Chia Laguna (
http://www.hotelchialaguna.com ), Sardegna, Italy, Sept4-6,2002.
                       
The aim of the Med-hoc-Net Workshop is to bring together researchers
from both sides of the Atlantic (and Pacific) to the shores of the
Mediterranean sea. The Workshop will serve as a forum for ad hoc network
technologists and visionaries from academia, industry and research labs,
to present current research, advanced technology, ongoing prototyping
efforts, experience reports, case studies, and descriptions of
innovative ad hoc systems. 
Each offering of the Workshop will have a different theme. 
The specific theme this year will be “Quality of Service” in ad hoc
networks. 


The best papers will be published in a special issue of the ACM WINET
Journal  

Invited speaker: Leonard Kleinrock(UCLA) 


Topics will include (but are not limited to) : 

QoS-Oriented multi-hop mobile network architectures, Intserv, Diffserv,
MPLS etc. protocols   
over AdHoc networks 

QoS support in Bluetooth, HomeR, HIPERLAN, IEEE 802.11 etc. 

Multimedia applications Middleware for support in Ad Hoc networks and
real-time transports over Ad Hoc networks 

Unicast and multicast routing in ad hoc multi-hop wireless networks 

Resource discovery and network reconfiguration 

Multimedia location services 

Scheduling, radio resource sharing and MAC protocols for multi hop
networks 

Call admission and traffic control policies for ad hoc networks 

Power management and control algorithms 

Fault tolerance and error recovery 

Interconnection between Ad Hoc and wired networks 

Congestion control 

Ad Hoc TCP implementations 

Fair sharing between different traffic classes 

Performance evaluation of QoS-oriented protocols, middleware and
applications via measurement, analytical models or simulation 

QoS enabling ad hoc network prototypes 

Signal processing algorithms (coding, compression) for Ad Hoc networks 

Security in Ad Hoc networks 


General Chairs : 
Mario Gerla and Guy Pujolle 

Technical Program Chair : 
Khaldoun Al Agha (LRI, France) 

Technical Program Committee : 

Arve Aagesen Norvegian University, Norway)
Hossam Afifi (INT, France) 
Ian Akyildiz (Georgia Tech, USA) 
Khaldoun Al Agha(LRI, France) 
Hamid Aghvami (King's College London, UK) 
Roberto Battiti (University of Trento, Italy) 
Elizabeth Belding-Royer (UCSB, USA) 
Raouf Boutaba (Waterloo, Canada) 
Otto Duarte (UFRJ, Brazil) 
Anne Fladenmuller (LIP6, France) 
Jean-Pierre Hubaux (EPFL, Switzerland) 
Philippe Jacquet (INRIA, France) 
Farouk Kamoun (ENSI, Tunis, Tunisia) 
Parviz Kermani (IBM, USA) 
Ulf Körner(Lund University, Sweden) 
Gérard Le Lann (INRIA, France) 
Daniela Maniezzo (UCLA, USA) 
Gianluca Mazzini (University of Ferrara, Italy) 
Lazaros Merakos (University of Athens, Greece) 
Guy Omidyar (CWC, Singapure) 
Sergio Palazzo (University of Catania, Italy) 
Giovanni Pau (UCLA, USA) 
Kimmo Raatikainen (Univ. of Helsinki, Finland) 
Tomas Robles (Univ. of Madrid – DIM, Spain) 
Jan Slavik (Testcom,CZ) 
Sami Tabbabe (Sup Com)
Samir Tohmé (ENST, France) 
Franco Vatalaro (University of Rome)
Bernhard Walke (Univ of Aachen, Germany)



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 12 20:12:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20955
	for ; Fri, 12 Jul 2002 20:12:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA27843
	for manet-archive@odin.ietf.org; Fri, 12 Jul 2002 20:13:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26678;
	Fri, 12 Jul 2002 19:51:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26649
	for ; Fri, 12 Jul 2002 19:51:26 -0400 (EDT)
Received: from einstmob (Einstmob.CS.UCLA.EDU [131.179.136.73])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20271
	for ; Fri, 12 Jul 2002 19:50:29 -0400 (EDT)
Received: from einstmob ([127.0.0.1])
	by einstmob (Kerio MailServer 5.0.5)
	for manet@ietf.org;
	Fri, 12 Jul 2002 16:50:35 -0700
From: "Giovanni Pau" 
To: 
Date: Fri, 12 Jul 2002 16:50:35 -0700
Organization: University of California Los Angeles - USA
Message-ID: <003e01c229fe$ea8964e0$4988b383@einstmob>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA26650
Subject: [manet] FW:  Med-Hoc-Net DEADLINE ESTENSION TO **  July 15th  ** - NEW WEB SITE
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit



Due problems reported in accessing our WEB server the deadline for  

***** Med-Hoc-Net 2002 *****

has been extended. The New deadline IS 

********  J U L Y   15th  *************

NEW WEB SITE 
*********************

http://www-rp.lip6.fr/medhocnet/


*********************

The First Annual Mediterranean Ad Hoc Networking Workshop,Med-hoc-Net
2002, sponsored by IFIP, will take place in Hotel Chia Laguna (
http://www.hotelchialaguna.com ), Sardegna, Italy, Sept4-6,2002.
                       
The aim of the Med-hoc-Net Workshop is to bring together researchers
from both sides of the Atlantic (and Pacific) to the shores of the
Mediterranean sea. The Workshop will serve as a forum for ad hoc network
technologists and visionaries from academia, industry and research labs,
to present current research, advanced technology, ongoing prototyping
efforts, experience reports, case studies, and descriptions of
innovative ad hoc systems. 
Each offering of the Workshop will have a different theme. 
The specific theme this year will be “Quality of Service” in ad hoc
networks. 


The best papers will be published in a special issue of the ACM WINET
Journal  

Invited speaker: Leonard Kleinrock(UCLA) 


Topics will include (but are not limited to) : 

QoS-Oriented multi-hop mobile network architectures, Intserv, Diffserv,
MPLS etc. protocols   
over AdHoc networks 

QoS support in Bluetooth, HomeR, HIPERLAN, IEEE 802.11 etc. 

Multimedia applications Middleware for support in Ad Hoc networks and
real-time transports over Ad Hoc networks 

Unicast and multicast routing in ad hoc multi-hop wireless networks 

Resource discovery and network reconfiguration 

Multimedia location services 

Scheduling, radio resource sharing and MAC protocols for multi hop
networks 

Call admission and traffic control policies for ad hoc networks 

Power management and control algorithms 

Fault tolerance and error recovery 

Interconnection between Ad Hoc and wired networks 

Congestion control 

Ad Hoc TCP implementations 

Fair sharing between different traffic classes 

Performance evaluation of QoS-oriented protocols, middleware and
applications via measurement, analytical models or simulation 

QoS enabling ad hoc network prototypes 

Signal processing algorithms (coding, compression) for Ad Hoc networks 

Security in Ad Hoc networks 


General Chairs : 
Mario Gerla and Guy Pujolle 

Technical Program Chair : 
Khaldoun Al Agha (LRI, France) 

Technical Program Committee : 

Arve Aagesen Norvegian University, Norway)
Hossam Afifi (INT, France) 
Ian Akyildiz (Georgia Tech, USA) 
Khaldoun Al Agha(LRI, France) 
Hamid Aghvami (King's College London, UK) 
Roberto Battiti (University of Trento, Italy) 
Elizabeth Belding-Royer (UCSB, USA) 
Raouf Boutaba (Waterloo, Canada) 
Otto Duarte (UFRJ, Brazil) 
Anne Fladenmuller (LIP6, France) 
Jean-Pierre Hubaux (EPFL, Switzerland) 
Philippe Jacquet (INRIA, France) 
Farouk Kamoun (ENSI, Tunis, Tunisia) 
Parviz Kermani (IBM, USA) 
Ulf Körner(Lund University, Sweden) 
Gérard Le Lann (INRIA, France) 
Daniela Maniezzo (UCLA, USA) 
Gianluca Mazzini (University of Ferrara, Italy) 
Lazaros Merakos (University of Athens, Greece) 
Guy Omidyar (CWC, Singapure) 
Sergio Palazzo (University of Catania, Italy) 
Giovanni Pau (UCLA, USA) 
Kimmo Raatikainen (Univ. of Helsinki, Finland) 
Tomas Robles (Univ. of Madrid – DIM, Spain) 
Jan Slavik (Testcom,CZ) 
Sami Tabbabe (Sup Com)
Samir Tohmé (ENST, France) 
Franco Vatalaro (University of Rome)
Bernhard Walke (Univ of Aachen, Germany)



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Sat Jul 13 15:09:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00672
	for ; Sat, 13 Jul 2002 15:09:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29019;
	Sat, 13 Jul 2002 14:19:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28989
	for ; Sat, 13 Jul 2002 14:18:59 -0400 (EDT)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29290
	for ; Sat, 13 Jul 2002 14:18:02 -0400 (EDT)
Received: from sm.luth.se ([130.240.3.179])
	by sm.luth.se (8.12.3/8.12.3) with ESMTP id g6DIIouC017120;
	Sat, 13 Jul 2002 20:18:51 +0200 (MET DST)
Message-ID: <3D306ED7.B9C5EE6E@sm.luth.se>
Date: Sat, 13 Jul 2002 20:17:59 +0200
From: Anders Lindgren 
X-Mailer: Mozilla 4.78 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: yasser.lotfy@lycos.com
CC: MANET mailing list ,
        Anders Nilsson 
Subject: Re: [manet] QoS over shared media
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang)
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

I have done some work, evaluating different QoS schemes for IEEE 802.11.
My publications can be found at
http://www.sm.luth.se/~dugdale/index/publications.shtml

This does not consider the interactions with IP, but might at least give
you an idea of the solutions available for 802.11.

/Anders

"Yasser A. Lotfy" wrote:
> 
> 
> The problem is that QoS solutions have always been implemented on IP layer. Implementing this kind of solution will require tight marriage with MAC layer. In addition, the dynamics of varying MAC resources based on the need seem to carry lots of difficulties.
> 
> My question is whether you can point me to any research done on that area? INSIGNIA, and FQMM (not quite sure about SWAN) they all work on IP layer without investigating this kind of otimization. Does Bluetooth, or 802.11b provide any mean to carry over such ideas?
> 
> Inputs are highly appreciated.
> 
> Yasser
> Carleton University
> 
> _____________________________________________________
> Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads
> and NoTaglines --> LYCOS MAIL PLUS.
> http://www.mail.lycos.com/brandPage.shtml?pageId=plus
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Sat Jul 13 15:09:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00681
	for ; Sat, 13 Jul 2002 15:09:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA01519
	for manet-archive@odin.ietf.org; Sat, 13 Jul 2002 15:10:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29019;
	Sat, 13 Jul 2002 14:19:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28989
	for ; Sat, 13 Jul 2002 14:18:59 -0400 (EDT)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29290
	for ; Sat, 13 Jul 2002 14:18:02 -0400 (EDT)
Received: from sm.luth.se ([130.240.3.179])
	by sm.luth.se (8.12.3/8.12.3) with ESMTP id g6DIIouC017120;
	Sat, 13 Jul 2002 20:18:51 +0200 (MET DST)
Message-ID: <3D306ED7.B9C5EE6E@sm.luth.se>
Date: Sat, 13 Jul 2002 20:17:59 +0200
From: Anders Lindgren 
X-Mailer: Mozilla 4.78 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: yasser.lotfy@lycos.com
CC: MANET mailing list ,
        Anders Nilsson 
Subject: Re: [manet] QoS over shared media
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang)
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

I have done some work, evaluating different QoS schemes for IEEE 802.11.
My publications can be found at
http://www.sm.luth.se/~dugdale/index/publications.shtml

This does not consider the interactions with IP, but might at least give
you an idea of the solutions available for 802.11.

/Anders

"Yasser A. Lotfy" wrote:
> 
> 
> The problem is that QoS solutions have always been implemented on IP layer. Implementing this kind of solution will require tight marriage with MAC layer. In addition, the dynamics of varying MAC resources based on the need seem to carry lots of difficulties.
> 
> My question is whether you can point me to any research done on that area? INSIGNIA, and FQMM (not quite sure about SWAN) they all work on IP layer without investigating this kind of otimization. Does Bluetooth, or 802.11b provide any mean to carry over such ideas?
> 
> Inputs are highly appreciated.
> 
> Yasser
> Carleton University
> 
> _____________________________________________________
> Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads
> and NoTaglines --> LYCOS MAIL PLUS.
> http://www.mail.lycos.com/brandPage.shtml?pageId=plus
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Sun Jul 14 00:11:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14023
	for ; Sun, 14 Jul 2002 00:11:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21567;
	Sat, 13 Jul 2002 23:38:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21530
	for ; Sat, 13 Jul 2002 23:38:00 -0400 (EDT)
Received: from dagger.nd.edu (dagger.nd.edu [129.74.250.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13366
	for ; Sat, 13 Jul 2002 23:37:04 -0400 (EDT)
Received: from webmail.nd.edu (webmail.nd.edu [129.74.250.146])
	by dagger.nd.edu (8.12.2/8.12.2) with ESMTP id g6E3bvcw027074;
	Sat, 13 Jul 2002 22:37:58 -0500 (EST)
X-WebMail-UserID:  mhaenggi
Date: Sat, 13 Jul 2002 22:37:40 -0500
From: "mhaenggi@nd.edu" 
To: manet@ietf.org
X-EXP32-SerialNo: 00002313
Subject: RE: [manet] Interference in ad hoc network
Message-ID: <3D310842@webmail.nd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: WebMail (Hydra) SMTP v3.61
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

[Manfredi, Albert E wrote:]
> I guess I'm saying that the ratio that matters here is S/(N+I), not just 
S/I?

Yes, I was just focusing on the "I" since (I thought) that was the topic
under discussion. If N< An interesting thing I have found is that interference range is
> usually 1.7 times the transmitter-receiver distance.

Is that an experimental or a simulation result? And how do you
define the interference range?

[Summeth Nagaraj wrote:]
> you are right but I I think it was in the context of  less number of nodes
> hearing the signal and thereby less interference from other nodes while
> contending for a channel. on the other hand if a large number of nodes are
> able to hear the signal then comes the problem of interference while all the
> nodes contend to access the channel.

Less nodes hearing the signal is again a noise issue, not an interference
issue. Are you thinking about a flooding scenario, assuming every nodes
tries to re-transmit what it receives? If yes, then the protocol could
make sure that only those that are far away (received signal strength
below a certain threshold) try to retransmit.
If the network is (at least locally) synchronized at the symbol level,
then collisions are actually beneficial when flooding, since the packets
from different transmitters add up constructively (a type of cooperative
diversity). Then re-transmission from a large number of nodes becomes merely
an energy issue, not an interference issue.

[ John P. Mullen wrote:]
> Although the ratio of signal to interference is constant, receivers work on
> the ratio of signal to noise + interference.
> If power reduction were not able to reduce interference, it would be
> impossible to reuse channels in cellular systems and even low power systems
> would interfere with each other.

I don't agree with that. Let's assume for a moment that there is no
noise, and let's focus on the SIR. Spatial reuse of the spectrum is 
still possible, since the SIR depends on the relative distances of
the receiver to the desired transmitter and to the interfering transmitters
(and the path loss exponent). So, if the interferers are far enough
away, the SIR will be high. Hence the fact that the SIR is independent of
the transmit power does not preclude channel reuse - it's a matter
of distance not of transmit power.
Including the noise does not change that, it just sets a lower bound
on the transmit power for successful transmission to the receiver.
(Whether the interference is low by itself or buried in the noise
does not matter here.)
 
[Jim Stevens wrote:]
> 2.  Martin Haenggi wrote that "if all nodes use the same power level, then
> the effect of the interference is completely independent of that power
> level, since the signal-to-interference ratio remains constant.  So, a
> (global) reduction of the power level does not help alleviate the
> interference problem."  Yes, but why should all nodes use the same power
> level instead of adaptively using different power levels depending upon
> which neighbor node (or set of neighbor nodes) they are trying to talk to.

Power control is certainly the strategy that leads to optimum performance,
but it may not be possible in all ad hoc nets, either because of resource
constraints, or because the locations of the nodes are not known or
cannot be kept track of.

> Also, by reducing transmit power across the network, frequency reuse goes
> up, which increases total network throughput.

If nodes have different transmit powers, and you just scale all of them
by the same factor, all the SIRs remain constant.

[Manfredi, Albert E wrote:]
>This seems like a non-sequitur to me. We just finished saying that many
>transmitters drop out of sight, so by defintion, we must have reduced
>interference. Ultimately, as power levels go to 0, there will be no
>interference at all.

True but there is also no signal. And the SIR is not determined.
(Luckily we have the noise to avoid this dilemma.)
Clearly the interference itself scales with the transmit power, but the
effect of that interference, measured by the SIR, does not depend on
the power.

Regards,
Martin


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Sun Jul 14 00:11:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14036
	for ; Sun, 14 Jul 2002 00:11:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA23265
	for manet-archive@odin.ietf.org; Sun, 14 Jul 2002 00:12:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21567;
	Sat, 13 Jul 2002 23:38:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21530
	for ; Sat, 13 Jul 2002 23:38:00 -0400 (EDT)
Received: from dagger.nd.edu (dagger.nd.edu [129.74.250.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13366
	for ; Sat, 13 Jul 2002 23:37:04 -0400 (EDT)
Received: from webmail.nd.edu (webmail.nd.edu [129.74.250.146])
	by dagger.nd.edu (8.12.2/8.12.2) with ESMTP id g6E3bvcw027074;
	Sat, 13 Jul 2002 22:37:58 -0500 (EST)
X-WebMail-UserID:  mhaenggi
Date: Sat, 13 Jul 2002 22:37:40 -0500
From: "mhaenggi@nd.edu" 
To: manet@ietf.org
X-EXP32-SerialNo: 00002313
Subject: RE: [manet] Interference in ad hoc network
Message-ID: <3D310842@webmail.nd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: WebMail (Hydra) SMTP v3.61
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

[Manfredi, Albert E wrote:]
> I guess I'm saying that the ratio that matters here is S/(N+I), not just 
S/I?

Yes, I was just focusing on the "I" since (I thought) that was the topic
under discussion. If N< An interesting thing I have found is that interference range is
> usually 1.7 times the transmitter-receiver distance.

Is that an experimental or a simulation result? And how do you
define the interference range?

[Summeth Nagaraj wrote:]
> you are right but I I think it was in the context of  less number of nodes
> hearing the signal and thereby less interference from other nodes while
> contending for a channel. on the other hand if a large number of nodes are
> able to hear the signal then comes the problem of interference while all the
> nodes contend to access the channel.

Less nodes hearing the signal is again a noise issue, not an interference
issue. Are you thinking about a flooding scenario, assuming every nodes
tries to re-transmit what it receives? If yes, then the protocol could
make sure that only those that are far away (received signal strength
below a certain threshold) try to retransmit.
If the network is (at least locally) synchronized at the symbol level,
then collisions are actually beneficial when flooding, since the packets
from different transmitters add up constructively (a type of cooperative
diversity). Then re-transmission from a large number of nodes becomes merely
an energy issue, not an interference issue.

[ John P. Mullen wrote:]
> Although the ratio of signal to interference is constant, receivers work on
> the ratio of signal to noise + interference.
> If power reduction were not able to reduce interference, it would be
> impossible to reuse channels in cellular systems and even low power systems
> would interfere with each other.

I don't agree with that. Let's assume for a moment that there is no
noise, and let's focus on the SIR. Spatial reuse of the spectrum is 
still possible, since the SIR depends on the relative distances of
the receiver to the desired transmitter and to the interfering transmitters
(and the path loss exponent). So, if the interferers are far enough
away, the SIR will be high. Hence the fact that the SIR is independent of
the transmit power does not preclude channel reuse - it's a matter
of distance not of transmit power.
Including the noise does not change that, it just sets a lower bound
on the transmit power for successful transmission to the receiver.
(Whether the interference is low by itself or buried in the noise
does not matter here.)
 
[Jim Stevens wrote:]
> 2.  Martin Haenggi wrote that "if all nodes use the same power level, then
> the effect of the interference is completely independent of that power
> level, since the signal-to-interference ratio remains constant.  So, a
> (global) reduction of the power level does not help alleviate the
> interference problem."  Yes, but why should all nodes use the same power
> level instead of adaptively using different power levels depending upon
> which neighbor node (or set of neighbor nodes) they are trying to talk to.

Power control is certainly the strategy that leads to optimum performance,
but it may not be possible in all ad hoc nets, either because of resource
constraints, or because the locations of the nodes are not known or
cannot be kept track of.

> Also, by reducing transmit power across the network, frequency reuse goes
> up, which increases total network throughput.

If nodes have different transmit powers, and you just scale all of them
by the same factor, all the SIRs remain constant.

[Manfredi, Albert E wrote:]
>This seems like a non-sequitur to me. We just finished saying that many
>transmitters drop out of sight, so by defintion, we must have reduced
>interference. Ultimately, as power levels go to 0, there will be no
>interference at all.

True but there is also no signal. And the SIR is not determined.
(Luckily we have the noise to avoid this dilemma.)
Clearly the interference itself scales with the transmit power, but the
effect of that interference, measured by the SIR, does not depend on
the power.

Regards,
Martin


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Sun Jul 14 11:49:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10004
	for ; Sun, 14 Jul 2002 11:49:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23591;
	Sun, 14 Jul 2002 11:16:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23560
	for ; Sun, 14 Jul 2002 11:16:10 -0400 (EDT)
Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08868
	for ; Sun, 14 Jul 2002 11:15:14 -0400 (EDT)
Received: from pit.erg.sri.com (localhost [127.0.0.1])
	by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id IAA15632;
	Sun, 14 Jul 2002 08:05:55 -0700 (PDT)
Message-Id: <200207141505.IAA15632@pit.erg.sri.com>
To: T.Clausen@computer.org
cc: manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] New OLSR draft 
In-reply-to: Your message of "Tue, 02 Jul 2002 16:25:54 +0200."
              
Date: Sun, 14 Jul 2002 08:05:55 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


I have read the OLSR updates and have a few comments.

The new "relay willingness" field in the HELLO message
is certainly a good thing, and we have already been
planning to add a similar field (called "relay priority") 
to TBRPF HELLO messages.  For example, a node with a very low
battery level would have a low relay priority.  (Note that 
TBRPF already supports non-relay nodes simply by sending
only HELLOs but no topology updates.)

The new OLSR parameter TC_REDUNDANCY results in additional
topology information being reported (up to the full topology).  
Since TBRPF already allowed additional topology information
to be reported, I'm glad to see that INRIA agrees with us.

However, I do not see an *efficient* method for reporting 
sufficient topology information to provide each node with 
two disjoint paths to each destination (without providing
each node with the full topology).  Setting MPR_COVERAGE 
to 2 does provide each node with two disjoint paths to each 
destination (if such paths exist), but not only does it 
double the number of links flooded, it also doubles the 
number of MPRs that need to forward each TC message, 
which seems to multiply the TC overhead by 4.  
(In TBRPF, the factor is 2 since the number of nodes 
reporting each update does not increase.)
Since our ns-2 simulations show that OLSR generates more than 
twice as much overhead as TBRPF, this would likely give TBRPF 
an even bigger advantage in overhead.

Speaking of ns-2 simulations, I am still waiting for the updated 
ns-2 code that INRIA has been promising for a long time.
The code at their web site is still for version 03 of OLSR.
Since several changes have been made to OLSR in the last year,
I really would like to run ns-2 simulations to compare TBRPF
to the new OLSR.  

In fact, the ns-2 code at the INRIA site still has the bug (affecting 
packet size) that I discovered several months ago.  So someone using 
that code who does not know about the bug fix will get incorrect 
results. 

Regarding TBRPF, there is no TBRPF presentation scheduled at the 
meeting this week, but we plan to submit an update to the draft 
by September, which will include more readable descriptions of 
the TBRPF procedures, in addition to a few other changes.
As I previously posted, an updated IPR statement has been 
submitted to the IETF Secretariat.

We have received dozens of requests for our ns-2 code in
the last few weeks, so occasionally there may be a delay
in processing a request, and we apologize for this.

Although some recent changes have been made to OLSR that remove
some of the advantages that TBRPF previously had (e.g., OLSR introduced
REFRESH_INTERVAL so that all neighbors need not be reported every 
HELLO_PERIOD), I believe TBRPF still has several advantages over OLSR,
such as:

  - Less overhead, better performance in simulations (using old OLSR code).
  - Modular (1-hop) neighbor discovery.
  - Differential topology updates.
  - Avoids disadvantages of MPRs as discussed previously.
  - Parent computation based only on RIDs, avoiding the redundancy of 
    selecting MPRs to cover all 2-hop interfaces.  
  - Each HELLO sent on only one interface (like OSPF), reducing overhead.
  - Link metrics may be used to select better routes.
  - Note that TBRPF can employ hysteresis similar to OLSR.

Regards,
Richard

-----------------------
Richard Ogier
Sr. Research Engineer
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
Tel: 650-859-4216
Fax: 650-859-4812
Email: ogier@erg.sri.com
------------------------

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Sun Jul 14 11:49:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10023
	for ; Sun, 14 Jul 2002 11:49:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA24961
	for manet-archive@odin.ietf.org; Sun, 14 Jul 2002 11:50:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23591;
	Sun, 14 Jul 2002 11:16:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23560
	for ; Sun, 14 Jul 2002 11:16:10 -0400 (EDT)
Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08868
	for ; Sun, 14 Jul 2002 11:15:14 -0400 (EDT)
Received: from pit.erg.sri.com (localhost [127.0.0.1])
	by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id IAA15632;
	Sun, 14 Jul 2002 08:05:55 -0700 (PDT)
Message-Id: <200207141505.IAA15632@pit.erg.sri.com>
To: T.Clausen@computer.org
cc: manet@ietf.org
Reply-To: ogier@erg.sri.com
From: ogier@erg.sri.com
Subject: Re: [manet] New OLSR draft 
In-reply-to: Your message of "Tue, 02 Jul 2002 16:25:54 +0200."
              
Date: Sun, 14 Jul 2002 08:05:55 -0700
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


I have read the OLSR updates and have a few comments.

The new "relay willingness" field in the HELLO message
is certainly a good thing, and we have already been
planning to add a similar field (called "relay priority") 
to TBRPF HELLO messages.  For example, a node with a very low
battery level would have a low relay priority.  (Note that 
TBRPF already supports non-relay nodes simply by sending
only HELLOs but no topology updates.)

The new OLSR parameter TC_REDUNDANCY results in additional
topology information being reported (up to the full topology).  
Since TBRPF already allowed additional topology information
to be reported, I'm glad to see that INRIA agrees with us.

However, I do not see an *efficient* method for reporting 
sufficient topology information to provide each node with 
two disjoint paths to each destination (without providing
each node with the full topology).  Setting MPR_COVERAGE 
to 2 does provide each node with two disjoint paths to each 
destination (if such paths exist), but not only does it 
double the number of links flooded, it also doubles the 
number of MPRs that need to forward each TC message, 
which seems to multiply the TC overhead by 4.  
(In TBRPF, the factor is 2 since the number of nodes 
reporting each update does not increase.)
Since our ns-2 simulations show that OLSR generates more than 
twice as much overhead as TBRPF, this would likely give TBRPF 
an even bigger advantage in overhead.

Speaking of ns-2 simulations, I am still waiting for the updated 
ns-2 code that INRIA has been promising for a long time.
The code at their web site is still for version 03 of OLSR.
Since several changes have been made to OLSR in the last year,
I really would like to run ns-2 simulations to compare TBRPF
to the new OLSR.  

In fact, the ns-2 code at the INRIA site still has the bug (affecting 
packet size) that I discovered several months ago.  So someone using 
that code who does not know about the bug fix will get incorrect 
results. 

Regarding TBRPF, there is no TBRPF presentation scheduled at the 
meeting this week, but we plan to submit an update to the draft 
by September, which will include more readable descriptions of 
the TBRPF procedures, in addition to a few other changes.
As I previously posted, an updated IPR statement has been 
submitted to the IETF Secretariat.

We have received dozens of requests for our ns-2 code in
the last few weeks, so occasionally there may be a delay
in processing a request, and we apologize for this.

Although some recent changes have been made to OLSR that remove
some of the advantages that TBRPF previously had (e.g., OLSR introduced
REFRESH_INTERVAL so that all neighbors need not be reported every 
HELLO_PERIOD), I believe TBRPF still has several advantages over OLSR,
such as:

  - Less overhead, better performance in simulations (using old OLSR code).
  - Modular (1-hop) neighbor discovery.
  - Differential topology updates.
  - Avoids disadvantages of MPRs as discussed previously.
  - Parent computation based only on RIDs, avoiding the redundancy of 
    selecting MPRs to cover all 2-hop interfaces.  
  - Each HELLO sent on only one interface (like OSPF), reducing overhead.
  - Link metrics may be used to select better routes.
  - Note that TBRPF can employ hysteresis similar to OLSR.

Regards,
Richard

-----------------------
Richard Ogier
Sr. Research Engineer
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
Tel: 650-859-4216
Fax: 650-859-4812
Email: ogier@erg.sri.com
------------------------

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Sun Jul 14 18:18:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18754
	for ; Sun, 14 Jul 2002 18:18:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07777;
	Sun, 14 Jul 2002 17:48:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07748
	for ; Sun, 14 Jul 2002 17:48:33 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17852
	for ; Sun, 14 Jul 2002 17:47:36 -0400 (EDT)
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA12792;
	Sun, 14 Jul 2002 14:48:29 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA01026;
	Sun, 14 Jul 2002 16:48:23 -0500 (CDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6ELmR601322;
	Sun, 14 Jul 2002 14:48:27 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <37GWXM2V>; Sun, 14 Jul 2002 17:48:26 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A20@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'mhaenggi@nd.edu'" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Sun, 14 Jul 2002 17:48:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

mhaenggi@nd.edu (Martin) wrote:

> I had written:
>
> > I guess I'm saying that the ratio that matters here is 
> S/(N+I), not just 
> S/I?
> 
> Yes, I was just focusing on the "I" since (I thought) that 
> was the topic
> under discussion. If N< transmit power.

I think the general topic of discussion was that the reduction of transmitter power causes a reduction of inter-host interference in a MANET, and the extent to which this helps (or hurts?) the MANET problem. And some interesting discussions were spawned, I think. (I don't think one can ignore the effect of background noise in this discussion, since that would create an unrealistic and fairly trivial special case.)

There are clearly many variables to consider, from comments made in all the discussions.

Trying to sum this up, I'll use a special initial condition, and then generalize from there.

If virtually all sessions in the MANET were between very distant hosts, hosts on periphery of the MANET, then high transmit power would reduce the number of hops required for each session, but would also reduce the number of users simultaneously capable of gaining access to the medium.

Keeping the same initial condition (sessions mostly between hosts on the periphery), low transmit power would mandate many hops, with consequently many medium access events, and with hosts in the core of the MANET having to relay packets of multiple sessions. So this requires computationally faster hosts. The multiple medium access evolutions would not necessarily create more latency, though, because each one would encounter less congestion than the high power case. So if you have such fast hosts in the MANET, then even this special initial condition is better met with low transmit power (just enough to reach a neighbor). Because the aggregate throughput of the MANET would go up.

Since, in the more general case, the vast majority of sessions would _not_ be between hosts on the periphery, but would be distributed throughout, I think one can conclude that in the more general case, low power would be beneficial (as long as one or a few neighbors can be reached) _and_ that very fast hosts would not necessarily be required, because all sessions would not require so many hops after all.

Does pretty much cover what everyone said?

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Sun Jul 14 18:18:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18761
	for ; Sun, 14 Jul 2002 18:18:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA09224
	for manet-archive@odin.ietf.org; Sun, 14 Jul 2002 18:19:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07777;
	Sun, 14 Jul 2002 17:48:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07748
	for ; Sun, 14 Jul 2002 17:48:33 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17852
	for ; Sun, 14 Jul 2002 17:47:36 -0400 (EDT)
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA12792;
	Sun, 14 Jul 2002 14:48:29 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id QAA01026;
	Sun, 14 Jul 2002 16:48:23 -0500 (CDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6ELmR601322;
	Sun, 14 Jul 2002 14:48:27 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <37GWXM2V>; Sun, 14 Jul 2002 17:48:26 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A20@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'mhaenggi@nd.edu'" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Sun, 14 Jul 2002 17:48:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

mhaenggi@nd.edu (Martin) wrote:

> I had written:
>
> > I guess I'm saying that the ratio that matters here is 
> S/(N+I), not just 
> S/I?
> 
> Yes, I was just focusing on the "I" since (I thought) that 
> was the topic
> under discussion. If N< transmit power.

I think the general topic of discussion was that the reduction of transmitter power causes a reduction of inter-host interference in a MANET, and the extent to which this helps (or hurts?) the MANET problem. And some interesting discussions were spawned, I think. (I don't think one can ignore the effect of background noise in this discussion, since that would create an unrealistic and fairly trivial special case.)

There are clearly many variables to consider, from comments made in all the discussions.

Trying to sum this up, I'll use a special initial condition, and then generalize from there.

If virtually all sessions in the MANET were between very distant hosts, hosts on periphery of the MANET, then high transmit power would reduce the number of hops required for each session, but would also reduce the number of users simultaneously capable of gaining access to the medium.

Keeping the same initial condition (sessions mostly between hosts on the periphery), low transmit power would mandate many hops, with consequently many medium access events, and with hosts in the core of the MANET having to relay packets of multiple sessions. So this requires computationally faster hosts. The multiple medium access evolutions would not necessarily create more latency, though, because each one would encounter less congestion than the high power case. So if you have such fast hosts in the MANET, then even this special initial condition is better met with low transmit power (just enough to reach a neighbor). Because the aggregate throughput of the MANET would go up.

Since, in the more general case, the vast majority of sessions would _not_ be between hosts on the periphery, but would be distributed throughout, I think one can conclude that in the more general case, low power would be beneficial (as long as one or a few neighbors can be reached) _and_ that very fast hosts would not necessarily be required, because all sessions would not require so many hops after all.

Does pretty much cover what everyone said?

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Sun Jul 14 23:41:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28645
	for ; Sun, 14 Jul 2002 23:41:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12243;
	Sun, 14 Jul 2002 23:07:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12212
	for ; Sun, 14 Jul 2002 23:07:30 -0400 (EDT)
Received: from opie.usu.edu (opie.usu.edu [129.123.1.150])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27666
	for ; Sun, 14 Jul 2002 23:06:33 -0400 (EDT)
Received: from D7KQ4P01 ("port 2848"@maxwell-6.ece.usu.edu [129.123.85.141])
 by cc.usu.edu (PMDF V5.2-32 #39089)
 with SMTP id <01KK3KPQQNL8ADCHOJ@cc.usu.edu> for manet@ietf.org; Sun,
 14 Jul 2002 21:07:17 MST
Date: Sun, 14 Jul 2002 21:11:21 -0600
From: Sumeeth Nagaraj 
Subject: Re: [manet] Interference in ad hoc network
To: mhaenggi@nd.edu, manet@ietf.org
Message-id: <00ad01c22bad$4be52440$8d557b81@D7KQ4P01>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <3D310842@webmail.nd.edu>
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

> [Sumeeth Nagaraj wrote:]
> > you are right but I I think it was in the context of  less number of
nodes
> > hearing the signal and thereby less interference from other nodes while
> > contending for a channel. on the other hand if a large number of nodes
are
> > able to hear the signal then comes the problem of interference while all
the
> > nodes contend to access the channel.
>
> Less nodes hearing the signal is again a noise issue, not an interference
> issue.

If a node can reach a large number of nodes: the number of nodes contending
for
a channel would be more at a time. the number of RTS sent drastically
increases
and so does the collisions,  before one node gets a chance to transmit. This
also
increases the time for a packet to reach the destination.

>Are you thinking about a flooding scenario, assuming every nodes
> tries to re-transmit what it receives? If yes, then the protocol could
> make sure that only those that are far away (received signal strength
> below a certain threshold) try to retransmit.

> If the network is (at least locally) synchronized at the symbol level,
> then collisions are actually beneficial when flooding, since the packets
> from different transmitters add up constructively (a type of cooperative
> diversity). Then re-transmission from a large number of nodes becomes
merely
> an energy issue, not an interference issue.

Here is another Question I have. Are you thinking about packets sent by 2
different
 transmitter to be the same? By all chances it could happen two different
sources
sending a RREQ(Broadcast) ? then I think it would surely be an interference
issue
 too and not just an energy issue.

Regards,
Sumeeth




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Sun Jul 14 23:41:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28655
	for ; Sun, 14 Jul 2002 23:41:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA14462
	for manet-archive@odin.ietf.org; Sun, 14 Jul 2002 23:41:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12243;
	Sun, 14 Jul 2002 23:07:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12212
	for ; Sun, 14 Jul 2002 23:07:30 -0400 (EDT)
Received: from opie.usu.edu (opie.usu.edu [129.123.1.150])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27666
	for ; Sun, 14 Jul 2002 23:06:33 -0400 (EDT)
Received: from D7KQ4P01 ("port 2848"@maxwell-6.ece.usu.edu [129.123.85.141])
 by cc.usu.edu (PMDF V5.2-32 #39089)
 with SMTP id <01KK3KPQQNL8ADCHOJ@cc.usu.edu> for manet@ietf.org; Sun,
 14 Jul 2002 21:07:17 MST
Date: Sun, 14 Jul 2002 21:11:21 -0600
From: Sumeeth Nagaraj 
Subject: Re: [manet] Interference in ad hoc network
To: mhaenggi@nd.edu, manet@ietf.org
Message-id: <00ad01c22bad$4be52440$8d557b81@D7KQ4P01>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <3D310842@webmail.nd.edu>
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

> [Sumeeth Nagaraj wrote:]
> > you are right but I I think it was in the context of  less number of
nodes
> > hearing the signal and thereby less interference from other nodes while
> > contending for a channel. on the other hand if a large number of nodes
are
> > able to hear the signal then comes the problem of interference while all
the
> > nodes contend to access the channel.
>
> Less nodes hearing the signal is again a noise issue, not an interference
> issue.

If a node can reach a large number of nodes: the number of nodes contending
for
a channel would be more at a time. the number of RTS sent drastically
increases
and so does the collisions,  before one node gets a chance to transmit. This
also
increases the time for a packet to reach the destination.

>Are you thinking about a flooding scenario, assuming every nodes
> tries to re-transmit what it receives? If yes, then the protocol could
> make sure that only those that are far away (received signal strength
> below a certain threshold) try to retransmit.

> If the network is (at least locally) synchronized at the symbol level,
> then collisions are actually beneficial when flooding, since the packets
> from different transmitters add up constructively (a type of cooperative
> diversity). Then re-transmission from a large number of nodes becomes
merely
> an energy issue, not an interference issue.

Here is another Question I have. Are you thinking about packets sent by 2
different
 transmitter to be the same? By all chances it could happen two different
sources
sending a RREQ(Broadcast) ? then I think it would surely be an interference
issue
 too and not just an energy issue.

Regards,
Sumeeth




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 15 09:01:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02770
	for ; Mon, 15 Jul 2002 09:01:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22985;
	Mon, 15 Jul 2002 08:43:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22953
	for ; Mon, 15 Jul 2002 08:43:54 -0400 (EDT)
Received: from sina.com (sina35-239.sina.com.cn [202.108.35.239] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01828
	for ; Mon, 15 Jul 2002 08:42:54 -0400 (EDT)
Received: (qmail 10341 invoked by uid 99); 15 Jul 2002 12:35:57 -0000
Message-ID: <20020715123557.10340.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Mon, 15 Jul 2002 20:35:57 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] whu no use ftp in diffserv model in ns?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

hello everyone:
   Ad we know, current ns has implement diffserv model, but i find
all examples about diffserv use udp based cbr. Thus, i try ftp on tcp in diffserv, but i found tcp behave different, ie, though we config diffserv model to differentiate two tcp based ftp flows, butg result show there is little difference between them.I don not konw why ftp flows can no do as well as cbr. who can give me some thoughts. thanks in advance!
 best regard!
     haitsong
   

______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 15 09:01:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02781
	for ; Mon, 15 Jul 2002 09:01:29 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA24403
	for manet-archive@odin.ietf.org; Mon, 15 Jul 2002 09:02:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22985;
	Mon, 15 Jul 2002 08:43:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22953
	for ; Mon, 15 Jul 2002 08:43:54 -0400 (EDT)
Received: from sina.com (sina35-239.sina.com.cn [202.108.35.239] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01828
	for ; Mon, 15 Jul 2002 08:42:54 -0400 (EDT)
Received: (qmail 10341 invoked by uid 99); 15 Jul 2002 12:35:57 -0000
Message-ID: <20020715123557.10340.qmail@sina.com>
From: wht_slh_bao 
To: manet@ietf.org
MIME-Version: 1.0
Date: Mon, 15 Jul 2002 20:35:57 +0800
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3
Subject: [manet] whu no use ftp in diffserv model in ns?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

hello everyone:
   Ad we know, current ns has implement diffserv model, but i find
all examples about diffserv use udp based cbr. Thus, i try ftp on tcp in diffserv, but i found tcp behave different, ie, though we config diffserv model to differentiate two tcp based ftp flows, butg result show there is little difference between them.I don not konw why ftp flows can no do as well as cbr. who can give me some thoughts. thanks in advance!
 best regard!
     haitsong
   

______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 15 09:43:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04157
	for ; Mon, 15 Jul 2002 09:43:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25173;
	Mon, 15 Jul 2002 09:25:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25144
	for ; Mon, 15 Jul 2002 09:25:39 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03630
	for ; Mon, 15 Jul 2002 09:24:39 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117139>; Mon, 15 Jul 2002 07:25:26 -0600
Message-Id: <02Jul15.072526mdt.117139@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "Manfredi, Albert E" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Mon, 15 Jul 2002 07:25:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

Looks fine to me, except that although I'm sure there are situations in
which low power would be beneficial, I'm not entirely sure that low power
would necessarily be better in the general case.  

The trouble is that in the case of MANETs, the "general case" covers a lot
of territory.

:-)

John Mullen

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Sunday, July 14, 2002 3:48 PM
To: 'mhaenggi@nd.edu'; manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network


mhaenggi@nd.edu (Martin) wrote:

> I had written:
>
> > I guess I'm saying that the ratio that matters here is 
> S/(N+I), not just 
> S/I?
> 
> Yes, I was just focusing on the "I" since (I thought) that 
> was the topic
> under discussion. If N< transmit power.

I think the general topic of discussion was that the reduction of
transmitter power causes a reduction of inter-host interference in a MANET,
and the extent to which this helps (or hurts?) the MANET problem. And some
interesting discussions were spawned, I think. (I don't think one can ignore
the effect of background noise in this discussion, since that would create
an unrealistic and fairly trivial special case.)

There are clearly many variables to consider, from comments made in all the
discussions.

Trying to sum this up, I'll use a special initial condition, and then
generalize from there.

If virtually all sessions in the MANET were between very distant hosts,
hosts on periphery of the MANET, then high transmit power would reduce the
number of hops required for each session, but would also reduce the number
of users simultaneously capable of gaining access to the medium.

Keeping the same initial condition (sessions mostly between hosts on the
periphery), low transmit power would mandate many hops, with consequently
many medium access events, and with hosts in the core of the MANET having to
relay packets of multiple sessions. So this requires computationally faster
hosts. The multiple medium access evolutions would not necessarily create
more latency, though, because each one would encounter less congestion than
the high power case. So if you have such fast hosts in the MANET, then even
this special initial condition is better met with low transmit power (just
enough to reach a neighbor). Because the aggregate throughput of the MANET
would go up.

Since, in the more general case, the vast majority of sessions would _not_
be between hosts on the periphery, but would be distributed throughout, I
think one can conclude that in the more general case, low power would be
beneficial (as long as one or a few neighbors can be reached) _and_ that
very fast hosts would not necessarily be required, because all sessions
would not require so many hops after all.

Does pretty much cover what everyone said?

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 15 10:41:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04164
	for ; Mon, 15 Jul 2002 09:43:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA26587
	for manet-archive@odin.ietf.org; Mon, 15 Jul 2002 09:44:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25173;
	Mon, 15 Jul 2002 09:25:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25144
	for ; Mon, 15 Jul 2002 09:25:39 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03630
	for ; Mon, 15 Jul 2002 09:24:39 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117139>; Mon, 15 Jul 2002 07:25:26 -0600
Message-Id: <02Jul15.072526mdt.117139@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "Manfredi, Albert E" , manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date:  Mon, 15 Jul 2002 07:25:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

Looks fine to me, except that although I'm sure there are situations in
which low power would be beneficial, I'm not entirely sure that low power
would necessarily be better in the general case.  

The trouble is that in the case of MANETs, the "general case" covers a lot
of territory.

:-)

John Mullen

-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Sunday, July 14, 2002 3:48 PM
To: 'mhaenggi@nd.edu'; manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network


mhaenggi@nd.edu (Martin) wrote:

> I had written:
>
> > I guess I'm saying that the ratio that matters here is 
> S/(N+I), not just 
> S/I?
> 
> Yes, I was just focusing on the "I" since (I thought) that 
> was the topic
> under discussion. If N< transmit power.

I think the general topic of discussion was that the reduction of
transmitter power causes a reduction of inter-host interference in a MANET,
and the extent to which this helps (or hurts?) the MANET problem. And some
interesting discussions were spawned, I think. (I don't think one can ignore
the effect of background noise in this discussion, since that would create
an unrealistic and fairly trivial special case.)

There are clearly many variables to consider, from comments made in all the
discussions.

Trying to sum this up, I'll use a special initial condition, and then
generalize from there.

If virtually all sessions in the MANET were between very distant hosts,
hosts on periphery of the MANET, then high transmit power would reduce the
number of hops required for each session, but would also reduce the number
of users simultaneously capable of gaining access to the medium.

Keeping the same initial condition (sessions mostly between hosts on the
periphery), low transmit power would mandate many hops, with consequently
many medium access events, and with hosts in the core of the MANET having to
relay packets of multiple sessions. So this requires computationally faster
hosts. The multiple medium access evolutions would not necessarily create
more latency, though, because each one would encounter less congestion than
the high power case. So if you have such fast hosts in the MANET, then even
this special initial condition is better met with low transmit power (just
enough to reach a neighbor). Because the aggregate throughput of the MANET
would go up.

Since, in the more general case, the vast majority of sessions would _not_
be between hosts on the periphery, but would be distributed throughout, I
think one can conclude that in the more general case, low power would be
beneficial (as long as one or a few neighbors can be reached) _and_ that
very fast hosts would not necessarily be required, because all sessions
would not require so many hops after all.

Does pretty much cover what everyone said?

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 16 02:41:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11349
	for ; Tue, 16 Jul 2002 02:41:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04475;
	Tue, 16 Jul 2002 02:20:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04411
	for ; Tue, 16 Jul 2002 02:19:59 -0400 (EDT)
Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10597
	for ; Tue, 16 Jul 2002 02:19:01 -0400 (EDT)
Received: from shim.irt.drexel.edu (shim.irt.drexel.edu [129.25.3.91])
 by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9)
 with ESMTP id <0GZB00I1YW78TK@mail.drexel.edu> for manet@ietf.org; Tue,
 16 Jul 2002 02:18:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by shim.irt.drexel.edu (Postfix) with ESMTP	id 871437BD28; Tue,
 16 Jul 2002 02:18:44 -0400 (EDT)
Received: from glue.irt.drexel.edu (glue.irt.drexel.edu [129.25.3.22])
	by shim.irt.drexel.edu (Postfix) with ESMTP	id BAC677BD2A; Tue,
 16 Jul 2002 02:10:38 -0400 (EDT)
Received: from dunx1.irt.drexel.edu (dunx1.irt.drexel.edu [144.118.24.33])
	by glue.irt.drexel.edu (8.11.3/8.11.3) with ESMTP id g6G6AMZ20644; Tue,
 16 Jul 2002 02:10:22 -0400 (EDT)
Date: Tue, 16 Jul 2002 02:09:55 -0400 (EDT)
From: Harpreet Arora 
Subject: Re: [manet] whu no use ftp in diffserv model in ns?
In-reply-to: <20020715123557.10340.qmail@sina.com>
To: wht_slh_bao 
Cc: manet@ietf.org
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=X-UNKNOWN
X-Virus-Scanned: by AMaViS snapshot-20010915
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id CAA04440
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

what kind of results are u talking about? If its the overall
end-to-end throughput,
naturally, tcp takes care of it, not affected much by the MAC layer, 
which is where the diffserv queue is implemented. 

Harpreet

On Mon, 15 Jul 2002, wht_slh_bao wrote:

> hello everyone:
>    Ad we know, current ns has implement diffserv model, but i find
> all examples about diffserv use udp based cbr. Thus, i try ftp on tcp in diffserv, but i found tcp behave different, ie, though we config diffserv model to differentiate two tcp based ftp flows, butg result show there is little difference between them.I don not konw why ftp flows can no do as well as cbr. who can give me some thoughts. thanks in advance!
>  best regard!
>      haitsong
>    
> 
> ______________________________________
> 
> ===================================================================
> ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
> ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 16 02:41:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11355
	for ; Tue, 16 Jul 2002 02:41:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA06060
	for manet-archive@odin.ietf.org; Tue, 16 Jul 2002 02:42:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04475;
	Tue, 16 Jul 2002 02:20:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04411
	for ; Tue, 16 Jul 2002 02:19:59 -0400 (EDT)
Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10597
	for ; Tue, 16 Jul 2002 02:19:01 -0400 (EDT)
Received: from shim.irt.drexel.edu (shim.irt.drexel.edu [129.25.3.91])
 by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9)
 with ESMTP id <0GZB00I1YW78TK@mail.drexel.edu> for manet@ietf.org; Tue,
 16 Jul 2002 02:18:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by shim.irt.drexel.edu (Postfix) with ESMTP	id 871437BD28; Tue,
 16 Jul 2002 02:18:44 -0400 (EDT)
Received: from glue.irt.drexel.edu (glue.irt.drexel.edu [129.25.3.22])
	by shim.irt.drexel.edu (Postfix) with ESMTP	id BAC677BD2A; Tue,
 16 Jul 2002 02:10:38 -0400 (EDT)
Received: from dunx1.irt.drexel.edu (dunx1.irt.drexel.edu [144.118.24.33])
	by glue.irt.drexel.edu (8.11.3/8.11.3) with ESMTP id g6G6AMZ20644; Tue,
 16 Jul 2002 02:10:22 -0400 (EDT)
Date: Tue, 16 Jul 2002 02:09:55 -0400 (EDT)
From: Harpreet Arora 
Subject: Re: [manet] whu no use ftp in diffserv model in ns?
In-reply-to: <20020715123557.10340.qmail@sina.com>
To: wht_slh_bao 
Cc: manet@ietf.org
Message-id: 
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=X-UNKNOWN
X-Virus-Scanned: by AMaViS snapshot-20010915
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id CAA04440
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

what kind of results are u talking about? If its the overall
end-to-end throughput,
naturally, tcp takes care of it, not affected much by the MAC layer, 
which is where the diffserv queue is implemented. 

Harpreet

On Mon, 15 Jul 2002, wht_slh_bao wrote:

> hello everyone:
>    Ad we know, current ns has implement diffserv model, but i find
> all examples about diffserv use udp based cbr. Thus, i try ftp on tcp in diffserv, but i found tcp behave different, ie, though we config diffserv model to differentiate two tcp based ftp flows, butg result show there is little difference between them.I don not konw why ftp flows can no do as well as cbr. who can give me some thoughts. thanks in advance!
>  best regard!
>      haitsong
>    
> 
> ______________________________________
> 
> ===================================================================
> ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
> ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/)
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 16 05:21:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14817
	for ; Tue, 16 Jul 2002 05:21:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14021;
	Tue, 16 Jul 2002 04:56:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13990
	for ; Tue, 16 Jul 2002 04:56:46 -0400 (EDT)
Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14299
	for ; Tue, 16 Jul 2002 04:55:49 -0400 (EDT)
Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0)
	id JAA06646; Tue, 16 Jul 2002 09:56:44 +0100 (BST)
Received: (from tapselj0@localhost)
	by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g6G8uhD01147
	for manet@ietf.org; Tue, 16 Jul 2002 09:56:43 +0100
Date: Tue, 16 Jul 2002 09:56:43 +0100
From: John Tapsell 
To: manet@ietf.org
Message-ID: <20020716095643.A1134@ug003.cs.man.ac.uk>
References: <20020715123557.10340.qmail@sina.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: ; from ha33@drexel.edu on Tue, Jul 16, 2002 at 02:09:55AM -0400
Subject: [manet] IBM Patent?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
  Has anyone heard of an IBM patent that covers, at least partially,
RSVP ?

  I saw a mention about it in a last email on an RSVP mailing list, which
stopped about 3-4 years ago..

  If anyone has any information, I'd like to know :)

Thanks

JohnFlux

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 16 05:21:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14825
	for ; Tue, 16 Jul 2002 05:21:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA15577
	for manet-archive@odin.ietf.org; Tue, 16 Jul 2002 05:21:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14021;
	Tue, 16 Jul 2002 04:56:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13990
	for ; Tue, 16 Jul 2002 04:56:46 -0400 (EDT)
Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14299
	for ; Tue, 16 Jul 2002 04:55:49 -0400 (EDT)
Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0)
	id JAA06646; Tue, 16 Jul 2002 09:56:44 +0100 (BST)
Received: (from tapselj0@localhost)
	by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g6G8uhD01147
	for manet@ietf.org; Tue, 16 Jul 2002 09:56:43 +0100
Date: Tue, 16 Jul 2002 09:56:43 +0100
From: John Tapsell 
To: manet@ietf.org
Message-ID: <20020716095643.A1134@ug003.cs.man.ac.uk>
References: <20020715123557.10340.qmail@sina.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: ; from ha33@drexel.edu on Tue, Jul 16, 2002 at 02:09:55AM -0400
Subject: [manet] IBM Patent?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
  Has anyone heard of an IBM patent that covers, at least partially,
RSVP ?

  I saw a mention about it in a last email on an RSVP mailing list, which
stopped about 3-4 years ago..

  If anyone has any information, I'd like to know :)

Thanks

JohnFlux

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 16 11:48:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22290
	for ; Tue, 16 Jul 2002 11:48:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03606;
	Tue, 16 Jul 2002 11:27:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03579
	for ; Tue, 16 Jul 2002 11:27:42 -0400 (EDT)
Received: from bjapp15.163.net ([202.108.255.197])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21745
	for ; Tue, 16 Jul 2002 11:26:42 -0400 (EDT)
Received: by bjapp15.163.net (Postfix, from userid 1005)
	id 4926A1CBA570B; Tue, 16 Jul 2002 23:27:36 +0800 (CST)
MIME-Version: 1.0
Message-ID: <3D343B68.00001D.00926@bjapp15>
Date: Tue, 16 Jul 2002 23:27:36 +0800 (CST)
From: "Íõº£" 
To: yuanyg@cs.dartmouth.edu
Cc: manet@ietf.org
X-Priority: 3
X-Originating-IP: [218.2.151.246]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
Content-Type: Multipart/Alternative; boundary="Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh"
Subject: [manet] =?gb2312?B?UmU6IFttYW5ldF0gUmU6IE1BQyBzZXF1ZW5jZSBudW1iZXI=?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
    I read Glomosim source of 802.11, it uses 1 bit to represent sequence number. I think there is no need for sequence number negotiation process in the 802.11. When one of the talking side reboot, as you may discover, two sides may have different sequence number. For example, when B reboot, A's sequence number is different from B, the sequence number of A is 1, B is 0. then A send a packet with sequence number 1, B will find the packet number from A is different from what it expected from A. Then B regards this packet as an obsolete packet, return ACK with sequence number 0, and A will think that this packet is accepted by B, its sequence number will increase to 0, then two sides will have the same sequence number thereafter. I think this may be called "sequence number negotiation" if you insist, With the worst payment of 1 packet loss. However, in a real implementation, when reboot, system will become stable after a certain period(such as for route discovery), during this!
  period, a packet loss means little for the whole system. So I think if your system does not shut down and restart frequently, this simple negotiation scheme will work. No complicated sequence number negotiation process is needed.

B.R   
Hai Wang


> I think I should make my question more clear. I read some part of the 
> standard. It didn't say clearly that there is anything like handshaking. 
> 
> If two nodes, A and B, just meet, they can set the sequence numbers from 
> their first exchanged packets, that's ok. But if after a while, A reboots, 
> coming back with a clean cache, while B still keeps the old sequence number 
> cache, there is a clear mismatch that will cause them to drop packets from 
> each other unless they can settle down on a new sequnce number. I'm wondering 
> how this is done. Does it depends on a timer of the sequence number cache? Or 
> some field in the MAC header?
> 
> 
> On Thursday 11 July 2002 13:47, Yougu Yuan wrote:
> > Hi, all. Maybe it is a little bit off topic to send this question to manet,
> > but I have a question about the MAC802.11 packet sequence number.
> >
> > In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> > when two nodes meet, how do the negotiate the sequence number pair? Is
> > there a special bit in the header that says "reset the sequence number of
> > me to the sequence number in this packet"? I'm reading the 802.11 standard,
> > but it's too thick for a quick answer.
> >
> > Thanks in advance.
> 
> -- 
> Yougu Yuan
> 
> ----------------------------------------------------
> Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
> Dept. of Computer Science, Dartmouth College
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> 
--Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
    I read Glomosim source of 802.11, it uses 1 bit to represent sequence number. I think there is no need for sequence number negotiation process in the 802.11. When one of the talking side reboot, as you may discover, two sides may have different sequence number. For example, when B reboot, A's sequence number is different from B, the sequence number of A is 1, B is 0. then A send a packet with sequence number 1, B will find the packet number from A is different from what it expected from A. Then B regards this packet as an obsolete packet, return ACK with sequence number 0, and A will think that this packet is accepted by B, its sequence number will increase to 0, then two sides will have the same sequence number thereafter. I think this may be called "sequence number negotiation" if you insist, With the worst payment of 1 packet loss. However, in a real implementation, when reboot, system will become stable after a certain period(such as for !
 route discovery), during this period, a packet loss means little for the whole system. So I think if your system does not shut down and restart frequently, this simple negotiation scheme will work. No complicated sequence number negotiation process is needed.

B.R   
Hai Wang


> I think I should make my question more clear. I read some part of the 
> standard. It didn't say clearly that there is anything like handshaking. 
> 
> If two nodes, A and B, just meet, they can set the sequence numbers from 
> their first exchanged packets, that's ok. But if after a while, A reboots, 
> coming back with a clean cache, while B still keeps the old sequence number 
> cache, there is a clear mismatch that will cause them to drop packets from 
> each other unless they can settle down on a new sequnce number. I'm wondering 
> how this is done. Does it depends on a timer of the sequence number cache? Or 
> some fi!
 eld in the MAC header?
> 
> 
> On Thursday 11 July 2
002 13:47, Yougu Yuan wrote:
> > Hi, all. Maybe it is a little bit off topic to send this question to manet,
> > but I have a question about the MAC802.11 packet sequence number.
> >
> > In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> > when two nodes meet, how do the negotiate the sequence number pair? Is
> > there a special bit in the header that says "reset the sequence number of
> > me to the sequence number in this packet"? I'm reading the 802.11 standard,
> > but it's too thick for a quick answer.
> >
> > Thanks in advance.
> 
> -- 
> Yougu Yuan
> 
> ----------------------------------------------------
> Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
> Dept. of Computer Science, Dartmouth College
> 
> _______________________________________________
> manet mailing list
> man!
 et@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> 

--Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Tue Jul 16 11:51:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22393
	for ; Tue, 16 Jul 2002 11:51:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02834;
	Tue, 16 Jul 2002 11:11:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02803
	for ; Tue, 16 Jul 2002 11:11:27 -0400 (EDT)
Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21361
	for ; Tue, 16 Jul 2002 11:10:30 -0400 (EDT)
Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0)
	id QAA10377; Tue, 16 Jul 2002 16:11:20 +0100 (BST)
Received: (from tapselj0@localhost)
	by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g6GFB9I01337
	for manet@ietf.org; Tue, 16 Jul 2002 16:11:09 +0100
Date: Tue, 16 Jul 2002 16:11:09 +0100
From: John Tapsell 
To: manet@ietf.org
Message-ID: <20020716161109.C1317@ug003.cs.man.ac.uk>
References:  <200207141505.IAA15632@pit.erg.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200207141505.IAA15632@pit.erg.sri.com>; from ogier@erg.sri.com on Sun, Jul 14, 2002 at 08:05:55AM -0700
Subject: [manet] QOSPF, RSVP, etc
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
  What implementations (actual or simulators) are there for the various
ways of doing QoS on a manet?
  I couldn't find any code for QOSPF, and draft-zhang-qos-01.txt (or
something) has expired...
  I found a 2.2 implementation of RSVP over mobile ip, which isn't quite the
same as a manet - are there any dRSVP implementations or anything?


Thanks

JohnFlux

-- 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 16 11:51:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22399
	for ; Tue, 16 Jul 2002 11:51:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA05390
	for manet-archive@odin.ietf.org; Tue, 16 Jul 2002 11:52:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02834;
	Tue, 16 Jul 2002 11:11:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02803
	for ; Tue, 16 Jul 2002 11:11:27 -0400 (EDT)
Received: from m1.cs.man.ac.uk (m1.cs.man.ac.uk [130.88.192.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21361
	for ; Tue, 16 Jul 2002 11:10:30 -0400 (EDT)
Received: from ug003.cs.man.ac.uk by m1.cs.man.ac.uk (8.8.8/AL/MJK-2.0)
	id QAA10377; Tue, 16 Jul 2002 16:11:20 +0100 (BST)
Received: (from tapselj0@localhost)
	by ug003.cs.man.ac.uk (8.11.6/8.9.3) id g6GFB9I01337
	for manet@ietf.org; Tue, 16 Jul 2002 16:11:09 +0100
Date: Tue, 16 Jul 2002 16:11:09 +0100
From: John Tapsell 
To: manet@ietf.org
Message-ID: <20020716161109.C1317@ug003.cs.man.ac.uk>
References:  <200207141505.IAA15632@pit.erg.sri.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200207141505.IAA15632@pit.erg.sri.com>; from ogier@erg.sri.com on Sun, Jul 14, 2002 at 08:05:55AM -0700
Subject: [manet] QOSPF, RSVP, etc
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
  What implementations (actual or simulators) are there for the various
ways of doing QoS on a manet?
  I couldn't find any code for QOSPF, and draft-zhang-qos-01.txt (or
something) has expired...
  I found a 2.2 implementation of RSVP over mobile ip, which isn't quite the
same as a manet - are there any dRSVP implementations or anything?


Thanks

JohnFlux

-- 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Tue Jul 16 12:41:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22296
	for ; Tue, 16 Jul 2002 11:48:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA05155
	for manet-archive@odin.ietf.org; Tue, 16 Jul 2002 11:48:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03606;
	Tue, 16 Jul 2002 11:27:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03579
	for ; Tue, 16 Jul 2002 11:27:42 -0400 (EDT)
Received: from bjapp15.163.net ([202.108.255.197])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21745
	for ; Tue, 16 Jul 2002 11:26:42 -0400 (EDT)
Received: by bjapp15.163.net (Postfix, from userid 1005)
	id 4926A1CBA570B; Tue, 16 Jul 2002 23:27:36 +0800 (CST)
MIME-Version: 1.0
Message-ID: <3D343B68.00001D.00926@bjapp15>
Date: Tue, 16 Jul 2002 23:27:36 +0800 (CST)
From: "Íõº£" 
To: yuanyg@cs.dartmouth.edu
Cc: manet@ietf.org
X-Priority: 3
X-Originating-IP: [218.2.151.246]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
Content-Type: Multipart/Alternative; boundary="Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh"
Subject: [manet] =?gb2312?B?UmU6IFttYW5ldF0gUmU6IE1BQyBzZXF1ZW5jZSBudW1iZXI=?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
    I read Glomosim source of 802.11, it uses 1 bit to represent sequence number. I think there is no need for sequence number negotiation process in the 802.11. When one of the talking side reboot, as you may discover, two sides may have different sequence number. For example, when B reboot, A's sequence number is different from B, the sequence number of A is 1, B is 0. then A send a packet with sequence number 1, B will find the packet number from A is different from what it expected from A. Then B regards this packet as an obsolete packet, return ACK with sequence number 0, and A will think that this packet is accepted by B, its sequence number will increase to 0, then two sides will have the same sequence number thereafter. I think this may be called "sequence number negotiation" if you insist, With the worst payment of 1 packet loss. However, in a real implementation, when reboot, system will become stable after a certain period(such as for route discovery), during this!
  period, a packet loss means little for the whole system. So I think if your system does not shut down and restart frequently, this simple negotiation scheme will work. No complicated sequence number negotiation process is needed.

B.R   
Hai Wang


> I think I should make my question more clear. I read some part of the 
> standard. It didn't say clearly that there is anything like handshaking. 
> 
> If two nodes, A and B, just meet, they can set the sequence numbers from 
> their first exchanged packets, that's ok. But if after a while, A reboots, 
> coming back with a clean cache, while B still keeps the old sequence number 
> cache, there is a clear mismatch that will cause them to drop packets from 
> each other unless they can settle down on a new sequnce number. I'm wondering 
> how this is done. Does it depends on a timer of the sequence number cache? Or 
> some field in the MAC header?
> 
> 
> On Thursday 11 July 2002 13:47, Yougu Yuan wrote:
> > Hi, all. Maybe it is a little bit off topic to send this question to manet,
> > but I have a question about the MAC802.11 packet sequence number.
> >
> > In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> > when two nodes meet, how do the negotiate the sequence number pair? Is
> > there a special bit in the header that says "reset the sequence number of
> > me to the sequence number in this packet"? I'm reading the 802.11 standard,
> > but it's too thick for a quick answer.
> >
> > Thanks in advance.
> 
> -- 
> Yougu Yuan
> 
> ----------------------------------------------------
> Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
> Dept. of Computer Science, Dartmouth College
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> 
--Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
    I read Glomosim source of 802.11, it uses 1 bit to represent sequence number. I think there is no need for sequence number negotiation process in the 802.11. When one of the talking side reboot, as you may discover, two sides may have different sequence number. For example, when B reboot, A's sequence number is different from B, the sequence number of A is 1, B is 0. then A send a packet with sequence number 1, B will find the packet number from A is different from what it expected from A. Then B regards this packet as an obsolete packet, return ACK with sequence number 0, and A will think that this packet is accepted by B, its sequence number will increase to 0, then two sides will have the same sequence number thereafter. I think this may be called "sequence number negotiation" if you insist, With the worst payment of 1 packet loss. However, in a real implementation, when reboot, system will become stable after a certain period(such as for !
 route discovery), during this period, a packet loss means little for the whole system. So I think if your system does not shut down and restart frequently, this simple negotiation scheme will work. No complicated sequence number negotiation process is needed.

B.R   
Hai Wang


> I think I should make my question more clear. I read some part of the 
> standard. It didn't say clearly that there is anything like handshaking. 
> 
> If two nodes, A and B, just meet, they can set the sequence numbers from 
> their first exchanged packets, that's ok. But if after a while, A reboots, 
> coming back with a clean cache, while B still keeps the old sequence number 
> cache, there is a clear mismatch that will cause them to drop packets from 
> each other unless they can settle down on a new sequnce number. I'm wondering 
> how this is done. Does it depends on a timer of the sequence number cache? Or 
> some fi!
 eld in the MAC header?
> 
> 
> On Thursday 11 July 2
002 13:47, Yougu Yuan wrote:
> > Hi, all. Maybe it is a little bit off topic to send this question to manet,
> > but I have a question about the MAC802.11 packet sequence number.
> >
> > In the MAC802.11 header, there is a sequence number. In ad-hoc network,
> > when two nodes meet, how do the negotiate the sequence number pair? Is
> > there a special bit in the header that says "reset the sequence number of
> > me to the sequence number in this packet"? I'm reading the 802.11 standard,
> > but it's too thick for a quick answer.
> >
> > Thanks in advance.
> 
> -- 
> Yougu Yuan
> 
> ----------------------------------------------------
> Office Phone 603-646-0679    yuanyg@cs.dartmouth.edu
> Dept. of Computer Science, Dartmouth College
> 
> _______________________________________________
> manet mailing list
> man!
 et@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> 

--Boundary-=_sfxARigbMViIjEgqjNhYmEPjTkQh--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 16 14:19:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26061
	for ; Tue, 16 Jul 2002 14:19:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12235;
	Tue, 16 Jul 2002 13:47:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12207
	for ; Tue, 16 Jul 2002 13:47:01 -0400 (EDT)
Received: from xmxpita.excite.com (nat4.excitenetwork.com [63.236.75.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25257
	for ; Tue, 16 Jul 2002 13:46:03 -0400 (EDT)
Received: by xmxpita.excite.com (Postfix, from userid 110)
	id CC34429A0B; Tue, 16 Jul 2002 13:46:27 -0400 (EDT)
To: manet@ietf.org
Received: from [128.163.6.77] by xprdmailfe23.nwk.excite.com via HTTP; Tue, 16 Jul 2002 13:46:27 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = 6af70e33fb583ccba3c88d08fec18d99
Reply-To: jw2000@excite.com
From: "Jack Wang" 
MIME-Version: 1.0
X-Sender: jw2000@excite.com
X-Mailer: PHP
Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1";
Content-Transfer-Encoding: 7bit
Message-Id: <20020716174627.CC34429A0B@xmxpita.excite.com>
Date: Tue, 16 Jul 2002 13:46:27 -0400 (EDT)
Subject: [manet] promiscuous mode
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org




--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Hi All: We know "promiscuous mode" can be used to monitor data traffic in a network. How about its application in ad hoc networks?Is there any published materials that I can refer to? Thanks. Jack 

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
Hi All:
 
We know "promiscuous mode" can be used to monitor data traffic in a network. How about its application in ad hoc networks?
Is there any published materials that I can refer to?
 
Thanks.
 
Jack 



Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 16 14:19:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26070
	for ; Tue, 16 Jul 2002 14:19:13 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA14434
	for manet-archive@odin.ietf.org; Tue, 16 Jul 2002 14:20:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12235;
	Tue, 16 Jul 2002 13:47:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12207
	for ; Tue, 16 Jul 2002 13:47:01 -0400 (EDT)
Received: from xmxpita.excite.com (nat4.excitenetwork.com [63.236.75.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25257
	for ; Tue, 16 Jul 2002 13:46:03 -0400 (EDT)
Received: by xmxpita.excite.com (Postfix, from userid 110)
	id CC34429A0B; Tue, 16 Jul 2002 13:46:27 -0400 (EDT)
To: manet@ietf.org
Received: from [128.163.6.77] by xprdmailfe23.nwk.excite.com via HTTP; Tue, 16 Jul 2002 13:46:27 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = 6af70e33fb583ccba3c88d08fec18d99
Reply-To: jw2000@excite.com
From: "Jack Wang" 
MIME-Version: 1.0
X-Sender: jw2000@excite.com
X-Mailer: PHP
Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1";
Content-Transfer-Encoding: 7bit
Message-Id: <20020716174627.CC34429A0B@xmxpita.excite.com>
Date: Tue, 16 Jul 2002 13:46:27 -0400 (EDT)
Subject: [manet] promiscuous mode
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org




--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Hi All: We know "promiscuous mode" can be used to monitor data traffic in a network. How about its application in ad hoc networks?Is there any published materials that I can refer to? Thanks. Jack 

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
Hi All:
 
We know "promiscuous mode" can be used to monitor data traffic in a network. How about its application in ad hoc networks?
Is there any published materials that I can refer to?
 
Thanks.
 
Jack 



Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 04:18:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09596
	for ; Wed, 17 Jul 2002 04:18:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19610;
	Wed, 17 Jul 2002 03:57:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19579
	for ; Wed, 17 Jul 2002 03:57:09 -0400 (EDT)
Received: from bjapp9.163.net ([202.108.255.198])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09088
	for ; Wed, 17 Jul 2002 03:56:04 -0400 (EDT)
Received: by bjapp9.163.net (Postfix, from userid 1005)
	id 63CA51C6210AA; Wed, 17 Jul 2002 15:56:57 +0800 (CST)
MIME-Version: 1.0
Message-ID: <3D352349.00000B.06702@bjapp9>
Date: Wed, 17 Jul 2002 15:56:57 +0800 (CST)
From: "Íõº£" 
To: yuanyg@cs.dartmouth.edu
Cc: manet@ietf.org
X-Priority: 3
X-Originating-IP: [218.2.151.246]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
Content-Type: Multipart/Alternative; boundary="Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY"
Subject: [manet] =?gb2312?B?UmU6IE1BQyBzZXF1ZW5jZSBudW1iZXI=?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
   Firstly, I am very sorry for my misleading.:(
   I recheck the code, instead of using 1 bit, it uses "int" to represent sequence number, so it meets standard requirement. There is a bug in my mind. :)
   In fact, if 12 bit sequence number is used, same scheme which I described in last mail will work too, and packet loss probability will become ignorable.  If B restart, it may start from sequence number 0, or some random sequence number M, between 0 to 4095.  A send packet with sequence number K to B, only when [K+1]MOD 4096=M will cause packet loss. For other cases, B will discard this packet, reply ACK with sequence number M, and A will find that the sequence number of ACK is not what it expected, then A understand that the sequence number has not yet been synchronized, A change its sequence number to M, send the packet again, and B will ACK normally. Both sides will have the right sequence number from then on. 
   Surprisingly, in Glomosim source code, It is not working as I suggested. The sending packet sure has sequence number, however, the ACK does not carry any sequence number at all. I don't know how to do ¡°sequence number negotiation¡± in such environment. Maybe there is someone in this mail list will give us more authoritative answer.

Hai Wang


> Thanks for checking the code. But in 802.11 standard, it uses 12 bits for the 
> sequence number, as I barely remember. So it's not a one bit change any more. 
> Of course one doesn't want to waste too many packets for the sequence number 
> mismatch. So I think in the real implementation there must be something else 
> there.
> 
> Best regards.
> 
> On Tuesday 16 July 2002 11:27, you wrote:
> > Hi, Yougu Yuan:
> >     I read Glomosim source of 802.11, it uses 1 bit to represent sequence
> > number. I think there is no need for sequence number negotiation process in
> > the 802.11. When one of the talking side reboot, as you may discover, two
> > sides may have different sequence number. For example, when B reboot, A's
> > sequence number is different from B, the sequence number of A is 1, B is 0.
> > then A send a packet with sequence number 1, B will find the packet number
> > from A is different from what it expected from A. Then B regards this
> > packet as an obsolete packet, return ACK with sequence number 0, and A will
> > think that this packet is accepted by B, its sequence number will increase
> > to 0, then two sides will have the same sequence number thereafter. I think
> > this may be called "sequence number negotiation" if you insist, With the
> > worst payment of 1 packet loss. However, in a real implementation, when
> > reboot, system will become stable after a certain period(such as for route
> > discovery), during this period, a packet loss means little for the whole
> > system. So I think if your system does not shut down and restart
> > frequently, this simple negotiation scheme will work. No complicated
> > sequence number negotiation process is needed.
> >
> > B.R
> > Hai Wang

--Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
   Firstly, I am very sorry for my misleading.:(
   I recheck the code, instead of using 1 bit, it uses "int" to represent sequence number, so it meets standard requirement. There is a bug in my mind. :)
   In fact, if 12 bit sequence number is used, same scheme which I described in last mail will work too, and packet loss probability will become ignorable.  If B restart, it may start from sequence number 0, or some random sequence number M, between 0 to 4095.  A send packet with sequence number K to B, only when [K+1]MOD 4096=M will cause packet loss. For other cases, B will discard this packet, reply ACK with sequence number M, and A will find that the sequence number of ACK is not what it expected, then A understand that the sequence number has not yet been synchronized, A change its sequence number to M, send the packet again, and B will ACK normally. Both sides will have the right sequence number from then on. 
   Surprisingly, in G!
 lomosim source code, It is not working as I suggested. The sending packet sure has sequence number, however, the ACK does not carry any sequence number at all. I don't know how to do ¡°sequence number negotiation¡± in such environment. Maybe there is someone in this mail list will give us more authoritative answer.

Hai Wang


> Thanks for checking the code. But in 802.11 standard, it uses 12 bits for the 
> sequence number, as I barely remember. So it's not a one bit change any more. 
> Of course one doesn't want to waste too many packets for the sequence number 
> mismatch. So I think in the real implementation there must be something else 
> there.
> 
> Best regards.
> 
> On Tuesday 16 July 2002 11:27, you wrote:
> > Hi, Yougu Yuan:
> >     I read Glomosim source of 802.11, it uses 1 bit to represent sequence
> > number. I think there is no need for sequence number negotiation pr!
 ocess in
> > the 802.11. When one of the talking side reboot,
 as you may discover, two
> > sides may have different sequence number. For example, when B reboot, A's
> > sequence number is different from B, the sequence number of A is 1, B is 0.
> > then A send a packet with sequence number 1, B will find the packet number
> > from A is different from what it expected from A. Then B regards this
> > packet as an obsolete packet, return ACK with sequence number 0, and A will
> > think that this packet is accepted by B, its sequence number will increase
> > to 0, then two sides will have the same sequence number thereafter. I think
> > this may be called "sequence number negotiation" if you insist, With the
> > worst payment of 1 packet loss. However, in a real implementation, when
> > reboot, system will become stable after a certain period(such as for route
> > discovery), during this period, a packet loss means little for the w!
 hole
> > system. So I think if your system does not shut down and restart
> > frequently, this simple negotiation scheme will work. No complicated
> > sequence number negotiation process is needed.
> >
> > B.R
> > Hai Wang


--Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 05:19:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09605
	for ; Wed, 17 Jul 2002 04:18:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA21502
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 04:19:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19610;
	Wed, 17 Jul 2002 03:57:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19579
	for ; Wed, 17 Jul 2002 03:57:09 -0400 (EDT)
Received: from bjapp9.163.net ([202.108.255.198])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09088
	for ; Wed, 17 Jul 2002 03:56:04 -0400 (EDT)
Received: by bjapp9.163.net (Postfix, from userid 1005)
	id 63CA51C6210AA; Wed, 17 Jul 2002 15:56:57 +0800 (CST)
MIME-Version: 1.0
Message-ID: <3D352349.00000B.06702@bjapp9>
Date: Wed, 17 Jul 2002 15:56:57 +0800 (CST)
From: "Íõº£" 
To: yuanyg@cs.dartmouth.edu
Cc: manet@ietf.org
X-Priority: 3
X-Originating-IP: [218.2.151.246]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
Content-Type: Multipart/Alternative; boundary="Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY"
Subject: [manet] =?gb2312?B?UmU6IE1BQyBzZXF1ZW5jZSBudW1iZXI=?=
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
   Firstly, I am very sorry for my misleading.:(
   I recheck the code, instead of using 1 bit, it uses "int" to represent sequence number, so it meets standard requirement. There is a bug in my mind. :)
   In fact, if 12 bit sequence number is used, same scheme which I described in last mail will work too, and packet loss probability will become ignorable.  If B restart, it may start from sequence number 0, or some random sequence number M, between 0 to 4095.  A send packet with sequence number K to B, only when [K+1]MOD 4096=M will cause packet loss. For other cases, B will discard this packet, reply ACK with sequence number M, and A will find that the sequence number of ACK is not what it expected, then A understand that the sequence number has not yet been synchronized, A change its sequence number to M, send the packet again, and B will ACK normally. Both sides will have the right sequence number from then on. 
   Surprisingly, in Glomosim source code, It is not working as I suggested. The sending packet sure has sequence number, however, the ACK does not carry any sequence number at all. I don't know how to do ¡°sequence number negotiation¡± in such environment. Maybe there is someone in this mail list will give us more authoritative answer.

Hai Wang


> Thanks for checking the code. But in 802.11 standard, it uses 12 bits for the 
> sequence number, as I barely remember. So it's not a one bit change any more. 
> Of course one doesn't want to waste too many packets for the sequence number 
> mismatch. So I think in the real implementation there must be something else 
> there.
> 
> Best regards.
> 
> On Tuesday 16 July 2002 11:27, you wrote:
> > Hi, Yougu Yuan:
> >     I read Glomosim source of 802.11, it uses 1 bit to represent sequence
> > number. I think there is no need for sequence number negotiation process in
> > the 802.11. When one of the talking side reboot, as you may discover, two
> > sides may have different sequence number. For example, when B reboot, A's
> > sequence number is different from B, the sequence number of A is 1, B is 0.
> > then A send a packet with sequence number 1, B will find the packet number
> > from A is different from what it expected from A. Then B regards this
> > packet as an obsolete packet, return ACK with sequence number 0, and A will
> > think that this packet is accepted by B, its sequence number will increase
> > to 0, then two sides will have the same sequence number thereafter. I think
> > this may be called "sequence number negotiation" if you insist, With the
> > worst payment of 1 packet loss. However, in a real implementation, when
> > reboot, system will become stable after a certain period(such as for route
> > discovery), during this period, a packet loss means little for the whole
> > system. So I think if your system does not shut down and restart
> > frequently, this simple negotiation scheme will work. No complicated
> > sequence number negotiation process is needed.
> >
> > B.R
> > Hai Wang

--Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi, Yougu Yuan:
   Firstly, I am very sorry for my misleading.:(
   I recheck the code, instead of using 1 bit, it uses "int" to represent sequence number, so it meets standard requirement. There is a bug in my mind. :)
   In fact, if 12 bit sequence number is used, same scheme which I described in last mail will work too, and packet loss probability will become ignorable.  If B restart, it may start from sequence number 0, or some random sequence number M, between 0 to 4095.  A send packet with sequence number K to B, only when [K+1]MOD 4096=M will cause packet loss. For other cases, B will discard this packet, reply ACK with sequence number M, and A will find that the sequence number of ACK is not what it expected, then A understand that the sequence number has not yet been synchronized, A change its sequence number to M, send the packet again, and B will ACK normally. Both sides will have the right sequence number from then on. 
   Surprisingly, in G!
 lomosim source code, It is not working as I suggested. The sending packet sure has sequence number, however, the ACK does not carry any sequence number at all. I don't know how to do ¡°sequence number negotiation¡± in such environment. Maybe there is someone in this mail list will give us more authoritative answer.

Hai Wang


> Thanks for checking the code. But in 802.11 standard, it uses 12 bits for the 
> sequence number, as I barely remember. So it's not a one bit change any more. 
> Of course one doesn't want to waste too many packets for the sequence number 
> mismatch. So I think in the real implementation there must be something else 
> there.
> 
> Best regards.
> 
> On Tuesday 16 July 2002 11:27, you wrote:
> > Hi, Yougu Yuan:
> >     I read Glomosim source of 802.11, it uses 1 bit to represent sequence
> > number. I think there is no need for sequence number negotiation pr!
 ocess in
> > the 802.11. When one of the talking side reboot,
 as you may discover, two
> > sides may have different sequence number. For example, when B reboot, A's
> > sequence number is different from B, the sequence number of A is 1, B is 0.
> > then A send a packet with sequence number 1, B will find the packet number
> > from A is different from what it expected from A. Then B regards this
> > packet as an obsolete packet, return ACK with sequence number 0, and A will
> > think that this packet is accepted by B, its sequence number will increase
> > to 0, then two sides will have the same sequence number thereafter. I think
> > this may be called "sequence number negotiation" if you insist, With the
> > worst payment of 1 packet loss. However, in a real implementation, when
> > reboot, system will become stable after a certain period(such as for route
> > discovery), during this period, a packet loss means little for the w!
 hole
> > system. So I think if your system does not shut down and restart
> > frequently, this simple negotiation scheme will work. No complicated
> > sequence number negotiation process is needed.
> >
> > B.R
> > Hai Wang


--Boundary-=_zcvQoTVrSzfqSXxEGLFwnArgUkuY--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 07:20:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12817
	for ; Wed, 17 Jul 2002 07:20:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29413;
	Wed, 17 Jul 2002 07:02:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29380
	for ; Wed, 17 Jul 2002 07:02:51 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12265
	for ; Wed, 17 Jul 2002 07:01:53 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id EAA07578;
	Wed, 17 Jul 2002 04:02:19 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HB2In18055;
	Wed, 17 Jul 2002 04:02:18 -0700
X-mProtect: <200207171102> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdc9PvKE; Wed, 17 Jul 2002 04:02:16 PDT
Message-ID: <3D354E51.A2381E8A@iprg.nokia.com>
Date: Wed, 17 Jul 2002 04:00:34 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Johnson 
CC: Mobile Ad Hoc IETF working group 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [manet] "Global6" --> Internet connectivity for ad hoc networks
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Dave,

I am definitely interested in getting your comments about our
draft which we had called "Global6".  It is our intention to make
it serve for the various manet protocols, and DSR is in fact
the one we have paid most effort on after AODV.

I reckon we'd generally work pretty hard to fix it according
to whatever mistakes you find.

Regards,
Charlie P.






_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Wed Jul 17 08:13:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14170
	for ; Wed, 17 Jul 2002 08:13:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02065;
	Wed, 17 Jul 2002 07:53:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02034
	for ; Wed, 17 Jul 2002 07:53:37 -0400 (EDT)
Received: from naava.cc.jyu.fi (naava.cc.jyu.fi [130.234.4.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13524
	for ; Wed, 17 Jul 2002 07:52:38 -0400 (EDT)
From: gsenen@cc.jyu.fi
Received: (from apache@localhost)
	by naava.cc.jyu.fi (8.11.6/8.11.6) id g6HBrXY31740
	for manet@ietf.org; Wed, 17 Jul 2002 14:53:33 +0300
X-Authentication-Warning: naava.cc.jyu.fi: apache set sender to gsenen@cc.jyu.fi using -f
To: manet@ietf.org
Message-ID: <1026906813.3d355abde5801@webmail.cc.jyu.fi>
Date: Wed, 17 Jul 2002 14:53:33 +0300 (EEST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.6
Content-Transfer-Encoding: 8bit
Subject: [manet] How do you parse trace files?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello
I simulate Ad Hoc networks and use AODV and DSR routing protocols. As I 
understood I have to parse trace file to get some results. But I have problems 
with understanding these files, because i found sources, but they have 
different format. In my case i have the following trace file 

s 127.936679222 _0_ AGT  --- 0 cbr 512 [0 0 0 0] ------- [0:0 2:0 32 0] [0] 0 3
r 128.033408580 _2_ AGT  --- 0 cbr 544 [a2 2 1 800] ------- [0:0 2:0 32 2] [0] 
2 3

I undersood that
s - event (send)
127.936679222 - time
_0_ from node
AGT  trace level
---  flag 
0 i don't know what it is
cbr constant bit rate
512 number of bytes

But other characters I don't understand, I suppose that [0:0 2:0 32 0] means 
source and destination address in form of "node:port".Can somebody give me 
advice how to explain these characters, please? Actually I need to have packet 
id and how to distinguish data from routing information.
Thanks in advance.
Best regards, Georgiy.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 08:13:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14179
	for ; Wed, 17 Jul 2002 08:13:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA03534
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 08:14:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02065;
	Wed, 17 Jul 2002 07:53:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02034
	for ; Wed, 17 Jul 2002 07:53:37 -0400 (EDT)
Received: from naava.cc.jyu.fi (naava.cc.jyu.fi [130.234.4.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13524
	for ; Wed, 17 Jul 2002 07:52:38 -0400 (EDT)
From: gsenen@cc.jyu.fi
Received: (from apache@localhost)
	by naava.cc.jyu.fi (8.11.6/8.11.6) id g6HBrXY31740
	for manet@ietf.org; Wed, 17 Jul 2002 14:53:33 +0300
X-Authentication-Warning: naava.cc.jyu.fi: apache set sender to gsenen@cc.jyu.fi using -f
To: manet@ietf.org
Message-ID: <1026906813.3d355abde5801@webmail.cc.jyu.fi>
Date: Wed, 17 Jul 2002 14:53:33 +0300 (EEST)
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.6
Content-Transfer-Encoding: 8bit
Subject: [manet] How do you parse trace files?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello
I simulate Ad Hoc networks and use AODV and DSR routing protocols. As I 
understood I have to parse trace file to get some results. But I have problems 
with understanding these files, because i found sources, but they have 
different format. In my case i have the following trace file 

s 127.936679222 _0_ AGT  --- 0 cbr 512 [0 0 0 0] ------- [0:0 2:0 32 0] [0] 0 3
r 128.033408580 _2_ AGT  --- 0 cbr 544 [a2 2 1 800] ------- [0:0 2:0 32 2] [0] 
2 3

I undersood that
s - event (send)
127.936679222 - time
_0_ from node
AGT  trace level
---  flag 
0 i don't know what it is
cbr constant bit rate
512 number of bytes

But other characters I don't understand, I suppose that [0:0 2:0 32 0] means 
source and destination address in form of "node:port".Can somebody give me 
advice how to explain these characters, please? Actually I need to have packet 
id and how to distinguish data from routing information.
Thanks in advance.
Best regards, Georgiy.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Wed Jul 17 08:21:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12822
	for ; Wed, 17 Jul 2002 07:20:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA00310
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 07:21:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29413;
	Wed, 17 Jul 2002 07:02:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29380
	for ; Wed, 17 Jul 2002 07:02:51 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12265
	for ; Wed, 17 Jul 2002 07:01:53 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id EAA07578;
	Wed, 17 Jul 2002 04:02:19 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HB2In18055;
	Wed, 17 Jul 2002 04:02:18 -0700
X-mProtect: <200207171102> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdc9PvKE; Wed, 17 Jul 2002 04:02:16 PDT
Message-ID: <3D354E51.A2381E8A@iprg.nokia.com>
Date: Wed, 17 Jul 2002 04:00:34 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Johnson 
CC: Mobile Ad Hoc IETF working group 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [manet] "Global6" --> Internet connectivity for ad hoc networks
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Dave,

I am definitely interested in getting your comments about our
draft which we had called "Global6".  It is our intention to make
it serve for the various manet protocols, and DSR is in fact
the one we have paid most effort on after AODV.

I reckon we'd generally work pretty hard to fix it according
to whatever mistakes you find.

Regards,
Charlie P.






_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 08:38:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14677
	for ; Wed, 17 Jul 2002 08:38:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03996;
	Wed, 17 Jul 2002 08:20:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03967
	for ; Wed, 17 Jul 2002 08:20:23 -0400 (EDT)
Received: from infres.enst.fr (infres.enst.fr [137.194.160.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14333
	for ; Wed, 17 Jul 2002 08:19:25 -0400 (EDT)
Received: from schaula (dhcp162-223.enst.fr [137.194.162.223])
	by infres.enst.fr (Postfix) with SMTP
	id 8A6FE1BDB; Wed, 17 Jul 2002 14:20:21 +0200 (MEST)
Message-ID: <008501c22d8d$741e0bc0$dfa2c289@galaxy.enst.fr>
From: "Moustafa Hasnaa" 
To: , 
References:  <1026906813.3d355abde5801@webmail.cc.jyu.fi>
Subject: Re: [manet] How do you parse trace files?
Date: Wed, 17 Jul 2002 14:28:28 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="KOI8-R"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Concerning the trace files, i do not know exactly which version of ns are u
using.
 As far as i know for verion 2.17 , parsing trace files is well explained in
the manuel.
     The ns Manual (formely ns Notes and Documentation)

Hope this can help
regards
----- Original Message -----
From: 
To: 
Sent: Wednesday, July 17, 2002 1:53 PM
Subject: [manet] How do you parse trace files?


> Hello
> I simulate Ad Hoc networks and use AODV and DSR routing protocols. As I
> understood I have to parse trace file to get some results. But I have
problems
> with understanding these files, because i found sources, but they have
> different format. In my case i have the following trace file
>
> s 127.936679222 _0_ AGT  --- 0 cbr 512 [0 0 0 0] ------- [0:0 2:0 32 0]
[0] 0 3
> r 128.033408580 _2_ AGT  --- 0 cbr 544 [a2 2 1 800] ------- [0:0 2:0 32 2]
[0]
> 2 3
>
> I undersood that
> s - event (send)
> 127.936679222 - time
> _0_ from node
> AGT  trace level
> ---  flag
> 0 i don't know what it is
> cbr constant bit rate
> 512 number of bytes
>
> But other characters I don't understand, I suppose that [0:0 2:0 32 0]
means
> source and destination address in form of "node:port".Can somebody give me
> advice how to explain these characters, please? Actually I need to have
packet
> id and how to distinguish data from routing information.
> Thanks in advance.
> Best regards, Georgiy.
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 08:38:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14685
	for ; Wed, 17 Jul 2002 08:38:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA05476
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 08:39:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03996;
	Wed, 17 Jul 2002 08:20:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03967
	for ; Wed, 17 Jul 2002 08:20:23 -0400 (EDT)
Received: from infres.enst.fr (infres.enst.fr [137.194.160.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14333
	for ; Wed, 17 Jul 2002 08:19:25 -0400 (EDT)
Received: from schaula (dhcp162-223.enst.fr [137.194.162.223])
	by infres.enst.fr (Postfix) with SMTP
	id 8A6FE1BDB; Wed, 17 Jul 2002 14:20:21 +0200 (MEST)
Message-ID: <008501c22d8d$741e0bc0$dfa2c289@galaxy.enst.fr>
From: "Moustafa Hasnaa" 
To: , 
References:  <1026906813.3d355abde5801@webmail.cc.jyu.fi>
Subject: Re: [manet] How do you parse trace files?
Date: Wed, 17 Jul 2002 14:28:28 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="KOI8-R"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Concerning the trace files, i do not know exactly which version of ns are u
using.
 As far as i know for verion 2.17 , parsing trace files is well explained in
the manuel.
     The ns Manual (formely ns Notes and Documentation)

Hope this can help
regards
----- Original Message -----
From: 
To: 
Sent: Wednesday, July 17, 2002 1:53 PM
Subject: [manet] How do you parse trace files?


> Hello
> I simulate Ad Hoc networks and use AODV and DSR routing protocols. As I
> understood I have to parse trace file to get some results. But I have
problems
> with understanding these files, because i found sources, but they have
> different format. In my case i have the following trace file
>
> s 127.936679222 _0_ AGT  --- 0 cbr 512 [0 0 0 0] ------- [0:0 2:0 32 0]
[0] 0 3
> r 128.033408580 _2_ AGT  --- 0 cbr 544 [a2 2 1 800] ------- [0:0 2:0 32 2]
[0]
> 2 3
>
> I undersood that
> s - event (send)
> 127.936679222 - time
> _0_ from node
> AGT  trace level
> ---  flag
> 0 i don't know what it is
> cbr constant bit rate
> 512 number of bytes
>
> But other characters I don't understand, I suppose that [0:0 2:0 32 0]
means
> source and destination address in form of "node:port".Can somebody give me
> advice how to explain these characters, please? Actually I need to have
packet
> id and how to distinguish data from routing information.
> Thanks in advance.
> Best regards, Georgiy.
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 09:20:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15666
	for ; Wed, 17 Jul 2002 09:20:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06354;
	Wed, 17 Jul 2002 08:59:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06323
	for ; Wed, 17 Jul 2002 08:59:30 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15076
	for ; Wed, 17 Jul 2002 08:58:31 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117130>; Wed, 17 Jul 2002 06:59:27 -0600
Message-Id: <02Jul17.065927mdt.117130@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: jw2000@excite.com, manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Wed, 17 Jul 2002 06:59:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Jack,

The two ad hoc protocols I am aware of that employ promiscuous mode are
Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).

John Mullen


-----Original Message-----
From: Jack Wang [mailto:jw2000@excite.com]
Sent: Tuesday, July 16, 2002 11:46 AM
To: manet@ietf.org
Subject: [manet] promiscuous mode





--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Hi All: We know "promiscuous mode" can be used to monitor data traffic in a
network. How about its application in ad hoc networks?Is there any published
materials that I can refer to? Thanks. Jack 

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
Hi All:


We know "promiscuous mode" can be used to monitor data traffic in
a network. How about its application in ad hoc networks?
Is there
any published materials that I can refer to?


Thanks.
 
Jack




Join Excite! - http://www.excite.com
The most personalized portal on
the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 09:20:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15674
	for ; Wed, 17 Jul 2002 09:20:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA08139
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 09:21:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06354;
	Wed, 17 Jul 2002 08:59:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06323
	for ; Wed, 17 Jul 2002 08:59:30 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15076
	for ; Wed, 17 Jul 2002 08:58:31 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117130>; Wed, 17 Jul 2002 06:59:27 -0600
Message-Id: <02Jul17.065927mdt.117130@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: jw2000@excite.com, manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Wed, 17 Jul 2002 06:59:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Jack,

The two ad hoc protocols I am aware of that employ promiscuous mode are
Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).

John Mullen


-----Original Message-----
From: Jack Wang [mailto:jw2000@excite.com]
Sent: Tuesday, July 16, 2002 11:46 AM
To: manet@ietf.org
Subject: [manet] promiscuous mode





--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Hi All: We know "promiscuous mode" can be used to monitor data traffic in a
network. How about its application in ad hoc networks?Is there any published
materials that I can refer to? Thanks. Jack 

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
Hi All:


We know "promiscuous mode" can be used to monitor data traffic in
a network. How about its application in ad hoc networks?
Is there
any published materials that I can refer to?


Thanks.
 
Jack




Join Excite! - http://www.excite.com
The most personalized portal on
the Web!

--EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Wed Jul 17 10:27:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17640
	for ; Wed, 17 Jul 2002 10:27:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13523
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 10:28:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11969;
	Wed, 17 Jul 2002 10:04:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11927
	for ; Wed, 17 Jul 2002 10:04:02 -0400 (EDT)
Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16962
	for ; Wed, 17 Jul 2002 10:03:02 -0400 (EDT)
From: haas@ece.cornell.edu
Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71])
	by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g6HDxia28143;
	Wed, 17 Jul 2002 09:59:44 -0400
Date: Wed, 17 Jul 2002 10:03:50 -0400 (EDT)
X-Sender: haas@verdi.ee.cornell.edu
To: "Mullen, John P. (Contractor)" 
cc: jw2000@excite.com, manet@ietf.org
Subject: RE: [manet] promiscuous mode
In-Reply-To: <02Jul17.065927mdt.117130@gw.trac.wsmr.army.mil>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi John,

In general, use of promiscuous mode can lead to substantial saving in
control traffic in most of the reactive protocols, for example by
eavesdropping on the route replies and storing this information to reply
to future route requests.

Just as another point of reference, ZRP also uses promiscuous mode to
eavesdrop on the propagation of the route request queries, thus reducing
the unnecessary control traffic load. (This is one of the elements of 
the Query Control scheme in IERP).

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



On Wed, 17 Jul 2002, Mullen, John P. (Contractor) wrote:

> Hi Jack,
> 
> The two ad hoc protocols I am aware of that employ promiscuous mode are
> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).
> 
> John Mullen
> 
> 
> -----Original Message-----
> From: Jack Wang [mailto:jw2000@excite.com]
> Sent: Tuesday, July 16, 2002 11:46 AM
> To: manet@ietf.org
> Subject: [manet] promiscuous mode
> 
> 
> 
> 
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>  Hi All: We know "promiscuous mode" can be used to monitor data traffic in a
> network. How about its application in ad hoc networks?Is there any published
> materials that I can refer to? Thanks. Jack 
> 
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>   height=200>
Hi All:

> 
We know "promiscuous mode" can be used to monitor data traffic in
> a network. How about its application in ad hoc networks?
Is there
> any published materials that I can refer to?

> 
Thanks.
 
Jack
> 



Join Excite! -  href="http://www.excite.com/?PG=Email&SEC=Signature"
> target=_top>http://www.excite.com
The most personalized portal on
> the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 10:50:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18317
	for ; Wed, 17 Jul 2002 10:50:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14339;
	Wed, 17 Jul 2002 10:33:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14308
	for ; Wed, 17 Jul 2002 10:33:38 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17870
	for ; Wed, 17 Jul 2002 10:32:40 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117124>; Wed, 17 Jul 2002 08:33:35 -0600
Message-Id: <02Jul17.083335mdt.117124@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: haas@ece.cornell.edu
Cc: manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Wed, 17 Jul 2002 08:33:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Zygmunt,

Thanks.  

I think of promiscuous mode as an example of capitalizing on what would
otherwise would be a disadvantage.  I don't know who was the first bright
guy to figure out that eavesdropping could turn the wait for an open channel
into useful information gathering, but he or she had one heck of an idea!

:-)

Which leads me to ask:

Eavesdropping is an effective MANET strategy that could be used in a number
of protocols.  Another related strategy is the implicit ACK.  There are a
number of additional fundamental strategies.  Has anyone ever sat down and
described these basic MANET tools, independent of a specific protocol?

Wondering,

John Mullen

-----Original Message-----
From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu]
Sent: Wednesday, July 17, 2002 8:04 AM
To: Mullen, John P. (Contractor)
Cc: jw2000@excite.com; manet@ietf.org
Subject: RE: [manet] promiscuous mode


Hi John,

In general, use of promiscuous mode can lead to substantial saving in
control traffic in most of the reactive protocols, for example by
eavesdropping on the route replies and storing this information to reply
to future route requests.

Just as another point of reference, ZRP also uses promiscuous mode to
eavesdrop on the propagation of the route request queries, thus reducing
the unnecessary control traffic load. (This is one of the elements of 
the Query Control scheme in IERP).

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



On Wed, 17 Jul 2002, Mullen, John P. (Contractor) wrote:

> Hi Jack,
> 
> The two ad hoc protocols I am aware of that employ promiscuous mode are
> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).
> 
> John Mullen
> 
> 
> -----Original Message-----
> From: Jack Wang [mailto:jw2000@excite.com]
> Sent: Tuesday, July 16, 2002 11:46 AM
> To: manet@ietf.org
> Subject: [manet] promiscuous mode
> 
> 
> 
> 
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>  Hi All: We know "promiscuous mode" can be used to monitor data traffic in
a
> network. How about its application in ad hoc networks?Is there any
published
> materials that I can refer to? Thanks. Jack 
> 
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>   height=200>
Hi All:

> 
We know "promiscuous mode" can be used to monitor data traffic
in
> a network. How about its application in ad hoc networks?
Is
there
> any published materials that I can refer to?

> 
Thanks.
 
Jack
> 



Join Excite! -  href="http://www.excite.com/?PG=Email&SEC=Signature"
> target=_top>http://www.excite.com
The most personalized portal
on
> the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 10:50:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18325
	for ; Wed, 17 Jul 2002 10:50:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA15381
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 10:51:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14339;
	Wed, 17 Jul 2002 10:33:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14308
	for ; Wed, 17 Jul 2002 10:33:38 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17870
	for ; Wed, 17 Jul 2002 10:32:40 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117124>; Wed, 17 Jul 2002 08:33:35 -0600
Message-Id: <02Jul17.083335mdt.117124@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: haas@ece.cornell.edu
Cc: manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Wed, 17 Jul 2002 08:33:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Zygmunt,

Thanks.  

I think of promiscuous mode as an example of capitalizing on what would
otherwise would be a disadvantage.  I don't know who was the first bright
guy to figure out that eavesdropping could turn the wait for an open channel
into useful information gathering, but he or she had one heck of an idea!

:-)

Which leads me to ask:

Eavesdropping is an effective MANET strategy that could be used in a number
of protocols.  Another related strategy is the implicit ACK.  There are a
number of additional fundamental strategies.  Has anyone ever sat down and
described these basic MANET tools, independent of a specific protocol?

Wondering,

John Mullen

-----Original Message-----
From: haas@ece.cornell.edu [mailto:haas@ece.cornell.edu]
Sent: Wednesday, July 17, 2002 8:04 AM
To: Mullen, John P. (Contractor)
Cc: jw2000@excite.com; manet@ietf.org
Subject: RE: [manet] promiscuous mode


Hi John,

In general, use of promiscuous mode can lead to substantial saving in
control traffic in most of the reactive protocols, for example by
eavesdropping on the route replies and storing this information to reply
to future route requests.

Just as another point of reference, ZRP also uses promiscuous mode to
eavesdrop on the propagation of the route request queries, thus reducing
the unnecessary control traffic load. (This is one of the elements of 
the Query Control scheme in IERP).

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



On Wed, 17 Jul 2002, Mullen, John P. (Contractor) wrote:

> Hi Jack,
> 
> The two ad hoc protocols I am aware of that employ promiscuous mode are
> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).
> 
> John Mullen
> 
> 
> -----Original Message-----
> From: Jack Wang [mailto:jw2000@excite.com]
> Sent: Tuesday, July 16, 2002 11:46 AM
> To: manet@ietf.org
> Subject: [manet] promiscuous mode
> 
> 
> 
> 
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>  Hi All: We know "promiscuous mode" can be used to monitor data traffic in
a
> network. How about its application in ad hoc networks?Is there any
published
> materials that I can refer to? Thanks. Jack 
> 
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>   height=200>
Hi All:

> 
We know "promiscuous mode" can be used to monitor data traffic
in
> a network. How about its application in ad hoc networks?
Is
there
> any published materials that I can refer to?

> 
Thanks.
 
Jack
> 



Join Excite! -  href="http://www.excite.com/?PG=Email&SEC=Signature"
> target=_top>http://www.excite.com
The most personalized portal
on
> the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 11:16:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17634
	for ; Wed, 17 Jul 2002 10:27:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11969;
	Wed, 17 Jul 2002 10:04:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11927
	for ; Wed, 17 Jul 2002 10:04:02 -0400 (EDT)
Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16962
	for ; Wed, 17 Jul 2002 10:03:02 -0400 (EDT)
From: haas@ece.cornell.edu
Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71])
	by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g6HDxia28143;
	Wed, 17 Jul 2002 09:59:44 -0400
Date: Wed, 17 Jul 2002 10:03:50 -0400 (EDT)
X-Sender: haas@verdi.ee.cornell.edu
To: "Mullen, John P. (Contractor)" 
cc: jw2000@excite.com, manet@ietf.org
Subject: RE: [manet] promiscuous mode
In-Reply-To: <02Jul17.065927mdt.117130@gw.trac.wsmr.army.mil>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi John,

In general, use of promiscuous mode can lead to substantial saving in
control traffic in most of the reactive protocols, for example by
eavesdropping on the route replies and storing this information to reply
to future route requests.

Just as another point of reference, ZRP also uses promiscuous mode to
eavesdrop on the propagation of the route request queries, thus reducing
the unnecessary control traffic load. (This is one of the elements of 
the Query Control scheme in IERP).

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



On Wed, 17 Jul 2002, Mullen, John P. (Contractor) wrote:

> Hi Jack,
> 
> The two ad hoc protocols I am aware of that employ promiscuous mode are
> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).
> 
> John Mullen
> 
> 
> -----Original Message-----
> From: Jack Wang [mailto:jw2000@excite.com]
> Sent: Tuesday, July 16, 2002 11:46 AM
> To: manet@ietf.org
> Subject: [manet] promiscuous mode
> 
> 
> 
> 
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>  Hi All: We know "promiscuous mode" can be used to monitor data traffic in a
> network. How about its application in ad hoc networks?Is there any published
> materials that I can refer to? Thanks. Jack 
> 
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
>   height=200>
Hi All:

> 
We know "promiscuous mode" can be used to monitor data traffic in
> a network. How about its application in ad hoc networks?
Is there
> any published materials that I can refer to?

> 
Thanks.
 
Jack
> 



Join Excite! -  href="http://www.excite.com/?PG=Email&SEC=Signature"
> target=_top>http://www.excite.com
The most personalized portal on
> the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Wed Jul 17 13:18:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23802
	for ; Wed, 17 Jul 2002 13:18:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12675;
	Wed, 17 Jul 2002 12:55:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17872
	for ; Tue, 16 Jul 2002 15:36:59 -0400 (EDT)
Received: from tosh.netlab.uky.edu (tosh.netlab.uky.edu [204.198.76.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28029
	for ; Tue, 16 Jul 2002 15:36:00 -0400 (EDT)
Received: from gum.netlab.uky.edu (gum.netlab.uky.edu [204.198.76.71])
	by tosh.netlab.uky.edu (Postfix) with ESMTP
	id B9768CE81; Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
Received: by gum.netlab.uky.edu (Postfix, from userid 1109)
	id 9759827EEF; Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by gum.netlab.uky.edu (Postfix) with ESMTP
	id 9474E2C31E; Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
Date: Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
From: Krishna Prabhala 
To: manet@ietf.org
Cc: aodvimpl-public@lists.sourceforge.net
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] Ad Hoc Address Autoconfiguration draft
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I would like to know if a new version of the Ad Hoc Address
Autoconfiguration draft for IPv4 by Perkins et al. will be out soon.  

I also have the following questions regarding autoconfiguration:

1) The range 169.254/16 (according to the Zeroconf working group) refers
to link-local addresses.  Can they still be used by a node for routing?  

2) In the expired draft, it is said that AREQ and AREP messages are ICMP
messages.  Are they Information Request/Reply messages?  Also, can these
messages be used with a proactive routing protocol?

3) It is possible that two nodes may acquire the same temporary IP
address when they boot up.  Though highly unlikely, it is also possible
that they may request for the same permanent IP address.  In such
circumstances, how do the nodes initiate DAD again with a different
temporary IP address?  I think the reserved fields (or may be another
field if more bits are needed) in the AREQ and AREP messages can be used
to specify a sequence/ID number to break the ties.  

Please clarify me if I am missing something.

I think the partitioning and merging concepts should also come under the
purview of the draft.

Thanks,
Krishna.






_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 13:18:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23809
	for ; Wed, 17 Jul 2002 13:18:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA14568
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 13:19:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12675;
	Wed, 17 Jul 2002 12:55:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17872
	for ; Tue, 16 Jul 2002 15:36:59 -0400 (EDT)
Received: from tosh.netlab.uky.edu (tosh.netlab.uky.edu [204.198.76.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28029
	for ; Tue, 16 Jul 2002 15:36:00 -0400 (EDT)
Received: from gum.netlab.uky.edu (gum.netlab.uky.edu [204.198.76.71])
	by tosh.netlab.uky.edu (Postfix) with ESMTP
	id B9768CE81; Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
Received: by gum.netlab.uky.edu (Postfix, from userid 1109)
	id 9759827EEF; Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by gum.netlab.uky.edu (Postfix) with ESMTP
	id 9474E2C31E; Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
Date: Tue, 16 Jul 2002 15:36:57 -0400 (EDT)
From: Krishna Prabhala 
To: manet@ietf.org
Cc: aodvimpl-public@lists.sourceforge.net
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] Ad Hoc Address Autoconfiguration draft
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I would like to know if a new version of the Ad Hoc Address
Autoconfiguration draft for IPv4 by Perkins et al. will be out soon.  

I also have the following questions regarding autoconfiguration:

1) The range 169.254/16 (according to the Zeroconf working group) refers
to link-local addresses.  Can they still be used by a node for routing?  

2) In the expired draft, it is said that AREQ and AREP messages are ICMP
messages.  Are they Information Request/Reply messages?  Also, can these
messages be used with a proactive routing protocol?

3) It is possible that two nodes may acquire the same temporary IP
address when they boot up.  Though highly unlikely, it is also possible
that they may request for the same permanent IP address.  In such
circumstances, how do the nodes initiate DAD again with a different
temporary IP address?  I think the reserved fields (or may be another
field if more bits are needed) in the AREQ and AREP messages can be used
to specify a sequence/ID number to break the ties.  

Please clarify me if I am missing something.

I think the partitioning and merging concepts should also come under the
purview of the draft.

Thanks,
Krishna.






_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 13:32:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24160
	for ; Wed, 17 Jul 2002 13:32:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13737;
	Wed, 17 Jul 2002 13:07:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13703
	for ; Wed, 17 Jul 2002 13:06:59 -0400 (EDT)
Received: from mail.informatik.uni-ulm.de (mail.informatik.uni-ulm.de [134.60.68.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23466
	for ; Wed, 17 Jul 2002 13:06:01 -0400 (EDT)
Received: from brandung.informatik.uni-ulm.de ([134.60.70.41] helo=informatik.uni-ulm.de)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.33 #1)
	id 17UsGQ-00040G-00
	for manet@ietf.org; Wed, 17 Jul 2002 19:06:58 +0200
Message-ID: <3D35A3F0.BD7239B5@informatik.uni-ulm.de>
Date: Wed, 17 Jul 2002 19:05:52 +0200
From: =?iso-8859-1?Q?J=FCrgen?= Nagler 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode
References: <02Jul17.083335mdt.117124@gw.trac.wsmr.army.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi,
 
"Mullen, John P. (Contractor)" wrote:
> 
> number of additional fundamental strategies.  Has anyone ever sat down and
> described these basic MANET tools, independent of a specific protocol?

yes, but only in German. I described in my diploma thesis some of the
common concepts used in many MANET protocols. We needed this step for
creating a framework for all protocols. I used two chapters: one
describing criterions of differentiation and one describing basic
modules for all protocols.

Criterions of differentiation covered "time of route discovery
(proactive, reactive)", "algorithms for route discorvery", "structuring
mechanisms", "supported address types", "more influences (energy,
location-aware)", "transport of data". But many protocolls used at least
one solution in each section.

Basic modules covered "broadcast and flooding", "sequence numbers",
"link control (which covered promiscuous mode)", "topology dump" and
"tabelles".

I think it's sure not complete but it's a begin.

We also have a section "common functions" in our (sorry) German paper "A
framework for MANET routing protocols"
http://medien.informatik.uni-ulm.de/forschung/publikationen/wman02.pdf


Regards,
Jürgen Nagler

PS: Sorry for my poor English.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Wed Jul 17 13:59:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24907
	for ; Wed, 17 Jul 2002 13:59:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14474;
	Wed, 17 Jul 2002 13:18:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14445
	for ; Wed, 17 Jul 2002 13:18:03 -0400 (EDT)
Received: from xmxpita.excite.com (nat6.excitenetwork.com [63.236.75.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23751
	for ; Wed, 17 Jul 2002 13:17:06 -0400 (EDT)
Received: by xmxpita.excite.com (Postfix, from userid 110)
	id D17823DC6; Wed, 17 Jul 2002 13:17:30 -0400 (EDT)
To: haas@ece.cornell.edu
Subject: RE: [manet] promiscuous mode
Received: from [128.163.240.101] by xprdmailfe9.nwk.excite.com via HTTP; Wed, 17 Jul 2002 13:17:30 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = ed30013d601f2ce7c064c883e90c6183
Reply-To: jw2000@excite.com
From: "Jack Wang" 
MIME-Version: 1.0
X-Sender: jw2000@excite.com
X-Mailer: PHP
Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea";
Content-Transfer-Encoding: 7bit
Cc: manet@ietf.org, mullenjp.contractor@trac.wsmr.army.mil,
        gaitan@enel.ucalgary.ca, psholand@scires.com
Message-Id: <20020717171730.D17823DC6@xmxpita.excite.com>
Date: Wed, 17 Jul 2002 13:17:30 -0400 (EDT)
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org




--EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 




Thank you all for your valuable information."Promiscuous mode" can increase the efficiency of routing protocol. But it also exposes some information. How about the security issue? For routing, it is fine, since confidentiality is relatively not important. But for real data traffic, secrecy should be ensured. Should "promiscuous mode" be turned off for data traffic? regards, Jack  --- On Wed 07/17, < haas@ece.cornell.edu > wrote:From: [mailto: haas@ece.cornell.edu]To: mullenjp.contractor@trac.wsmr.army.milCc: jw2000@excite.com, manet@ietf.orgDate: Wed, 17 Jul 2002 10:03:50 -0400 (EDT)Subject: RE: [manet] promiscuous modeHi John,In general, use of promiscuous mode can lead to substantial saving incontrol traffic in most of the reactive protocols, for example byeavesdropping on the route replies and storing this information to replyto future route requests.Just as another point of reference, ZRP also uses promiscuous mode toeavesdrop on the propagation of the route reques!
 t queries, thus reducingthe unnecessary control traffic load. (This is one of the elements of the Query Control scheme in IERP).Zygmunt.===--====~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.eduSchool of Electrical Engineering Cornell University tel: +1-607-255-3454323 Frank Rhodes Hall fax: +1-607-255-9072Ithaca, NY 14853 e-mail: haas@ece.cornell.eduU.S.A WNL web page: http://wnl.ece.cornell.edu~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-On Wed, 17 Jul 2002, Mullen, John P. (Contractor) wrote:> Hi Jack,> > The two ad hoc protocols I am aware of that employ promiscuous mode are> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).> > John Mullen> > > -----Original Message-----> From: Jack Wang [mailto:jw2000@excite.com]> Sent: Tuesday, July 16, 2002 11:46 AM&g!
 t; To: manet@ietf.org> Subject: [manet] promiscuous mode> > &
gt; > > > --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1> Content-Type: text/plain; charset="us-ascii"> Content-Transfer-Encoding: 7bit> > Hi All: We know "promiscuous mode" can be used to monitor data traffic in a> network. How about its application in ad hoc networks?Is there any published> materials that I can refer to? Thanks. Jack > > ------------------------------------------------> Join Excite! - http://www.excite.com> The most personalized portal on the Web!> > --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1> Content-Type: text/html; charset="us-ascii"> Content-Transfer-Encoding: 7bit> > 
> height=200>



Hi All:> We know "promiscuous mode" can be used to monitor data traffic in> a network. How about its application in ad hoc networks?Is there> any published materials that I can refer to?> Thanks.Jack> 


Join Excite! - > href="http://www.excite.com/?PG=Email&SEC=Signature"> target=_top>http://www.excite.comThe most personalized portal on> the Web!> > --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--> > _______________________________________________> manet mailing list> manet@ietf.org> https://www1.ietf.org/mailman/listinfo/manet> > _______________________________________________> manet mailing list> manet@ietf.org> https://www1.ietf.org/mailman/listinfo/manet>

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
















Thank you all for your valuable information.
"Promiscuous mode" can increase the efficiency of routing protocol. But it also exposes some information. How about the security issue? For routing, it is fine, since confidentiality is relatively not important. But for real data traffic, secrecy should be ensured. Should "promiscuous mode" be turned off for data traffic?
 
regards,
 
Jack  





--- On Wed 07/17, < haas@ece.cornell.edu > wrote:
From: [mailto: haas@ece.cornell.edu]
To: mullenjp.contractor@trac.wsmr.army.mil
Cc: jw2000@excite.com, manet@ietf.org
Date: Wed, 17 Jul 2002 10:03:50 -0400 (EDT)
Subject: RE: [manet] promiscuous mode

Hi John,

In general, use of promiscuous mode can lead to substantial saving in
control traffic in most of !
 the reactive protocols, for example by
eavesdropping on the route replies and storing this information to reply
to future route requests.

Just as another point of reference, ZRP also uses promiscuous mode to
eavesdrop on the propagation of the route request queries, thus reducing
the unnecessary control traffic load. (This is one of the elements of 
the Query Control scheme in IERP).

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



On Wed, 17 Jul 2002, Mullen, J!
 ohn P. (Contractor) wrote:

> Hi Jack,
> 
> The t
wo ad hoc protocols I am aware of that employ promiscuous mode are
> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).
> 
> John Mullen
> 
> 
> -----Original Message-----
> From: Jack Wang [mailto:jw2000@excite.com]
> Sent: Tuesday, July 16, 2002 11:46 AM
> To: manet@ietf.org
> Subject: [manet] promiscuous mode
> 
> 
> 
> 
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> Hi All: We know "promiscuous mode" can be used to monitor data traffic in a
> network. How about its application in ad hoc networks?Is there any published
> materials that I can refer to? Thanks. Jack 
> 
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
!
 > 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> 


> height=200>













Hi All:

> 
We know "promiscuous mode" can be used to monitor data traffic in
> a network. How about its application in ad hoc networks?
Is there
> any published materials that I can refer to?

> 
Thanks.
Jack
> 














Join Excite! - > href="http://www.excite.com/?PG=Email&SEC=Signature"
> target=_top>http://www.excite.com
The most personalized portal on
> the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 13:59:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24915
	for ; Wed, 17 Jul 2002 13:59:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA17771
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 14:00:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14474;
	Wed, 17 Jul 2002 13:18:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14445
	for ; Wed, 17 Jul 2002 13:18:03 -0400 (EDT)
Received: from xmxpita.excite.com (nat6.excitenetwork.com [63.236.75.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23751
	for ; Wed, 17 Jul 2002 13:17:06 -0400 (EDT)
Received: by xmxpita.excite.com (Postfix, from userid 110)
	id D17823DC6; Wed, 17 Jul 2002 13:17:30 -0400 (EDT)
To: haas@ece.cornell.edu
Subject: RE: [manet] promiscuous mode
Received: from [128.163.240.101] by xprdmailfe9.nwk.excite.com via HTTP; Wed, 17 Jul 2002 13:17:30 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = ed30013d601f2ce7c064c883e90c6183
Reply-To: jw2000@excite.com
From: "Jack Wang" 
MIME-Version: 1.0
X-Sender: jw2000@excite.com
X-Mailer: PHP
Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea";
Content-Transfer-Encoding: 7bit
Cc: manet@ietf.org, mullenjp.contractor@trac.wsmr.army.mil,
        gaitan@enel.ucalgary.ca, psholand@scires.com
Message-Id: <20020717171730.D17823DC6@xmxpita.excite.com>
Date: Wed, 17 Jul 2002 13:17:30 -0400 (EDT)
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org




--EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 




Thank you all for your valuable information."Promiscuous mode" can increase the efficiency of routing protocol. But it also exposes some information. How about the security issue? For routing, it is fine, since confidentiality is relatively not important. But for real data traffic, secrecy should be ensured. Should "promiscuous mode" be turned off for data traffic? regards, Jack  --- On Wed 07/17, < haas@ece.cornell.edu > wrote:From: [mailto: haas@ece.cornell.edu]To: mullenjp.contractor@trac.wsmr.army.milCc: jw2000@excite.com, manet@ietf.orgDate: Wed, 17 Jul 2002 10:03:50 -0400 (EDT)Subject: RE: [manet] promiscuous modeHi John,In general, use of promiscuous mode can lead to substantial saving incontrol traffic in most of the reactive protocols, for example byeavesdropping on the route replies and storing this information to replyto future route requests.Just as another point of reference, ZRP also uses promiscuous mode toeavesdrop on the propagation of the route reques!
 t queries, thus reducingthe unnecessary control traffic load. (This is one of the elements of the Query Control scheme in IERP).Zygmunt.===--====~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.eduSchool of Electrical Engineering Cornell University tel: +1-607-255-3454323 Frank Rhodes Hall fax: +1-607-255-9072Ithaca, NY 14853 e-mail: haas@ece.cornell.eduU.S.A WNL web page: http://wnl.ece.cornell.edu~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-On Wed, 17 Jul 2002, Mullen, John P. (Contractor) wrote:> Hi Jack,> > The two ad hoc protocols I am aware of that employ promiscuous mode are> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).> > John Mullen> > > -----Original Message-----> From: Jack Wang [mailto:jw2000@excite.com]> Sent: Tuesday, July 16, 2002 11:46 AM&g!
 t; To: manet@ietf.org> Subject: [manet] promiscuous mode> > &
gt; > > > --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1> Content-Type: text/plain; charset="us-ascii"> Content-Transfer-Encoding: 7bit> > Hi All: We know "promiscuous mode" can be used to monitor data traffic in a> network. How about its application in ad hoc networks?Is there any published> materials that I can refer to? Thanks. Jack > > ------------------------------------------------> Join Excite! - http://www.excite.com> The most personalized portal on the Web!> > --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1> Content-Type: text/html; charset="us-ascii"> Content-Transfer-Encoding: 7bit> > 
> height=200>



Hi All:> We know "promiscuous mode" can be used to monitor data traffic in> a network. How about its application in ad hoc networks?Is there> any published materials that I can refer to?> Thanks.Jack> 


Join Excite! - > href="http://www.excite.com/?PG=Email&SEC=Signature"> target=_top>http://www.excite.comThe most personalized portal on> the Web!> > --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--> > _______________________________________________> manet mailing list> manet@ietf.org> https://www1.ietf.org/mailman/listinfo/manet> > _______________________________________________> manet mailing list> manet@ietf.org> https://www1.ietf.org/mailman/listinfo/manet>

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
















Thank you all for your valuable information.
"Promiscuous mode" can increase the efficiency of routing protocol. But it also exposes some information. How about the security issue? For routing, it is fine, since confidentiality is relatively not important. But for real data traffic, secrecy should be ensured. Should "promiscuous mode" be turned off for data traffic?
 
regards,
 
Jack  





--- On Wed 07/17, < haas@ece.cornell.edu > wrote:
From: [mailto: haas@ece.cornell.edu]
To: mullenjp.contractor@trac.wsmr.army.mil
Cc: jw2000@excite.com, manet@ietf.org
Date: Wed, 17 Jul 2002 10:03:50 -0400 (EDT)
Subject: RE: [manet] promiscuous mode

Hi John,

In general, use of promiscuous mode can lead to substantial saving in
control traffic in most of !
 the reactive protocols, for example by
eavesdropping on the route replies and storing this information to reply
to future route requests.

Just as another point of reference, ZRP also uses promiscuous mode to
eavesdrop on the propagation of the route request queries, thus reducing
the unnecessary control traffic load. (This is one of the elements of 
the Query Control scheme in IERP).

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



On Wed, 17 Jul 2002, Mullen, J!
 ohn P. (Contractor) wrote:

> Hi Jack,
> 
> The t
wo ad hoc protocols I am aware of that employ promiscuous mode are
> Dynamic Source Routing (DSR), and Source Tree Adaptive Routing (STAR).
> 
> John Mullen
> 
> 
> -----Original Message-----
> From: Jack Wang [mailto:jw2000@excite.com]
> Sent: Tuesday, July 16, 2002 11:46 AM
> To: manet@ietf.org
> Subject: [manet] promiscuous mode
> 
> 
> 
> 
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> Hi All: We know "promiscuous mode" can be used to monitor data traffic in a
> network. How about its application in ad hoc networks?Is there any published
> materials that I can refer to? Thanks. Jack 
> 
> ------------------------------------------------
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
!
 > 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> 


> height=200>













Hi All:

> 
We know "promiscuous mode" can be used to monitor data traffic in
> a network. How about its application in ad hoc networks?
Is there
> any published materials that I can refer to?

> 
Thanks.
Jack
> 














Join Excite! - > href="http://www.excite.com/?PG=Email&SEC=Signature"
> target=_top>http://www.excite.com
The most personalized portal on
> the Web!
> 
> --EXCITEBOUNDARY_000__7705a3bdad555dd407e51a76672516d1--
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

--EXCITEBOUNDARY_000__8af2d42788c5556869dafccaf34fbaea--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 14:05:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25103
	for ; Wed, 17 Jul 2002 14:05:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15086;
	Wed, 17 Jul 2002 13:27:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15058
	for ; Wed, 17 Jul 2002 13:27:45 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24011
	for ; Wed, 17 Jul 2002 13:26:47 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117124>; Wed, 17 Jul 2002 11:27:33 -0600
Message-Id: <02Jul17.112733mdt.117124@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: =?iso-8859-1?Q?J=FCrgen_Nagler?= 
Cc: manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Wed, 17 Jul 2002 11:27:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15059
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Jürgen,

Well, I suppose this is why I studied German all those years ago.  Even so,
your English is a darn sight better than my German.  

I'm willing to give reading the paper a whack, but my German technical
dictionary is very much outdated.  Can anyone recommend an up-to-date
technical reference?

Thanks,

John Mullen

-----Original Message-----
From: Jürgen Nagler [mailto:juergen.nagler@informatik.uni-ulm.de]
Sent: Wednesday, July 17, 2002 11:06 AM
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode


Hi,
 
"Mullen, John P. (Contractor)" wrote:
> 
> number of additional fundamental strategies.  Has anyone ever sat down and
> described these basic MANET tools, independent of a specific protocol?

yes, but only in German. I described in my diploma thesis some of the
common concepts used in many MANET protocols. We needed this step for
creating a framework for all protocols. I used two chapters: one
describing criterions of differentiation and one describing basic
modules for all protocols.

Criterions of differentiation covered "time of route discovery
(proactive, reactive)", "algorithms for route discorvery", "structuring
mechanisms", "supported address types", "more influences (energy,
location-aware)", "transport of data". But many protocolls used at least
one solution in each section.

Basic modules covered "broadcast and flooding", "sequence numbers",
"link control (which covered promiscuous mode)", "topology dump" and
"tabelles".

I think it's sure not complete but it's a begin.

We also have a section "common functions" in our (sorry) German paper "A
framework for MANET routing protocols"
http://medien.informatik.uni-ulm.de/forschung/publikationen/wman02.pdf


Regards,
Jürgen Nagler

PS: Sorry for my poor English.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 14:05:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25108
	for ; Wed, 17 Jul 2002 14:05:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA18878
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 14:06:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15086;
	Wed, 17 Jul 2002 13:27:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15058
	for ; Wed, 17 Jul 2002 13:27:45 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24011
	for ; Wed, 17 Jul 2002 13:26:47 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117124>; Wed, 17 Jul 2002 11:27:33 -0600
Message-Id: <02Jul17.112733mdt.117124@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: =?iso-8859-1?Q?J=FCrgen_Nagler?= 
Cc: manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Wed, 17 Jul 2002 11:27:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15059
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Jürgen,

Well, I suppose this is why I studied German all those years ago.  Even so,
your English is a darn sight better than my German.  

I'm willing to give reading the paper a whack, but my German technical
dictionary is very much outdated.  Can anyone recommend an up-to-date
technical reference?

Thanks,

John Mullen

-----Original Message-----
From: Jürgen Nagler [mailto:juergen.nagler@informatik.uni-ulm.de]
Sent: Wednesday, July 17, 2002 11:06 AM
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode


Hi,
 
"Mullen, John P. (Contractor)" wrote:
> 
> number of additional fundamental strategies.  Has anyone ever sat down and
> described these basic MANET tools, independent of a specific protocol?

yes, but only in German. I described in my diploma thesis some of the
common concepts used in many MANET protocols. We needed this step for
creating a framework for all protocols. I used two chapters: one
describing criterions of differentiation and one describing basic
modules for all protocols.

Criterions of differentiation covered "time of route discovery
(proactive, reactive)", "algorithms for route discorvery", "structuring
mechanisms", "supported address types", "more influences (energy,
location-aware)", "transport of data". But many protocolls used at least
one solution in each section.

Basic modules covered "broadcast and flooding", "sequence numbers",
"link control (which covered promiscuous mode)", "topology dump" and
"tabelles".

I think it's sure not complete but it's a begin.

We also have a section "common functions" in our (sorry) German paper "A
framework for MANET routing protocols"
http://medien.informatik.uni-ulm.de/forschung/publikationen/wman02.pdf


Regards,
Jürgen Nagler

PS: Sorry for my poor English.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Wed Jul 17 14:26:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24166
	for ; Wed, 17 Jul 2002 13:32:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA16157
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 13:33:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13737;
	Wed, 17 Jul 2002 13:07:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13703
	for ; Wed, 17 Jul 2002 13:06:59 -0400 (EDT)
Received: from mail.informatik.uni-ulm.de (mail.informatik.uni-ulm.de [134.60.68.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23466
	for ; Wed, 17 Jul 2002 13:06:01 -0400 (EDT)
Received: from brandung.informatik.uni-ulm.de ([134.60.70.41] helo=informatik.uni-ulm.de)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.33 #1)
	id 17UsGQ-00040G-00
	for manet@ietf.org; Wed, 17 Jul 2002 19:06:58 +0200
Message-ID: <3D35A3F0.BD7239B5@informatik.uni-ulm.de>
Date: Wed, 17 Jul 2002 19:05:52 +0200
From: =?iso-8859-1?Q?J=FCrgen?= Nagler 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode
References: <02Jul17.083335mdt.117124@gw.trac.wsmr.army.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi,
 
"Mullen, John P. (Contractor)" wrote:
> 
> number of additional fundamental strategies.  Has anyone ever sat down and
> described these basic MANET tools, independent of a specific protocol?

yes, but only in German. I described in my diploma thesis some of the
common concepts used in many MANET protocols. We needed this step for
creating a framework for all protocols. I used two chapters: one
describing criterions of differentiation and one describing basic
modules for all protocols.

Criterions of differentiation covered "time of route discovery
(proactive, reactive)", "algorithms for route discorvery", "structuring
mechanisms", "supported address types", "more influences (energy,
location-aware)", "transport of data". But many protocolls used at least
one solution in each section.

Basic modules covered "broadcast and flooding", "sequence numbers",
"link control (which covered promiscuous mode)", "topology dump" and
"tabelles".

I think it's sure not complete but it's a begin.

We also have a section "common functions" in our (sorry) German paper "A
framework for MANET routing protocols"
http://medien.informatik.uni-ulm.de/forschung/publikationen/wman02.pdf


Regards,
Jürgen Nagler

PS: Sorry for my poor English.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 14:51:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26804
	for ; Wed, 17 Jul 2002 14:51:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21418;
	Wed, 17 Jul 2002 14:33:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08868
	for ; Mon, 24 Jun 2002 16:21:38 -0400 (EDT)
Received: from goober.cs.colorado.edu (goober.cs.colorado.edu [128.138.241.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28317
	for ; Mon, 24 Jun 2002 16:20:53 -0400 (EDT)
Received: from cs.colorado.edu (neuf.cs.colorado.edu [128.138.241.84])
	by goober.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id g5OKKs520057;
	Mon, 24 Jun 2002 14:20:54 -0600 (MDT)
Message-ID: <3D177F2F.907@cs.colorado.edu>
Date: Mon, 24 Jun 2002 14:21:03 -0600
From: Michael Neufeld 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: decouto@lcs.mit.edu
CC: dyoung@pobox.com, manet@ietf.org
Subject: Re: [manet] on-demand routing for BSD?
References: <20020619151603.A31659@che.onthejob.net> <3D11E04B.8090601@lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Our AODV implementation in Click here at the University of Colorado has 
just been redone, and we're looking to release the new version within a 
month or so. We've been developing it using a tool which may be of 
interest to others on this list. The nsclick simulator is the Click 
Modular Router embedded inside of ns-2, allowing the use of Click 
routing graphs inside of ns-2 simulations. We've found it to be very 
helpful for testing and debugging. The release is a set of patches on 
top of ns-2 2.1b9 and Click 1.2.4, check out:
http://systems.cs.colorado.edu/Networking/nsclick

if you'd like to experiment with it. Feedback, comments and bug reports 
are appreciated. Thanks.

-Mike Neufeld

Douglas S. J. De Couto wrote:

> David Young wrote:
> 
>> Does any AODV implementation exist for *BSD?
>>
>> It seems like a purely "userland" implementation of AODV, DSR, and
>> other varieties of on-demand ad hoc routing are impossible because they
>> require the kernel queue packets without nexthops for long enough that
>> route discovery can be attempted. BSD kernels, however, discard packets
>> immediately when they do not know a nexthop.
> 
> 
> or you could handle the queuing and route lookup in userland, using e.g. 
> the click modular router (http://pdos.lcs.mit.edu/click).  we have a 
> protocol that combines DSDV and geographic forwarding implemented in 
> userlevel click (http://pdos.lcs.mit.edu/grid).  others have implemented 
> DSR, AODV, and TORA using click 
> (http://systems.cs.colorado.edu/Networking/modular-adhoc.html)
> 
> d
> 




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 14:51:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26809
	for ; Wed, 17 Jul 2002 14:51:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA23406
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 14:51:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21418;
	Wed, 17 Jul 2002 14:33:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08868
	for ; Mon, 24 Jun 2002 16:21:38 -0400 (EDT)
Received: from goober.cs.colorado.edu (goober.cs.colorado.edu [128.138.241.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28317
	for ; Mon, 24 Jun 2002 16:20:53 -0400 (EDT)
Received: from cs.colorado.edu (neuf.cs.colorado.edu [128.138.241.84])
	by goober.cs.colorado.edu (8.10.1/8.10.1) with ESMTP id g5OKKs520057;
	Mon, 24 Jun 2002 14:20:54 -0600 (MDT)
Message-ID: <3D177F2F.907@cs.colorado.edu>
Date: Mon, 24 Jun 2002 14:21:03 -0600
From: Michael Neufeld 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: decouto@lcs.mit.edu
CC: dyoung@pobox.com, manet@ietf.org
Subject: Re: [manet] on-demand routing for BSD?
References: <20020619151603.A31659@che.onthejob.net> <3D11E04B.8090601@lcs.mit.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Our AODV implementation in Click here at the University of Colorado has 
just been redone, and we're looking to release the new version within a 
month or so. We've been developing it using a tool which may be of 
interest to others on this list. The nsclick simulator is the Click 
Modular Router embedded inside of ns-2, allowing the use of Click 
routing graphs inside of ns-2 simulations. We've found it to be very 
helpful for testing and debugging. The release is a set of patches on 
top of ns-2 2.1b9 and Click 1.2.4, check out:
http://systems.cs.colorado.edu/Networking/nsclick

if you'd like to experiment with it. Feedback, comments and bug reports 
are appreciated. Thanks.

-Mike Neufeld

Douglas S. J. De Couto wrote:

> David Young wrote:
> 
>> Does any AODV implementation exist for *BSD?
>>
>> It seems like a purely "userland" implementation of AODV, DSR, and
>> other varieties of on-demand ad hoc routing are impossible because they
>> require the kernel queue packets without nexthops for long enough that
>> route discovery can be attempted. BSD kernels, however, discard packets
>> immediately when they do not know a nexthop.
> 
> 
> or you could handle the queuing and route lookup in userland, using e.g. 
> the click modular router (http://pdos.lcs.mit.edu/click).  we have a 
> protocol that combines DSDV and geographic forwarding implemented in 
> userlevel click (http://pdos.lcs.mit.edu/grid).  others have implemented 
> DSR, AODV, and TORA using click 
> (http://systems.cs.colorado.edu/Networking/modular-adhoc.html)
> 
> d
> 




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 14:56:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27017
	for ; Wed, 17 Jul 2002 14:56:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22025;
	Wed, 17 Jul 2002 14:42:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16361
	for ; Wed, 3 Jul 2002 17:35:09 -0400 (EDT)
Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07546
	for ; Wed, 3 Jul 2002 17:34:20 -0400 (EDT)
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202])
	by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with SMTP id g63LZ4Fl014234;
	Wed, 3 Jul 2002 17:35:04 -0400
From: "Andrew T. Campbell" 
To: , "'John Tapsell'" ,
        "'Harpreet Arora'" 
Cc: 
Subject: RE: [manet] QoS over a wireless Ad Hoc network
Date: Wed, 3 Jul 2002 17:32:21 -0400
Message-ID: <000801c222d9$1e607240$ca413b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <20020703162743.40132.qmail@web21008.mail.yahoo.com>
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


John, Yang and Harpreet:

I think its difficult to implement the classic DiffServ
paradigm in wireline networks, nevermind ad hoc mobile and
wireless networks. I think best you can do is
have fast local rate control of best effort traffic to
yield the necessary low delays and stable bandwidth for
real-time traffic. 

You can take a look at the SWAN approach that uses this
in combination with a slower time scale and coarser end-to-end 
algorithms for admission control and regulation.

SWAN follows the end to end argument pushing the smarts to
the 'edge' (source/destination) and leaving the 'network' stateless.

See:

http://comet.columbia.edu/swan/

for some papers.  We are planning on submitting an ID soon
and releasing the ns-2 and testbed code.

---
Andrew
http://comet.columbia.edu/~campbell


> -----Original Message-----
> From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of
> Yang Xiao
> Sent: Wednesday, July 03, 2002 12:28 PM
> To: John Tapsell; Harpreet Arora
> Cc: manet@ietf.org
> Subject: Re: [manet] QoS over a wireless Ad Hoc network
> 
> 
> Harpeet and JohnFlux
> 
> I did not follow this thread. Where can I find this paper?
> 
> Thanks
> 
> Yang
> 
> --- John Tapsell  wrote:
> > Harpeet,
> >   Hi!   I'm replying in reference to the Simulation Study of the 
> > Feasibility of Differentiated Services Framework for QoS in
> > MANET's (long title..)
> > 
> >   An excellent paper :)
> > 
> >   A few comments:
> > 	Is having 3 layers of priority enough?
> > 	Should control packets for non-priority traffic be considered
> > 		higher priority as priority traffic itself?
> > 	What if you have more high priority traffic than bandwidth?
> > 		In such a situation you need to either try to take
> > 		another route (dynamically adjust weighting(cost) at the
> > 		routing level), throttle back the clients (dynamically
> > 		adjust output based on bandwidth), or drop some streams
> > 		for the sake of others (perhaps could be done with more
> > 		layers of priority)
> > Comments!
> > 
> > JohnFlux
> > 
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 14:56:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27022
	for ; Wed, 17 Jul 2002 14:56:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA24003
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 14:57:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22025;
	Wed, 17 Jul 2002 14:42:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16361
	for ; Wed, 3 Jul 2002 17:35:09 -0400 (EDT)
Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07546
	for ; Wed, 3 Jul 2002 17:34:20 -0400 (EDT)
Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202])
	by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with SMTP id g63LZ4Fl014234;
	Wed, 3 Jul 2002 17:35:04 -0400
From: "Andrew T. Campbell" 
To: , "'John Tapsell'" ,
        "'Harpreet Arora'" 
Cc: 
Subject: RE: [manet] QoS over a wireless Ad Hoc network
Date: Wed, 3 Jul 2002 17:32:21 -0400
Message-ID: <000801c222d9$1e607240$ca413b80@SWEETPEA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <20020703162743.40132.qmail@web21008.mail.yahoo.com>
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


John, Yang and Harpreet:

I think its difficult to implement the classic DiffServ
paradigm in wireline networks, nevermind ad hoc mobile and
wireless networks. I think best you can do is
have fast local rate control of best effort traffic to
yield the necessary low delays and stable bandwidth for
real-time traffic. 

You can take a look at the SWAN approach that uses this
in combination with a slower time scale and coarser end-to-end 
algorithms for admission control and regulation.

SWAN follows the end to end argument pushing the smarts to
the 'edge' (source/destination) and leaving the 'network' stateless.

See:

http://comet.columbia.edu/swan/

for some papers.  We are planning on submitting an ID soon
and releasing the ns-2 and testbed code.

---
Andrew
http://comet.columbia.edu/~campbell


> -----Original Message-----
> From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of
> Yang Xiao
> Sent: Wednesday, July 03, 2002 12:28 PM
> To: John Tapsell; Harpreet Arora
> Cc: manet@ietf.org
> Subject: Re: [manet] QoS over a wireless Ad Hoc network
> 
> 
> Harpeet and JohnFlux
> 
> I did not follow this thread. Where can I find this paper?
> 
> Thanks
> 
> Yang
> 
> --- John Tapsell  wrote:
> > Harpeet,
> >   Hi!   I'm replying in reference to the Simulation Study of the 
> > Feasibility of Differentiated Services Framework for QoS in
> > MANET's (long title..)
> > 
> >   An excellent paper :)
> > 
> >   A few comments:
> > 	Is having 3 layers of priority enough?
> > 	Should control packets for non-priority traffic be considered
> > 		higher priority as priority traffic itself?
> > 	What if you have more high priority traffic than bandwidth?
> > 		In such a situation you need to either try to take
> > 		another route (dynamically adjust weighting(cost) at the
> > 		routing level), throttle back the clients (dynamically
> > 		adjust output based on bandwidth), or drop some streams
> > 		for the sake of others (perhaps could be done with more
> > 		layers of priority)
> > Comments!
> > 
> > JohnFlux
> > 
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 14:57:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27096
	for ; Wed, 17 Jul 2002 14:57:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22074;
	Wed, 17 Jul 2002 14:43:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24392
	for ; Thu, 4 Jul 2002 11:05:32 -0400 (EDT)
Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19188
	for ; Thu, 4 Jul 2002 11:04:45 -0400 (EDT)
Received: from coltrane (coltrane.ocs.columbia.edu [128.59.240.174])
	by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with SMTP id g64F52Fl028805;
	Thu, 4 Jul 2002 11:05:02 -0400
From: "Andrew T. Campbell" 
To: "John Peter Tapsell" , ,
        , 
Cc: 
Subject: RE: [manet] QoS over a wireless Ad Hoc network
Date: Thu, 4 Jul 2002 11:12:25 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <200207041027.g64ARUp01883@ug002.cs.man.ac.uk>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

John:

DiffServ is much more sophisticated than a simple prioritization
scheme. It calls for engineering techniques such over provisioning
in support of bounds on delay; can't do that well in wireless
networks without killing performance. I suggest you read the
various Internet Drafts on DiffServ and some of the wireline
papers.

Andrew

> -----Original Message-----
> From: John Peter Tapsell [mailto:tapselj0@cs.man.ac.uk]
> Sent: Thursday, July 04, 2002 6:28 AM
> To: campbell@ee.columbia.edu; ha33@drexel.edu; tapselj0@cs.man.ac.uk;
> YangXiao@IEEE.ORG
> Cc: manet@ietf.org
> Subject: RE: [manet] QoS over a wireless Ad Hoc network
> 
> 
> I'm confused.. :)
> 
> I thought diffserv was simply each node knowing about priority traffic
> so simply queueing that first.. ?  In which case I can't see the 
> difficulty
> in doing this in ad-hoc networks?
> Were you thinking of intserv ?  Or am I going looney? :)
> 
> JohnFlux
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 14:57:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27104
	for ; Wed, 17 Jul 2002 14:57:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA24073
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 14:58:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22074;
	Wed, 17 Jul 2002 14:43:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24392
	for ; Thu, 4 Jul 2002 11:05:32 -0400 (EDT)
Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19188
	for ; Thu, 4 Jul 2002 11:04:45 -0400 (EDT)
Received: from coltrane (coltrane.ocs.columbia.edu [128.59.240.174])
	by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with SMTP id g64F52Fl028805;
	Thu, 4 Jul 2002 11:05:02 -0400
From: "Andrew T. Campbell" 
To: "John Peter Tapsell" , ,
        , 
Cc: 
Subject: RE: [manet] QoS over a wireless Ad Hoc network
Date: Thu, 4 Jul 2002 11:12:25 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <200207041027.g64ARUp01883@ug002.cs.man.ac.uk>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

John:

DiffServ is much more sophisticated than a simple prioritization
scheme. It calls for engineering techniques such over provisioning
in support of bounds on delay; can't do that well in wireless
networks without killing performance. I suggest you read the
various Internet Drafts on DiffServ and some of the wireline
papers.

Andrew

> -----Original Message-----
> From: John Peter Tapsell [mailto:tapselj0@cs.man.ac.uk]
> Sent: Thursday, July 04, 2002 6:28 AM
> To: campbell@ee.columbia.edu; ha33@drexel.edu; tapselj0@cs.man.ac.uk;
> YangXiao@IEEE.ORG
> Cc: manet@ietf.org
> Subject: RE: [manet] QoS over a wireless Ad Hoc network
> 
> 
> I'm confused.. :)
> 
> I thought diffserv was simply each node knowing about priority traffic
> so simply queueing that first.. ?  In which case I can't see the 
> difficulty
> in doing this in ad-hoc networks?
> Were you thinking of intserv ?  Or am I going looney? :)
> 
> JohnFlux
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 17 15:09:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27525
	for ; Wed, 17 Jul 2002 15:09:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22835;
	Wed, 17 Jul 2002 14:49:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23821
	for ; Mon, 8 Jul 2002 11:15:33 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18904
	for ; Mon, 8 Jul 2002 11:14:41 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68FFVrU014697;
	Mon, 8 Jul 2002 17:15:31 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 8 Jul 2002 17:15:31 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180B6@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'Ryuji Wakikawa'" , sessinghaus@web.de
Cc: manet@ietf.org
Subject: RE: [manet] AODV and Mobile IP References
Date: Mon, 8 Jul 2002 17:10:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23822
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Michael, 

At http://www.e.kth.se/~e94_fal/mipmanet.pdf you can find our M.Sc. thesis from ´99 called MIPMANET, which is about connecting IPv4 MANETs to the Internet. We've identified many of the problems, proposed several solutions, and compared a few of them by means of simulations. The work was also published at the first MobiHOC workshop in August, 2000; send me an email if you're interested in a soft copy of this paper.

I haven't really followed the MANET-list lately, but the approach taken in draft-royer-manet-globalv4-00.txt seems to be very similar to ours. If going for IPv6, you get some things 'for free' and the solution can be much nicer, as is shown in draft-wakikawa-manet-globalv6-00.txt, but many of the problems we discuss in our thesis are still valid.

BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
fredrik.alriksson@ericsson.com


> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 5 juli 2002 19:49
> To: sessinghaus@web.de
> Cc: manet@ietf.org
> Subject: Re: [manet] AODV and Mobile IP References
> 
> 
> 
> Hello Michael.
> 
> We are working on this and have drafts about internet 
> connectivity (IPv6) for manet.
> Please check the draft here.
> http://search.ietf.org/internet-drafts/draft-wakikawa-manet-gl
obalv6-01.txt

We have already implemented the system (AODV6 + global6-draft) on
Linux and make sure to provide internet connectivity to mobile node
and to general nodes from manet.

I am also implementing AODV6+global6-draft on ANY-BSD+kamestack. I
hope it will be soon available in public. 

We also simulate the system (not test MIP6 case).

Prof.Elizabeth Belding-Royer is working on IPv4 connectivity for manet.
http://www.cs.ucsb.edu/~eroyer/txt/globalv4.txt

The draft for address auto-configuration in manet is also available.
http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt

best regards,
ryuji	


At Fri, 5 Jul 2002 15:40:38 +0200,
Michael Sessinghaus wrote:
> 
> [1  ]
> Hi people,
> 
> Has any research been done on simulation of aodv and mobile ip to assure connectivity to internet?
> Any ns-simulation (tcl scripts) and references?
> 
> Thanks for your Help
> 
> Best regards, Michael.
> 
> [2  ]
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 17 15:56:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27532
	for ; Wed, 17 Jul 2002 15:09:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA25520
	for manet-archive@odin.ietf.org; Wed, 17 Jul 2002 15:10:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22835;
	Wed, 17 Jul 2002 14:49:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23821
	for ; Mon, 8 Jul 2002 11:15:33 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18904
	for ; Mon, 8 Jul 2002 11:14:41 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g68FFVrU014697;
	Mon, 8 Jul 2002 17:15:31 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 8 Jul 2002 17:15:31 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180B6@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'Ryuji Wakikawa'" , sessinghaus@web.de
Cc: manet@ietf.org
Subject: RE: [manet] AODV and Mobile IP References
Date: Mon, 8 Jul 2002 17:10:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23822
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Michael, 

At http://www.e.kth.se/~e94_fal/mipmanet.pdf you can find our M.Sc. thesis from ´99 called MIPMANET, which is about connecting IPv4 MANETs to the Internet. We've identified many of the problems, proposed several solutions, and compared a few of them by means of simulations. The work was also published at the first MobiHOC workshop in August, 2000; send me an email if you're interested in a soft copy of this paper.

I haven't really followed the MANET-list lately, but the approach taken in draft-royer-manet-globalv4-00.txt seems to be very similar to ours. If going for IPv6, you get some things 'for free' and the solution can be much nicer, as is shown in draft-wakikawa-manet-globalv6-00.txt, but many of the problems we discuss in our thesis are still valid.

BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
fredrik.alriksson@ericsson.com


> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 5 juli 2002 19:49
> To: sessinghaus@web.de
> Cc: manet@ietf.org
> Subject: Re: [manet] AODV and Mobile IP References
> 
> 
> 
> Hello Michael.
> 
> We are working on this and have drafts about internet 
> connectivity (IPv6) for manet.
> Please check the draft here.
> http://search.ietf.org/internet-drafts/draft-wakikawa-manet-gl
obalv6-01.txt

We have already implemented the system (AODV6 + global6-draft) on
Linux and make sure to provide internet connectivity to mobile node
and to general nodes from manet.

I am also implementing AODV6+global6-draft on ANY-BSD+kamestack. I
hope it will be soon available in public. 

We also simulate the system (not test MIP6 case).

Prof.Elizabeth Belding-Royer is working on IPv4 connectivity for manet.
http://www.cs.ucsb.edu/~eroyer/txt/globalv4.txt

The draft for address auto-configuration in manet is also available.
http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt

best regards,
ryuji	


At Fri, 5 Jul 2002 15:40:38 +0200,
Michael Sessinghaus wrote:
> 
> [1  ]
> Hi people,
> 
> Has any research been done on simulation of aodv and mobile ip to assure connectivity to internet?
> Any ns-simulation (tcl scripts) and references?
> 
> Thanks for your Help
> 
> Best regards, Michael.
> 
> [2  ]
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:11:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09037
	for ; Fri, 19 Jul 2002 10:11:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06546;
	Fri, 19 Jul 2002 09:53:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13448
	for ; Fri, 19 Jul 2002 01:16:45 -0400 (EDT)
Received: from ep_mailout1 ([203.254.224.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21800
	for ; Fri, 19 Jul 2002 01:15:46 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 id <0GZH00H01DEEY4@mailout1.samsung.com> for manet@ietf.org; Fri,
 19 Jul 2002 14:18:14 +0900 (KST)
Received: from ep_ms7_bk (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZH00H7JDEDO5@mailout1.samsung.com> for manet@ietf.org; Fri,
 19 Jul 2002 14:18:14 +0900 (KST)
Received: from ep_was10 (ms7 [203.254.225.101])
 by ms7.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZH00FC3DA5YK@ms7.samsung.com> for manet@ietf.org; Fri,
 19 Jul 2002 14:15:42 +0900 (KST)
Content-return: prohibited
Date: Fri, 19 Jul 2002 14:18:19 +0900
From: =?EUC-KR?B?w9a47bz2?= 
To: manet@ietf.org
Reply-to: mschoe@samsung.com
Message-id: <0GZH00FC4DA5YK@ms7.samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=euc-kr
Content-transfer-encoding: 7BIT
X-Priority: 3
Msgkey: 20020719141812@mschoe
X-MTR: 20020719141812@mschoe
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
Content-Transfer-Encoding: 7BIT
Subject: [manet] MANET implementation using UWB?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7BIT

Hi,

Most of the MANET simulation or implementation are based on the use of wireless LAN 802.11, precisely speaking, DCF, 
I think. I would like to know some differences between 802.11 and UWB. 
In addition, is there someone who has experiences or knows some details about the MANET implementation on top of UWB?

I would be very appreciated of your comments or suggestions.

Thanks in advance,

-
Myongsu.

 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:11:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09046
	for ; Fri, 19 Jul 2002 10:11:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11018
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:12:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06546;
	Fri, 19 Jul 2002 09:53:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13448
	for ; Fri, 19 Jul 2002 01:16:45 -0400 (EDT)
Received: from ep_mailout1 ([203.254.224.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21800
	for ; Fri, 19 Jul 2002 01:15:46 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 id <0GZH00H01DEEY4@mailout1.samsung.com> for manet@ietf.org; Fri,
 19 Jul 2002 14:18:14 +0900 (KST)
Received: from ep_ms7_bk (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZH00H7JDEDO5@mailout1.samsung.com> for manet@ietf.org; Fri,
 19 Jul 2002 14:18:14 +0900 (KST)
Received: from ep_was10 (ms7 [203.254.225.101])
 by ms7.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZH00FC3DA5YK@ms7.samsung.com> for manet@ietf.org; Fri,
 19 Jul 2002 14:15:42 +0900 (KST)
Content-return: prohibited
Date: Fri, 19 Jul 2002 14:18:19 +0900
From: =?EUC-KR?B?w9a47bz2?= 
To: manet@ietf.org
Reply-to: mschoe@samsung.com
Message-id: <0GZH00FC4DA5YK@ms7.samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=euc-kr
Content-transfer-encoding: 7BIT
X-Priority: 3
Msgkey: 20020719141812@mschoe
X-MTR: 20020719141812@mschoe
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
Content-Transfer-Encoding: 7BIT
Subject: [manet] MANET implementation using UWB?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7BIT

Hi,

Most of the MANET simulation or implementation are based on the use of wireless LAN 802.11, precisely speaking, DCF, 
I think. I would like to know some differences between 802.11 and UWB. 
In addition, is there someone who has experiences or knows some details about the MANET implementation on top of UWB?

I would be very appreciated of your comments or suggestions.

Thanks in advance,

-
Myongsu.

 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:12:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09103
	for ; Fri, 19 Jul 2002 10:12:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06169;
	Fri, 19 Jul 2002 09:51:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19961
	for ; Wed, 17 Jul 2002 22:54:28 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08925
	for ; Wed, 17 Jul 2002 22:53:29 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA27334
	for ; Wed, 17 Jul 2002 19:53:57 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I2ru320455
	for ; Wed, 17 Jul 2002 19:53:56 -0700
X-mProtect: <200207180253> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdUq1fef; Wed, 17 Jul 2002 19:53:53 PDT
Message-ID: <3D362D57.23C3A68C@iprg.nokia.com>
Date: Wed, 17 Jul 2002 19:52:07 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mobile Ad Hoc IETF working group 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [manet] [Fwd: Re: Presentation files]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello folks,

Joe Macker has been kind enough to provide a temporary
home for the presentation files that I used for recent
discussions within manet:
        http://tonnant.itd.nrl.navy.mil/manet/yokohama/

Thanks, Joe!

Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:12:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09112
	for ; Fri, 19 Jul 2002 10:12:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11107
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:13:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06169;
	Fri, 19 Jul 2002 09:51:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19961
	for ; Wed, 17 Jul 2002 22:54:28 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08925
	for ; Wed, 17 Jul 2002 22:53:29 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA27334
	for ; Wed, 17 Jul 2002 19:53:57 -0700 (PDT)
X-Delivered-For: 
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I2ru320455
	for ; Wed, 17 Jul 2002 19:53:56 -0700
X-mProtect: <200207180253> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdUq1fef; Wed, 17 Jul 2002 19:53:53 PDT
Message-ID: <3D362D57.23C3A68C@iprg.nokia.com>
Date: Wed, 17 Jul 2002 19:52:07 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mobile Ad Hoc IETF working group 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [manet] [Fwd: Re: Presentation files]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello folks,

Joe Macker has been kind enough to provide a temporary
home for the presentation files that I used for recent
discussions within manet:
        http://tonnant.itd.nrl.navy.mil/manet/yokohama/

Thanks, Joe!

Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:12:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09149
	for ; Fri, 19 Jul 2002 10:12:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06661;
	Fri, 19 Jul 2002 09:53:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21318
	for ; Fri, 19 Jul 2002 04:20:33 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03101
	for ; Fri, 19 Jul 2002 04:19:33 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8KVRb013960
	for ; Fri, 19 Jul 2002 10:20:31 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACVQ0>; Fri, 19 Jul 2002 10:20:30 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FA@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Gateway address resolution
Date: Fri, 19 Jul 2002 10:14:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

The solution you describe, plus how the communication between the foreign agent and the MANET host can be done, was published '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf).

BR,
Fredrik

> -----Original Message-----
> From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
> Sent: den 10 juli 2002 17:48
> To: 'Mullen, John P. (Contractor)'
> Cc: manet@ietf.org
> Subject: RE: [manet] Gateway address resolution
> 
> 
> John Mullen wrote:
> 
> > Hi Bert,
> > 
> > I am concerned, as Charlie is, with the problem of how a node 
> > within the
> > Internet locates a host within a MANET, when it knows noting 
> > about that
> > host, except its IP (however that is constructed).  If a host 
> > will only
> > belong to a particular MANET, some sort of subnet address 
> would seem a
> > logical choice, but if that host could belong to any one of 
> > numerous MANETs,
> > I can see things are far more complex.  The MANETs I work 
> > with are of the
> > first type, but, as you point out, this is not the most 
> general case.
> 
> This is in RFC 2002.
> 
> Begin this story with the MANET host, call it Host M, coming 
> on line suddenly in some arbitrary MANET. The first thing 
> Host M does is it figures out if it's home or away. It does 
> so by listening for agent advertisements and/or transmitting 
> agent solicitations. (This protocol is an extensions of the 
> older ICMP router discovery protocol.)
> 
> Having found that it is away, and that a "foreign agent" is 
> available, host M then registers with its "home agent" 
> through this "foreign agent." The foreign agent acts only as 
> a passive relay to and from the home agent, in this process.
> 
> Host M's "home agent" authenticates this registration 
> request, and now knows which foreign agent in the Internet is 
> currently entrusted with host M. In our case, this foreign 
> agent would be associated with an Internet-MANET gateway. Or 
> it might be part of the gateway.
> 
> Let's say an Internet host "I" needs to reach a host M, 
> without knowing where host M is. In general, all host I knows 
> is the address of host M.
> 
> The IP packet from host I reaches the "home agent" of host M, 
> simply because the IP DA on that packet routes it through 
> that host M home agent. Host M's home agent knows to 
> intercept any packet addressed to host M, and is keeping 
> track of the current foreign agent servicing host M. This 
> home agent then tunnels the packet meant for host M by 
> encapsulating it in an outer wrapper with the foreign agent's 
> address on it. And the foreign agent forwards it to the MANET host.
> 
> The problem of how to reach the MANET host within the MANET 
> remains, of course, since that is not part of Mobile IP. 
> However, Mobile IP does pretty well answer the question of 
> how an Internet host can initiate a session with a MANET 
> host, without knowing where that MANET host is.
> 
> I believe that the hosts within the MANET can keep using 
> their own, permanent IP addresses, as we discussed already, 
> as long as the gateways keep a list of every host in their 
> MANET and as long as every MANET packet is routed explicitly, 
> hop by hop, within the MANET (not very scalable, but that's 
> not unusual in MANETs). So I believe that this combination 
> would create a generic solution.
> 
> Bert
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:12:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09158
	for ; Fri, 19 Jul 2002 10:12:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11189
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:13:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06661;
	Fri, 19 Jul 2002 09:53:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21318
	for ; Fri, 19 Jul 2002 04:20:33 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03101
	for ; Fri, 19 Jul 2002 04:19:33 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8KVRb013960
	for ; Fri, 19 Jul 2002 10:20:31 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACVQ0>; Fri, 19 Jul 2002 10:20:30 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FA@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Gateway address resolution
Date: Fri, 19 Jul 2002 10:14:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Bert,

The solution you describe, plus how the communication between the foreign agent and the MANET host can be done, was published '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf).

BR,
Fredrik

> -----Original Message-----
> From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
> Sent: den 10 juli 2002 17:48
> To: 'Mullen, John P. (Contractor)'
> Cc: manet@ietf.org
> Subject: RE: [manet] Gateway address resolution
> 
> 
> John Mullen wrote:
> 
> > Hi Bert,
> > 
> > I am concerned, as Charlie is, with the problem of how a node 
> > within the
> > Internet locates a host within a MANET, when it knows noting 
> > about that
> > host, except its IP (however that is constructed).  If a host 
> > will only
> > belong to a particular MANET, some sort of subnet address 
> would seem a
> > logical choice, but if that host could belong to any one of 
> > numerous MANETs,
> > I can see things are far more complex.  The MANETs I work 
> > with are of the
> > first type, but, as you point out, this is not the most 
> general case.
> 
> This is in RFC 2002.
> 
> Begin this story with the MANET host, call it Host M, coming 
> on line suddenly in some arbitrary MANET. The first thing 
> Host M does is it figures out if it's home or away. It does 
> so by listening for agent advertisements and/or transmitting 
> agent solicitations. (This protocol is an extensions of the 
> older ICMP router discovery protocol.)
> 
> Having found that it is away, and that a "foreign agent" is 
> available, host M then registers with its "home agent" 
> through this "foreign agent." The foreign agent acts only as 
> a passive relay to and from the home agent, in this process.
> 
> Host M's "home agent" authenticates this registration 
> request, and now knows which foreign agent in the Internet is 
> currently entrusted with host M. In our case, this foreign 
> agent would be associated with an Internet-MANET gateway. Or 
> it might be part of the gateway.
> 
> Let's say an Internet host "I" needs to reach a host M, 
> without knowing where host M is. In general, all host I knows 
> is the address of host M.
> 
> The IP packet from host I reaches the "home agent" of host M, 
> simply because the IP DA on that packet routes it through 
> that host M home agent. Host M's home agent knows to 
> intercept any packet addressed to host M, and is keeping 
> track of the current foreign agent servicing host M. This 
> home agent then tunnels the packet meant for host M by 
> encapsulating it in an outer wrapper with the foreign agent's 
> address on it. And the foreign agent forwards it to the MANET host.
> 
> The problem of how to reach the MANET host within the MANET 
> remains, of course, since that is not part of Mobile IP. 
> However, Mobile IP does pretty well answer the question of 
> how an Internet host can initiate a session with a MANET 
> host, without knowing where that MANET host is.
> 
> I believe that the hosts within the MANET can keep using 
> their own, permanent IP addresses, as we discussed already, 
> as long as the gateways keep a list of every host in their 
> MANET and as long as every MANET packet is routed explicitly, 
> hop by hop, within the MANET (not very scalable, but that's 
> not unusual in MANETs). So I believe that this combination 
> would create a generic solution.
> 
> Bert
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:13:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09196
	for ; Fri, 19 Jul 2002 10:13:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07782;
	Fri, 19 Jul 2002 09:56:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21363
	for ; Fri, 19 Jul 2002 04:22:03 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03121
	for ; Fri, 19 Jul 2002 04:21:04 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8M2Rc014301
	for ; Fri, 19 Jul 2002 10:22:02 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACW1J>; Fri, 19 Jul 2002 10:22:02 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FB@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Date: Fri, 19 Jul 2002 10:15:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [manet] Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that sending gateway advertisements peridically would generate unnecessary packets in the Manet. Can you please explain how you came to that conclusion? Our simulation study on MIPMANET from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) indicates that it actually can decrease the number of packet transmissions in the MANET.

BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email: fredrik.alriksson@ericsson.com





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:13:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09205
	for ; Fri, 19 Jul 2002 10:13:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11298
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:14:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07782;
	Fri, 19 Jul 2002 09:56:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21363
	for ; Fri, 19 Jul 2002 04:22:03 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03121
	for ; Fri, 19 Jul 2002 04:21:04 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8M2Rc014301
	for ; Fri, 19 Jul 2002 10:22:02 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACW1J>; Fri, 19 Jul 2002 10:22:02 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FB@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Date: Fri, 19 Jul 2002 10:15:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [manet] Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that sending gateway advertisements peridically would generate unnecessary packets in the Manet. Can you please explain how you came to that conclusion? Our simulation study on MIPMANET from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) indicates that it actually can decrease the number of packet transmissions in the MANET.

BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email: fredrik.alriksson@ericsson.com





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:16:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09288
	for ; Fri, 19 Jul 2002 10:16:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08365;
	Fri, 19 Jul 2002 09:59:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21459
	for ; Fri, 19 Jul 2002 04:23:15 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03137
	for ; Fri, 19 Jul 2002 04:22:16 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8NErU024754
	for ; Fri, 19 Jul 2002 10:23:14 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACW39>; Fri, 19 Jul 2002 10:23:14 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FE@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:17:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Ryuji,

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 11 juli 2002 02:38
> To: Fredrik.Alriksson@era.ericsson.se
> Cc: ryuji@sfc.wide.ad.jp; charliep@iprg.nokia.com;
> jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
> manet@ietf.org
> Subject: [manet] Re: Gateway Advertisements
> 
> 
> 
> Hello Fredrik
> 
> I am catching up now, but let me reply to this first.
> 
> At Tue, 9 Jul 2002 09:46:15 +0200 ,
> Fredrik Alriksson (EAB) wrote:
> > 
> > Hi Ryuji,
> > 
> > In what sense are the gateway advertisements unnecessary?
> 
> I did not say all RAs which are periodically advertising are
> un-necessary.  If gateway advertise RAs periodically, some of RAs are 
> not processed by any nodes. And these RAs are flooded over manet
> network untill TTL is expired.

But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!

> 
> 
> > In case there are multiple gateways, the flooding of gateway
> > advertisements may actually _decrease_ the total number of packet
> > transmissions (control and user data transmissions) in the MANET!
> > 
> > Flooding gateway advertisements can enable manet nodes which already
> > have a global address to select a _closer_ gateway. This means that
> > the average distance between gateway and manet node can be
> > decreased. This in turn decreases the number of packet transmissions
> > required to deliver user data between the gateways and the manet
> > nodes. Depending on the user activity, this reduction can be larger
> > than the increase in control packet transmissions.
> >
> > Other benefits are that the average user data delay decreases, and
> > that the manet nodes loose contact with their gateway less
> > frequently.
> 
> The draft said that once manet node gets global info from a GW, it can
> update the info by unicasting request message to the GW. 
> Manet node may change
> the GW to closer one any time by re-selecting an appropriate GW from
> the node's GW lists or by re-flooding requests to discover closer
> depending on some events like topology change.  
> GW lists is node introduced in the draft, but let's say it is the
> lists of GWs which are replyig to node's gateway discovery.

For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
How does the Manet node know when to re-flood the request?
How large fraction of all relevant topology changes will the Manet node detect?

My conclusion is still: it is better to let the GW flood periodically.

> 
> In appendix A, we explain how to use the most appropriate GW with a
> routing header. I think the draft can be adapted to your above
> situation. What do you think?
> 
> --Snip from the drat
>    Using a routing header is also preferable if there are 
> more than two
> Internet-gateways, because the node then have the ability to decide
> which Internet-gateway is the best, by distance in hops, or by some
> other priority.  By assign a priority number for each 
> Internet-gateway,
> the route reply message and the Manet Router Advertisement messages
> could be extended to support a candidate Internet-gateway 
> option in it.
> -----

I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?

> I think we should clarify much more about situations when multiple GWs
> are located.
> 
> # Can you explain more about simulated unicast situation.  Can a manet
>   node receive RA from only associated GW? Didn't you use solicited
>   request from the manet node? If not, GW will discover the manet node
>   route, when it sends RA to the node and can not find fresh route for
>   the node. 

I think you have a good point here; we did use RA's but perhaps not optimally.

> This does not happen to our solution.

Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.

Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
 
> > Regarding TTL, I don't see the problem, unless advertisements were
> > forwarded on non-manet interfaces. Can you please elaborate a bit?
> 
> In your thesis, you mentioned "Limited TTL". This is almost what I
> want to explain here. If there is a single GW in manet, RA should be
> flooded over whole manet. You can not use optimization like expanding
> ring search for flooding. If Manet nodes can not get RAs sent with
> limited TTL by GW, it has to discover GW by solicited requests.

Sure, but is that really a problem?

BR,
Fredrik

> best regards,
> ryuji
> 
> > BR,
> > Fredrik
> > 
> > > -----Original Message-----
> > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> > > Sent: den 8 juli 2002 18:40
> > > To: Fredrik.Alriksson@era.ericsson.se
> > > Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
> > > jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; 
> andersn@telecom.lth.se;
> > > manet@ietf.org
> > > Subject: Re: Gateway Advertisements
> > > 
> > > 
> > > 
> > > Hello Fredrik.
> > > 
> > > In the draft, unnecessary packets basically indicates un-necessary
> > > gateway advertisements. For example, if a gateway 
> generates a route
> > > advertisement every 1 sec, most of router advertisements 
> are redundant
> > > for manet nodes which have already had a global address. They may
> > > update lifetime of their global address, but the interval(1sec) is
> > > still too short for this operations.
> > > 
> > > Since flooding packets is easy to cause performance 
> damage in manet,
> > > our approach tries to reduce a number of packets which are 
> > > flooded over
> > > manet. I think manet nodes should not wait flooded 
> advertisements from
> > > gateway, instead manet node should discover gateways on their
> > > initiative.
> > > 
> > > It is also difficult for gateways to decide TTL for flooded
> > > advertisements. Expanding ring search technique can not 
> be applied to
> > > this situation, because advertisements should reach at the edge of
> > > manet. It can imagine that unnecessary network-wide 
> dissemination of
> > > advertisements will occur when a gateway sets larger TTL 
> than manet
> > > scale.
> > > 
> > > regards,
> > > ryuji
> > > 
> > > 
> > > At Mon, 8 Jul 2002 17:27:19 +0200 ,
> > > Fredrik Alriksson (EAB) wrote:
> > > > 
> > > > Hi All,
> > > > 
> > > > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> > > sending gateway advertisements peridically would generate 
> > > unnecessary packets in the Manet. Can you please explain how 
> > > you came to that conclusion? Our simulation study on MIPMANET 
> > > from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
> > > indicates that it actually can decrease the number of packet 
> > > transmissions in the MANET.
> > > > 
> > > > BR,
> > > > Fredrik
> > > > 
> > > > ---
> > > > Fredrik Alriksson, Ericsson Research
> > > > Email: fredrik.alriksson@ericsson.com
> > > > 
> > > > 
> > > 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:16:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09295
	for ; Fri, 19 Jul 2002 10:16:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11581
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:17:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08365;
	Fri, 19 Jul 2002 09:59:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21459
	for ; Fri, 19 Jul 2002 04:23:15 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03137
	for ; Fri, 19 Jul 2002 04:22:16 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8NErU024754
	for ; Fri, 19 Jul 2002 10:23:14 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACW39>; Fri, 19 Jul 2002 10:23:14 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FE@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:17:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Ryuji,

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 11 juli 2002 02:38
> To: Fredrik.Alriksson@era.ericsson.se
> Cc: ryuji@sfc.wide.ad.jp; charliep@iprg.nokia.com;
> jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
> manet@ietf.org
> Subject: [manet] Re: Gateway Advertisements
> 
> 
> 
> Hello Fredrik
> 
> I am catching up now, but let me reply to this first.
> 
> At Tue, 9 Jul 2002 09:46:15 +0200 ,
> Fredrik Alriksson (EAB) wrote:
> > 
> > Hi Ryuji,
> > 
> > In what sense are the gateway advertisements unnecessary?
> 
> I did not say all RAs which are periodically advertising are
> un-necessary.  If gateway advertise RAs periodically, some of RAs are 
> not processed by any nodes. And these RAs are flooded over manet
> network untill TTL is expired.

But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!

> 
> 
> > In case there are multiple gateways, the flooding of gateway
> > advertisements may actually _decrease_ the total number of packet
> > transmissions (control and user data transmissions) in the MANET!
> > 
> > Flooding gateway advertisements can enable manet nodes which already
> > have a global address to select a _closer_ gateway. This means that
> > the average distance between gateway and manet node can be
> > decreased. This in turn decreases the number of packet transmissions
> > required to deliver user data between the gateways and the manet
> > nodes. Depending on the user activity, this reduction can be larger
> > than the increase in control packet transmissions.
> >
> > Other benefits are that the average user data delay decreases, and
> > that the manet nodes loose contact with their gateway less
> > frequently.
> 
> The draft said that once manet node gets global info from a GW, it can
> update the info by unicasting request message to the GW. 
> Manet node may change
> the GW to closer one any time by re-selecting an appropriate GW from
> the node's GW lists or by re-flooding requests to discover closer
> depending on some events like topology change.  
> GW lists is node introduced in the draft, but let's say it is the
> lists of GWs which are replyig to node's gateway discovery.

For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
How does the Manet node know when to re-flood the request?
How large fraction of all relevant topology changes will the Manet node detect?

My conclusion is still: it is better to let the GW flood periodically.

> 
> In appendix A, we explain how to use the most appropriate GW with a
> routing header. I think the draft can be adapted to your above
> situation. What do you think?
> 
> --Snip from the drat
>    Using a routing header is also preferable if there are 
> more than two
> Internet-gateways, because the node then have the ability to decide
> which Internet-gateway is the best, by distance in hops, or by some
> other priority.  By assign a priority number for each 
> Internet-gateway,
> the route reply message and the Manet Router Advertisement messages
> could be extended to support a candidate Internet-gateway 
> option in it.
> -----

I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?

> I think we should clarify much more about situations when multiple GWs
> are located.
> 
> # Can you explain more about simulated unicast situation.  Can a manet
>   node receive RA from only associated GW? Didn't you use solicited
>   request from the manet node? If not, GW will discover the manet node
>   route, when it sends RA to the node and can not find fresh route for
>   the node. 

I think you have a good point here; we did use RA's but perhaps not optimally.

> This does not happen to our solution.

Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.

Furthermore, if using flooding, how often should Manet nodes flood the solicitations?
 
> > Regarding TTL, I don't see the problem, unless advertisements were
> > forwarded on non-manet interfaces. Can you please elaborate a bit?
> 
> In your thesis, you mentioned "Limited TTL". This is almost what I
> want to explain here. If there is a single GW in manet, RA should be
> flooded over whole manet. You can not use optimization like expanding
> ring search for flooding. If Manet nodes can not get RAs sent with
> limited TTL by GW, it has to discover GW by solicited requests.

Sure, but is that really a problem?

BR,
Fredrik

> best regards,
> ryuji
> 
> > BR,
> > Fredrik
> > 
> > > -----Original Message-----
> > > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> > > Sent: den 8 juli 2002 18:40
> > > To: Fredrik.Alriksson@era.ericsson.se
> > > Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
> > > jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; 
> andersn@telecom.lth.se;
> > > manet@ietf.org
> > > Subject: Re: Gateway Advertisements
> > > 
> > > 
> > > 
> > > Hello Fredrik.
> > > 
> > > In the draft, unnecessary packets basically indicates un-necessary
> > > gateway advertisements. For example, if a gateway 
> generates a route
> > > advertisement every 1 sec, most of router advertisements 
> are redundant
> > > for manet nodes which have already had a global address. They may
> > > update lifetime of their global address, but the interval(1sec) is
> > > still too short for this operations.
> > > 
> > > Since flooding packets is easy to cause performance 
> damage in manet,
> > > our approach tries to reduce a number of packets which are 
> > > flooded over
> > > manet. I think manet nodes should not wait flooded 
> advertisements from
> > > gateway, instead manet node should discover gateways on their
> > > initiative.
> > > 
> > > It is also difficult for gateways to decide TTL for flooded
> > > advertisements. Expanding ring search technique can not 
> be applied to
> > > this situation, because advertisements should reach at the edge of
> > > manet. It can imagine that unnecessary network-wide 
> dissemination of
> > > advertisements will occur when a gateway sets larger TTL 
> than manet
> > > scale.
> > > 
> > > regards,
> > > ryuji
> > > 
> > > 
> > > At Mon, 8 Jul 2002 17:27:19 +0200 ,
> > > Fredrik Alriksson (EAB) wrote:
> > > > 
> > > > Hi All,
> > > > 
> > > > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> > > sending gateway advertisements peridically would generate 
> > > unnecessary packets in the Manet. Can you please explain how 
> > > you came to that conclusion? Our simulation study on MIPMANET 
> > > from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
> > > indicates that it actually can decrease the number of packet 
> > > transmissions in the MANET.
> > > > 
> > > > BR,
> > > > Fredrik
> > > > 
> > > > ---
> > > > Fredrik Alriksson, Ericsson Research
> > > > Email: fredrik.alriksson@ericsson.com
> > > > 
> > > > 
> > > 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:16:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09319
	for ; Fri, 19 Jul 2002 10:16:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06277;
	Fri, 19 Jul 2002 09:52:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15428
	for ; Thu, 18 Jul 2002 03:38:55 -0400 (EDT)
Received: from mail.informatik.uni-ulm.de (mail.informatik.uni-ulm.de [134.60.68.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25148
	for ; Thu, 18 Jul 2002 03:37:55 -0400 (EDT)
Received: from brandung.informatik.uni-ulm.de ([134.60.70.41] helo=informatik.uni-ulm.de)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.33 #1)
	id 17V5sC-0003EI-00
	for manet@ietf.org; Thu, 18 Jul 2002 09:38:52 +0200
Message-ID: <3D36704B.4B412604@informatik.uni-ulm.de>
Date: Thu, 18 Jul 2002 09:37:47 +0200
From: =?iso-8859-1?Q?J=FCrgen?= Nagler 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode
References: <02Jul17.112733mdt.117124@gw.trac.wsmr.army.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

"Mullen, John P. (Contractor)" wrote:
> 
> I'm willing to give reading the paper a whack, but my German technical
> dictionary is very much outdated.  Can anyone recommend an up-to-date
> technical reference?

as John already found out by reading our paper the technical expressions
in the network field almost have no German translation :-)


Regards,

Jürgen Nagler


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:16:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09326
	for ; Fri, 19 Jul 2002 10:16:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11617
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:17:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06277;
	Fri, 19 Jul 2002 09:52:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15428
	for ; Thu, 18 Jul 2002 03:38:55 -0400 (EDT)
Received: from mail.informatik.uni-ulm.de (mail.informatik.uni-ulm.de [134.60.68.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25148
	for ; Thu, 18 Jul 2002 03:37:55 -0400 (EDT)
Received: from brandung.informatik.uni-ulm.de ([134.60.70.41] helo=informatik.uni-ulm.de)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.33 #1)
	id 17V5sC-0003EI-00
	for manet@ietf.org; Thu, 18 Jul 2002 09:38:52 +0200
Message-ID: <3D36704B.4B412604@informatik.uni-ulm.de>
Date: Thu, 18 Jul 2002 09:37:47 +0200
From: =?iso-8859-1?Q?J=FCrgen?= Nagler 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode
References: <02Jul17.112733mdt.117124@gw.trac.wsmr.army.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

"Mullen, John P. (Contractor)" wrote:
> 
> I'm willing to give reading the paper a whack, but my German technical
> dictionary is very much outdated.  Can anyone recommend an up-to-date
> technical reference?

as John already found out by reading our paper the technical expressions
in the network field almost have no German translation :-)


Regards,

Jürgen Nagler


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:17:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09360
	for ; Fri, 19 Jul 2002 10:17:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06202;
	Fri, 19 Jul 2002 09:51:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09330
	for ; Thu, 18 Jul 2002 02:00:58 -0400 (EDT)
Received: from patty.levels.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13991
	for ; Thu, 18 Jul 2002 01:59:58 -0400 (EDT)
Received: from pphampc (haddock [172.17.0.69])
	by patty.levels.unisa.edu.au (8.12.2/8.12.2) with ESMTP id g6I60hDs018369
	for ; Thu, 18 Jul 2002 15:30:53 +0930 (CST)
From: "Peter Pham" 
To: 
Date: Thu, 18 Jul 2002 15:31:32 +0930
Organization: Institute for Telecommunications Research
Message-ID: <001f01c22e20$93f42f40$450011ac@pphampc>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0020_01C22E70.34BE0B40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: [manet] TCP/IP over DSR
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C22E70.34BE0B40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi everyone.
Has anyone had result of performance of DSR over TCP/IP by model in
OPNET or ns2. 
I checked out the DSR model from NIST and extension of that by someone
on that website using OPNET. However, all does not have TCP/IP included.
Has anyone enhanced that model using TCP/IP traffic to see the
performance ???. I am planning to do some development on that to see how
really it behaves.
I remembered reading one paper saying that with TCP/IP the best
performance is achieved when the window size is 1 which is really scary.
If anyone can share the knowledge of TCP/IP in adhoc networks, I really
appreciate that.
Thanks 
 
Best Regards. 
Peter Pham 
================================= 
The University of South Australia 
Institute for Telecommunications Research
Mawson Lakes Campus SA5095 
Office  :   08-83025188
Fax      :   83023873
Mob    :   0422100867   
Email   :   ppham@spri.levels.unisa.edu.au 
WWW:   http://www.itr.unisa.edu.au/~ppham
 ================================= 
 

------=_NextPart_000_0020_01C22E70.34BE0B40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message




Hi=20
everyone.


Has =
anyone had=20
result of performance of DSR over TCP/IP by model in OPNET or ns2.=20



I =
checked out the=20
DSR model from NIST and extension of that by someone on that =
website using=20
OPNET. However, all does not have TCP/IP included.


Has=20
anyone enhanced that model using TCP/IP traffic to see the =
performance ???.=20
I am planning to do some development on that to see how really it=20
behaves.


I =
remembered reading=20
one paper saying that with TCP/IP the best performance is achieved when =
the=20
window size is 1 which is really scary.


If =
anyone can share=20
the knowledge of TCP/IP in adhoc networks, I really appreciate=20
that.


Thanks =




 


Best Regards. 


Peter Pham 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


The University of South Australia 


Institute for Telecommunications Research


Mawson Lakes Campus SA5095 


Office  :   08-83025188


Fax      :   =
83023873


Mob    :   =
0422100867  =20



Email   :   ppham@spri.levels.unisa.ed=
u.au=20



WWW:   http://www.itr.unisa.edu.au/~=
ppham


 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


 


------=_NextPart_000_0020_01C22E70.34BE0B40--




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:17:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09368
	for ; Fri, 19 Jul 2002 10:17:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11674
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:18:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06202;
	Fri, 19 Jul 2002 09:51:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09330
	for ; Thu, 18 Jul 2002 02:00:58 -0400 (EDT)
Received: from patty.levels.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13991
	for ; Thu, 18 Jul 2002 01:59:58 -0400 (EDT)
Received: from pphampc (haddock [172.17.0.69])
	by patty.levels.unisa.edu.au (8.12.2/8.12.2) with ESMTP id g6I60hDs018369
	for ; Thu, 18 Jul 2002 15:30:53 +0930 (CST)
From: "Peter Pham" 
To: 
Date: Thu, 18 Jul 2002 15:31:32 +0930
Organization: Institute for Telecommunications Research
Message-ID: <001f01c22e20$93f42f40$450011ac@pphampc>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0020_01C22E70.34BE0B40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Subject: [manet] TCP/IP over DSR
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C22E70.34BE0B40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi everyone.
Has anyone had result of performance of DSR over TCP/IP by model in
OPNET or ns2. 
I checked out the DSR model from NIST and extension of that by someone
on that website using OPNET. However, all does not have TCP/IP included.
Has anyone enhanced that model using TCP/IP traffic to see the
performance ???. I am planning to do some development on that to see how
really it behaves.
I remembered reading one paper saying that with TCP/IP the best
performance is achieved when the window size is 1 which is really scary.
If anyone can share the knowledge of TCP/IP in adhoc networks, I really
appreciate that.
Thanks 
 
Best Regards. 
Peter Pham 
================================= 
The University of South Australia 
Institute for Telecommunications Research
Mawson Lakes Campus SA5095 
Office  :   08-83025188
Fax      :   83023873
Mob    :   0422100867   
Email   :   ppham@spri.levels.unisa.edu.au 
WWW:   http://www.itr.unisa.edu.au/~ppham
 ================================= 
 

------=_NextPart_000_0020_01C22E70.34BE0B40
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message




Hi=20
everyone.


Has =
anyone had=20
result of performance of DSR over TCP/IP by model in OPNET or ns2.=20



I =
checked out the=20
DSR model from NIST and extension of that by someone on that =
website using=20
OPNET. However, all does not have TCP/IP included.


Has=20
anyone enhanced that model using TCP/IP traffic to see the =
performance ???.=20
I am planning to do some development on that to see how really it=20
behaves.


I =
remembered reading=20
one paper saying that with TCP/IP the best performance is achieved when =
the=20
window size is 1 which is really scary.


If =
anyone can share=20
the knowledge of TCP/IP in adhoc networks, I really appreciate=20
that.


Thanks =




 


Best Regards. 


Peter Pham 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


The University of South Australia 


Institute for Telecommunications Research


Mawson Lakes Campus SA5095 


Office  :   08-83025188


Fax      :   =
83023873


Mob    :   =
0422100867  =20



Email   :   ppham@spri.levels.unisa.ed=
u.au=20



WWW:   http://www.itr.unisa.edu.au/~=
ppham


 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


 


------=_NextPart_000_0020_01C22E70.34BE0B40--




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:20:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09468
	for ; Fri, 19 Jul 2002 10:20:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06351;
	Fri, 19 Jul 2002 09:52:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19439
	for ; Thu, 18 Jul 2002 19:58:42 -0400 (EDT)
Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16168
	for ; Thu, 18 Jul 2002 19:57:44 -0400 (EDT)
Received: from pphampc nppham@smtp-send.myrealbox.com [130.220.36.156]
	by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision:   3.9  $ on Novell NetWare;
	Thu, 18 Jul 2002 17:58:42 -0600
From: "Peter Pham" 
To: 
Date: Fri, 19 Jul 2002 09:29:27 +0930
Organization: Institute for Telecommunications Research
Message-ID: <000d01c22eb7$27162210$450011ac@pphampc>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01C22F06.C7DFFE10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [manet] TCP/IP over DSR
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C22F06.C7DFFE10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi everyone.
Has anyone had result of performance of DSR over TCP/IP by model in
OPNET or ns2. 
I checked out the DSR model from NIST and extension of that by someone
on that website using OPNET. However, all does not have TCP/IP included.
Has anyone enhanced that model using TCP/IP traffic to see the
performance ???. I am planning to do some development on that to see how
really it behaves.
I remembered reading one paper saying that with TCP/IP the best
performance is achieved when the window size is 1 which is really scary.
If anyone can share the knowledge of TCP/IP in adhoc networks, I really
appreciate that.
Thanks 
 
Best Regards. 
Peter Pham 
================================= 
The University of South Australia 
Institute for Telecommunications Research
Mawson Lakes Campus SA5095 
Office  :   08-83025188
Fax      :   83023873
Mob    :   0422100867   
Email   :   ppham@spri.levels.unisa.edu.au 
WWW:   http://www.itr.unisa.edu.au/~ppham
 ================================= 
 
 
Best Regards. 
Peter Pham 
================================= 
The University of South Australia 
Institute for Telecommunications Research
Mawson Lakes Campus SA5095 
Office  :   08-83025188
Fax      :   83023873
Mob    :   0422100867   
Email   :   ppham@spri.levels.unisa.edu.au 
WWW:   http://www.itr.unisa.edu.au/~ppham
 ================================= 
 

------=_NextPart_000_000E_01C22F06.C7DFFE10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message






Hi=20
everyone.


Has =
anyone had=20
result of performance of DSR over TCP/IP by model in OPNET or ns2.=20



I =
checked out the=20
DSR model from NIST and extension of that by someone on that =
website using=20
OPNET. However, all does not have TCP/IP included.


Has=20
anyone enhanced that model using TCP/IP traffic to see the =
performance ???.=20
I am planning to do some development on that to see how really it=20
behaves.


I =
remembered reading=20
one paper saying that with TCP/IP the best performance is achieved when =
the=20
window size is 1 which is really scary.


If =
anyone can share=20
the knowledge of TCP/IP in adhoc networks, I really appreciate=20
that.


Thanks =




 


Best Regards. 


Peter Pham 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


The University of South Australia 


Institute for Telecommunications Research


Mawson Lakes Campus SA5095 


Office  :   08-83025188


Fax      :   =
83023873


Mob    :   =
0422100867  =20



Email   :   ppham@spri.levels.unisa.ed=
u.au=20



WWW:   http://www.itr.unisa.edu.au/~=
ppham


 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


 


 


Best Regards. 


Peter Pham 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


The University of South Australia 


Institute for Telecommunications Research


Mawson Lakes Campus SA5095 


Office  :   08-83025188


Fax      :   =
83023873


Mob    :   =
0422100867  =20



Email   :   ppham@spri.levels.unisa.ed=
u.au=20



WWW:   http://www.itr.unisa.edu.au/~=
ppham


 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


 


------=_NextPart_000_000E_01C22F06.C7DFFE10--




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:20:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09476
	for ; Fri, 19 Jul 2002 10:20:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11865
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:21:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06351;
	Fri, 19 Jul 2002 09:52:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19439
	for ; Thu, 18 Jul 2002 19:58:42 -0400 (EDT)
Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16168
	for ; Thu, 18 Jul 2002 19:57:44 -0400 (EDT)
Received: from pphampc nppham@smtp-send.myrealbox.com [130.220.36.156]
	by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision:   3.9  $ on Novell NetWare;
	Thu, 18 Jul 2002 17:58:42 -0600
From: "Peter Pham" 
To: 
Date: Fri, 19 Jul 2002 09:29:27 +0930
Organization: Institute for Telecommunications Research
Message-ID: <000d01c22eb7$27162210$450011ac@pphampc>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000E_01C22F06.C7DFFE10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [manet] TCP/IP over DSR
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C22F06.C7DFFE10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi everyone.
Has anyone had result of performance of DSR over TCP/IP by model in
OPNET or ns2. 
I checked out the DSR model from NIST and extension of that by someone
on that website using OPNET. However, all does not have TCP/IP included.
Has anyone enhanced that model using TCP/IP traffic to see the
performance ???. I am planning to do some development on that to see how
really it behaves.
I remembered reading one paper saying that with TCP/IP the best
performance is achieved when the window size is 1 which is really scary.
If anyone can share the knowledge of TCP/IP in adhoc networks, I really
appreciate that.
Thanks 
 
Best Regards. 
Peter Pham 
================================= 
The University of South Australia 
Institute for Telecommunications Research
Mawson Lakes Campus SA5095 
Office  :   08-83025188
Fax      :   83023873
Mob    :   0422100867   
Email   :   ppham@spri.levels.unisa.edu.au 
WWW:   http://www.itr.unisa.edu.au/~ppham
 ================================= 
 
 
Best Regards. 
Peter Pham 
================================= 
The University of South Australia 
Institute for Telecommunications Research
Mawson Lakes Campus SA5095 
Office  :   08-83025188
Fax      :   83023873
Mob    :   0422100867   
Email   :   ppham@spri.levels.unisa.edu.au 
WWW:   http://www.itr.unisa.edu.au/~ppham
 ================================= 
 

------=_NextPart_000_000E_01C22F06.C7DFFE10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message






Hi=20
everyone.


Has =
anyone had=20
result of performance of DSR over TCP/IP by model in OPNET or ns2.=20



I =
checked out the=20
DSR model from NIST and extension of that by someone on that =
website using=20
OPNET. However, all does not have TCP/IP included.


Has=20
anyone enhanced that model using TCP/IP traffic to see the =
performance ???.=20
I am planning to do some development on that to see how really it=20
behaves.


I =
remembered reading=20
one paper saying that with TCP/IP the best performance is achieved when =
the=20
window size is 1 which is really scary.


If =
anyone can share=20
the knowledge of TCP/IP in adhoc networks, I really appreciate=20
that.


Thanks =




 


Best Regards. 


Peter Pham 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


The University of South Australia 


Institute for Telecommunications Research


Mawson Lakes Campus SA5095 


Office  :   08-83025188


Fax      :   =
83023873


Mob    :   =
0422100867  =20



Email   :   ppham@spri.levels.unisa.ed=
u.au=20



WWW:   http://www.itr.unisa.edu.au/~=
ppham


 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


 


 


Best Regards. 


Peter Pham 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


The University of South Australia 


Institute for Telecommunications Research


Mawson Lakes Campus SA5095 


Office  :   08-83025188


Fax      :   =
83023873


Mob    :   =
0422100867  =20



Email   :   ppham@spri.levels.unisa.ed=
u.au=20



WWW:   http://www.itr.unisa.edu.au/~=
ppham


 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


 


------=_NextPart_000_000E_01C22F06.C7DFFE10--




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:21:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09558
	for ; Fri, 19 Jul 2002 10:21:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08077;
	Fri, 19 Jul 2002 09:58:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21393
	for ; Fri, 19 Jul 2002 04:22:34 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03126
	for ; Fri, 19 Jul 2002 04:21:35 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8MXRb014414
	for ; Fri, 19 Jul 2002 10:22:33 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACWJM>; Fri, 19 Jul 2002 10:22:33 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FC@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Date: Fri, 19 Jul 2002 10:16:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [manet] RE: Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet interfaces. Can you please elaborate a bit?

BR,
Fredrik

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 8 juli 2002 18:40
> To: Fredrik.Alriksson@era.ericsson.se
> Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
> jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
> manet@ietf.org
> Subject: Re: Gateway Advertisements
> 
> 
> 
> Hello Fredrik.
> 
> In the draft, unnecessary packets basically indicates un-necessary
> gateway advertisements. For example, if a gateway generates a route
> advertisement every 1 sec, most of router advertisements are redundant
> for manet nodes which have already had a global address. They may
> update lifetime of their global address, but the interval(1sec) is
> still too short for this operations.
> 
> Since flooding packets is easy to cause performance damage in manet,
> our approach tries to reduce a number of packets which are 
> flooded over
> manet. I think manet nodes should not wait flooded advertisements from
> gateway, instead manet node should discover gateways on their
> initiative.
> 
> It is also difficult for gateways to decide TTL for flooded
> advertisements. Expanding ring search technique can not be applied to
> this situation, because advertisements should reach at the edge of
> manet. It can imagine that unnecessary network-wide dissemination of
> advertisements will occur when a gateway sets larger TTL than manet
> scale.
> 
> regards,
> ryuji
> 
> 
> At Mon, 8 Jul 2002 17:27:19 +0200 ,
> Fredrik Alriksson (EAB) wrote:
> > 
> > Hi All,
> > 
> > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> sending gateway advertisements peridically would generate 
> unnecessary packets in the Manet. Can you please explain how 
> you came to that conclusion? Our simulation study on MIPMANET 
> from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
> indicates that it actually can decrease the number of packet 
> transmissions in the MANET.
> > 
> > BR,
> > Fredrik
> > 
> > ---
> > Fredrik Alriksson, Ericsson Research
> > Email: fredrik.alriksson@ericsson.com
> > 
> > 
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:21:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09566
	for ; Fri, 19 Jul 2002 10:21:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11977
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:22:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08077;
	Fri, 19 Jul 2002 09:58:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21393
	for ; Fri, 19 Jul 2002 04:22:34 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03126
	for ; Fri, 19 Jul 2002 04:21:35 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8MXRb014414
	for ; Fri, 19 Jul 2002 10:22:33 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACWJM>; Fri, 19 Jul 2002 10:22:33 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FC@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Date: Fri, 19 Jul 2002 10:16:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [manet] RE: Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet interfaces. Can you please elaborate a bit?

BR,
Fredrik

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 8 juli 2002 18:40
> To: Fredrik.Alriksson@era.ericsson.se
> Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
> jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
> manet@ietf.org
> Subject: Re: Gateway Advertisements
> 
> 
> 
> Hello Fredrik.
> 
> In the draft, unnecessary packets basically indicates un-necessary
> gateway advertisements. For example, if a gateway generates a route
> advertisement every 1 sec, most of router advertisements are redundant
> for manet nodes which have already had a global address. They may
> update lifetime of their global address, but the interval(1sec) is
> still too short for this operations.
> 
> Since flooding packets is easy to cause performance damage in manet,
> our approach tries to reduce a number of packets which are 
> flooded over
> manet. I think manet nodes should not wait flooded advertisements from
> gateway, instead manet node should discover gateways on their
> initiative.
> 
> It is also difficult for gateways to decide TTL for flooded
> advertisements. Expanding ring search technique can not be applied to
> this situation, because advertisements should reach at the edge of
> manet. It can imagine that unnecessary network-wide dissemination of
> advertisements will occur when a gateway sets larger TTL than manet
> scale.
> 
> regards,
> ryuji
> 
> 
> At Mon, 8 Jul 2002 17:27:19 +0200 ,
> Fredrik Alriksson (EAB) wrote:
> > 
> > Hi All,
> > 
> > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> sending gateway advertisements peridically would generate 
> unnecessary packets in the Manet. Can you please explain how 
> you came to that conclusion? Our simulation study on MIPMANET 
> from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
> indicates that it actually can decrease the number of packet 
> transmissions in the MANET.
> > 
> > BR,
> > Fredrik
> > 
> > ---
> > Fredrik Alriksson, Ericsson Research
> > Email: fredrik.alriksson@ericsson.com
> > 
> > 
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:38:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10089
	for ; Fri, 19 Jul 2002 10:38:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08288;
	Fri, 19 Jul 2002 09:59:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21433
	for ; Fri, 19 Jul 2002 04:23:01 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03133
	for ; Fri, 19 Jul 2002 04:22:01 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8N0rU024715
	for ; Fri, 19 Jul 2002 10:23:00 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACWMC>; Fri, 19 Jul 2002 10:22:53 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FD@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'MANET mailing list'" 
Date: Fri, 19 Jul 2002 10:16:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22EFC.9FB71F90"
Subject: [manet] RE: Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C22EFC.9FB71F90
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Anders,
 
See comments inline.

-----Original Message-----
From: Anders Nilsson [mailto:andersn@telecom.lth.se]
Sent: den 9 juli 2002 11:29
To: Fredrik Alriksson (EAB); MANET mailing list
Cc: Ryuji Wakikawa
Subject: Re: Gateway Advertisements


Hello Fredrik!

For the solution described in the draft, unsolicited gateway advertisments are not neccessary
for the correct operation of the protocol.

[Fredrik Alriksson]  I never questioned that. You state that "Sending them (advertisements) periodically would generate unnecessary packets in the Manet", but as I've said in previous emails _not_ sending them periodically may generate _more_ traffic in the Manet.


I see your point and I think that it is question of whether a reactive or a more proactive approach
should be used. 

[Fredrik Alriksson] Perhaps a combination is preferable?


One of the reasons for not recomending gateway advertisement flooding is when you consider the scenario where some nodes might need internet access, and some might not.

[Fredrik Alriksson] Well, the nodes which do not need internet access may still benefit from the periodic floodings, since they probably are involved in the communication between the gateways and the manet nodes what do need internet access. Decreasing the total number of packet transmissions does not only benefit the nodes that need internet access!

When flooding of advertisements is being used,  packets are being flooded periodicly over all
nodes in the ad hoc network, regardsless of their need for internet connectivity. This is where hop_limit (TTL) considerations becomes important since every advertisement is rebroadcasted
as long as allowed by the hop_limit. So, what value for this hop_limit should be used? If we choose
a too small value we might not reach all nodes, and choosing a high value will introduce lots of traffic. 

[Fredrik Alriksson]  Can't a node that does not get the periodic advertisments send solicitations?


Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary.

[Fredrik Alriksson]  Even though the advertisements are not _necessary_ for the non-internet connected nodes, they may still benefit from the periodic advertisments indirectly, since the total number of packets that they have to forward (including both the advertisements _and_ the user data) may decrease!


In the draft we instead propose that the node itself should initiate this process, the gateway discovery process. In the case where there are multiple gateways, the node should upon receiving these advertisements choose the closest gateway.

[Fredrik Alriksson] Aren't we talking about _mobile_ ad hoc networks? For how long will the chosen gateway remain the closest gateway? 

regards,

Anders


[Fredrik Alriksson] BR, Fredrik

 

Fredrik Alriksson (EAB) wrote:

Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet 
interfaces. Can you please elaborate a bit?

BR,
Fredrik



-----Original Message-----
From: Ryuji Wakikawa [ mailto:ryuji@sfc.wide.ad.jp  ]
Sent: den 8 juli 2002 18:40
To:  Fredrik.Alriksson@era.ericsson.se  
Cc:  charliep@iprg.nokia.com  ;  ryuji@sfc.wide.ad.jp  ;
jmalinen@ipgr.nokia.com  ;  ajtuomin@tml.hut.fi  ;  andersn@telecom.lth.se  ;
manet@ietf.org  
Subject: Re: Gateway Advertisements



Hello Fred
rik.

In the draft, unnecessary packets basically indicates un-necessary
gateway advertisements. For example, if a gateway generates a route
advertisement every 1 sec, most of router advertisements are redundant
for manet nodes which have already had a global address. They may
update lifetime of their global address, but the interval(1sec) is
still too short for this operations.

Since flooding packets is easy to cause performance damage in manet,
our approach tries to reduce a number of packets which are 
flooded over
manet. I think manet nodes should not wait flooded advertisements from
gateway, instead manet node should discover gateways on their
initiative.

It is also difficult for gateways to decide TTL for flooded
advertisements. Expanding ring search technique can not be applied to
this situation, because advertisements should reach at the edge of
manet. It can imagine that unnecessary network-wide dissemination of
advertisements will occur when a gateway sets larger TTL than manet
scale.

regards,
ryuji


At Mon, 8 Jul 2002 17:27:19 +0200 ,
Fredrik Alriksson (EAB) wrote:


Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that 

sending gateway advertisements peridically would generate 
unnecessary packets in the Manet. Can you please explain how 
you came to that conclusion? Our simulation study on MIPMANET 
from '99 ( http://www.e.kth.se/~e94_fal/mipmanet.pdf  ) 
indicates that it actually can decrease the number of packet 
transmissions in the MANET.

BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email:  fredrik.alriksson@ericsson.com  






 


------_=_NextPart_001_01C22EFC.9FB71F90
Content-Type: text/html;
	charset="iso-8859-1"









Hi 
Anders,


 


See 
comments inline.



  
-----Original Message-----
From: Anders Nilsson 
  [mailto:andersn@telecom.lth.se]
Sent: den 9 juli 2002 
  11:29
To: Fredrik Alriksson (EAB); MANET mailing list
Cc: 
  Ryuji Wakikawa
Subject: Re: Gateway 
  Advertisements


  
Hello Fredrik!

For the solution described in the draft, 
  unsolicited gateway advertisments are not neccessary
for the correct 
  operation of the protocol.


[Fredrik Alriksson]  I never questioned that. You state 
that "Sending them (advertisements) periodically would generate unnecessary 
packets in the Manet", but as I've said in previous emails _not_ sending them 
periodically may generate _more_ traffic in the Manet.



  
I see your point and I think that it is question of whether a 
  reactive or a more proactive approach
should be used. 


[Fredrik Alriksson] Perhaps a combination is 
preferable?



  
One of the reasons for not recomending gateway advertisement 
  flooding is when you consider the scenario where some nodes might need 
  internet access, and some might not.


[Fredrik Alriksson] Well, the nodes which do not need internet 
access may still benefit from the periodic floodings, since they probably are 
involved in the communication between the gateways and the manet nodes what do 
need internet access. Decreasing the total number of packet transmissions does 
not only benefit the nodes that need internet access!



  
When flooding of advertisements is being used,  packets are 
  being flooded periodicly over all
nodes in the ad hoc network, regardsless 
  of their need for internet connectivity. This is where hop_limit (TTL) 
  considerations becomes important since every advertisement is 
  rebroadcasted
as long as allowed by the hop_limit. So, what value for this 
  hop_limit should be used? If we choose
a too small value we might not reach 
  all nodes, and choosing a high value will introduce lots of 
  traffic. 


[Fredrik Alriksson]  Can't a node that does 
not get the periodic advertisments send 
solicitations?



  
Nodes that have no need for internet connectivity will also 
  receive and process this traffic, uneccessary.


[Fredrik Alriksson]  Even though the advertisements are not 
_necessary_ for the non-internet connected nodes, they may still benefit 
from the periodic advertisments indirectly, since the total number of packets 
that they have to forward (including both the advertisements _and_ the user 
data) may decrease!



  
In the draft we instead propose that the node itself should 
  initiate this process, the gateway discovery process. In the case where there 
  are multiple gateways, the node should upon receiving these advertisements 
  choose the closest gateway.


[Fredrik Alriksson] Aren't we talking about 
_mobile_ ad hoc networks? For how long will the chosen gateway remain the 
closest gateway? 



  
regards,

Anders


[Fredrik Alriksson] BR, Fredrik



  
 

Fredrik 
  Alriksson (EAB) wrote:
Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisem!
ents were forwarded on non-manet 

  interfaces. Can you please elaborate a bit?

BR,
Fredrik


  

    

      
-----Original Message-----
From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
Sent: den 8 juli 2002 18:40
To: Fredrik.Alriksson@era.ericsson.se
Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
manet@ietf.org
Subject: Re: Gateway Advertisements



Hello !
Fred

      rik.

In the draft, unnecessary packets basically indicates 
      un-necessary
gateway advertisements. For example, if a gateway 
      generates a route
advertisement every 1 sec, most of router 
      advertisements are redundant
for manet nodes which have already had a 
      global address. They may
update lifetime of their global address, but 
      the interval(1sec) is
still too short for this operations.

Since 
      flooding packets is easy to cause performance damage in manet,
our 
      approach tries to reduce a number of packets which are 
flooded 
      over
manet. I think manet nodes should not wait flooded advertisements 
      from
gateway, instead manet node should discover gateways on 
      their
initiative.

It is also difficult for gateways to decide 
      TTL for flooded
advertisements. Expanding ring search technique can not 
      be applied to
this situation, because advertisements should reach at 
      the edge of
manet. It can imagine that unnecessary network-wide 
      dissemination of
advertisements will occur when a gateway sets larger 
      TTL than manet
scale.

regards,
ryuji


At Mon, 8 Jul 
      2002 17:27:19 +0200 ,
Fredrik Alriksson (EAB) wrote:

      
Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that 

      
sending gateway advertisements peridically would generate 
unnecessary packets in the Manet. Can you please explain how 
you came to that conclusion? Our simulation study on MIPMANET 
from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
indicates that it actually can decrease the number of packet 
transmissions in the MANET.

      
BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email: fredrik.alriksson@ericsson.com



    


  

 


------_=_NextPart_001_01C22EFC.9FB71F90--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:38:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10100
	for ; Fri, 19 Jul 2002 10:38:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA23102
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:39:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08288;
	Fri, 19 Jul 2002 09:59:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21433
	for ; Fri, 19 Jul 2002 04:23:01 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03133
	for ; Fri, 19 Jul 2002 04:22:01 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8N0rU024715
	for ; Fri, 19 Jul 2002 10:23:00 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACWMC>; Fri, 19 Jul 2002 10:22:53 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FD@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'MANET mailing list'" 
Date: Fri, 19 Jul 2002 10:16:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22EFC.9FB71F90"
Subject: [manet] RE: Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C22EFC.9FB71F90
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Anders,
 
See comments inline.

-----Original Message-----
From: Anders Nilsson [mailto:andersn@telecom.lth.se]
Sent: den 9 juli 2002 11:29
To: Fredrik Alriksson (EAB); MANET mailing list
Cc: Ryuji Wakikawa
Subject: Re: Gateway Advertisements


Hello Fredrik!

For the solution described in the draft, unsolicited gateway advertisments are not neccessary
for the correct operation of the protocol.

[Fredrik Alriksson]  I never questioned that. You state that "Sending them (advertisements) periodically would generate unnecessary packets in the Manet", but as I've said in previous emails _not_ sending them periodically may generate _more_ traffic in the Manet.


I see your point and I think that it is question of whether a reactive or a more proactive approach
should be used. 

[Fredrik Alriksson] Perhaps a combination is preferable?


One of the reasons for not recomending gateway advertisement flooding is when you consider the scenario where some nodes might need internet access, and some might not.

[Fredrik Alriksson] Well, the nodes which do not need internet access may still benefit from the periodic floodings, since they probably are involved in the communication between the gateways and the manet nodes what do need internet access. Decreasing the total number of packet transmissions does not only benefit the nodes that need internet access!

When flooding of advertisements is being used,  packets are being flooded periodicly over all
nodes in the ad hoc network, regardsless of their need for internet connectivity. This is where hop_limit (TTL) considerations becomes important since every advertisement is rebroadcasted
as long as allowed by the hop_limit. So, what value for this hop_limit should be used? If we choose
a too small value we might not reach all nodes, and choosing a high value will introduce lots of traffic. 

[Fredrik Alriksson]  Can't a node that does not get the periodic advertisments send solicitations?


Nodes that have no need for internet connectivity will also receive and process this traffic, uneccessary.

[Fredrik Alriksson]  Even though the advertisements are not _necessary_ for the non-internet connected nodes, they may still benefit from the periodic advertisments indirectly, since the total number of packets that they have to forward (including both the advertisements _and_ the user data) may decrease!


In the draft we instead propose that the node itself should initiate this process, the gateway discovery process. In the case where there are multiple gateways, the node should upon receiving these advertisements choose the closest gateway.

[Fredrik Alriksson] Aren't we talking about _mobile_ ad hoc networks? For how long will the chosen gateway remain the closest gateway? 

regards,

Anders


[Fredrik Alriksson] BR, Fredrik

 

Fredrik Alriksson (EAB) wrote:

Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisements were forwarded on non-manet 
interfaces. Can you please elaborate a bit?

BR,
Fredrik



-----Original Message-----
From: Ryuji Wakikawa [ mailto:ryuji@sfc.wide.ad.jp  ]
Sent: den 8 juli 2002 18:40
To:  Fredrik.Alriksson@era.ericsson.se  
Cc:  charliep@iprg.nokia.com  ;  ryuji@sfc.wide.ad.jp  ;
jmalinen@ipgr.nokia.com  ;  ajtuomin@tml.hut.fi  ;  andersn@telecom.lth.se  ;
manet@ietf.org  
Subject: Re: Gateway Advertisements



Hello Fred
rik.

In the draft, unnecessary packets basically indicates un-necessary
gateway advertisements. For example, if a gateway generates a route
advertisement every 1 sec, most of router advertisements are redundant
for manet nodes which have already had a global address. They may
update lifetime of their global address, but the interval(1sec) is
still too short for this operations.

Since flooding packets is easy to cause performance damage in manet,
our approach tries to reduce a number of packets which are 
flooded over
manet. I think manet nodes should not wait flooded advertisements from
gateway, instead manet node should discover gateways on their
initiative.

It is also difficult for gateways to decide TTL for flooded
advertisements. Expanding ring search technique can not be applied to
this situation, because advertisements should reach at the edge of
manet. It can imagine that unnecessary network-wide dissemination of
advertisements will occur when a gateway sets larger TTL than manet
scale.

regards,
ryuji


At Mon, 8 Jul 2002 17:27:19 +0200 ,
Fredrik Alriksson (EAB) wrote:


Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that 

sending gateway advertisements peridically would generate 
unnecessary packets in the Manet. Can you please explain how 
you came to that conclusion? Our simulation study on MIPMANET 
from '99 ( http://www.e.kth.se/~e94_fal/mipmanet.pdf  ) 
indicates that it actually can decrease the number of packet 
transmissions in the MANET.

BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email:  fredrik.alriksson@ericsson.com  






 


------_=_NextPart_001_01C22EFC.9FB71F90
Content-Type: text/html;
	charset="iso-8859-1"









Hi 
Anders,


 


See 
comments inline.



  
-----Original Message-----
From: Anders Nilsson 
  [mailto:andersn@telecom.lth.se]
Sent: den 9 juli 2002 
  11:29
To: Fredrik Alriksson (EAB); MANET mailing list
Cc: 
  Ryuji Wakikawa
Subject: Re: Gateway 
  Advertisements


  
Hello Fredrik!

For the solution described in the draft, 
  unsolicited gateway advertisments are not neccessary
for the correct 
  operation of the protocol.


[Fredrik Alriksson]  I never questioned that. You state 
that "Sending them (advertisements) periodically would generate unnecessary 
packets in the Manet", but as I've said in previous emails _not_ sending them 
periodically may generate _more_ traffic in the Manet.



  
I see your point and I think that it is question of whether a 
  reactive or a more proactive approach
should be used. 


[Fredrik Alriksson] Perhaps a combination is 
preferable?



  
One of the reasons for not recomending gateway advertisement 
  flooding is when you consider the scenario where some nodes might need 
  internet access, and some might not.


[Fredrik Alriksson] Well, the nodes which do not need internet 
access may still benefit from the periodic floodings, since they probably are 
involved in the communication between the gateways and the manet nodes what do 
need internet access. Decreasing the total number of packet transmissions does 
not only benefit the nodes that need internet access!



  
When flooding of advertisements is being used,  packets are 
  being flooded periodicly over all
nodes in the ad hoc network, regardsless 
  of their need for internet connectivity. This is where hop_limit (TTL) 
  considerations becomes important since every advertisement is 
  rebroadcasted
as long as allowed by the hop_limit. So, what value for this 
  hop_limit should be used? If we choose
a too small value we might not reach 
  all nodes, and choosing a high value will introduce lots of 
  traffic. 


[Fredrik Alriksson]  Can't a node that does 
not get the periodic advertisments send 
solicitations?



  
Nodes that have no need for internet connectivity will also 
  receive and process this traffic, uneccessary.


[Fredrik Alriksson]  Even though the advertisements are not 
_necessary_ for the non-internet connected nodes, they may still benefit 
from the periodic advertisments indirectly, since the total number of packets 
that they have to forward (including both the advertisements _and_ the user 
data) may decrease!



  
In the draft we instead propose that the node itself should 
  initiate this process, the gateway discovery process. In the case where there 
  are multiple gateways, the node should upon receiving these advertisements 
  choose the closest gateway.


[Fredrik Alriksson] Aren't we talking about 
_mobile_ ad hoc networks? For how long will the chosen gateway remain the 
closest gateway? 



  
regards,

Anders


[Fredrik Alriksson] BR, Fredrik



  
 

Fredrik 
  Alriksson (EAB) wrote:
Hi Ryuji,

In what sense are the gateway advertisements unnecessary?

In case there are multiple gateways, the flooding of gateway advertisements may actually _decrease_ the total number of packet transmissions (control and user data transmissions) in the MANET! 

Flooding gateway advertisements can enable manet nodes which already have a global address to select a _closer_ gateway. This means that the average distance between gateway and manet node can be decreased. This in turn decreases the number of packet transmissions required to deliver user data between the gateways and the manet nodes. Depending on the user activity, this reduction can be larger than the increase in control packet transmissions. 

Other benefits are that the average user data delay decreases, and that the manet nodes loose contact with their gateway less frequently.

Regarding TTL, I don't see the problem, unless advertisem!
ents were forwarded on non-manet 

  interfaces. Can you please elaborate a bit?

BR,
Fredrik


  

    

      
-----Original Message-----
From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
Sent: den 8 juli 2002 18:40
To: Fredrik.Alriksson@era.ericsson.se
Cc: charliep@iprg.nokia.com; ryuji@sfc.wide.ad.jp;
jmalinen@ipgr.nokia.com; ajtuomin@tml.hut.fi; andersn@telecom.lth.se;
manet@ietf.org
Subject: Re: Gateway Advertisements



Hello !
Fred

      rik.

In the draft, unnecessary packets basically indicates 
      un-necessary
gateway advertisements. For example, if a gateway 
      generates a route
advertisement every 1 sec, most of router 
      advertisements are redundant
for manet nodes which have already had a 
      global address. They may
update lifetime of their global address, but 
      the interval(1sec) is
still too short for this operations.

Since 
      flooding packets is easy to cause performance damage in manet,
our 
      approach tries to reduce a number of packets which are 
flooded 
      over
manet. I think manet nodes should not wait flooded advertisements 
      from
gateway, instead manet node should discover gateways on 
      their
initiative.

It is also difficult for gateways to decide 
      TTL for flooded
advertisements. Expanding ring search technique can not 
      be applied to
this situation, because advertisements should reach at 
      the edge of
manet. It can imagine that unnecessary network-wide 
      dissemination of
advertisements will occur when a gateway sets larger 
      TTL than manet
scale.

regards,
ryuji


At Mon, 8 Jul 
      2002 17:27:19 +0200 ,
Fredrik Alriksson (EAB) wrote:

      
Hi All,

In draft-wakikawa-manet-globalv6-00.txt you claim that 

      
sending gateway advertisements peridically would generate 
unnecessary packets in the Manet. Can you please explain how 
you came to that conclusion? Our simulation study on MIPMANET 
from '99 (http://www.e.kth.se/~e94_fal/mipmanet.pdf) 
indicates that it actually can decrease the number of packet 
transmissions in the MANET.

      
BR,
Fredrik

---
Fredrik Alriksson, Ericsson Research
Email: fredrik.alriksson@ericsson.com



    


  

 


------_=_NextPart_001_01C22EFC.9FB71F90--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 10:56:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10596
	for ; Fri, 19 Jul 2002 10:56:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19666;
	Fri, 19 Jul 2002 10:37:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19546
	for ; Fri, 19 Jul 2002 10:37:01 -0400 (EDT)
Received: from mailer.cacs.louisiana.edu (mailer.cacs.louisiana.edu [130.70.72.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10002
	for ; Fri, 19 Jul 2002 10:36:02 -0400 (EDT)
Received: from wusun.cacs.louisiana.edu (wusun.cacs.louisiana.edu [130.70.76.9])
	by mailer.cacs.louisiana.edu (8.11.3/8.11.3) with ESMTP id g6JEape16427
	for ; Fri, 19 Jul 2002 09:36:51 -0500 (CDT)
Received: from localhost (wu@localhost)
	by wusun.cacs.louisiana.edu (8.10.2+Sun/8.10.2) with ESMTP id g6JEauj25194
	for ; Fri, 19 Jul 2002 09:36:56 -0500 (CDT)
Date: Fri, 19 Jul 2002 09:36:55 -0500 (CDT)
From: Hongyi Wu 
To: manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] CFP: MONET Special Issue
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


--------------------------------------------------------------
Please accept our apologies if you receive this multiple times
--------------------------------------------------------------

Kluwer Academic Publishers in cooperation with  ACM announce a
Special Issue of the Journal on Special Topics in Mobile
Networking and Applications (MONET)

on

INTEGRATION Of HETEROGENOUS WIRELESS TECHNOLOGIES


The full CFP can be found at: http://www.kluweronline.com/issn/1383-469X


Guest Editors:
--------------

Dr. Hongyi Wu
The Center for Advanced Computer Studies
University of Louisiana at Lafayette

Dr. Chunming Qiao
Dept. of Computer Science and Engineering
State University of New York at Buffalo

Dr. Sudhir Dixit
Nokia Research Center

Dr. Erdal Cayirci
Computer Engineering Department
Yeditepe University

Important Dates:
----------------

MANUSCRIPT DUE: Feb 1, 2003
ACCEPTANCE NOTIFICATION: May 1, 2003
FINAL MANUSCRIPT DUE: July 1, 2003

Topics:
-------

Topics of interest include, but are not limited to the following, with
particular emphasis on the integration of heterogeneous wireless
technologies:

* System architecture
* Interoperation between wired, terrestrial wireless and satellite
networks
* Hybrid cellular systems, wireless LANs, ad hoc/sensor networks,
Bluetooth
* Location, Mobility and Handoff Management
* System modeling and performance evaluation
* Protocol design, analysis and optimization
  - Routing (including multicasting and broadcasting)
  - Energy efficient, self-organizing and resilient protocols
  - Medium access control protocols
  - TCP/IP over integrated wireless networks
* Congestion, admission and flow control
* Quality of service in the hybrid networks
* Security and Privacy
* Applications
* Implementation and testbed experiments

========================================================================
Dr. Hongyi Wu,  Assistant Professor
The Center for Advanced Computer Studies (CACS)
University of Louisiana (UL) at Lafayette
P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A.
Tel: 337-482-5779, Fax: 337-482-5791
E-mail: wu@cacs.louisiana.edu
========================================================================


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 10:56:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10608
	for ; Fri, 19 Jul 2002 10:56:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA04542
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 10:57:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19666;
	Fri, 19 Jul 2002 10:37:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19546
	for ; Fri, 19 Jul 2002 10:37:01 -0400 (EDT)
Received: from mailer.cacs.louisiana.edu (mailer.cacs.louisiana.edu [130.70.72.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10002
	for ; Fri, 19 Jul 2002 10:36:02 -0400 (EDT)
Received: from wusun.cacs.louisiana.edu (wusun.cacs.louisiana.edu [130.70.76.9])
	by mailer.cacs.louisiana.edu (8.11.3/8.11.3) with ESMTP id g6JEape16427
	for ; Fri, 19 Jul 2002 09:36:51 -0500 (CDT)
Received: from localhost (wu@localhost)
	by wusun.cacs.louisiana.edu (8.10.2+Sun/8.10.2) with ESMTP id g6JEauj25194
	for ; Fri, 19 Jul 2002 09:36:56 -0500 (CDT)
Date: Fri, 19 Jul 2002 09:36:55 -0500 (CDT)
From: Hongyi Wu 
To: manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] CFP: MONET Special Issue
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


--------------------------------------------------------------
Please accept our apologies if you receive this multiple times
--------------------------------------------------------------

Kluwer Academic Publishers in cooperation with  ACM announce a
Special Issue of the Journal on Special Topics in Mobile
Networking and Applications (MONET)

on

INTEGRATION Of HETEROGENOUS WIRELESS TECHNOLOGIES


The full CFP can be found at: http://www.kluweronline.com/issn/1383-469X


Guest Editors:
--------------

Dr. Hongyi Wu
The Center for Advanced Computer Studies
University of Louisiana at Lafayette

Dr. Chunming Qiao
Dept. of Computer Science and Engineering
State University of New York at Buffalo

Dr. Sudhir Dixit
Nokia Research Center

Dr. Erdal Cayirci
Computer Engineering Department
Yeditepe University

Important Dates:
----------------

MANUSCRIPT DUE: Feb 1, 2003
ACCEPTANCE NOTIFICATION: May 1, 2003
FINAL MANUSCRIPT DUE: July 1, 2003

Topics:
-------

Topics of interest include, but are not limited to the following, with
particular emphasis on the integration of heterogeneous wireless
technologies:

* System architecture
* Interoperation between wired, terrestrial wireless and satellite
networks
* Hybrid cellular systems, wireless LANs, ad hoc/sensor networks,
Bluetooth
* Location, Mobility and Handoff Management
* System modeling and performance evaluation
* Protocol design, analysis and optimization
  - Routing (including multicasting and broadcasting)
  - Energy efficient, self-organizing and resilient protocols
  - Medium access control protocols
  - TCP/IP over integrated wireless networks
* Congestion, admission and flow control
* Quality of service in the hybrid networks
* Security and Privacy
* Applications
* Implementation and testbed experiments

========================================================================
Dr. Hongyi Wu,  Assistant Professor
The Center for Advanced Computer Studies (CACS)
University of Louisiana (UL) at Lafayette
P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A.
Tel: 337-482-5779, Fax: 337-482-5791
E-mail: wu@cacs.louisiana.edu
========================================================================


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 11:26:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11756
	for ; Fri, 19 Jul 2002 11:26:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05982;
	Fri, 19 Jul 2002 11:08:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21597
	for ; Fri, 19 Jul 2002 04:26:33 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03161
	for ; Fri, 19 Jul 2002 04:25:33 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8QVrU025564
	for ; Fri, 19 Jul 2002 10:26:31 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACX2F>; Fri, 19 Jul 2002 10:26:31 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418101@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Charlie,

> > For how long is the metrics about the GWs in the GW list 
> valid (e.g. hop count)?
> 
> This answer is the same as for the metric field in any other
> AODV destination route.  Due to route repairs, the metric
> may not represent the actual hop count to a destination,
> and yet the destination remains reachable.

Well, the question should be viewed in conjunction with Ryuji's(?) statement:
"Manet node may change the GW to closer one any time by re-selecting an appropriate GW from the node's GW lists or by re-flooding requests"

I suspect that selecting a _closer_ GW by just looking into the GW list, without updating the GW list, will only be a good strategy for a limited period of time. 

> 
> > How does the Manet node know when to re-flood the request?
> 
> When the manet node needs a route to a node in the Internet,
> and it does not have a default route, it will re-flood
> the request.  Is this your concern?

My concern is that a Manet node that is communicating via a GW will stick to this GW even if better GW's become available in the Manet. Someone commented that the Manet node can re-flood requests whenever they want to find better GWs; in response to that I wonder how the Manet node can know that there is a better GW available and that it thus should re-flood a request. The answer is of course that in many cases it cannot know. 

> > How large fraction of all relevant topology changes will 
> the Manet node detect?
> 
> The best case would be for it to detect _none_ of the topology
> changes, and yet retain routability to all of its communication
> partners.

Even if the total traffic load, mean delay, etc. are higher?

> 
> > My conclusion is still: it is better to let the GW flood 
> periodically.
> 
> I think the argument for periodic advertisement is the same
> as for any other manet-wide advertisement.  The decision about
> whether to go for periodic vs. reactive depends on traffic
> patterns in either case.

Sorry, the above statement was a slip from my side. However, I cannot conclude that periodic advertisements SHOULD NOT be used...

Regarding traffic patterns: I suspect that the traffic patterns will be quite different in an Internet connected Manet than in a standalone Manet (which is the most common scenario in previous simulation studies).

BR,
Fredrik

> 
> Regards,
> Charlie P.
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 11:26:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11769
	for ; Fri, 19 Jul 2002 11:26:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA08713
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 11:27:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05982;
	Fri, 19 Jul 2002 11:08:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21597
	for ; Fri, 19 Jul 2002 04:26:33 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03161
	for ; Fri, 19 Jul 2002 04:25:33 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8QVrU025564
	for ; Fri, 19 Jul 2002 10:26:31 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACX2F>; Fri, 19 Jul 2002 10:26:31 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418101@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Charlie,

> > For how long is the metrics about the GWs in the GW list 
> valid (e.g. hop count)?
> 
> This answer is the same as for the metric field in any other
> AODV destination route.  Due to route repairs, the metric
> may not represent the actual hop count to a destination,
> and yet the destination remains reachable.

Well, the question should be viewed in conjunction with Ryuji's(?) statement:
"Manet node may change the GW to closer one any time by re-selecting an appropriate GW from the node's GW lists or by re-flooding requests"

I suspect that selecting a _closer_ GW by just looking into the GW list, without updating the GW list, will only be a good strategy for a limited period of time. 

> 
> > How does the Manet node know when to re-flood the request?
> 
> When the manet node needs a route to a node in the Internet,
> and it does not have a default route, it will re-flood
> the request.  Is this your concern?

My concern is that a Manet node that is communicating via a GW will stick to this GW even if better GW's become available in the Manet. Someone commented that the Manet node can re-flood requests whenever they want to find better GWs; in response to that I wonder how the Manet node can know that there is a better GW available and that it thus should re-flood a request. The answer is of course that in many cases it cannot know. 

> > How large fraction of all relevant topology changes will 
> the Manet node detect?
> 
> The best case would be for it to detect _none_ of the topology
> changes, and yet retain routability to all of its communication
> partners.

Even if the total traffic load, mean delay, etc. are higher?

> 
> > My conclusion is still: it is better to let the GW flood 
> periodically.
> 
> I think the argument for periodic advertisement is the same
> as for any other manet-wide advertisement.  The decision about
> whether to go for periodic vs. reactive depends on traffic
> patterns in either case.

Sorry, the above statement was a slip from my side. However, I cannot conclude that periodic advertisements SHOULD NOT be used...

Regarding traffic patterns: I suspect that the traffic patterns will be quite different in an Internet connected Manet than in a standalone Manet (which is the most common scenario in previous simulation studies).

BR,
Fredrik

> 
> Regards,
> Charlie P.
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 11:26:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11789
	for ; Fri, 19 Jul 2002 11:26:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05905;
	Fri, 19 Jul 2002 11:08:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21572
	for ; Fri, 19 Jul 2002 04:26:22 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03158
	for ; Fri, 19 Jul 2002 04:25:23 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8QLrU025526
	for ; Fri, 19 Jul 2002 10:26:21 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACXG4>; Fri, 19 Jul 2002 10:26:18 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418100@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'MANET mailing list'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22EFD.1CC39AE0"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C22EFD.1CC39AE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi again Anders,

-----Original Message-----
From: Anders Nilsson [mailto:andersn@telecom.lth.se]
Sent: den 11 juli 2002 16:30
To: Fredrik Alriksson (EAB)
Cc: MANET mailing list; Ryuji Wakikawa
Subject: Re: [manet] Re: Gateway Advertisements


Hello Fredrik!




But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!

You are absolutely right. This is always what you should try to optimize when you have an proactive approach , like yours. Our approach is more reactive. So for the real question; is a proactive, a reactive or a hybrid
solution the best one? I think the answer depends on several factors, such as network size, mobility
rate, traffic load, but also on battery life, routing protocol, security etc. I think I can agree on that your proposal is better in some situations and scenarios, but that our solution is better in some. I think that these are questions that needs to be more thoroughly simulated. 


[Fredrik Alriksson]  Then I think we agree; I originally started this thread since you in the draft claim that a proactive approach SHOULD NOT be used, but now you say that it depends and that we don't really know. Will that be reflected in the draft as well?

 


For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
How does the Manet node know when to re-flood the request?
How large fraction of all relevant topology changes will the Manet node detect?

My conclusion is still: it is better to let the GW flood periodically.

Are you absolutely sure that this will be the optimal solution in all situations?


[Fredrik Alriksson] No, not in all situations. Isn't that a general 'feature' with MANETs, no single solution will ever be optimal for all MANETs ;-)

 





In appendix A, we explain how to use the most appropriate GW with a
routing header. I think the draft can be adapted to your above
situation. What do you think?

--Snip from the drat
   Using a routing header is also preferable if there are 
more than two
Internet-gateways, because the node then have the ability to decide
which Internet-gateway is the best, by distance in hops, or by some
other priority.  By assign a priority number for each 
Internet-gateway,
the route reply message and the Manet Router Advertisement messages
could be extended to support a candidate Internet-gateway 
option in it.
-----


I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?

He describes how the gateway selection process can be implemented. 


[Fredrik Alriksson] ...which is somewhat independent from how the advertisements are distributed...right?

 


Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.

Furthermore, if using flooding, how often should Manet nodes flood the solicitations?

... needs more testing... 


[Fredrik Alriksson] The reason for asking is this: assume a MANET with 2 GWs and 10 manet nodes using these 2 GWs for Internet access. What is the overhead with proactive vs. reactive? Assuming that the periodicity is the same: reactive: 10 floodings, proactive: 2 floodings. 

 



Regarding TTL, I don't see the problem, unless advertisements were
forwarded on non-manet interfaces. Can you please elaborate a bit?

In your thesis, you mentioned "Limited TTL". This is almost what I
want to explain here. If there is a single GW in manet, RA should be
flooded over whole manet. You can not use optimization like expanding
ring search for flooding. If Manet nodes can not get RAs sent with
limited TTL by GW, it has to discover GW by solicited requests.


Sure, but is that really a problem?

No, and I think that it could be a good hybrid solution.


[Fredrik Alriksson] Agreed.

 
[and in your previous mail:] Can you elaborate what is the most reason for generating more traffic

> when GW does not flood advertisements.



>The average hop count between the GW and the Manet node increases, 
>since the probability that a Manet node will use a sub-optimal 
> GW increases.




>Then I think I didn't express myself clearly enough. My point is 
>that using a 4-hop route between Manet node and GW1 consumes more 
>resources in the Manet as a whole than using a 2-hop route between the 
>same Manet node and GW2. Thus being able to select the closest gateway 
>is a concern for all nodes in the Manet, including those that do not 
>use internet connectivity.
But minimizing the hop count is, of course, also the purpose of our solution. The question is whether it really
does differ in average hop, or whether it really is more costful. Flooding could be very costful for battery sensitive devices. As for choosing the closest gateway, this should always be the ambition. The node could either rerequest gateway information, or maybe we could piggyback this information somewhere, in case a "handover"is needed.


[Fredrik Alriksson] The question with a reactive approach is how to detect that a reaction is needed. Could you please describe that again?
 
BR,
Fredrik

 

best regards,

Anders 







------_=_NextPart_001_01C22EFD.1CC39AE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi=20
again Anders,


  
-----Original Message-----
From: Anders Nilsson=20
  [mailto:andersn@telecom.lth.se]
Sent: den 11 juli 2002=20
  16:30
To: Fredrik Alriksson (EAB)
Cc: MANET =
mailing list;=20
  Ryuji Wakikawa
Subject: Re: [manet] Re: Gateway=20
  Advertisements

Hello Fredrik!


  

But you can't know which of the =
advertisements that are "unnecessary" beforehand. I would say that =
sending the periodic advertisements too frequently creates unnecessary =
overhead, and that the problem is to define an "optimal" period. This =
is not at all the same as to say that periodic advertisements SHOULD =
NOT be used at all!

  
You are absolutely right. This is always what you should try to =
optimize=20
  when you have an proactive approach , like yours. Our approach is =
more=20
  reactive. So for the real question; is a proactive, a reactive or a=20
  hybrid
solution the best one? I think the answer depends on =
several=20
  factors, such as network size, mobility
rate, traffic load, but =
also on=20
  battery life, routing protocol, security etc. I think I can agree on =
that your=20
  proposal is better in some situations and scenarios, but that our =
solution is=20
  better in some. I think that these are questions that needs to be =
more=20
  thoroughly simulated. 


[Fredrik Alriksson]  Then I think =
we agree; I=20
originally started this thread since you in the draft claim that a =
proactive=20
approach SHOULD NOT be used, but now you say that it depends and that =
we don't=20
really know. Will that be reflected in the draft as=20
well?


  
 

  

For how long is the metrics about =
the GWs in the GW list valid (e.g. hop count)? 
How does the Manet =
node know when to re-flood the request?
How large fraction of all =
relevant topology changes will the Manet node detect?

My =
conclusion is still: it is better to let the GW flood =
periodically.

  
Are you absolutely sure that this will be the optimal solution =
in all=20
  situations?


[Fredrik Alriksson] No, not in all situations. Isn't that =
a general=20
'feature' with MANETs, no single solution will ever be optimal for all =
MANETs=20
;-)


  
 

  



    
In appendix A, we explain =
how to use the most appropriate GW with a
routing header. I think =
the draft can be adapted to your above
situation. What do you =
think?

--Snip from the drat
   Using a routing header is also =
preferable if there are 
more than two
Internet-gateways, because =
the node then have the ability to decide
which Internet-gateway is =
the best, by distance in hops, or by some
other priority.  By assign =
a priority number for each 
Internet-gateway,
the route reply =
message and the Manet Router Advertisement messages
could be =
extended to support a candidate Internet-gateway 
option in =
it.
-----

I'm sorry, =
I don't really follow you here. In what sense is the text you refer to =
about sending advertisements periodically or not?

  
He describes how the gateway selection process can be =
implemented.=20
  


[Fredrik Alriksson] ...which is somewhat independent from =
how the=20
advertisements are distributed...right?


  
 

  

Well, it does if the Manet node =
unicasts the solicitation, which use list as one alternative if I =
understand the draft correct.

Furthermore, if using flooding, =
how often should Manet nodes flood the =
solicitations?

  
... needs more testing... 


[Fredrik Alriksson] The reason for asking is this: assume =
a MANET=20
with 2 GWs and 10 manet nodes using these 2 GWs for Internet access. =
What is the=20
overhead with proactive vs. reactive? Assuming that the periodicity is =
the same:=20
reactive: 10 floodings, proactive: 2 floodings. 


  
 

  

  
    

      
Regarding TTL, I don't =
see the problem, unless advertisements were
forwarded on non-manet =
interfaces. Can you please elaborate a bit?
In your thesis, you mentioned "Limited TTL". This is almost =
what I
want to explain here. If there is a single GW in manet, RA =
should be
flooded over whole manet. You can not use optimization =
like expanding
ring search for flooding. If Manet nodes can not get =
RAs sent with
limited TTL by GW, it has to discover GW by solicited =
requests.

Sure, but is =
that really a problem?
No, and I think that it =
could be a good hybrid solution.
[Fredrik Alriksson] Agreed.


 
[and in your =
previous mail:] Can you elaborate what is the most reason for =
generating more traffic
> when GW does not flood =
advertisements.

>The average hop count between the GW and the Manet node increases, =

>since the probability that a Manet node will use a sub-optimal =

> GW increases.


>Then I think I didn't express myself clearly enough. My point is =

>that using a 4-hop route between Manet node and GW1 consumes =
more 
>resources in the Manet as a whole than using a 2-hop route =
between the 
>same Manet node and GW2. Thus being able to select =
the closest gateway 
>is a concern for all nodes in the Manet, =
including those that do not 
>use internet connectivity.

  
But minimizing the hop count is, of course, also the =
purpose of=20
  our solution. The question is whether it really
does differ in =
average hop,=20
  or whether it really is more costful. Flooding could be very costful =
for=20
  battery sensitive devices. As for choosing the closest gateway, this =
should=20
  always be the ambition. The node could either rerequest gateway =
information,=20
  or maybe we could piggyback this information somewhere, in case a =
"handover"is=20
  needed.


[Fredrik Alriksson] The question with a reactive approach =
is how to=20
detect that a reaction is needed. Could you please describe that=20
again?


 


BR,


Fredrik


  
 

best=20
  regards,

Anders =







------_=_NextPart_001_01C22EFD.1CC39AE0--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 11:26:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11799
	for ; Fri, 19 Jul 2002 11:26:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA08731
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 11:27:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05905;
	Fri, 19 Jul 2002 11:08:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21572
	for ; Fri, 19 Jul 2002 04:26:22 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03158
	for ; Fri, 19 Jul 2002 04:25:23 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8QLrU025526
	for ; Fri, 19 Jul 2002 10:26:21 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACXG4>; Fri, 19 Jul 2002 10:26:18 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418100@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'MANET mailing list'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22EFD.1CC39AE0"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C22EFD.1CC39AE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi again Anders,

-----Original Message-----
From: Anders Nilsson [mailto:andersn@telecom.lth.se]
Sent: den 11 juli 2002 16:30
To: Fredrik Alriksson (EAB)
Cc: MANET mailing list; Ryuji Wakikawa
Subject: Re: [manet] Re: Gateway Advertisements


Hello Fredrik!




But you can't know which of the advertisements that are "unnecessary" beforehand. I would say that sending the periodic advertisements too frequently creates unnecessary overhead, and that the problem is to define an "optimal" period. This is not at all the same as to say that periodic advertisements SHOULD NOT be used at all!

You are absolutely right. This is always what you should try to optimize when you have an proactive approach , like yours. Our approach is more reactive. So for the real question; is a proactive, a reactive or a hybrid
solution the best one? I think the answer depends on several factors, such as network size, mobility
rate, traffic load, but also on battery life, routing protocol, security etc. I think I can agree on that your proposal is better in some situations and scenarios, but that our solution is better in some. I think that these are questions that needs to be more thoroughly simulated. 


[Fredrik Alriksson]  Then I think we agree; I originally started this thread since you in the draft claim that a proactive approach SHOULD NOT be used, but now you say that it depends and that we don't really know. Will that be reflected in the draft as well?

 


For how long is the metrics about the GWs in the GW list valid (e.g. hop count)? 
How does the Manet node know when to re-flood the request?
How large fraction of all relevant topology changes will the Manet node detect?

My conclusion is still: it is better to let the GW flood periodically.

Are you absolutely sure that this will be the optimal solution in all situations?


[Fredrik Alriksson] No, not in all situations. Isn't that a general 'feature' with MANETs, no single solution will ever be optimal for all MANETs ;-)

 





In appendix A, we explain how to use the most appropriate GW with a
routing header. I think the draft can be adapted to your above
situation. What do you think?

--Snip from the drat
   Using a routing header is also preferable if there are 
more than two
Internet-gateways, because the node then have the ability to decide
which Internet-gateway is the best, by distance in hops, or by some
other priority.  By assign a priority number for each 
Internet-gateway,
the route reply message and the Manet Router Advertisement messages
could be extended to support a candidate Internet-gateway 
option in it.
-----


I'm sorry, I don't really follow you here. In what sense is the text you refer to about sending advertisements periodically or not?

He describes how the gateway selection process can be implemented. 


[Fredrik Alriksson] ...which is somewhat independent from how the advertisements are distributed...right?

 


Well, it does if the Manet node unicasts the solicitation, which use list as one alternative if I understand the draft correct.

Furthermore, if using flooding, how often should Manet nodes flood the solicitations?

... needs more testing... 


[Fredrik Alriksson] The reason for asking is this: assume a MANET with 2 GWs and 10 manet nodes using these 2 GWs for Internet access. What is the overhead with proactive vs. reactive? Assuming that the periodicity is the same: reactive: 10 floodings, proactive: 2 floodings. 

 



Regarding TTL, I don't see the problem, unless advertisements were
forwarded on non-manet interfaces. Can you please elaborate a bit?

In your thesis, you mentioned "Limited TTL". This is almost what I
want to explain here. If there is a single GW in manet, RA should be
flooded over whole manet. You can not use optimization like expanding
ring search for flooding. If Manet nodes can not get RAs sent with
limited TTL by GW, it has to discover GW by solicited requests.


Sure, but is that really a problem?

No, and I think that it could be a good hybrid solution.


[Fredrik Alriksson] Agreed.

 
[and in your previous mail:] Can you elaborate what is the most reason for generating more traffic

> when GW does not flood advertisements.



>The average hop count between the GW and the Manet node increases, 
>since the probability that a Manet node will use a sub-optimal 
> GW increases.




>Then I think I didn't express myself clearly enough. My point is 
>that using a 4-hop route between Manet node and GW1 consumes more 
>resources in the Manet as a whole than using a 2-hop route between the 
>same Manet node and GW2. Thus being able to select the closest gateway 
>is a concern for all nodes in the Manet, including those that do not 
>use internet connectivity.
But minimizing the hop count is, of course, also the purpose of our solution. The question is whether it really
does differ in average hop, or whether it really is more costful. Flooding could be very costful for battery sensitive devices. As for choosing the closest gateway, this should always be the ambition. The node could either rerequest gateway information, or maybe we could piggyback this information somewhere, in case a "handover"is needed.


[Fredrik Alriksson] The question with a reactive approach is how to detect that a reaction is needed. Could you please describe that again?
 
BR,
Fredrik

 

best regards,

Anders 







------_=_NextPart_001_01C22EFD.1CC39AE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi=20
again Anders,


  
-----Original Message-----
From: Anders Nilsson=20
  [mailto:andersn@telecom.lth.se]
Sent: den 11 juli 2002=20
  16:30
To: Fredrik Alriksson (EAB)
Cc: MANET =
mailing list;=20
  Ryuji Wakikawa
Subject: Re: [manet] Re: Gateway=20
  Advertisements

Hello Fredrik!


  

But you can't know which of the =
advertisements that are "unnecessary" beforehand. I would say that =
sending the periodic advertisements too frequently creates unnecessary =
overhead, and that the problem is to define an "optimal" period. This =
is not at all the same as to say that periodic advertisements SHOULD =
NOT be used at all!

  
You are absolutely right. This is always what you should try to =
optimize=20
  when you have an proactive approach , like yours. Our approach is =
more=20
  reactive. So for the real question; is a proactive, a reactive or a=20
  hybrid
solution the best one? I think the answer depends on =
several=20
  factors, such as network size, mobility
rate, traffic load, but =
also on=20
  battery life, routing protocol, security etc. I think I can agree on =
that your=20
  proposal is better in some situations and scenarios, but that our =
solution is=20
  better in some. I think that these are questions that needs to be =
more=20
  thoroughly simulated. 


[Fredrik Alriksson]  Then I think =
we agree; I=20
originally started this thread since you in the draft claim that a =
proactive=20
approach SHOULD NOT be used, but now you say that it depends and that =
we don't=20
really know. Will that be reflected in the draft as=20
well?


  
 

  

For how long is the metrics about =
the GWs in the GW list valid (e.g. hop count)? 
How does the Manet =
node know when to re-flood the request?
How large fraction of all =
relevant topology changes will the Manet node detect?

My =
conclusion is still: it is better to let the GW flood =
periodically.

  
Are you absolutely sure that this will be the optimal solution =
in all=20
  situations?


[Fredrik Alriksson] No, not in all situations. Isn't that =
a general=20
'feature' with MANETs, no single solution will ever be optimal for all =
MANETs=20
;-)


  
 

  



    
In appendix A, we explain =
how to use the most appropriate GW with a
routing header. I think =
the draft can be adapted to your above
situation. What do you =
think?

--Snip from the drat
   Using a routing header is also =
preferable if there are 
more than two
Internet-gateways, because =
the node then have the ability to decide
which Internet-gateway is =
the best, by distance in hops, or by some
other priority.  By assign =
a priority number for each 
Internet-gateway,
the route reply =
message and the Manet Router Advertisement messages
could be =
extended to support a candidate Internet-gateway 
option in =
it.
-----

I'm sorry, =
I don't really follow you here. In what sense is the text you refer to =
about sending advertisements periodically or not?

  
He describes how the gateway selection process can be =
implemented.=20
  


[Fredrik Alriksson] ...which is somewhat independent from =
how the=20
advertisements are distributed...right?


  
 

  

Well, it does if the Manet node =
unicasts the solicitation, which use list as one alternative if I =
understand the draft correct.

Furthermore, if using flooding, =
how often should Manet nodes flood the =
solicitations?

  
... needs more testing... 


[Fredrik Alriksson] The reason for asking is this: assume =
a MANET=20
with 2 GWs and 10 manet nodes using these 2 GWs for Internet access. =
What is the=20
overhead with proactive vs. reactive? Assuming that the periodicity is =
the same:=20
reactive: 10 floodings, proactive: 2 floodings. 


  
 

  

  
    

      
Regarding TTL, I don't =
see the problem, unless advertisements were
forwarded on non-manet =
interfaces. Can you please elaborate a bit?
In your thesis, you mentioned "Limited TTL". This is almost =
what I
want to explain here. If there is a single GW in manet, RA =
should be
flooded over whole manet. You can not use optimization =
like expanding
ring search for flooding. If Manet nodes can not get =
RAs sent with
limited TTL by GW, it has to discover GW by solicited =
requests.

Sure, but is =
that really a problem?
No, and I think that it =
could be a good hybrid solution.
[Fredrik Alriksson] Agreed.


 
[and in your =
previous mail:] Can you elaborate what is the most reason for =
generating more traffic
> when GW does not flood =
advertisements.

>The average hop count between the GW and the Manet node increases, =

>since the probability that a Manet node will use a sub-optimal =

> GW increases.


>Then I think I didn't express myself clearly enough. My point is =

>that using a 4-hop route between Manet node and GW1 consumes =
more 
>resources in the Manet as a whole than using a 2-hop route =
between the 
>same Manet node and GW2. Thus being able to select =
the closest gateway 
>is a concern for all nodes in the Manet, =
including those that do not 
>use internet connectivity.

  
But minimizing the hop count is, of course, also the =
purpose of=20
  our solution. The question is whether it really
does differ in =
average hop,=20
  or whether it really is more costful. Flooding could be very costful =
for=20
  battery sensitive devices. As for choosing the closest gateway, this =
should=20
  always be the ambition. The node could either rerequest gateway =
information,=20
  or maybe we could piggyback this information somewhere, in case a =
"handover"is=20
  needed.


[Fredrik Alriksson] The question with a reactive approach =
is how to=20
detect that a reaction is needed. Could you please describe that=20
again?


 


BR,


Fredrik


  
 

best=20
  regards,

Anders =







------_=_NextPart_001_01C22EFD.1CC39AE0--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 11:29:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11935
	for ; Fri, 19 Jul 2002 11:29:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06219;
	Fri, 19 Jul 2002 11:09:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21660
	for ; Fri, 19 Jul 2002 04:27:09 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03203
	for ; Fri, 19 Jul 2002 04:26:10 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8R8Rb015313
	for ; Fri, 19 Jul 2002 10:27:08 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACXRD>; Fri, 19 Jul 2002 10:27:08 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418103@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hello,

> By the way, will you come IETF Yokohama in next week?

No, unfortunately not.

> > [Fredrik Alriksson] The reason for asking is this: assume a MANET
> > with 2 GWs and 10 manet nodes using these 2 GWs for Internet
> > access. What is the overhead with proactive vs. reactive? Assuming
> > that the periodicity is the same: reactive: 10 floodings, proactive:
> > 2 floodings.
> > 
> 
> I do not know if this example is good enough, because we can get
> another results depending on topology changes, measurements periods:-)
> 
> After first discovery, reactive stop flooding and start 
> unicasting instead.
> So the result will change after first discovery.
> For 10 sec: reactive: 0 floodings, proactive 10 floodings.
> Well this is best case for reactive, another result can be 
> expected, of
> course!

I agree; another example is of course the scenario we used in our thesis.

> > 
> > >Then I think I didn't express myself clearly enough. My point is 
> > >that using a 4-hop route between Manet node and GW1 consumes more 
> > >resources in the Manet as a whole than using a 2-hop route 
> between the 
> > >same Manet node and GW2. Thus being able to select the 
> closest gateway 
> > >is a concern for all nodes in the Manet, including those 
> that do not 
> > >use internet connectivity.
> > But minimizing the hop count is, of course, also the 
> purpose of our solution. The question is whether it really
> > does differ in average hop, or whether it really is more 
> costful. Flooding could be very costful for battery sensitive 
> devices. As for choosing the closest gateway, this should 
> always be the ambition. The node could either rerequest 
> gateway information, or maybe we could piggyback this 
> information somewhere, in case a "handover"is needed.
> > 
> > 
> > [Fredrik Alriksson] The question with a reactive approach is how to
> > detect that a reaction is needed. Could you please describe that
> > again?
> 
> Actually, the use of multiple GW is not considered enough yet, we just
> mention our rough idea in the draft.  So I don't know if I have good
> answer for this.

Ok, I see. Saving the best for last, are we ;-)

BR,
Fredrik

> regards,
> ryuji
> 
> > BR,
> > Fredrik
> > 
> >  
> > 
> > best regards,
> > 
> > Anders 
> > 
> > 
> > 
> > 
> > 
> > 
> > [2  ]
> > 
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Fri Jul 19 11:32:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12018
	for ; Fri, 19 Jul 2002 11:32:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06103;
	Fri, 19 Jul 2002 11:09:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21623
	for ; Fri, 19 Jul 2002 04:26:49 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03165
	for ; Fri, 19 Jul 2002 04:25:50 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8QmRb015219
	for ; Fri, 19 Jul 2002 10:26:48 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACXLP>; Fri, 19 Jul 2002 10:26:48 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418102@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Ryuji,

> > 
> > For how long is the metrics about the GWs in the GW list valid
> > (e.g. hop count)?  
> 
> Manet node does not keep a hop count which is known by 
> advertisements from GW.
> Hop count is alway updated during maintenance of the route 
> path to GW by a manet protocol.
> But if the route is expired, manet node have to discover the 
> route again.

But only the hop count to the GW that the Manet node currently is using is updated, right? If the metric of that route is changed, what is then the probability that the older metrics for the other GW in the GW list are correct? 
 
> > How does the Manet node know when to re-flood the request?  
> 
> We haven't specified yet. maybe when hop count change, movements
> detection, receiving RERR.

I suspect that there are many situations where better GWs become available without the Manet node being able to detect it.

> 
> > How large fraction of all relevant topology changes will 
> the Manet node detect?
> 
> It depends on a base manet protocol. For example, the manet 
> node may not
> know the changes since AODV has local repair functions.

Note that the relevant topology changes are not limited to those that concern the active route to the currently selected gateway, but include topology changes that affect the distance to all the GWs in the Manet. Even if there were no local repair functions, the node would still not detect all relevant topology changes.

> > > This does not happen to our solution.
> > 
> > Well, it does if the Manet node unicasts the solicitation, which use
> > list as one alternative if I understand the draft correct.
> 
> You are right.
> But this happens once. not periodically. 

Doesn't the node have to do this every GWINFO_REFRESH (= 8 sec)? 

BR,
Fredrik


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 11:32:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12026
	for ; Fri, 19 Jul 2002 11:32:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA09830
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 11:33:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06103;
	Fri, 19 Jul 2002 11:09:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21623
	for ; Fri, 19 Jul 2002 04:26:49 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03165
	for ; Fri, 19 Jul 2002 04:25:50 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8QmRb015219
	for ; Fri, 19 Jul 2002 10:26:48 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACXLP>; Fri, 19 Jul 2002 10:26:48 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418102@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Ryuji,

> > 
> > For how long is the metrics about the GWs in the GW list valid
> > (e.g. hop count)?  
> 
> Manet node does not keep a hop count which is known by 
> advertisements from GW.
> Hop count is alway updated during maintenance of the route 
> path to GW by a manet protocol.
> But if the route is expired, manet node have to discover the 
> route again.

But only the hop count to the GW that the Manet node currently is using is updated, right? If the metric of that route is changed, what is then the probability that the older metrics for the other GW in the GW list are correct? 
 
> > How does the Manet node know when to re-flood the request?  
> 
> We haven't specified yet. maybe when hop count change, movements
> detection, receiving RERR.

I suspect that there are many situations where better GWs become available without the Manet node being able to detect it.

> 
> > How large fraction of all relevant topology changes will 
> the Manet node detect?
> 
> It depends on a base manet protocol. For example, the manet 
> node may not
> know the changes since AODV has local repair functions.

Note that the relevant topology changes are not limited to those that concern the active route to the currently selected gateway, but include topology changes that affect the distance to all the GWs in the Manet. Even if there were no local repair functions, the node would still not detect all relevant topology changes.

> > > This does not happen to our solution.
> > 
> > Well, it does if the Manet node unicasts the solicitation, which use
> > list as one alternative if I understand the draft correct.
> 
> You are right.
> But this happens once. not periodically. 

Doesn't the node have to do this every GWINFO_REFRESH (= 8 sec)? 

BR,
Fredrik


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 11:33:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12085
	for ; Fri, 19 Jul 2002 11:33:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05778;
	Fri, 19 Jul 2002 11:07:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21485
	for ; Fri, 19 Jul 2002 04:23:36 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03143
	for ; Fri, 19 Jul 2002 04:22:37 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8NZRb014640
	for ; Fri, 19 Jul 2002 10:23:35 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACWR0>; Fri, 19 Jul 2002 10:23:35 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Date: Fri, 19 Jul 2002 10:17:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [manet] RE: Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi again,

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 11 juli 2002 03:11
> To: Fredrik.Alriksson@era.ericsson.se
> Cc: andersn@telecom.lth.se; manet@ietf.org; ryuji@sfc.wide.ad.jp
> Subject: Re: Gateway Advertisements
> 
> 
> 
> Hello again Fredrik and Thanks Anders.
> 
> At Tue, 9 Jul 2002 13:08:24 +0200 ,
> Fredrik Alriksson (EAB) wrote:
> > 
> > For the solution described in the draft, unsolicited gateway
> > advertisements are not neccessary for the correct operation of the
> > protocol.
> > 
> > [Fredrik Alriksson] I never questioned that. You state that "Sending
> > them (advertisements) periodically would generate unnecessary
> > packets in the Manet", but as I've said in previous emails _not_
> > sending them periodically may generate _more_ traffic in the Manet.
> 
> Can you elaborate what is the most reason for generating more traffic
> when GW does not flood advertisements.

The average hop count between the GW and the Manet node increases, since the probability that a Manet node will use a sub-optimal GW increases.
 
> > I see your point and I think that it is question of whether 
> a reactive or a more proactive approach
> > should be used. 
> > 
> > [Fredrik Alriksson] Perhaps a combination is preferable?
> 
> Does it depend on network topology? (a number of manet nodes, a number
> of GWs, size of manet) 

Yes, and how dynamic the topology. The activity within the Manet should also be considered.
 
> > 
> > One of the reasons for not recomending gateway advertisement
> > flooding is when you consider the scenario where some nodes might
> > need internet access, and some might not.
> > 
> > [Fredrik Alriksson] Well, the nodes which do not need internet
> > access may still benefit from the periodic floodings, since they
> > probably are involved in the communication between the gateways and
> > the manet nodes what do need internet access. Decreasing the total
> > number of packet transmissions does not only benefit the nodes that
> > need internet access!
> 
> We assume that base manet protocol supports next hop forwarding like
> AODV.  And if some base manet protocols do not support it (like DSR),
> we recommend to the use of routing header.
> 
> When a node sends packets to the Internet, a node put a GW address
> into a routing header.  During packet routing inside manet, the
> destination is the GW addressed in the routing header, therefore
> intermediate nodes routes packets to GW according to base manet
> operation.  The route is maintained by base manet protocol because GW
> can be seen as a normal manet node from the nodes which do not need
> Internet access. The route towards the GW is basically constructed
> when the node requests advertisements.
> 
> What I want to say here is that intermediate nodes just forward/route
> packets to the GW and this is the operations of general manet
> protocol. Intermediate nodes may create routes while some node set up
> global connectivity, but they are basically nothing to do with the
> operation of internet connectivity.

Then I think I didn't express myself clearly enough. My point is that using a 4-hop route between Manet node and GW1 consumes more resources in the Manet as a whole than using a 2-hop route between the same Manet node and GW2. Thus being able to select the closest gateway is a concern for all nodes in the Manet, including those that do not use internet connectivity.

> 
> > When flooding of advertisements is being used, packets are being
> > flooded periodicly over all nodes in the ad hoc network, regardsless
> > of their need for internet connectivity. This is where hop_limit
> > (TTL) considerations becomes important since every advertisement is
> > rebroadcasted as long as allowed by the hop_limit. So, what value
> > for this hop_limit should be used? If we choose a too small value we
> > might not reach all nodes, and choosing a high value will introduce
> > lots of traffic.
> > 
> > [Fredrik Alriksson] Can't a node that does not get the periodic
> > advertisments send solicitations?
> > 
> > 
> > Nodes that have no need for internet connectivity will also 
> receive and process this traffic, uneccessary.
> > 
> > [Fredrik Alriksson] Even though the advertisements are not
> > _necessary_ for the non-internet connected nodes, they may still
> > benefit from the periodic advertisments indirectly, since the total
> > number of packets that they have to forward (including both the
> > advertisements _and_ the user data) may decrease!
> 
> Sorry, I can not see your point in last sentence. 
> Why may the total number of packets decrease?

I think this should be clear from my comment above.

> > In the draft we instead propose that the node itself should initiate
> > this process, the gateway discovery process. In the case where there
> > are multiple gateways, the node should upon receiving these
> > advertisements choose the closest gateway.
> > 
> > [Fredrik Alriksson] Aren't we talking about _mobile_ ad hoc
> > networks? For how long will the chosen gateway remain the closest
> > gateway?
> 
> Yes, talking about manet  :-)

So, it is not enough to make the decision once, since the topology is dynamic.

BR,
Fredrik

> Best Regards,
> ryuji
> 
> 
> > regards,
> > 
> > Anders
> > 
> > 
> > [Fredrik Alriksson] BR, Fredrik
> > 
> >  
> > 
> > Fredrik Alriksson (EAB) wrote:
> > 
> > Hi Ryuji,
> > 
> > In what sense are the gateway advertisements unnecessary?
> > 
> > In case there are multiple gateways, the flooding of 
> gateway advertisements may actually _decrease_ the total 
> number of packet transmissions (control and user data 
> transmissions) in the MANET! 
> > 
> > Flooding gateway advertisements can enable manet nodes 
> which already have a global address to select a _closer_ 
> gateway. This means that the average distance between gateway 
> and manet node can be decreased. This in turn decreases the 
> number of packet transmissions required to deliver user data 
> between the gateways and the manet nodes. Depending on the 
> user activity, this reduction can be larger than the increase 
> in control packet transmissions. 
> > 
> > Other benefits are that the average user data delay 
> decreases, and that the manet nodes loose contact with their 
> gateway less frequently.
> > 
> > Regarding TTL, I don't see the problem, unless 
> advertisements were forwarded on non-manet 
> > interfaces. Can you please elaborate a bit?
> > 
> > BR,
> > Fredrik
> > 
> > 
> > 
> > -----Original Message-----
> > From: Ryuji Wakikawa [ mailto:ryuji@sfc.wide.ad.jp 
>  ]
> > Sent: den 8 juli 2002 18:40
> > To:  Fredrik.Alriksson@era.ericsson.se 
>  
> > Cc:  charliep@iprg.nokia.com 
>  ;  ryuji@sfc.wide.ad.jp 
>  ;
> > jmalinen@ipgr.nokia.com  ;  
> ajtuomin@tml.hut.fi  ;  
> andersn@telecom.lth.se  ;
> > manet@ietf.org  
> > Subject: Re: Gateway Advertisements
> > 
> > 
> > 
> > Hello Fred
> > rik.
> > 
> > In the draft, unnecessary packets basically indicates un-necessary
> > gateway advertisements. For example, if a gateway generates a route
> > advertisement every 1 sec, most of router advertisements 
> are redundant
> > for manet nodes which have already had a global address. They may
> > update lifetime of their global address, but the interval(1sec) is
> > still too short for this operations.
> > 
> > Since flooding packets is easy to cause performance damage in manet,
> > our approach tries to reduce a number of packets which are 
> > flooded over
> > manet. I think manet nodes should not wait flooded 
> advertisements from
> > gateway, instead manet node should discover gateways on their
> > initiative.
> > 
> > It is also difficult for gateways to decide TTL for flooded
> > advertisements. Expanding ring search technique can not be 
> applied to
> > this situation, because advertisements should reach at the edge of
> > manet. It can imagine that unnecessary network-wide dissemination of
> > advertisements will occur when a gateway sets larger TTL than manet
> > scale.
> > 
> > regards,
> > ryuji
> > 
> > 
> > At Mon, 8 Jul 2002 17:27:19 +0200 ,
> > Fredrik Alriksson (EAB) wrote:
> > 
> > 
> > Hi All,
> > 
> > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> > 
> > sending gateway advertisements peridically would generate 
> > unnecessary packets in the Manet. Can you please explain how 
> > you came to that conclusion? Our simulation study on MIPMANET 
> > from '99 ( http://www.e.kth.se/~e94_fal/mipmanet.pdf 
 ) 
> indicates that it actually can decrease the number of packet 
> transmissions in the MANET.
> 
> BR,
> Fredrik
> 
> ---
> Fredrik Alriksson, Ericsson Research
> Email:  fredrik.alriksson@ericsson.com  
> 
> 
> 
> 
> 
> 
>  
> 
> [2  ]
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 11:33:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12094
	for ; Fri, 19 Jul 2002 11:33:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA09950
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 11:34:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05778;
	Fri, 19 Jul 2002 11:07:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21485
	for ; Fri, 19 Jul 2002 04:23:36 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03143
	for ; Fri, 19 Jul 2002 04:22:37 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8NZRb014640
	for ; Fri, 19 Jul 2002 10:23:35 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACWR0>; Fri, 19 Jul 2002 10:23:35 +0200
Message-ID: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Date: Fri, 19 Jul 2002 10:17:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [manet] RE: Gateway Advertisements
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi again,

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]
> Sent: den 11 juli 2002 03:11
> To: Fredrik.Alriksson@era.ericsson.se
> Cc: andersn@telecom.lth.se; manet@ietf.org; ryuji@sfc.wide.ad.jp
> Subject: Re: Gateway Advertisements
> 
> 
> 
> Hello again Fredrik and Thanks Anders.
> 
> At Tue, 9 Jul 2002 13:08:24 +0200 ,
> Fredrik Alriksson (EAB) wrote:
> > 
> > For the solution described in the draft, unsolicited gateway
> > advertisements are not neccessary for the correct operation of the
> > protocol.
> > 
> > [Fredrik Alriksson] I never questioned that. You state that "Sending
> > them (advertisements) periodically would generate unnecessary
> > packets in the Manet", but as I've said in previous emails _not_
> > sending them periodically may generate _more_ traffic in the Manet.
> 
> Can you elaborate what is the most reason for generating more traffic
> when GW does not flood advertisements.

The average hop count between the GW and the Manet node increases, since the probability that a Manet node will use a sub-optimal GW increases.
 
> > I see your point and I think that it is question of whether 
> a reactive or a more proactive approach
> > should be used. 
> > 
> > [Fredrik Alriksson] Perhaps a combination is preferable?
> 
> Does it depend on network topology? (a number of manet nodes, a number
> of GWs, size of manet) 

Yes, and how dynamic the topology. The activity within the Manet should also be considered.
 
> > 
> > One of the reasons for not recomending gateway advertisement
> > flooding is when you consider the scenario where some nodes might
> > need internet access, and some might not.
> > 
> > [Fredrik Alriksson] Well, the nodes which do not need internet
> > access may still benefit from the periodic floodings, since they
> > probably are involved in the communication between the gateways and
> > the manet nodes what do need internet access. Decreasing the total
> > number of packet transmissions does not only benefit the nodes that
> > need internet access!
> 
> We assume that base manet protocol supports next hop forwarding like
> AODV.  And if some base manet protocols do not support it (like DSR),
> we recommend to the use of routing header.
> 
> When a node sends packets to the Internet, a node put a GW address
> into a routing header.  During packet routing inside manet, the
> destination is the GW addressed in the routing header, therefore
> intermediate nodes routes packets to GW according to base manet
> operation.  The route is maintained by base manet protocol because GW
> can be seen as a normal manet node from the nodes which do not need
> Internet access. The route towards the GW is basically constructed
> when the node requests advertisements.
> 
> What I want to say here is that intermediate nodes just forward/route
> packets to the GW and this is the operations of general manet
> protocol. Intermediate nodes may create routes while some node set up
> global connectivity, but they are basically nothing to do with the
> operation of internet connectivity.

Then I think I didn't express myself clearly enough. My point is that using a 4-hop route between Manet node and GW1 consumes more resources in the Manet as a whole than using a 2-hop route between the same Manet node and GW2. Thus being able to select the closest gateway is a concern for all nodes in the Manet, including those that do not use internet connectivity.

> 
> > When flooding of advertisements is being used, packets are being
> > flooded periodicly over all nodes in the ad hoc network, regardsless
> > of their need for internet connectivity. This is where hop_limit
> > (TTL) considerations becomes important since every advertisement is
> > rebroadcasted as long as allowed by the hop_limit. So, what value
> > for this hop_limit should be used? If we choose a too small value we
> > might not reach all nodes, and choosing a high value will introduce
> > lots of traffic.
> > 
> > [Fredrik Alriksson] Can't a node that does not get the periodic
> > advertisments send solicitations?
> > 
> > 
> > Nodes that have no need for internet connectivity will also 
> receive and process this traffic, uneccessary.
> > 
> > [Fredrik Alriksson] Even though the advertisements are not
> > _necessary_ for the non-internet connected nodes, they may still
> > benefit from the periodic advertisments indirectly, since the total
> > number of packets that they have to forward (including both the
> > advertisements _and_ the user data) may decrease!
> 
> Sorry, I can not see your point in last sentence. 
> Why may the total number of packets decrease?

I think this should be clear from my comment above.

> > In the draft we instead propose that the node itself should initiate
> > this process, the gateway discovery process. In the case where there
> > are multiple gateways, the node should upon receiving these
> > advertisements choose the closest gateway.
> > 
> > [Fredrik Alriksson] Aren't we talking about _mobile_ ad hoc
> > networks? For how long will the chosen gateway remain the closest
> > gateway?
> 
> Yes, talking about manet  :-)

So, it is not enough to make the decision once, since the topology is dynamic.

BR,
Fredrik

> Best Regards,
> ryuji
> 
> 
> > regards,
> > 
> > Anders
> > 
> > 
> > [Fredrik Alriksson] BR, Fredrik
> > 
> >  
> > 
> > Fredrik Alriksson (EAB) wrote:
> > 
> > Hi Ryuji,
> > 
> > In what sense are the gateway advertisements unnecessary?
> > 
> > In case there are multiple gateways, the flooding of 
> gateway advertisements may actually _decrease_ the total 
> number of packet transmissions (control and user data 
> transmissions) in the MANET! 
> > 
> > Flooding gateway advertisements can enable manet nodes 
> which already have a global address to select a _closer_ 
> gateway. This means that the average distance between gateway 
> and manet node can be decreased. This in turn decreases the 
> number of packet transmissions required to deliver user data 
> between the gateways and the manet nodes. Depending on the 
> user activity, this reduction can be larger than the increase 
> in control packet transmissions. 
> > 
> > Other benefits are that the average user data delay 
> decreases, and that the manet nodes loose contact with their 
> gateway less frequently.
> > 
> > Regarding TTL, I don't see the problem, unless 
> advertisements were forwarded on non-manet 
> > interfaces. Can you please elaborate a bit?
> > 
> > BR,
> > Fredrik
> > 
> > 
> > 
> > -----Original Message-----
> > From: Ryuji Wakikawa [ mailto:ryuji@sfc.wide.ad.jp 
>  ]
> > Sent: den 8 juli 2002 18:40
> > To:  Fredrik.Alriksson@era.ericsson.se 
>  
> > Cc:  charliep@iprg.nokia.com 
>  ;  ryuji@sfc.wide.ad.jp 
>  ;
> > jmalinen@ipgr.nokia.com  ;  
> ajtuomin@tml.hut.fi  ;  
> andersn@telecom.lth.se  ;
> > manet@ietf.org  
> > Subject: Re: Gateway Advertisements
> > 
> > 
> > 
> > Hello Fred
> > rik.
> > 
> > In the draft, unnecessary packets basically indicates un-necessary
> > gateway advertisements. For example, if a gateway generates a route
> > advertisement every 1 sec, most of router advertisements 
> are redundant
> > for manet nodes which have already had a global address. They may
> > update lifetime of their global address, but the interval(1sec) is
> > still too short for this operations.
> > 
> > Since flooding packets is easy to cause performance damage in manet,
> > our approach tries to reduce a number of packets which are 
> > flooded over
> > manet. I think manet nodes should not wait flooded 
> advertisements from
> > gateway, instead manet node should discover gateways on their
> > initiative.
> > 
> > It is also difficult for gateways to decide TTL for flooded
> > advertisements. Expanding ring search technique can not be 
> applied to
> > this situation, because advertisements should reach at the edge of
> > manet. It can imagine that unnecessary network-wide dissemination of
> > advertisements will occur when a gateway sets larger TTL than manet
> > scale.
> > 
> > regards,
> > ryuji
> > 
> > 
> > At Mon, 8 Jul 2002 17:27:19 +0200 ,
> > Fredrik Alriksson (EAB) wrote:
> > 
> > 
> > Hi All,
> > 
> > In draft-wakikawa-manet-globalv6-00.txt you claim that 
> > 
> > sending gateway advertisements peridically would generate 
> > unnecessary packets in the Manet. Can you please explain how 
> > you came to that conclusion? Our simulation study on MIPMANET 
> > from '99 ( http://www.e.kth.se/~e94_fal/mipmanet.pdf 
 ) 
> indicates that it actually can decrease the number of packet 
> transmissions in the MANET.
> 
> BR,
> Fredrik
> 
> ---
> Fredrik Alriksson, Ericsson Research
> Email:  fredrik.alriksson@ericsson.com  
> 
> 
> 
> 
> 
> 
>  
> 
> [2  ]
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Fri Jul 19 12:24:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11943
	for ; Fri, 19 Jul 2002 11:29:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA09198
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 11:30:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06219;
	Fri, 19 Jul 2002 11:09:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21660
	for ; Fri, 19 Jul 2002 04:27:09 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03203
	for ; Fri, 19 Jul 2002 04:26:10 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6J8R8Rb015313
	for ; Fri, 19 Jul 2002 10:27:08 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <3YTACXRD>; Fri, 19 Jul 2002 10:27:08 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418103@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'manet@ietf.org'" 
Subject: RE: [manet] Re: Gateway Advertisements
Date: Fri, 19 Jul 2002 10:20:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hello,

> By the way, will you come IETF Yokohama in next week?

No, unfortunately not.

> > [Fredrik Alriksson] The reason for asking is this: assume a MANET
> > with 2 GWs and 10 manet nodes using these 2 GWs for Internet
> > access. What is the overhead with proactive vs. reactive? Assuming
> > that the periodicity is the same: reactive: 10 floodings, proactive:
> > 2 floodings.
> > 
> 
> I do not know if this example is good enough, because we can get
> another results depending on topology changes, measurements periods:-)
> 
> After first discovery, reactive stop flooding and start 
> unicasting instead.
> So the result will change after first discovery.
> For 10 sec: reactive: 0 floodings, proactive 10 floodings.
> Well this is best case for reactive, another result can be 
> expected, of
> course!

I agree; another example is of course the scenario we used in our thesis.

> > 
> > >Then I think I didn't express myself clearly enough. My point is 
> > >that using a 4-hop route between Manet node and GW1 consumes more 
> > >resources in the Manet as a whole than using a 2-hop route 
> between the 
> > >same Manet node and GW2. Thus being able to select the 
> closest gateway 
> > >is a concern for all nodes in the Manet, including those 
> that do not 
> > >use internet connectivity.
> > But minimizing the hop count is, of course, also the 
> purpose of our solution. The question is whether it really
> > does differ in average hop, or whether it really is more 
> costful. Flooding could be very costful for battery sensitive 
> devices. As for choosing the closest gateway, this should 
> always be the ambition. The node could either rerequest 
> gateway information, or maybe we could piggyback this 
> information somewhere, in case a "handover"is needed.
> > 
> > 
> > [Fredrik Alriksson] The question with a reactive approach is how to
> > detect that a reaction is needed. Could you please describe that
> > again?
> 
> Actually, the use of multiple GW is not considered enough yet, we just
> mention our rough idea in the draft.  So I don't know if I have good
> answer for this.

Ok, I see. Saving the best for last, are we ;-)

BR,
Fredrik

> regards,
> ryuji
> 
> > BR,
> > Fredrik
> > 
> >  
> > 
> > best regards,
> > 
> > Anders 
> > 
> > 
> > 
> > 
> > 
> > 
> > [2  ]
> > 
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 19 12:45:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13503
	for ; Fri, 19 Jul 2002 12:45:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13718;
	Fri, 19 Jul 2002 12:21:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13687
	for ; Fri, 19 Jul 2002 12:21:25 -0400 (EDT)
Received: from turing.cs.hmc.edu (turing.cs.hmc.edu [134.173.42.99])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12985
	for ; Fri, 19 Jul 2002 12:20:25 -0400 (EDT)
Received: (from clundber@localhost)
	by turing.cs.hmc.edu (8.9.3+Sun/8.9.3) id JAA06011
	for manet@ietf.org; Fri, 19 Jul 2002 09:20:47 -0700 (PDT)
X-Authentication-Warning: turing.cs.hmc.edu: clundber set sender to clundber@cs.hmc.edu using -f
Date: Fri, 19 Jul 2002 09:20:47 -0700
From: Chris Lundberg 
To: manet@ietf.org
Message-ID: <20020719162047.GA5460@cs.hmc.edu>
Mail-Followup-To: manet@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.27i
Subject: [manet] Question for the DSR folks.
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

I'm looking into some (wired) protocols for trust models, and one of the
models bases a lot of its communication on the DSR work.  My question
is this: Is DSR designed to scale to Internet scale or is it always an
assumption that such Ad-Hoc networks are somewhat localized and
eventually connected to a wired infrastructure.  Does route discovery
and caching scale to millions of hosts?

Just looking for some basis for comparison here.  As it stands now, I
believe that the protocols that I am looking at have scalability
problems.

Thanks in advance,
Chris Lundberg

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 19 12:45:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13510
	for ; Fri, 19 Jul 2002 12:45:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA15291
	for manet-archive@odin.ietf.org; Fri, 19 Jul 2002 12:46:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13718;
	Fri, 19 Jul 2002 12:21:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13687
	for ; Fri, 19 Jul 2002 12:21:25 -0400 (EDT)
Received: from turing.cs.hmc.edu (turing.cs.hmc.edu [134.173.42.99])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12985
	for ; Fri, 19 Jul 2002 12:20:25 -0400 (EDT)
Received: (from clundber@localhost)
	by turing.cs.hmc.edu (8.9.3+Sun/8.9.3) id JAA06011
	for manet@ietf.org; Fri, 19 Jul 2002 09:20:47 -0700 (PDT)
X-Authentication-Warning: turing.cs.hmc.edu: clundber set sender to clundber@cs.hmc.edu using -f
Date: Fri, 19 Jul 2002 09:20:47 -0700
From: Chris Lundberg 
To: manet@ietf.org
Message-ID: <20020719162047.GA5460@cs.hmc.edu>
Mail-Followup-To: manet@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.27i
Subject: [manet] Question for the DSR folks.
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

I'm looking into some (wired) protocols for trust models, and one of the
models bases a lot of its communication on the DSR work.  My question
is this: Is DSR designed to scale to Internet scale or is it always an
assumption that such Ad-Hoc networks are somewhat localized and
eventually connected to a wired infrastructure.  Does route discovery
and caching scale to millions of hosts?

Just looking for some basis for comparison here.  As it stands now, I
believe that the protocols that I am looking at have scalability
problems.

Thanks in advance,
Chris Lundberg

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 05:06:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28911
	for ; Mon, 22 Jul 2002 05:06:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00262;
	Mon, 22 Jul 2002 04:31:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00232
	for ; Mon, 22 Jul 2002 04:31:15 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28273
	for ; Mon, 22 Jul 2002 04:30:13 -0400 (EDT)
From: gchelius@telecom.insa-lyon.fr
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 234CA13A10; Mon, 22 Jul 2002 10:27:54 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id ABF9313A0F; Mon, 22 Jul 2002 10:27:53 +0200 (CEST)
To: manet , Charlie Perkins 
Message-Id: <20020722082753.ABF9313A0F@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 10:27:53 +0200 (CEST)
X-Virus-Scanned: by AMaViS snapshot-20020300
Subject: [manet] Comments on draft-ietf-manet-bcast-02.txt
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Message-ID: <1027326473.3d3bc209a51d3@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 10:27:53 +0200 (CEST)
From: Guillaume Chelius 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8

Hello, 

A small comment on the draft draft-ietf-manet-bcast-02.txt.

> The Unique Identifier MUST be placed in the Destination Options
> before the Routing Header (and, thus, before the fragment header).
> This allows proper handling by all intermediate forwarding nodes

I suggest the Unique Identifier MUST be placed in the Hop-by-Hop option header
instead of Destination option header.  Handling of the Destination option header
always take place after the handling of an eventual Hop-by-Hop option header. As
a result, nodes will process the Hop-by-Hop option header of a duplicated packet
before detecting it is a duplicated packet and dropping it. I'm quite sure this
is something we don't want to happen. 

Regards,
Guillaume Chelius.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 05:06:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28920
	for ; Mon, 22 Jul 2002 05:06:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA02439
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 05:07:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00262;
	Mon, 22 Jul 2002 04:31:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00232
	for ; Mon, 22 Jul 2002 04:31:15 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28273
	for ; Mon, 22 Jul 2002 04:30:13 -0400 (EDT)
From: gchelius@telecom.insa-lyon.fr
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 234CA13A10; Mon, 22 Jul 2002 10:27:54 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id ABF9313A0F; Mon, 22 Jul 2002 10:27:53 +0200 (CEST)
To: manet , Charlie Perkins 
Message-Id: <20020722082753.ABF9313A0F@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 10:27:53 +0200 (CEST)
X-Virus-Scanned: by AMaViS snapshot-20020300
Subject: [manet] Comments on draft-ietf-manet-bcast-02.txt
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Message-ID: <1027326473.3d3bc209a51d3@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 10:27:53 +0200 (CEST)
From: Guillaume Chelius 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8

Hello, 

A small comment on the draft draft-ietf-manet-bcast-02.txt.

> The Unique Identifier MUST be placed in the Destination Options
> before the Routing Header (and, thus, before the fragment header).
> This allows proper handling by all intermediate forwarding nodes

I suggest the Unique Identifier MUST be placed in the Hop-by-Hop option header
instead of Destination option header.  Handling of the Destination option header
always take place after the handling of an eventual Hop-by-Hop option header. As
a result, nodes will process the Hop-by-Hop option header of a duplicated packet
before detecting it is a duplicated packet and dropping it. I'm quite sure this
is something we don't want to happen. 

Regards,
Guillaume Chelius.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 05:22:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29144
	for ; Mon, 22 Jul 2002 05:22:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01268;
	Mon, 22 Jul 2002 04:54:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01238
	for ; Mon, 22 Jul 2002 04:54:43 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28729
	for ; Mon, 22 Jul 2002 04:53:41 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id B18A113A28; Mon, 22 Jul 2002 10:51:27 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id 2D4B513A19; Mon, 22 Jul 2002 10:51:27 +0200 (CEST)
To: "Fredrik Alriksson (EAB)" 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 10:51:27 +0200 (CEST)
From: Guillaume Chelius 
Cc: "'manet@ietf.org'" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
In-Reply-To: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello, 

I think discovering and selecting Gateway Nodes has something to do with the 
routing protocol used in the MANet. All the problems we have to deal with look
similar to the ones we have in routing: discovering the gateway (proactive or
reactive approach), construction of the route to the gateway (proactive or
rreq/rrep scheme), handling of mobility (reconstruction of route or selection of
a new gateway). This is something all routing protocols can already easily deal
with (or with minor modifications). It can be done by the addition of a
"Gateway" bit in C messages of OLSR TC packets, by the definition of an "All
Gateways" address to use with rreq in DSR or AODV... It is often a work that has
already be done.

Moreover, the question whether Gateways should advertise themselves or only
respond to requests is similar to the question whether routing protocols must be
reactive or procactive. Arguments are also similar: if the network is stable,
Gateway advertisments induce unnecessary load; if it is unstable, gateway
advertisments are interesting... It seems to me everybody has accepted that, in
some cases, proactive schemes are sometimes better than reactive ones, and in
other cases, the opposite is true. 

My opinion is that we should not split the gateway advertisement mechanism from
the routing protocol. It is the protocol responsability to propose a mechanism
which allows a node to discover gateways and to manage routes between nodes to
gateways.

Regards, 
Guillaume Chelius.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 05:22:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29153
	for ; Mon, 22 Jul 2002 05:22:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03077
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 05:23:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01268;
	Mon, 22 Jul 2002 04:54:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01238
	for ; Mon, 22 Jul 2002 04:54:43 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28729
	for ; Mon, 22 Jul 2002 04:53:41 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id B18A113A28; Mon, 22 Jul 2002 10:51:27 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id 2D4B513A19; Mon, 22 Jul 2002 10:51:27 +0200 (CEST)
To: "Fredrik Alriksson (EAB)" 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 10:51:27 +0200 (CEST)
From: Guillaume Chelius 
Cc: "'manet@ietf.org'" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
In-Reply-To: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello, 

I think discovering and selecting Gateway Nodes has something to do with the 
routing protocol used in the MANet. All the problems we have to deal with look
similar to the ones we have in routing: discovering the gateway (proactive or
reactive approach), construction of the route to the gateway (proactive or
rreq/rrep scheme), handling of mobility (reconstruction of route or selection of
a new gateway). This is something all routing protocols can already easily deal
with (or with minor modifications). It can be done by the addition of a
"Gateway" bit in C messages of OLSR TC packets, by the definition of an "All
Gateways" address to use with rreq in DSR or AODV... It is often a work that has
already be done.

Moreover, the question whether Gateways should advertise themselves or only
respond to requests is similar to the question whether routing protocols must be
reactive or procactive. Arguments are also similar: if the network is stable,
Gateway advertisments induce unnecessary load; if it is unstable, gateway
advertisments are interesting... It seems to me everybody has accepted that, in
some cases, proactive schemes are sometimes better than reactive ones, and in
other cases, the opposite is true. 

My opinion is that we should not split the gateway advertisement mechanism from
the routing protocol. It is the protocol responsability to propose a mechanism
which allows a node to discover gateways and to manage routes between nodes to
gateways.

Regards, 
Guillaume Chelius.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 08:17:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01982
	for ; Mon, 22 Jul 2002 08:17:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09758;
	Mon, 22 Jul 2002 07:41:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09731
	for ; Mon, 22 Jul 2002 07:40:57 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01360
	for ; Mon, 22 Jul 2002 07:39:54 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6MBekrU027778;
	Mon, 22 Jul 2002 13:40:46 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Mon, 22 Jul 2002 13:40:46 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418108@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'Guillaume Chelius'" 
Cc: "'manet@ietf.org'" 
Subject: RE: [manet] RE: Gateway Advertisements
Date: Mon, 22 Jul 2002 13:35:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Guillaume,

> I think discovering and selecting Gateway Nodes has something 
> to do with the 
> routing protocol used in the MANet. All the problems we have 
> to deal with look
> similar to the ones we have in routing: discovering the 
> gateway (proactive or
> reactive approach), construction of the route to the gateway 
> (proactive or
> rreq/rrep scheme), handling of mobility (reconstruction of 
> route or selection of
> a new gateway). This is something all routing protocols can 
> already easily deal
> with (or with minor modifications). It can be done by the 
> addition of a
> "Gateway" bit in C messages of OLSR TC packets, by the 
> definition of an "All
> Gateways" address to use with rreq in DSR or AODV... It is 
> often a work that has
> already be done.

Sure, it _can_ be done that way.

> Moreover, the question whether Gateways should advertise 
> themselves or only
> respond to requests is similar to the question whether 
> routing protocols must be
> reactive or procactive. Arguments are also similar: if the 
> network is stable,
> Gateway advertisments induce unnecessary load; if it is 
> unstable, gateway
> advertisments are interesting... 

The question is similar, but the nature of the communication between mobile and GW is quite different than that of communication between two mobile nodes, so conclusions drawn from mobile-to-mobile scenarios are not automatically valid for mobile-GW scenarios.

> It seems to me everybody has 
> accepted that, in
> some cases, proactive schemes are sometimes better than 
> reactive ones, and in
> other cases, the opposite is true. 

Well, draft-wakikawa-manet-globalv6-00.txt says that a proactive scheme SHOULD NOT be used, and I haven't seen any comments about that previously, so my impression was that everybody had "accepted" that a reactive approach is better in _most_ cases.
 
> My opinion is that we should not split the gateway 
> advertisement mechanism from
> the routing protocol. It is the protocol responsability to 
> propose a mechanism
> which allows a node to discover gateways and to manage routes 
> between nodes to
> gateways.

So, you don't see any need for e.g. draft-wakikawa-manet-globalv6-00.txt?

BR,
Fredrik

> Regards, 
> Guillaume Chelius.
> 
> -----------------
> Guillaume Chelius
> PhD student
> Ares Team, Inria, Citi Insa-Lyon
> Tel: (+33) 472 436 421
> Email: gchelius@telecom.insa-lyon.fr
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 08:17:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01990
	for ; Mon, 22 Jul 2002 08:17:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA11838
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 08:18:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09758;
	Mon, 22 Jul 2002 07:41:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09731
	for ; Mon, 22 Jul 2002 07:40:57 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01360
	for ; Mon, 22 Jul 2002 07:39:54 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6MBekrU027778;
	Mon, 22 Jul 2002 13:40:46 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Mon, 22 Jul 2002 13:40:46 +0200
Message-ID: <1F55F6582266314A85A55F6241509B67418108@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'Guillaume Chelius'" 
Cc: "'manet@ietf.org'" 
Subject: RE: [manet] RE: Gateway Advertisements
Date: Mon, 22 Jul 2002 13:35:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Guillaume,

> I think discovering and selecting Gateway Nodes has something 
> to do with the 
> routing protocol used in the MANet. All the problems we have 
> to deal with look
> similar to the ones we have in routing: discovering the 
> gateway (proactive or
> reactive approach), construction of the route to the gateway 
> (proactive or
> rreq/rrep scheme), handling of mobility (reconstruction of 
> route or selection of
> a new gateway). This is something all routing protocols can 
> already easily deal
> with (or with minor modifications). It can be done by the 
> addition of a
> "Gateway" bit in C messages of OLSR TC packets, by the 
> definition of an "All
> Gateways" address to use with rreq in DSR or AODV... It is 
> often a work that has
> already be done.

Sure, it _can_ be done that way.

> Moreover, the question whether Gateways should advertise 
> themselves or only
> respond to requests is similar to the question whether 
> routing protocols must be
> reactive or procactive. Arguments are also similar: if the 
> network is stable,
> Gateway advertisments induce unnecessary load; if it is 
> unstable, gateway
> advertisments are interesting... 

The question is similar, but the nature of the communication between mobile and GW is quite different than that of communication between two mobile nodes, so conclusions drawn from mobile-to-mobile scenarios are not automatically valid for mobile-GW scenarios.

> It seems to me everybody has 
> accepted that, in
> some cases, proactive schemes are sometimes better than 
> reactive ones, and in
> other cases, the opposite is true. 

Well, draft-wakikawa-manet-globalv6-00.txt says that a proactive scheme SHOULD NOT be used, and I haven't seen any comments about that previously, so my impression was that everybody had "accepted" that a reactive approach is better in _most_ cases.
 
> My opinion is that we should not split the gateway 
> advertisement mechanism from
> the routing protocol. It is the protocol responsability to 
> propose a mechanism
> which allows a node to discover gateways and to manage routes 
> between nodes to
> gateways.

So, you don't see any need for e.g. draft-wakikawa-manet-globalv6-00.txt?

BR,
Fredrik

> Regards, 
> Guillaume Chelius.
> 
> -----------------
> Guillaume Chelius
> PhD student
> Ares Team, Inria, Citi Insa-Lyon
> Tel: (+33) 472 436 421
> Email: gchelius@telecom.insa-lyon.fr
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 08:59:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03050
	for ; Mon, 22 Jul 2002 08:59:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13475;
	Mon, 22 Jul 2002 08:44:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13447
	for ; Mon, 22 Jul 2002 08:44:24 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02627
	for ; Mon, 22 Jul 2002 08:43:24 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 9FED613A1E; Mon, 22 Jul 2002 14:41:08 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id 1024C13A01; Mon, 22 Jul 2002 14:41:08 +0200 (CEST)
To: "Fredrik Alriksson (EAB)" 
Subject: RE: [manet] RE: Gateway Advertisements
Message-ID: <1027341668.3d3bfd6408dd1@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 14:41:08 +0200 (CEST)
From: Guillaume Chelius 
Cc: "'Guillaume Chelius'" ,
        "'manet@ietf.org'" 
References: <1F55F6582266314A85A55F6241509B67418108@Esealnt863.al.sw.ericsson.se>
In-Reply-To: <1F55F6582266314A85A55F6241509B67418108@Esealnt863.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Fredrik, 

> > Moreover, the question whether Gateways should advertise 
> > themselves or only
> > respond to requests is similar to the question whether 
> > routing protocols must be
> > reactive or procactive. Arguments are also similar: if the 
> > network is stable,
> > Gateway advertisments induce unnecessary load; if it is 
> > unstable, gateway
> > advertisments are interesting... 
> 
> The question is similar, but the nature of the communication between
> mobile and GW is quite different than that of communication between two
> mobile nodes, so conclusions drawn from mobile-to-mobile scenarios are
> not automatically valid for mobile-GW scenarios.

They are not so different to me.
 
> > It seems to me everybody has 
> > accepted that, in
> > some cases, proactive schemes are sometimes better than 
> > reactive ones, and in
> > other cases, the opposite is true. 
> 
> Well, draft-wakikawa-manet-globalv6-00.txt says that a proactive scheme
> SHOULD NOT be used, and I haven't seen any comments about that
> previously, so my impression was that everybody had "accepted" that a
> reactive approach is better in _most_ cases.

I don't think everybody has accepted it, at least you and I haven't. Many other
schemes have to be studied. Hybrid protocols for example. GW may flood
advertisements with a low TTL and support a solicitation/advertisment protocol
as well. Nodes receiving unsolicited advertisements will be able to select the
closest GW and nodes not receiving any unsolicited advertisement will request
for a GW. After mobility, nodes starting to receive new unsolicited
advertisments will be able to reselect a closer GW. This is an example. 
  
> > My opinion is that we should not split the gateway 
> > advertisement mechanism from
> > the routing protocol. It is the protocol responsability to 
> > propose a mechanism
> > which allows a node to discover gateways and to manage routes 
> > between nodes to
> > gateways.
> 
> So, you don't see any need for e.g.
> draft-wakikawa-manet-globalv6-00.txt?

The fact is that routing protocols integrate or may easily integrate a GW
discovery protocol. This integration is often more efficient than defining a
separate protocol. It is not worth defining and flooding a new packet in a MANet
with OLSR, when the use of one bit in TC messages leads to the same result. For
a basic GW discovery protocol, I think draft-wakikawa-manet-globalv6-00.txt is
useless. Not tobe misunderstood, I precise that its content is not useless. But
I think this problem should not be addressed in a specific draft.

I see one reason that could make this draft interesting: 

- The definition of a generic service discovery protocol.
draft-wakikawa-manet-globalv6-00.txt addresses the problem of discovering and
using Internet GWs. As I already said, I think it can be better done by routing
protocols. However, it could/should address a more general problem which is
service location. Instead of simply answering to "I'm looking for an Internet
GW" it should provide the way to answer more complex questions like "I'm looking
for a Web/FTP Proxy with high bandwidth"...  


Regards, 
Guillaume.
-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 08:59:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03060
	for ; Mon, 22 Jul 2002 08:59:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA14709
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 09:00:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13475;
	Mon, 22 Jul 2002 08:44:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13447
	for ; Mon, 22 Jul 2002 08:44:24 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02627
	for ; Mon, 22 Jul 2002 08:43:24 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 9FED613A1E; Mon, 22 Jul 2002 14:41:08 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id 1024C13A01; Mon, 22 Jul 2002 14:41:08 +0200 (CEST)
To: "Fredrik Alriksson (EAB)" 
Subject: RE: [manet] RE: Gateway Advertisements
Message-ID: <1027341668.3d3bfd6408dd1@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 14:41:08 +0200 (CEST)
From: Guillaume Chelius 
Cc: "'Guillaume Chelius'" ,
        "'manet@ietf.org'" 
References: <1F55F6582266314A85A55F6241509B67418108@Esealnt863.al.sw.ericsson.se>
In-Reply-To: <1F55F6582266314A85A55F6241509B67418108@Esealnt863.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Fredrik, 

> > Moreover, the question whether Gateways should advertise 
> > themselves or only
> > respond to requests is similar to the question whether 
> > routing protocols must be
> > reactive or procactive. Arguments are also similar: if the 
> > network is stable,
> > Gateway advertisments induce unnecessary load; if it is 
> > unstable, gateway
> > advertisments are interesting... 
> 
> The question is similar, but the nature of the communication between
> mobile and GW is quite different than that of communication between two
> mobile nodes, so conclusions drawn from mobile-to-mobile scenarios are
> not automatically valid for mobile-GW scenarios.

They are not so different to me.
 
> > It seems to me everybody has 
> > accepted that, in
> > some cases, proactive schemes are sometimes better than 
> > reactive ones, and in
> > other cases, the opposite is true. 
> 
> Well, draft-wakikawa-manet-globalv6-00.txt says that a proactive scheme
> SHOULD NOT be used, and I haven't seen any comments about that
> previously, so my impression was that everybody had "accepted" that a
> reactive approach is better in _most_ cases.

I don't think everybody has accepted it, at least you and I haven't. Many other
schemes have to be studied. Hybrid protocols for example. GW may flood
advertisements with a low TTL and support a solicitation/advertisment protocol
as well. Nodes receiving unsolicited advertisements will be able to select the
closest GW and nodes not receiving any unsolicited advertisement will request
for a GW. After mobility, nodes starting to receive new unsolicited
advertisments will be able to reselect a closer GW. This is an example. 
  
> > My opinion is that we should not split the gateway 
> > advertisement mechanism from
> > the routing protocol. It is the protocol responsability to 
> > propose a mechanism
> > which allows a node to discover gateways and to manage routes 
> > between nodes to
> > gateways.
> 
> So, you don't see any need for e.g.
> draft-wakikawa-manet-globalv6-00.txt?

The fact is that routing protocols integrate or may easily integrate a GW
discovery protocol. This integration is often more efficient than defining a
separate protocol. It is not worth defining and flooding a new packet in a MANet
with OLSR, when the use of one bit in TC messages leads to the same result. For
a basic GW discovery protocol, I think draft-wakikawa-manet-globalv6-00.txt is
useless. Not tobe misunderstood, I precise that its content is not useless. But
I think this problem should not be addressed in a specific draft.

I see one reason that could make this draft interesting: 

- The definition of a generic service discovery protocol.
draft-wakikawa-manet-globalv6-00.txt addresses the problem of discovering and
using Internet GWs. As I already said, I think it can be better done by routing
protocols. However, it could/should address a more general problem which is
service location. Instead of simply answering to "I'm looking for an Internet
GW" it should provide the way to answer more complex questions like "I'm looking
for a Web/FTP Proxy with high bandwidth"...  


Regards, 
Guillaume.
-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 09:33:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03937
	for ; Mon, 22 Jul 2002 09:33:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15402;
	Mon, 22 Jul 2002 09:14:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15369
	for ; Mon, 22 Jul 2002 09:14:15 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03357
	for ; Mon, 22 Jul 2002 09:13:15 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6MDEERc015632;
	Mon, 22 Jul 2002 15:14:14 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Mon, 22 Jul 2002 15:14:14 +0200
Message-ID: <1F55F6582266314A85A55F6241509B6741810A@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'Guillaume Chelius'" 
Cc: "'manet@ietf.org'" 
Subject: RE: [manet] RE: Gateway Advertisements
Date: Mon, 22 Jul 2002 15:09:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi again,

> > > Moreover, the question whether Gateways should advertise 
> > > themselves or only
> > > respond to requests is similar to the question whether 
> > > routing protocols must be
> > > reactive or procactive. Arguments are also similar: if the 
> > > network is stable,
> > > Gateway advertisments induce unnecessary load; if it is 
> > > unstable, gateway
> > > advertisments are interesting... 
> > 
> > The question is similar, but the nature of the communication between
> > mobile and GW is quite different than that of communication 
> between two
> > mobile nodes, so conclusions drawn from mobile-to-mobile 
> scenarios are
> > not automatically valid for mobile-GW scenarios.
> 
> They are not so different to me.

So, the gateway is just like any other node in the network? The route to the gateway is used about as much as any other route in the network? The chance that some other node also wants a route to the gateway is the same as the chance that some other node also wants a route to a specific mobile node?

>  
> > > It seems to me everybody has 
> > > accepted that, in
> > > some cases, proactive schemes are sometimes better than 
> > > reactive ones, and in
> > > other cases, the opposite is true. 
> > 
> > Well, draft-wakikawa-manet-globalv6-00.txt says that a 
> proactive scheme
> > SHOULD NOT be used, and I haven't seen any comments about that
> > previously, so my impression was that everybody had 
> "accepted" that a
> > reactive approach is better in _most_ cases.
> 
> I don't think everybody has accepted it, at least you and I 
> haven't. Many other
> schemes have to be studied. Hybrid protocols for example. GW may flood
> advertisements with a low TTL and support a 
> solicitation/advertisment protocol
> as well. Nodes receiving unsolicited advertisements will be 
> able to select the
> closest GW and nodes not receiving any unsolicited 
> advertisement will request
> for a GW. After mobility, nodes starting to receive new unsolicited
> advertisments will be able to reselect a closer GW. This is 
> an example. 

I think we agree on this.
   
> > > My opinion is that we should not split the gateway 
> > > advertisement mechanism from
> > > the routing protocol. It is the protocol responsability to 
> > > propose a mechanism
> > > which allows a node to discover gateways and to manage routes 
> > > between nodes to
> > > gateways.
> > 
> > So, you don't see any need for e.g.
> > draft-wakikawa-manet-globalv6-00.txt?
> 
> The fact is that routing protocols integrate or may easily 
> integrate a GW
> discovery protocol. This integration is often more efficient 
> than defining a
> separate protocol.

You'll have to give me some references on this matter to convince me I'm afraid... :-)

When using a proactive protocol, you are probably right, but I'm not so sure if we talk about reactive routing procotols.

> It is not worth defining and flooding a 
> new packet in a MANet
> with OLSR, when the use of one bit in TC messages leads to 
> the same result. 

Well, since OLSR is proactive, the result may be the same (I don't know OLSR that well). For reactive protocols, the result is not necessarily the same.

BR,
Fredrik

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 09:33:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03943
	for ; Mon, 22 Jul 2002 09:33:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA17009
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 09:34:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15402;
	Mon, 22 Jul 2002 09:14:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15369
	for ; Mon, 22 Jul 2002 09:14:15 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03357
	for ; Mon, 22 Jul 2002 09:13:15 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6MDEERc015632;
	Mon, 22 Jul 2002 15:14:14 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Mon, 22 Jul 2002 15:14:14 +0200
Message-ID: <1F55F6582266314A85A55F6241509B6741810A@Esealnt863.al.sw.ericsson.se>
From: "Fredrik Alriksson (EAB)" 
To: "'Guillaume Chelius'" 
Cc: "'manet@ietf.org'" 
Subject: RE: [manet] RE: Gateway Advertisements
Date: Mon, 22 Jul 2002 15:09:01 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi again,

> > > Moreover, the question whether Gateways should advertise 
> > > themselves or only
> > > respond to requests is similar to the question whether 
> > > routing protocols must be
> > > reactive or procactive. Arguments are also similar: if the 
> > > network is stable,
> > > Gateway advertisments induce unnecessary load; if it is 
> > > unstable, gateway
> > > advertisments are interesting... 
> > 
> > The question is similar, but the nature of the communication between
> > mobile and GW is quite different than that of communication 
> between two
> > mobile nodes, so conclusions drawn from mobile-to-mobile 
> scenarios are
> > not automatically valid for mobile-GW scenarios.
> 
> They are not so different to me.

So, the gateway is just like any other node in the network? The route to the gateway is used about as much as any other route in the network? The chance that some other node also wants a route to the gateway is the same as the chance that some other node also wants a route to a specific mobile node?

>  
> > > It seems to me everybody has 
> > > accepted that, in
> > > some cases, proactive schemes are sometimes better than 
> > > reactive ones, and in
> > > other cases, the opposite is true. 
> > 
> > Well, draft-wakikawa-manet-globalv6-00.txt says that a 
> proactive scheme
> > SHOULD NOT be used, and I haven't seen any comments about that
> > previously, so my impression was that everybody had 
> "accepted" that a
> > reactive approach is better in _most_ cases.
> 
> I don't think everybody has accepted it, at least you and I 
> haven't. Many other
> schemes have to be studied. Hybrid protocols for example. GW may flood
> advertisements with a low TTL and support a 
> solicitation/advertisment protocol
> as well. Nodes receiving unsolicited advertisements will be 
> able to select the
> closest GW and nodes not receiving any unsolicited 
> advertisement will request
> for a GW. After mobility, nodes starting to receive new unsolicited
> advertisments will be able to reselect a closer GW. This is 
> an example. 

I think we agree on this.
   
> > > My opinion is that we should not split the gateway 
> > > advertisement mechanism from
> > > the routing protocol. It is the protocol responsability to 
> > > propose a mechanism
> > > which allows a node to discover gateways and to manage routes 
> > > between nodes to
> > > gateways.
> > 
> > So, you don't see any need for e.g.
> > draft-wakikawa-manet-globalv6-00.txt?
> 
> The fact is that routing protocols integrate or may easily 
> integrate a GW
> discovery protocol. This integration is often more efficient 
> than defining a
> separate protocol.

You'll have to give me some references on this matter to convince me I'm afraid... :-)

When using a proactive protocol, you are probably right, but I'm not so sure if we talk about reactive routing procotols.

> It is not worth defining and flooding a 
> new packet in a MANet
> with OLSR, when the use of one bit in TC messages leads to 
> the same result. 

Well, since OLSR is proactive, the result may be the same (I don't know OLSR that well). For reactive protocols, the result is not necessarily the same.

BR,
Fredrik

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 10:36:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05327
	for ; Mon, 22 Jul 2002 10:36:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18818;
	Mon, 22 Jul 2002 10:07:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18787
	for ; Mon, 22 Jul 2002 10:07:05 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04617
	for ; Mon, 22 Jul 2002 10:06:05 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA29645;
	Mon, 22 Jul 2002 07:06:34 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6ME6XJ16176;
	Mon, 22 Jul 2002 07:06:33 -0700
X-mProtect: <200207221406> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdq3HRUD; Mon, 22 Jul 2002 07:06:30 PDT
Message-ID: <3D3C10DB.2F963AF6@iprg.nokia.com>
Date: Mon, 22 Jul 2002 07:04:12 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Guillaume Chelius 
CC: "Fredrik Alriksson (EAB)" ,
        "'manet@ietf.org'" 
Subject: Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Guillaume,

Guillaume Chelius wrote:

> I think discovering and selecting Gateway Nodes has something to do with the
> routing protocol used in the MANet. .....

This is true, but it's a very broad statement.

>                                                           ... It is often a work
> that has
> already be done.

I assume that you meant, "even before draft-wakikawa-...".

But that just isn't true.  There were a lot of problems that had to
be solved.  Even some things that may look easy in hindsight
are not easy to figure out before the fact.

> Moreover, the question whether Gateways should advertise themselves or only
> respond to requests is similar to the question whether routing protocols must be
> reactive or procactive. ....

This is more than just social acceptance.  It has been shown more
than once, and it is intuitively obvious if you think about extreme cases
of traffic patterns.

> My opinion is that we should not split the gateway advertisement mechanism from
> the routing protocol. It is the protocol responsability to propose a mechanism
> which allows a node to discover gateways and to manage routes between nodes to
> gateways.

What about using a Router Discovery protocol extension that is not specific
to any routing protocol?  There is no reason such an approach is wrong,
a priori, although your statement would disallow it from consideration.

Regards,
Charlie P.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 10:36:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05336
	for ; Mon, 22 Jul 2002 10:36:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA20941
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 10:37:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18818;
	Mon, 22 Jul 2002 10:07:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18787
	for ; Mon, 22 Jul 2002 10:07:05 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04617
	for ; Mon, 22 Jul 2002 10:06:05 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA29645;
	Mon, 22 Jul 2002 07:06:34 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6ME6XJ16176;
	Mon, 22 Jul 2002 07:06:33 -0700
X-mProtect: <200207221406> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdq3HRUD; Mon, 22 Jul 2002 07:06:30 PDT
Message-ID: <3D3C10DB.2F963AF6@iprg.nokia.com>
Date: Mon, 22 Jul 2002 07:04:12 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Guillaume Chelius 
CC: "Fredrik Alriksson (EAB)" ,
        "'manet@ietf.org'" 
Subject: Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Guillaume,

Guillaume Chelius wrote:

> I think discovering and selecting Gateway Nodes has something to do with the
> routing protocol used in the MANet. .....

This is true, but it's a very broad statement.

>                                                           ... It is often a work
> that has
> already be done.

I assume that you meant, "even before draft-wakikawa-...".

But that just isn't true.  There were a lot of problems that had to
be solved.  Even some things that may look easy in hindsight
are not easy to figure out before the fact.

> Moreover, the question whether Gateways should advertise themselves or only
> respond to requests is similar to the question whether routing protocols must be
> reactive or procactive. ....

This is more than just social acceptance.  It has been shown more
than once, and it is intuitively obvious if you think about extreme cases
of traffic patterns.

> My opinion is that we should not split the gateway advertisement mechanism from
> the routing protocol. It is the protocol responsability to propose a mechanism
> which allows a node to discover gateways and to manage routes between nodes to
> gateways.

What about using a Router Discovery protocol extension that is not specific
to any routing protocol?  There is no reason such an approach is wrong,
a priori, although your statement would disallow it from consideration.

Regards,
Charlie P.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 11:06:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06600
	for ; Mon, 22 Jul 2002 11:06:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21430;
	Mon, 22 Jul 2002 10:47:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21401
	for ; Mon, 22 Jul 2002 10:47:04 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05708
	for ; Mon, 22 Jul 2002 10:46:03 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 5D74E13A25; Mon, 22 Jul 2002 16:43:47 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id E9E4B13A24; Mon, 22 Jul 2002 16:43:46 +0200 (CEST)
To: Charlie Perkins 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 16:43:46 +0200 (CEST)
From: Guillaume Chelius 
Cc: Guillaume Chelius ,
        "Fredrik Alriksson (EAB)" ,
        "'manet@ietf.org'" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com>
In-Reply-To: <3D3C10DB.2F963AF6@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Charlie,

> > ... It is often a work that has already be done.
> 
> I assume that you meant, "even before draft-wakikawa-...".

Yes. I  mean that some ad hoc routing protocols already include mechanisms to
discover Internet gateways or to interconnect a non  ad hoc network to a MANet.

> But that just isn't true.  There were a lot of problems that had to
> be solved.  Even some things that may look easy in hindsight
> are not easy to figure out before the fact.

I easily believe you.

> > Moreover, the question whether Gateways should advertise themselves or only
> > respond to requests is similar to the question whether routing protocols
> > must be reactive or procactive. ....
> 
> This is more than just social acceptance.  It has been shown more
> than once, and it is intuitively obvious if you think about extreme
> cases of traffic patterns.

I agree.

> > My opinion is that we should not split the gateway advertisement
> > mechanism from the routing protocol. It is the protocol responsability to 
> > propose a mechanism which allows a node to discover gateways and to manage 
> > routes between nodes to gateways.
> 
> What about using a Router Discovery protocol extension that is not
> specific to any routing protocol?  There is no reason such an approach is
> wrong, a priori, although your statement would disallow it from
> consideration.

I'm ok to say it is not wrong. However, I think the definition of a Router
Discovery protocol should not prevent routing protocols to do Router Discovery
if it can at low cost. It means to me that the independant Router Discovery
protocol should not load the network if not needed or should not process if we
don't want it to (some kind of passive mode). 

I also think such a document is interesting only if it is not restrictive in the
way we use the protocol. A reative-only protocol is not satisfaying. As Fredrik
states it, unsolicited advertisements may be interestings for many reasons, e.g.
a better mobility support or global prefix advertisement.

Why not using some king of adaptation of the Router/Prefix  discovery protocol
of IPv6 NDP (Neighbor Discovery Protocol) to ad hoc netorks. 
Basically, Routers are free to advertise or not. Routers must respond to
solicitation. The protocol relies on ad hoc flooding. The maintenance of routes
btw nodes and GW  remains the routing protocol work. This lets enough freedom to
tune the protocol depending on what we want and on the MANet characteristics.

Regards, 
Guillaume.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Mon Jul 22 11:52:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08309
	for ; Mon, 22 Jul 2002 11:52:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24807;
	Mon, 22 Jul 2002 11:27:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24773
	for ; Mon, 22 Jul 2002 11:27:31 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07318
	for ; Mon, 22 Jul 2002 11:26:29 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA03206;
	Mon, 22 Jul 2002 08:26:59 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6MFQx802897;
	Mon, 22 Jul 2002 08:26:59 -0700
X-mProtect: <200207221526> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdQmMWPc; Mon, 22 Jul 2002 08:26:56 PDT
Message-ID: <3D3C23B6.DB3DED61@iprg.nokia.com>
Date: Mon, 22 Jul 2002 08:24:38 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Guillaume Chelius 
CC: "'manet@ietf.org'" 
Subject: Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Guillaume,

Guillaume Chelius wrote:

> > What about using a Router Discovery protocol extension that is not
> > specific to any routing protocol?  There is no reason such an approach is
> > wrong, a priori, although your statement would disallow it from
> > consideration.
>
> I'm ok to say it is not wrong. However, I think the definition of a Router
> Discovery protocol should not prevent routing protocols to do Router Discovery
> if it can at low cost. It means to me that the independant Router Discovery
> protocol should not load the network if not needed or should not process if we
> don't want it to (some kind of passive mode).

It could also be configurable at the gateway.  I would consider
that "passive" means "reactive", and the question of "reactive"
vs. "proactive" has just been discussed.

> Why not using some king of adaptation of the Router/Prefix  discovery protocol
> of IPv6 NDP (Neighbor Discovery Protocol) to ad hoc netorks.
> Basically, Routers are free to advertise or not. Routers must respond to
> solicitation. The protocol relies on ad hoc flooding. The maintenance of routes
> btw nodes and GW  remains the routing protocol work. This lets enough freedom to
> tune the protocol depending on what we want and on the MANet characteristics.

This sounds a lot like draft-wakikawa, except that the flooding happens
from the other way around.

I think the advantages of having default routes have been overlooked
in this discussion.  For one thing, it allows automatic switching to a
new gateway for many circumstances when a node moves closer to a
different gateway than it formerly was using.

Regards,
Charlie P.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 11:52:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08315
	for ; Mon, 22 Jul 2002 11:52:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA27455
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 11:53:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24807;
	Mon, 22 Jul 2002 11:27:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24773
	for ; Mon, 22 Jul 2002 11:27:31 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07318
	for ; Mon, 22 Jul 2002 11:26:29 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA03206;
	Mon, 22 Jul 2002 08:26:59 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6MFQx802897;
	Mon, 22 Jul 2002 08:26:59 -0700
X-mProtect: <200207221526> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdQmMWPc; Mon, 22 Jul 2002 08:26:56 PDT
Message-ID: <3D3C23B6.DB3DED61@iprg.nokia.com>
Date: Mon, 22 Jul 2002 08:24:38 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Guillaume Chelius 
CC: "'manet@ietf.org'" 
Subject: Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Guillaume,

Guillaume Chelius wrote:

> > What about using a Router Discovery protocol extension that is not
> > specific to any routing protocol?  There is no reason such an approach is
> > wrong, a priori, although your statement would disallow it from
> > consideration.
>
> I'm ok to say it is not wrong. However, I think the definition of a Router
> Discovery protocol should not prevent routing protocols to do Router Discovery
> if it can at low cost. It means to me that the independant Router Discovery
> protocol should not load the network if not needed or should not process if we
> don't want it to (some kind of passive mode).

It could also be configurable at the gateway.  I would consider
that "passive" means "reactive", and the question of "reactive"
vs. "proactive" has just been discussed.

> Why not using some king of adaptation of the Router/Prefix  discovery protocol
> of IPv6 NDP (Neighbor Discovery Protocol) to ad hoc netorks.
> Basically, Routers are free to advertise or not. Routers must respond to
> solicitation. The protocol relies on ad hoc flooding. The maintenance of routes
> btw nodes and GW  remains the routing protocol work. This lets enough freedom to
> tune the protocol depending on what we want and on the MANet characteristics.

This sounds a lot like draft-wakikawa, except that the flooding happens
from the other way around.

I think the advantages of having default routes have been overlooked
in this discussion.  For one thing, it allows automatic switching to a
new gateway for many circumstances when a node moves closer to a
different gateway than it formerly was using.

Regards,
Charlie P.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Mon Jul 22 11:54:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06607
	for ; Mon, 22 Jul 2002 11:06:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23412
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 11:07:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21430;
	Mon, 22 Jul 2002 10:47:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21401
	for ; Mon, 22 Jul 2002 10:47:04 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05708
	for ; Mon, 22 Jul 2002 10:46:03 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 5D74E13A25; Mon, 22 Jul 2002 16:43:47 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id E9E4B13A24; Mon, 22 Jul 2002 16:43:46 +0200 (CEST)
To: Charlie Perkins 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 16:43:46 +0200 (CEST)
From: Guillaume Chelius 
Cc: Guillaume Chelius ,
        "Fredrik Alriksson (EAB)" ,
        "'manet@ietf.org'" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com>
In-Reply-To: <3D3C10DB.2F963AF6@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Charlie,

> > ... It is often a work that has already be done.
> 
> I assume that you meant, "even before draft-wakikawa-...".

Yes. I  mean that some ad hoc routing protocols already include mechanisms to
discover Internet gateways or to interconnect a non  ad hoc network to a MANet.

> But that just isn't true.  There were a lot of problems that had to
> be solved.  Even some things that may look easy in hindsight
> are not easy to figure out before the fact.

I easily believe you.

> > Moreover, the question whether Gateways should advertise themselves or only
> > respond to requests is similar to the question whether routing protocols
> > must be reactive or procactive. ....
> 
> This is more than just social acceptance.  It has been shown more
> than once, and it is intuitively obvious if you think about extreme
> cases of traffic patterns.

I agree.

> > My opinion is that we should not split the gateway advertisement
> > mechanism from the routing protocol. It is the protocol responsability to 
> > propose a mechanism which allows a node to discover gateways and to manage 
> > routes between nodes to gateways.
> 
> What about using a Router Discovery protocol extension that is not
> specific to any routing protocol?  There is no reason such an approach is
> wrong, a priori, although your statement would disallow it from
> consideration.

I'm ok to say it is not wrong. However, I think the definition of a Router
Discovery protocol should not prevent routing protocols to do Router Discovery
if it can at low cost. It means to me that the independant Router Discovery
protocol should not load the network if not needed or should not process if we
don't want it to (some kind of passive mode). 

I also think such a document is interesting only if it is not restrictive in the
way we use the protocol. A reative-only protocol is not satisfaying. As Fredrik
states it, unsolicited advertisements may be interestings for many reasons, e.g.
a better mobility support or global prefix advertisement.

Why not using some king of adaptation of the Router/Prefix  discovery protocol
of IPv6 NDP (Neighbor Discovery Protocol) to ad hoc netorks. 
Basically, Routers are free to advertise or not. Routers must respond to
solicitation. The protocol relies on ad hoc flooding. The maintenance of routes
btw nodes and GW  remains the routing protocol work. This lets enough freedom to
tune the protocol depending on what we want and on the MANet characteristics.

Regards, 
Guillaume.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 11:55:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08485
	for ; Mon, 22 Jul 2002 11:55:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24879;
	Mon, 22 Jul 2002 11:28:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24840
	for ; Mon, 22 Jul 2002 11:28:09 -0400 (EDT)
Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07349
	for ; Mon, 22 Jul 2002 11:27:07 -0400 (EDT)
Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddf66a.tkyoac00.ap.so-net.ne.jp [218.221.246.106])
	(authenticated bits=0)
	by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6MFQvfg025447;
	Tue, 23 Jul 2002 00:26:57 +0900
Date: Tue, 23 Jul 2002 00:26:48 +0900
Message-ID: 
From: Ryuji Wakikawa
To: gchelius@telecom.insa-lyon.fr
Sent-via: gchelius@telecom.insa-lyon.fr
Cc: charliep@IPRG.nokia.com, Fredrik.Alriksson@era.ericsson.se, manet@ietf.org
Sent-via: charliep@IPRG.nokia.com,
	Fredrik.Alriksson@era.ericsson.se,
	manet@ietf.org
Subject: Re: [manet] RE: Gateway Advertisements
In-Reply-To: <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
	<1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr>
	<3D3C10DB.2F963AF6@iprg.nokia.com>
	<1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd)
 MULE/4.1 (AOI)
Organization: Keio University
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi, Guillaume

> 
> > > My opinion is that we should not split the gateway advertisement
> > > mechanism from the routing protocol. It is the protocol responsability to 
> > > propose a mechanism which allows a node to discover gateways and to manage 
> > > routes between nodes to gateways.
> > 
> > What about using a Router Discovery protocol extension that is not
> > specific to any routing protocol?  There is no reason such an approach is
> > wrong, a priori, although your statement would disallow it from
> > consideration.
> 
> I'm ok to say it is not wrong. However, I think the definition of a Router
> Discovery protocol should not prevent routing protocols to do Router Discovery
> if it can at low cost. It means to me that the independant Router Discovery
> protocol should not load the network if not needed or should not process if we
> don't want it to (some kind of passive mode). 
> 
> I also think such a document is interesting only if it is not restrictive in the
> way we use the protocol. A reative-only protocol is not satisfaying. As Fredrik
> states it, unsolicited advertisements may be interestings for many reasons, e.g.
> a better mobility support or global prefix advertisement.

We will revise the draft to support proactive protocols, too.

> Why not using some king of adaptation of the Router/Prefix  discovery protocol
> of IPv6 NDP (Neighbor Discovery Protocol) to ad hoc netorks. 

Because we believe NDP does not work with current rfc2461 on current MANET!
What kinds of adaptation? At least we need some agreement for this 
adaptations, otherwise we never have interoperability among
implementations. 

regards,
ryuji

> Basically, Routers are free to advertise or not. Routers must respond to
> solicitation. The protocol relies on ad hoc flooding. The maintenance of routes
> btw nodes and GW  remains the routing protocol work. This lets enough freedom to
> tune the protocol depending on what we want and on the MANet characteristics.
> 
> Regards, 
> Guillaume.
> 
> -----------------
> Guillaume Chelius
> PhD student
> Ares Team, Inria, Citi Insa-Lyon
> Tel: (+33) 472 436 421
> Email: gchelius@telecom.insa-lyon.fr
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 11:55:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08490
	for ; Mon, 22 Jul 2002 11:55:06 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA27910
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 11:56:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24879;
	Mon, 22 Jul 2002 11:28:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24840
	for ; Mon, 22 Jul 2002 11:28:09 -0400 (EDT)
Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07349
	for ; Mon, 22 Jul 2002 11:27:07 -0400 (EDT)
Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pddf66a.tkyoac00.ap.so-net.ne.jp [218.221.246.106])
	(authenticated bits=0)
	by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g6MFQvfg025447;
	Tue, 23 Jul 2002 00:26:57 +0900
Date: Tue, 23 Jul 2002 00:26:48 +0900
Message-ID: 
From: Ryuji Wakikawa
To: gchelius@telecom.insa-lyon.fr
Sent-via: gchelius@telecom.insa-lyon.fr
Cc: charliep@IPRG.nokia.com, Fredrik.Alriksson@era.ericsson.se, manet@ietf.org
Sent-via: charliep@IPRG.nokia.com,
	Fredrik.Alriksson@era.ericsson.se,
	manet@ietf.org
Subject: Re: [manet] RE: Gateway Advertisements
In-Reply-To: <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se>
	<1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr>
	<3D3C10DB.2F963AF6@iprg.nokia.com>
	<1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd)
 MULE/4.1 (AOI)
Organization: Keio University
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi, Guillaume

> 
> > > My opinion is that we should not split the gateway advertisement
> > > mechanism from the routing protocol. It is the protocol responsability to 
> > > propose a mechanism which allows a node to discover gateways and to manage 
> > > routes between nodes to gateways.
> > 
> > What about using a Router Discovery protocol extension that is not
> > specific to any routing protocol?  There is no reason such an approach is
> > wrong, a priori, although your statement would disallow it from
> > consideration.
> 
> I'm ok to say it is not wrong. However, I think the definition of a Router
> Discovery protocol should not prevent routing protocols to do Router Discovery
> if it can at low cost. It means to me that the independant Router Discovery
> protocol should not load the network if not needed or should not process if we
> don't want it to (some kind of passive mode). 
> 
> I also think such a document is interesting only if it is not restrictive in the
> way we use the protocol. A reative-only protocol is not satisfaying. As Fredrik
> states it, unsolicited advertisements may be interestings for many reasons, e.g.
> a better mobility support or global prefix advertisement.

We will revise the draft to support proactive protocols, too.

> Why not using some king of adaptation of the Router/Prefix  discovery protocol
> of IPv6 NDP (Neighbor Discovery Protocol) to ad hoc netorks. 

Because we believe NDP does not work with current rfc2461 on current MANET!
What kinds of adaptation? At least we need some agreement for this 
adaptations, otherwise we never have interoperability among
implementations. 

regards,
ryuji

> Basically, Routers are free to advertise or not. Routers must respond to
> solicitation. The protocol relies on ad hoc flooding. The maintenance of routes
> btw nodes and GW  remains the routing protocol work. This lets enough freedom to
> tune the protocol depending on what we want and on the MANet characteristics.
> 
> Regards, 
> Guillaume.
> 
> -----------------
> Guillaume Chelius
> PhD student
> Ares Team, Inria, Citi Insa-Lyon
> Tel: (+33) 472 436 421
> Email: gchelius@telecom.insa-lyon.fr
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 12:13:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09800
	for ; Mon, 22 Jul 2002 12:13:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27437;
	Mon, 22 Jul 2002 11:53:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27402
	for ; Mon, 22 Jul 2002 11:53:20 -0400 (EDT)
Received: from SMTP1.ECE.NEU.EDU (markov.ece.neu.edu [129.10.60.83])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08278
	for ; Mon, 22 Jul 2002 11:52:19 -0400 (EDT)
Received: from dharma.ece.neu.edu (dharma.ece.neu.edu [129.10.60.101])
	by SMTP1.ECE.NEU.EDU (8.11.3/8.11.3) with SMTP id g6MFrJ709948
	for ; Mon, 22 Jul 2002 11:53:19 -0400 (EDT)
Received: from bibbiena.ece.neu.edu ([129.10.60.216])
 by dharma.ece.neu.edu (NAVGW 2.5.2.9) with SMTP id M2002072211531927330
 ; Mon, 22 Jul 2002 11:53:19 -0400
Received: from localhost (basagni@localhost)
	by bibbiena.ece.neu.edu (8.11.6+Sun/8.9.3) with ESMTP id g6MFrIC01082;
	Mon, 22 Jul 2002 11:53:18 -0400 (EDT)
X-Authentication-Warning: bibbiena.ece.neu.edu: basagni owned process doing -bs
Date: Mon, 22 Jul 2002 11:53:18 -0400 (EDT)
From: Stefano Basagni 
X-X-Sender: basagni@bibbiena
To: manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] Papers on Scatternet Formation
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This mail is in reply to an e-mail of Samantha Arcidiacono who was
asking for papers on Bluetooth scatternet formation. It is also
addressed to all interested in scatternet formation.

There are a few recent works from our group you might be interested in.
Two of those are:

@InProceedings{BasagniP02,
  author =           {Basagni, S. and Petrioli, C.},
  title =            {A Scatternet Formation Protocol for Ad hoc Networks of
                     {B}luetooth Devices},
  booktitle = 	     {Proceedings of the IEEE Semiannual Vehicular
                      Technology Conference, VTC Spring 2002},
  year = 	     {2002},
  address =          {Birmingham, AL},
  month = 	     {May 6--9}
}

@InProceedings{PetrioliB02,
  author =           {Petrioli, C. and Basagni, S.},
  title =            {Degree-Constrained Multihop Scatternet Formation for
                     {B}luetooth Networks},
  booktitle = 	     {Proceedings of the IEEE Globecom 2002},
  year = 	     {2002},
  address =          {Taipei, Taiwan, R.O.C.},
  month = 	     {November 17--21}
}

Please let me know if you need an electronic copy. An extended version of
both papers have been accepted for publication in journals. Their final
versions will be available shortly.

Best, St.


--
Stefano Basagni, Ph.D.     Assistant Professor of Computer  Engineering
Dept. of Electrical and Computer Engineering   312 Dana Research Center
Northeastern University             360 Huntigton Ave. Boston, MA 02115
Tel. 617 373 3061, Fax 617 373 8970         E-mail: basagni@ece.neu.edu



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 12:13:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09808
	for ; Mon, 22 Jul 2002 12:13:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA04826
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 12:14:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27437;
	Mon, 22 Jul 2002 11:53:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27402
	for ; Mon, 22 Jul 2002 11:53:20 -0400 (EDT)
Received: from SMTP1.ECE.NEU.EDU (markov.ece.neu.edu [129.10.60.83])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08278
	for ; Mon, 22 Jul 2002 11:52:19 -0400 (EDT)
Received: from dharma.ece.neu.edu (dharma.ece.neu.edu [129.10.60.101])
	by SMTP1.ECE.NEU.EDU (8.11.3/8.11.3) with SMTP id g6MFrJ709948
	for ; Mon, 22 Jul 2002 11:53:19 -0400 (EDT)
Received: from bibbiena.ece.neu.edu ([129.10.60.216])
 by dharma.ece.neu.edu (NAVGW 2.5.2.9) with SMTP id M2002072211531927330
 ; Mon, 22 Jul 2002 11:53:19 -0400
Received: from localhost (basagni@localhost)
	by bibbiena.ece.neu.edu (8.11.6+Sun/8.9.3) with ESMTP id g6MFrIC01082;
	Mon, 22 Jul 2002 11:53:18 -0400 (EDT)
X-Authentication-Warning: bibbiena.ece.neu.edu: basagni owned process doing -bs
Date: Mon, 22 Jul 2002 11:53:18 -0400 (EDT)
From: Stefano Basagni 
X-X-Sender: basagni@bibbiena
To: manet@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [manet] Papers on Scatternet Formation
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This mail is in reply to an e-mail of Samantha Arcidiacono who was
asking for papers on Bluetooth scatternet formation. It is also
addressed to all interested in scatternet formation.

There are a few recent works from our group you might be interested in.
Two of those are:

@InProceedings{BasagniP02,
  author =           {Basagni, S. and Petrioli, C.},
  title =            {A Scatternet Formation Protocol for Ad hoc Networks of
                     {B}luetooth Devices},
  booktitle = 	     {Proceedings of the IEEE Semiannual Vehicular
                      Technology Conference, VTC Spring 2002},
  year = 	     {2002},
  address =          {Birmingham, AL},
  month = 	     {May 6--9}
}

@InProceedings{PetrioliB02,
  author =           {Petrioli, C. and Basagni, S.},
  title =            {Degree-Constrained Multihop Scatternet Formation for
                     {B}luetooth Networks},
  booktitle = 	     {Proceedings of the IEEE Globecom 2002},
  year = 	     {2002},
  address =          {Taipei, Taiwan, R.O.C.},
  month = 	     {November 17--21}
}

Please let me know if you need an electronic copy. An extended version of
both papers have been accepted for publication in journals. Their final
versions will be available shortly.

Best, St.


--
Stefano Basagni, Ph.D.     Assistant Professor of Computer  Engineering
Dept. of Electrical and Computer Engineering   312 Dana Research Center
Northeastern University             360 Huntigton Ave. Boston, MA 02115
Tel. 617 373 3061, Fax 617 373 8970         E-mail: basagni@ece.neu.edu



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 12:34:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12894
	for ; Mon, 22 Jul 2002 12:34:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02179;
	Mon, 22 Jul 2002 12:07:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02137
	for ; Mon, 22 Jul 2002 12:07:51 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09124
	for ; Mon, 22 Jul 2002 12:06:49 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id B793C13A2F; Mon, 22 Jul 2002 18:03:53 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id 3463C13A24; Mon, 22 Jul 2002 18:03:53 +0200 (CEST)
To: Charlie Perkins 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027353833.3d3c2ce92d7c6@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 18:03:53 +0200 (CEST)
From: Guillaume Chelius 
Cc: manet 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Charlie,

> It could also be configurable at the gateway.  I would consider
> that "passive" means "reactive", and the question of "reactive"
> vs. "proactive" has just been discussed.

Yes, passive means no unsolicited advertisement: reactive.

> This sounds a lot like draft-wakikawa, except that the flooding
> happens
> from the other way around.

Yes it does, except that it basically allows unsolicited router advertisements.

> I think the advantages of having default routes have been overlooked
> in this discussion.  For one thing, it allows automatic switching to a
> new gateway for many circumstances when a node moves closer to a
> different gateway than it formerly was using.

Please Correct me if I'm wrong, but one problem with default routes is that
they are not necessary the same on all nodes of a path to a default route. It
may lead to endless loops:
+ Node A has a default route to gateway X through node B
+ Node B has a default route to gateway Y through node C
+ Node C has a default route to gateway Z through node A
I agree this case is critical but it may occur.

More frequently, It may also lead to false IP-spoofing detection:
+ Node A has a default route to gateway X which advertises prefix M through
node B
+ Node B has a default route to gateway Z which advertises prefix N
Packets sent from node A with a source global address Prefix_M:ID_A  will be
routed to gateway Z instead of gateway X. But gateway Z will refuse the packet, 
considering it as IP spoofing since prefix M does not correspond to gateway Z


Of course, partial source routing correts these errors. But then, you loose the 
advantage you gave about default route.


A proactive or hybrid scheme may be interesting to handle these cases.

Regards,
Guillaume Chelius.
-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 12:34:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12904
	for ; Mon, 22 Jul 2002 12:34:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA23131
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 12:35:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02179;
	Mon, 22 Jul 2002 12:07:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02137
	for ; Mon, 22 Jul 2002 12:07:51 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09124
	for ; Mon, 22 Jul 2002 12:06:49 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id B793C13A2F; Mon, 22 Jul 2002 18:03:53 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id 3463C13A24; Mon, 22 Jul 2002 18:03:53 +0200 (CEST)
To: Charlie Perkins 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027353833.3d3c2ce92d7c6@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 18:03:53 +0200 (CEST)
From: Guillaume Chelius 
Cc: manet 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Charlie,

> It could also be configurable at the gateway.  I would consider
> that "passive" means "reactive", and the question of "reactive"
> vs. "proactive" has just been discussed.

Yes, passive means no unsolicited advertisement: reactive.

> This sounds a lot like draft-wakikawa, except that the flooding
> happens
> from the other way around.

Yes it does, except that it basically allows unsolicited router advertisements.

> I think the advantages of having default routes have been overlooked
> in this discussion.  For one thing, it allows automatic switching to a
> new gateway for many circumstances when a node moves closer to a
> different gateway than it formerly was using.

Please Correct me if I'm wrong, but one problem with default routes is that
they are not necessary the same on all nodes of a path to a default route. It
may lead to endless loops:
+ Node A has a default route to gateway X through node B
+ Node B has a default route to gateway Y through node C
+ Node C has a default route to gateway Z through node A
I agree this case is critical but it may occur.

More frequently, It may also lead to false IP-spoofing detection:
+ Node A has a default route to gateway X which advertises prefix M through
node B
+ Node B has a default route to gateway Z which advertises prefix N
Packets sent from node A with a source global address Prefix_M:ID_A  will be
routed to gateway Z instead of gateway X. But gateway Z will refuse the packet, 
considering it as IP spoofing since prefix M does not correspond to gateway Z


Of course, partial source routing correts these errors. But then, you loose the 
advantage you gave about default route.


A proactive or hybrid scheme may be interesting to handle these cases.

Regards,
Guillaume Chelius.
-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 12:37:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13340
	for ; Mon, 22 Jul 2002 12:37:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08108;
	Mon, 22 Jul 2002 12:18:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07983
	for ; Mon, 22 Jul 2002 12:17:59 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10386
	for ; Mon, 22 Jul 2002 12:16:56 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA05809;
	Mon, 22 Jul 2002 09:17:27 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6MGHQN21736;
	Mon, 22 Jul 2002 09:17:26 -0700
X-mProtect: <200207221617> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdxlB9P9; Mon, 22 Jul 2002 09:17:22 PDT
Message-ID: <3D3C2F89.675D9FDA@iprg.nokia.com>
Date: Mon, 22 Jul 2002 09:15:05 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Guillaume Chelius 
CC: Mobile Ad Hoc IETF working group 
Subject: Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Guillaume,

Guillaume Chelius wrote:

> Please Correct me if I'm wrong, but one problem with default routes is that
> they are not necessary the same on all nodes of a path to a default route. It
> may lead to endless loops:
> + Node A has a default route to gateway X through node B
> + Node B has a default route to gateway Y through node C
> + Node C has a default route to gateway Z through node A
> I agree this case is critical but it may occur.

With AODV or DSR this should never occur.

> More frequently, It may also lead to false IP-spoofing detection:
> + Node A has a default route to gateway X which advertises prefix M through
> node B
> + Node B has a default route to gateway Z which advertises prefix N
> Packets sent from node A with a source global address Prefix_M:ID_A  will be
> routed to gateway Z instead of gateway X. But gateway Z will refuse the packet,
> considering it as IP spoofing since prefix M does not correspond to gateway Z

This seems to depend on the gateways having certain inappropriate
behavior for ad hoc networks.

> Of course, partial source routing correts these errors. But then, you loose the
> advantage you gave about default route.

We're not sure how to get maximum benefit from default routes
in this case.

> A proactive or hybrid scheme may be interesting to handle these cases.

Agreed, but it's hard to know exactly the realm of beneficial applicability.

Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 12:37:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13349
	for ; Mon, 22 Jul 2002 12:37:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA25329
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 12:38:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08108;
	Mon, 22 Jul 2002 12:18:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07983
	for ; Mon, 22 Jul 2002 12:17:59 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10386
	for ; Mon, 22 Jul 2002 12:16:56 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA05809;
	Mon, 22 Jul 2002 09:17:27 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6MGHQN21736;
	Mon, 22 Jul 2002 09:17:26 -0700
X-mProtect: <200207221617> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.5.94, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdxlB9P9; Mon, 22 Jul 2002 09:17:22 PDT
Message-ID: <3D3C2F89.675D9FDA@iprg.nokia.com>
Date: Mon, 22 Jul 2002 09:15:05 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Guillaume Chelius 
CC: Mobile Ad Hoc IETF working group 
Subject: Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Guillaume,

Guillaume Chelius wrote:

> Please Correct me if I'm wrong, but one problem with default routes is that
> they are not necessary the same on all nodes of a path to a default route. It
> may lead to endless loops:
> + Node A has a default route to gateway X through node B
> + Node B has a default route to gateway Y through node C
> + Node C has a default route to gateway Z through node A
> I agree this case is critical but it may occur.

With AODV or DSR this should never occur.

> More frequently, It may also lead to false IP-spoofing detection:
> + Node A has a default route to gateway X which advertises prefix M through
> node B
> + Node B has a default route to gateway Z which advertises prefix N
> Packets sent from node A with a source global address Prefix_M:ID_A  will be
> routed to gateway Z instead of gateway X. But gateway Z will refuse the packet,
> considering it as IP spoofing since prefix M does not correspond to gateway Z

This seems to depend on the gateways having certain inappropriate
behavior for ad hoc networks.

> Of course, partial source routing correts these errors. But then, you loose the
> advantage you gave about default route.

We're not sure how to get maximum benefit from default routes
in this case.

> A proactive or hybrid scheme may be interesting to handle these cases.

Agreed, but it's hard to know exactly the realm of beneficial applicability.

Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 12:53:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15519
	for ; Mon, 22 Jul 2002 12:53:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19534;
	Mon, 22 Jul 2002 12:31:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19370
	for ; Mon, 22 Jul 2002 12:30:55 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12331
	for ; Mon, 22 Jul 2002 12:29:51 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Mon, 22 Jul 2002 10:30:44 -0600
Message-Id: <02Jul22.103044mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: =?iso-8859-1?Q?J=FCrgen_Nagler?= ,
        manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Mon, 22 Jul 2002 10:30:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA19379
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Jürgen,

Yes.  Also, if anybody else is considering this paper, I will point out that
all the cited references are in English.

:-)

John Mullen

-----Original Message-----
From: Jürgen Nagler [mailto:juergen.nagler@informatik.uni-ulm.de]
Sent: Thursday, July 18, 2002 1:38 AM
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode


Hi,

"Mullen, John P. (Contractor)" wrote:
> 
> I'm willing to give reading the paper a whack, but my German technical
> dictionary is very much outdated.  Can anyone recommend an up-to-date
> technical reference?

as John already found out by reading our paper the technical expressions
in the network field almost have no German translation :-)


Regards,

Jürgen Nagler


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 12:53:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15529
	for ; Mon, 22 Jul 2002 12:53:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA08512
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 12:54:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19534;
	Mon, 22 Jul 2002 12:31:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19370
	for ; Mon, 22 Jul 2002 12:30:55 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12331
	for ; Mon, 22 Jul 2002 12:29:51 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Mon, 22 Jul 2002 10:30:44 -0600
Message-Id: <02Jul22.103044mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: =?iso-8859-1?Q?J=FCrgen_Nagler?= ,
        manet@ietf.org
Subject: RE: [manet] promiscuous mode
Date:  Mon, 22 Jul 2002 10:30:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA19379
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Jürgen,

Yes.  Also, if anybody else is considering this paper, I will point out that
all the cited references are in English.

:-)

John Mullen

-----Original Message-----
From: Jürgen Nagler [mailto:juergen.nagler@informatik.uni-ulm.de]
Sent: Thursday, July 18, 2002 1:38 AM
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode


Hi,

"Mullen, John P. (Contractor)" wrote:
> 
> I'm willing to give reading the paper a whack, but my German technical
> dictionary is very much outdated.  Can anyone recommend an up-to-date
> technical reference?

as John already found out by reading our paper the technical expressions
in the network field almost have no German translation :-)


Regards,

Jürgen Nagler


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 13:05:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16944
	for ; Mon, 22 Jul 2002 13:05:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04743;
	Mon, 22 Jul 2002 12:49:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04594
	for ; Mon, 22 Jul 2002 12:49:28 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14846
	for ; Mon, 22 Jul 2002 12:48:26 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Mon, 22 Jul 2002 10:49:20 -0600
Message-Id: <02Jul22.104920mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "'manet@ietf.org'" 
Date:  Mon, 22 Jul 2002 10:49:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] Concerning reactive protocols
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Gradually, as I read the recent posts, I've formed a question.


In a reactive protocol, a node will request a route when it wishes to send a
message to another node.  This has been shown to be efficient, at least for
some MANETs because the increased latency is more than offset by the lower
routing overhead and smaller memory demands at each node.

However, how does the sending node know the receiving node is there?

I'm not speaking of a partition here, but a situation in which a node that
represents a resource, such as access to the Internet, emergency assistance,
technical advice, telephone modem, printer, etc., which may or may not be
present in a particular MANET.  Even if present, the sending node would only
know the node's function, not its IP address.

I hesitate to suggest the MANET equivalent of Spam, but would it be
appropriate for such special nodes to send out some sort of beacon to
advertise both their IP and the useful resource available at that IP, even
if the underlying protocol is reactive?

I suppose an alternative could be to have a RREQ for any node with a given
capability, rather than a specific IP address.

John Mullen


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 13:05:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16958
	for ; Mon, 22 Jul 2002 13:05:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA17719
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 13:06:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04743;
	Mon, 22 Jul 2002 12:49:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04594
	for ; Mon, 22 Jul 2002 12:49:28 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14846
	for ; Mon, 22 Jul 2002 12:48:26 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117121>; Mon, 22 Jul 2002 10:49:20 -0600
Message-Id: <02Jul22.104920mdt.117121@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: "'manet@ietf.org'" 
Date:  Mon, 22 Jul 2002 10:49:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] Concerning reactive protocols
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Gradually, as I read the recent posts, I've formed a question.


In a reactive protocol, a node will request a route when it wishes to send a
message to another node.  This has been shown to be efficient, at least for
some MANETs because the increased latency is more than offset by the lower
routing overhead and smaller memory demands at each node.

However, how does the sending node know the receiving node is there?

I'm not speaking of a partition here, but a situation in which a node that
represents a resource, such as access to the Internet, emergency assistance,
technical advice, telephone modem, printer, etc., which may or may not be
present in a particular MANET.  Even if present, the sending node would only
know the node's function, not its IP address.

I hesitate to suggest the MANET equivalent of Spam, but would it be
appropriate for such special nodes to send out some sort of beacon to
advertise both their IP and the useful resource available at that IP, even
if the underlying protocol is reactive?

I suppose an alternative could be to have a RREQ for any node with a given
capability, rather than a specific IP address.

John Mullen


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 13:13:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17801
	for ; Mon, 22 Jul 2002 13:13:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08869;
	Mon, 22 Jul 2002 12:54:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08757
	for ; Mon, 22 Jul 2002 12:54:34 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15575
	for ; Mon, 22 Jul 2002 12:53:31 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 34D2A13A40; Mon, 22 Jul 2002 18:51:16 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id A5506139FC; Mon, 22 Jul 2002 18:51:15 +0200 (CEST)
To: Charlie Perkins 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027356675.3d3c38039dca6@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 18:51:15 +0200 (CEST)
From: Guillaume Chelius 
Cc: Guillaume Chelius ,
        Mobile Ad Hoc IETF working group 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D3C2F89.675D9FDA@iprg.nokia.com>
In-Reply-To: <3D3C2F89.675D9FDA@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Charlie, 

> > Please Correct me if I'm wrong, but one problem with default routes is
> > that they are not necessary the same on all nodes of a path to a default
> > route. It may lead to endless loops:
> > + Node A has a default route to gateway X through node B
> > + Node B has a default route to gateway Y through node C
> > + Node C has a default route to gateway Z through node A
> > I agree this case is critical but it may occur.
> 
> With AODV or DSR this should never occur.

I agree.

> > More frequently, It may also lead to false IP-spoofing detection:
> > + Node A has a default route to gateway X which advertises prefix M
> > through node B
> > + Node B has a default route to gateway Z which advertises prefix N
> > Packets sent from node A with a source global address Prefix_M:ID_A 
> > will be routed to gateway Z instead of gateway X. But gateway Z will refuse
> > the packet, considering it as IP spoofing since prefix M does not 
> > correspond to gateway Z
> 
> This seems to depend on the gateways having certain inappropriate
> behavior for ad hoc networks.

I disagree on this point. There is no reason for an ad hoc network not to be 
connected to several "classical" networks. This is a normal situation and even 
something we may desire. In this case, Gateways  naturally advertise different 
prefixes. It is also legitimate for gateways to filter packets depending on the 
source address. You do not want your network to be the source for IP spoofing 
attacks, specially in ad hoc networks where you have not necessary an idea 
about who is connected to you. You can not also ask your gateway to accept 
addresses with other ad hoc advertised prefixes (not advertised by you). First, 
this set of prefixes change depending on the MANet connectivity. Second, it is 
a seurity hole since, for example, an ad hoc node may not be authorized to use 
the corresponding prefix.

In this situation, the false IP Spoofing detection I described may easily 
occur. 

> > Of course, partial source routing correts these errors. But then, you
> > loose the advantage you gave about default route.
> 
> We're not sure how to get maximum benefit from default routes
> in this case.
> 
> > A proactive or hybrid scheme may be interesting to handle these
> > cases.
> 
> Agreed, but it's hard to know exactly the realm of beneficial
> applicability.

I agree and I think this is a good reason not to prohibit proactive or hybrid 
schemes. 

Regards,
Guillaume Chelius.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 22 13:13:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17808
	for ; Mon, 22 Jul 2002 13:13:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA23231
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 13:14:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08869;
	Mon, 22 Jul 2002 12:54:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08757
	for ; Mon, 22 Jul 2002 12:54:34 -0400 (EDT)
Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15575
	for ; Mon, 22 Jul 2002 12:53:31 -0400 (EDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tc-mail.insa-lyon.fr (Postfix) with ESMTP
	id 34D2A13A40; Mon, 22 Jul 2002 18:51:16 +0200 (CEST)
Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151)
	id A5506139FC; Mon, 22 Jul 2002 18:51:15 +0200 (CEST)
To: Charlie Perkins 
Subject: Re: [manet] RE: Gateway Advertisements
Message-ID: <1027356675.3d3c38039dca6@tc-mail.insa-lyon.fr>
Date: Mon, 22 Jul 2002 18:51:15 +0200 (CEST)
From: Guillaume Chelius 
Cc: Guillaume Chelius ,
        Mobile Ad Hoc IETF working group 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D3C2F89.675D9FDA@iprg.nokia.com>
In-Reply-To: <3D3C2F89.675D9FDA@iprg.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Virus-Scanned: by AMaViS snapshot-20020300
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hello Charlie, 

> > Please Correct me if I'm wrong, but one problem with default routes is
> > that they are not necessary the same on all nodes of a path to a default
> > route. It may lead to endless loops:
> > + Node A has a default route to gateway X through node B
> > + Node B has a default route to gateway Y through node C
> > + Node C has a default route to gateway Z through node A
> > I agree this case is critical but it may occur.
> 
> With AODV or DSR this should never occur.

I agree.

> > More frequently, It may also lead to false IP-spoofing detection:
> > + Node A has a default route to gateway X which advertises prefix M
> > through node B
> > + Node B has a default route to gateway Z which advertises prefix N
> > Packets sent from node A with a source global address Prefix_M:ID_A 
> > will be routed to gateway Z instead of gateway X. But gateway Z will refuse
> > the packet, considering it as IP spoofing since prefix M does not 
> > correspond to gateway Z
> 
> This seems to depend on the gateways having certain inappropriate
> behavior for ad hoc networks.

I disagree on this point. There is no reason for an ad hoc network not to be 
connected to several "classical" networks. This is a normal situation and even 
something we may desire. In this case, Gateways  naturally advertise different 
prefixes. It is also legitimate for gateways to filter packets depending on the 
source address. You do not want your network to be the source for IP spoofing 
attacks, specially in ad hoc networks where you have not necessary an idea 
about who is connected to you. You can not also ask your gateway to accept 
addresses with other ad hoc advertised prefixes (not advertised by you). First, 
this set of prefixes change depending on the MANet connectivity. Second, it is 
a seurity hole since, for example, an ad hoc node may not be authorized to use 
the corresponding prefix.

In this situation, the false IP Spoofing detection I described may easily 
occur. 

> > Of course, partial source routing correts these errors. But then, you
> > loose the advantage you gave about default route.
> 
> We're not sure how to get maximum benefit from default routes
> in this case.
> 
> > A proactive or hybrid scheme may be interesting to handle these
> > cases.
> 
> Agreed, but it's hard to know exactly the realm of beneficial
> applicability.

I agree and I think this is a good reason not to prohibit proactive or hybrid 
schemes. 

Regards,
Guillaume Chelius.

-----------------
Guillaume Chelius
PhD student
Ares Team, Inria, Citi Insa-Lyon
Tel: (+33) 472 436 421
Email: gchelius@telecom.insa-lyon.fr

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 22 16:08:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04551
	for ; Mon, 22 Jul 2002 16:08:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12200;
	Mon, 22 Jul 2002 15:38:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12100
	for ; Mon, 22 Jul 2002 15:38:08 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01691
	for ; Mon, 22 Jul 2002 15:37:05 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF2603D0; Mon, 22 Jul 2002 15:37:48 -0400
Message-ID: <00ec01c231b7$42cf4010$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Mobile Ad Hoc IETF working group" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D3C2F89.675D9FDA@iprg.nokia.com> <1027356675.3d3c38039dca6@tc-mail.insa-lyon.fr>
Subject: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
Date: Mon, 22 Jul 2002 15:37:48 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

This is a long thread, but I have burning questions with respect to bridging AODV
with OSPF.

The AODV draft 11 does not specifically say what a mobile router is to do with
ICMP Router Discovery messages.  Specifically, it does not address the ICMP
Router Advertisements or Router Solicitation messages that will be multicast
ICMP broadcasts as used by OSPF, BGP, etc.  Right?

I propose that as an ad hoc network node detects that its current default fixed
network routing connection is failing (a matter of debate in PILC, mobileip,
seamoby, etc), that it mcast a ICMP Router Solicatation.  Furthermore, I recommend
that this ICMP have its TTL value set to 5 (or any other configurable value) (and be
interpreted as a hop count) by AODV  nodes.  This will allow the Router
Solicitation to hit a piece of OSPF,  BGP4, EIGRP, ISIS, etc. infrastructure within
5 hops from the mobile.  I believe this simple procedure would allow OSPF to be 
bridged in a natural way with AODV.  I am thinking that OSPF infrastructure equipment
will need to keep a route for each mobile seperately, since the definition of a subnet
in a mobile IP enabled MANET is quite far from being useable.   The OSPF router
may maintain its default 7 to 10 minute advertisement rate and it will also use a TTL
of 5 that is interpreted by AODV to mean hop count.  Does this make sense?

Since RFC-1256 is routing protocol agnostic this should work to bridge BGP with
AODV, AODV with DSR, or any other routing protocol to any other right?

To me this makes more sense than trying to get multi-hop (tunnelled) OSPF wiretapping
working over AODV.

Thanks,

Phil


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Mon Jul 22 16:54:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04557
	for ; Mon, 22 Jul 2002 16:08:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA27978
	for manet-archive@odin.ietf.org; Mon, 22 Jul 2002 16:09:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12200;
	Mon, 22 Jul 2002 15:38:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12100
	for ; Mon, 22 Jul 2002 15:38:08 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01691
	for ; Mon, 22 Jul 2002 15:37:05 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF2603D0; Mon, 22 Jul 2002 15:37:48 -0400
Message-ID: <00ec01c231b7$42cf4010$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Mobile Ad Hoc IETF working group" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D3C2F89.675D9FDA@iprg.nokia.com> <1027356675.3d3c38039dca6@tc-mail.insa-lyon.fr>
Subject: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
Date: Mon, 22 Jul 2002 15:37:48 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

This is a long thread, but I have burning questions with respect to bridging AODV
with OSPF.

The AODV draft 11 does not specifically say what a mobile router is to do with
ICMP Router Discovery messages.  Specifically, it does not address the ICMP
Router Advertisements or Router Solicitation messages that will be multicast
ICMP broadcasts as used by OSPF, BGP, etc.  Right?

I propose that as an ad hoc network node detects that its current default fixed
network routing connection is failing (a matter of debate in PILC, mobileip,
seamoby, etc), that it mcast a ICMP Router Solicatation.  Furthermore, I recommend
that this ICMP have its TTL value set to 5 (or any other configurable value) (and be
interpreted as a hop count) by AODV  nodes.  This will allow the Router
Solicitation to hit a piece of OSPF,  BGP4, EIGRP, ISIS, etc. infrastructure within
5 hops from the mobile.  I believe this simple procedure would allow OSPF to be 
bridged in a natural way with AODV.  I am thinking that OSPF infrastructure equipment
will need to keep a route for each mobile seperately, since the definition of a subnet
in a mobile IP enabled MANET is quite far from being useable.   The OSPF router
may maintain its default 7 to 10 minute advertisement rate and it will also use a TTL
of 5 that is interpreted by AODV to mean hop count.  Does this make sense?

Since RFC-1256 is routing protocol agnostic this should work to bridge BGP with
AODV, AODV with DSR, or any other routing protocol to any other right?

To me this makes more sense than trying to get multi-hop (tunnelled) OSPF wiretapping
working over AODV.

Thanks,

Phil


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 23 10:28:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13628
	for ; Tue, 23 Jul 2002 10:28:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12099;
	Tue, 23 Jul 2002 10:02:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12072
	for ; Tue, 23 Jul 2002 10:02:09 -0400 (EDT)
Received: from mail.informatik.uni-ulm.de (mail.informatik.uni-ulm.de [134.60.68.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12462
	for ; Tue, 23 Jul 2002 10:01:06 -0400 (EDT)
Received: from brandung.informatik.uni-ulm.de ([134.60.70.41] helo=informatik.uni-ulm.de)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.33 #1)
	id 17X0Ep-0007TR-00
	for manet@ietf.org; Tue, 23 Jul 2002 16:02:07 +0200
Message-ID: <3D3D619C.F20D69D@informatik.uni-ulm.de>
Date: Tue, 23 Jul 2002 16:01:00 +0200
From: =?iso-8859-1?Q?J=FCrgen?= Nagler 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode
References: <02Jul22.103044mdt.117121@gw.trac.wsmr.army.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

We now have a preliminary English version of our paper at
http://medien.informatik.uni-ulm.de/~frank/research/manetframework.pdf


Regards,
Jürgen Nagler

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 23 10:28:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13637
	for ; Tue, 23 Jul 2002 10:28:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13478
	for manet-archive@odin.ietf.org; Tue, 23 Jul 2002 10:29:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12099;
	Tue, 23 Jul 2002 10:02:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12072
	for ; Tue, 23 Jul 2002 10:02:09 -0400 (EDT)
Received: from mail.informatik.uni-ulm.de (mail.informatik.uni-ulm.de [134.60.68.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12462
	for ; Tue, 23 Jul 2002 10:01:06 -0400 (EDT)
Received: from brandung.informatik.uni-ulm.de ([134.60.70.41] helo=informatik.uni-ulm.de)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.33 #1)
	id 17X0Ep-0007TR-00
	for manet@ietf.org; Tue, 23 Jul 2002 16:02:07 +0200
Message-ID: <3D3D619C.F20D69D@informatik.uni-ulm.de>
Date: Tue, 23 Jul 2002 16:01:00 +0200
From: =?iso-8859-1?Q?J=FCrgen?= Nagler 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: manet@ietf.org
Subject: Re: [manet] promiscuous mode
References: <02Jul22.103044mdt.117121@gw.trac.wsmr.army.mil>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

We now have a preliminary English version of our paper at
http://medien.informatik.uni-ulm.de/~frank/research/manetframework.pdf


Regards,
Jürgen Nagler

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 23 11:35:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18221
	for ; Tue, 23 Jul 2002 11:35:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16454;
	Tue, 23 Jul 2002 11:02:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16428
	for ; Tue, 23 Jul 2002 11:02:25 -0400 (EDT)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15836
	for ; Tue, 23 Jul 2002 11:01:23 -0400 (EDT)
Received: from zephyrin (cedricadjih1.inria.fr [128.93.23.31])
	by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g6NF1qT01357;
	Tue, 23 Jul 2002 17:01:52 +0200 (MET DST)
Message-ID: <001901c2325d$266b2aa0$1f175d80@inria.fr>
From: "Philippe Jacquet" 
To: 
Cc: 
References: <200207141505.IAA15632@pit.erg.sri.com>
Subject: Re: [manet] New OLSR draft 
Date: Tue, 23 Jul 2002 17:25:17 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: 
To: 
Cc: 
Sent: Sunday, July 14, 2002 5:05 PM
Subject: Re: [manet] New OLSR draft


>
> The new OLSR parameter TC_REDUNDANCY results in additional
> topology information being reported (up to the full topology).
> Since TBRPF already allowed additional topology information
> to be reported, I'm glad to see that INRIA agrees with us.
>
Not really. As far as I understand TBRPF, an extra link is known by a remote
known only if there exists a chain of nodes from this link to the remote
node where all nodes agree adding this extra link in their respective
reported link sets.  In absence of a specified consensus protocol this may
be difficult to implement. In OLSR only the node which owns the link needs
to decide to advertize it or not. Adding extra links in the TC may be
triggered by local considerations such as:
-    willingness to act as a router
-    unreliable links needing back-up links
In the limit, the nodes can advertize their full neighborhood leading to
full topology knowledge in the network as with OSPF. The TC are greater and
similar to OSPF LSA, but the bandwidth is still saved since only MPRs
forward the information. The credits for this nice idea are to Joe Macker.

> However, I do not see an *efficient* method for reporting
> sufficient topology information to provide each node with
> two disjoint paths to each destination (without providing
> each node with the full topology).  Setting MPR_COVERAGE
> to 2 does provide each node with two disjoint paths to each
> destination (if such paths exist), but not only does it
> double the number of links flooded, it also doubles the
> number of MPRs that need to forward each TC message,
> which seems to multiply the TC overhead by 4.
> (In TBRPF, the factor is 2 since the number of nodes
> reporting each update does not increase.)
> Since our ns-2 simulations show that OLSR generates more than
> twice as much overhead as TBRPF, this would likely give TBRPF
> an even bigger advantage in overhead.
>
Not exactly. The MPR_COVERAGE parameter is about the broadcast reliability
over MPRs. If the links to your MPRs are not reliable enough, then you may
need redundant MPR sets. The problem may be more critical for TBRPF since
you have less flexibility in parent selection (always select the node with
the smallest ID). Maybe it can be solved by selecting the k-smallest ID node
as parent, with k=MPR_COVERAGE.

Thank you for your interesting comment.

Regards,

Philippe



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 23 11:35:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18229
	for ; Tue, 23 Jul 2002 11:35:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA19772
	for manet-archive@odin.ietf.org; Tue, 23 Jul 2002 11:36:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16454;
	Tue, 23 Jul 2002 11:02:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16428
	for ; Tue, 23 Jul 2002 11:02:25 -0400 (EDT)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15836
	for ; Tue, 23 Jul 2002 11:01:23 -0400 (EDT)
Received: from zephyrin (cedricadjih1.inria.fr [128.93.23.31])
	by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g6NF1qT01357;
	Tue, 23 Jul 2002 17:01:52 +0200 (MET DST)
Message-ID: <001901c2325d$266b2aa0$1f175d80@inria.fr>
From: "Philippe Jacquet" 
To: 
Cc: 
References: <200207141505.IAA15632@pit.erg.sri.com>
Subject: Re: [manet] New OLSR draft 
Date: Tue, 23 Jul 2002 17:25:17 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: 
To: 
Cc: 
Sent: Sunday, July 14, 2002 5:05 PM
Subject: Re: [manet] New OLSR draft


>
> The new OLSR parameter TC_REDUNDANCY results in additional
> topology information being reported (up to the full topology).
> Since TBRPF already allowed additional topology information
> to be reported, I'm glad to see that INRIA agrees with us.
>
Not really. As far as I understand TBRPF, an extra link is known by a remote
known only if there exists a chain of nodes from this link to the remote
node where all nodes agree adding this extra link in their respective
reported link sets.  In absence of a specified consensus protocol this may
be difficult to implement. In OLSR only the node which owns the link needs
to decide to advertize it or not. Adding extra links in the TC may be
triggered by local considerations such as:
-    willingness to act as a router
-    unreliable links needing back-up links
In the limit, the nodes can advertize their full neighborhood leading to
full topology knowledge in the network as with OSPF. The TC are greater and
similar to OSPF LSA, but the bandwidth is still saved since only MPRs
forward the information. The credits for this nice idea are to Joe Macker.

> However, I do not see an *efficient* method for reporting
> sufficient topology information to provide each node with
> two disjoint paths to each destination (without providing
> each node with the full topology).  Setting MPR_COVERAGE
> to 2 does provide each node with two disjoint paths to each
> destination (if such paths exist), but not only does it
> double the number of links flooded, it also doubles the
> number of MPRs that need to forward each TC message,
> which seems to multiply the TC overhead by 4.
> (In TBRPF, the factor is 2 since the number of nodes
> reporting each update does not increase.)
> Since our ns-2 simulations show that OLSR generates more than
> twice as much overhead as TBRPF, this would likely give TBRPF
> an even bigger advantage in overhead.
>
Not exactly. The MPR_COVERAGE parameter is about the broadcast reliability
over MPRs. If the links to your MPRs are not reliable enough, then you may
need redundant MPR sets. The problem may be more critical for TBRPF since
you have less flexibility in parent selection (always select the node with
the smallest ID). Maybe it can be solved by selecting the k-smallest ID node
as parent, with k=MPR_COVERAGE.

Thank you for your interesting comment.

Regards,

Philippe



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 23 15:17:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00278
	for ; Tue, 23 Jul 2002 15:17:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07767;
	Tue, 23 Jul 2002 14:51:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07734
	for ; Tue, 23 Jul 2002 14:51:25 -0400 (EDT)
Received: from che.onthejob.net (che.onthejob.net [63.146.38.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28812
	for ; Tue, 23 Jul 2002 14:50:21 -0400 (EDT)
Received: (from dyoung@localhost)
	by che.onthejob.net (8.9.3/8.9.3) id NAA00483
	for manet@ietf.org; Tue, 23 Jul 2002 13:50:47 -0500
Date: Tue, 23 Jul 2002 13:50:47 -0500
From: David Young 
To: manet@ietf.org
Message-ID: <20020723135047.A31977@che.onthejob.net>
Reply-To: dyoung@pobox.com
Mail-Followup-To: David Young , manet@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [manet] research for ad hoc community networks?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


In my community, a small band of community organizers and computer geeks
is trying to build a community network using inexpensive 802.11 radios. I
feel certain that our success will depend on our adoption of ad hoc
networking principles: We do not anticipate the magnitude of private
or governmental investment that will help us afford to individually
configure stations on the network, to buy space on radio towers for
wireless base stations, to point antennas from rooftop to base station,
or to administrate hundreds or thousands of stations. But with stations
that auto-configure their IP numbers, that tolerate ever-changing link
topologies, that discover and choose Internet gateways, we will be able to
build a network by modest expenditures (such as the cost of a computer,
radio, and omni antenna) and we will keep network administration costs
under control.

As I read the commercial literature and the scientific literature
on ad hoc networks, I am struck by two things:

 * it is difficult (for me) to infer from a routing protocol's performance
   in a "random waypoint" test how it will perform on rooftops in compact,
   semi-wooded neighborhoods of two-story homes

 * insofar as "rooftop networks" have been deployed, it is only by
   commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
   use technologies that are trade secrets, so I can draw no conclusions
   from their experience

I have the ear of some researchers in ad hoc networks on this mailing
list, so I ask you, are they any of your findings that speak directly to
the problem of networking communities from rooftops?

Will anyone advocate for a particular combination of protocols to build
a rooftop network?

Dave

-- 
David Young             OJC Technologies
dyoung@onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Tue Jul 23 15:17:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00292
	for ; Tue, 23 Jul 2002 15:17:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10265
	for manet-archive@odin.ietf.org; Tue, 23 Jul 2002 15:18:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07767;
	Tue, 23 Jul 2002 14:51:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07734
	for ; Tue, 23 Jul 2002 14:51:25 -0400 (EDT)
Received: from che.onthejob.net (che.onthejob.net [63.146.38.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28812
	for ; Tue, 23 Jul 2002 14:50:21 -0400 (EDT)
Received: (from dyoung@localhost)
	by che.onthejob.net (8.9.3/8.9.3) id NAA00483
	for manet@ietf.org; Tue, 23 Jul 2002 13:50:47 -0500
Date: Tue, 23 Jul 2002 13:50:47 -0500
From: David Young 
To: manet@ietf.org
Message-ID: <20020723135047.A31977@che.onthejob.net>
Reply-To: dyoung@pobox.com
Mail-Followup-To: David Young , manet@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [manet] research for ad hoc community networks?
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


In my community, a small band of community organizers and computer geeks
is trying to build a community network using inexpensive 802.11 radios. I
feel certain that our success will depend on our adoption of ad hoc
networking principles: We do not anticipate the magnitude of private
or governmental investment that will help us afford to individually
configure stations on the network, to buy space on radio towers for
wireless base stations, to point antennas from rooftop to base station,
or to administrate hundreds or thousands of stations. But with stations
that auto-configure their IP numbers, that tolerate ever-changing link
topologies, that discover and choose Internet gateways, we will be able to
build a network by modest expenditures (such as the cost of a computer,
radio, and omni antenna) and we will keep network administration costs
under control.

As I read the commercial literature and the scientific literature
on ad hoc networks, I am struck by two things:

 * it is difficult (for me) to infer from a routing protocol's performance
   in a "random waypoint" test how it will perform on rooftops in compact,
   semi-wooded neighborhoods of two-story homes

 * insofar as "rooftop networks" have been deployed, it is only by
   commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
   use technologies that are trade secrets, so I can draw no conclusions
   from their experience

I have the ear of some researchers in ad hoc networks on this mailing
list, so I ask you, are they any of your findings that speak directly to
the problem of networking communities from rooftops?

Will anyone advocate for a particular combination of protocols to build
a rooftop network?

Dave

-- 
David Young             OJC Technologies
dyoung@onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 23 15:40:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01346
	for ; Tue, 23 Jul 2002 15:40:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10526;
	Tue, 23 Jul 2002 15:24:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10502
	for ; Tue, 23 Jul 2002 15:24:21 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00476
	for ; Tue, 23 Jul 2002 15:23:19 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF260PPN; Tue, 23 Jul 2002 15:24:02 -0400
Message-ID: <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: , 
References: <20020723135047.A31977@che.onthejob.net>
Subject: Re: [manet] research for ad hoc community networks?
Date: Tue, 23 Jul 2002 15:24:02 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Dave,

A questions for you.

1).  Do you expect this network to provide access to mobiles (i.e. wireless devices
       in cars) or pedestrian mobiles?  

The reason I ask is, 802.11b does not work well at all for mobile devices.

Other comments below...

----- Original Message ----- 
From: "David Young" 
To: 
Sent: Tuesday, July 23, 2002 2:50 PM
Subject: [manet] research for ad hoc community networks?

> As I read the commercial literature and the scientific literature
> on ad hoc networks, I am struck by two things:
> 
>  * it is difficult (for me) to infer from a routing protocol's performance
>    in a "random waypoint" test how it will perform on rooftops in compact,
>    semi-wooded neighborhoods of two-story homes

If you used 802.11b outdoors, not very well.  You can use an effective radiated
power of (ERP) of 4 watt out of an omni antenna.  If you do the path loss equations
at 2.5 GHz you see your range will be somewhat limited.  Also it will be 
greatly affected by multi-path and foliage loss so higher data rates will become
unuseable pretty rapidly. 

With 802.11b we have measured about 1 dB of loss / meter through trees and 
vegetation here in Florida (this is a HEAVY foliage environment).  In your lightly
wooded scenario, 802.11b may do a bit better.  There is not a whole lot of 
"free" 2.4 GHz channel sounder information available for various propagation 
morphologies, something that could greatly enhance your success.

> 
>  * insofar as "rooftop networks" have been deployed, it is only by
>    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
>    use technologies that are trade secrets, so I can draw no conclusions
>    from their experience

We (MeshNetworks) support many different radios.  Our patented radio technology
and  proprietary stuff (patent pending) are radios that work better in outdoor
multi-path fading environments at higher data rates (have RAKE and doppler
compensation for high speed mobiles).  

> I have the ear of some researchers in ad hoc networks on this mailing
> list, so I ask you, are they any of your findings that speak directly to
> the problem of networking communities from rooftops?

Range will be a problem.  Security will be a problem.  Also, the telcos are trying
to squeeze money out of "free" spectrum by disallowing DSL/Cable backhaul.
I can't wait till that hits the courts see http://www.tmcnet.com/tmcnet/columns/laura071902.htm

> Will anyone advocate for a particular combination of protocols to build
> a rooftop network?

I believe Rooftop uses RIP, but their system is not truly ad hoc (or mobile) and
is intended for stationary subscribers.  I also believe it using 802.11 (original not
8 but the 2 Mbps FHSS radios).  There may be a possibility to use our products,
but some of the "carrier class" stuff would be of no use to you.  I would recommend
you start out on a small scale and do some measurements of your own.  I think you will
be disatisfied with the acheivable range of 802.11b on omnis pretty quickly.  This means
you will have to deploy more infrastructure then you might have wanted to.  As for
protocols, I recommend AODV or DSR.  I am sure that there are lots of people on 
the list (also read the archives) that would be happy to recommend one over the
other to you! :-)

Cheers!

Phil Neumiller


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Tue Jul 23 15:40:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01353
	for ; Tue, 23 Jul 2002 15:40:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA12629
	for manet-archive@odin.ietf.org; Tue, 23 Jul 2002 15:41:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10526;
	Tue, 23 Jul 2002 15:24:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10502
	for ; Tue, 23 Jul 2002 15:24:21 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00476
	for ; Tue, 23 Jul 2002 15:23:19 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF260PPN; Tue, 23 Jul 2002 15:24:02 -0400
Message-ID: <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: , 
References: <20020723135047.A31977@che.onthejob.net>
Subject: Re: [manet] research for ad hoc community networks?
Date: Tue, 23 Jul 2002 15:24:02 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Dave,

A questions for you.

1).  Do you expect this network to provide access to mobiles (i.e. wireless devices
       in cars) or pedestrian mobiles?  

The reason I ask is, 802.11b does not work well at all for mobile devices.

Other comments below...

----- Original Message ----- 
From: "David Young" 
To: 
Sent: Tuesday, July 23, 2002 2:50 PM
Subject: [manet] research for ad hoc community networks?

> As I read the commercial literature and the scientific literature
> on ad hoc networks, I am struck by two things:
> 
>  * it is difficult (for me) to infer from a routing protocol's performance
>    in a "random waypoint" test how it will perform on rooftops in compact,
>    semi-wooded neighborhoods of two-story homes

If you used 802.11b outdoors, not very well.  You can use an effective radiated
power of (ERP) of 4 watt out of an omni antenna.  If you do the path loss equations
at 2.5 GHz you see your range will be somewhat limited.  Also it will be 
greatly affected by multi-path and foliage loss so higher data rates will become
unuseable pretty rapidly. 

With 802.11b we have measured about 1 dB of loss / meter through trees and 
vegetation here in Florida (this is a HEAVY foliage environment).  In your lightly
wooded scenario, 802.11b may do a bit better.  There is not a whole lot of 
"free" 2.4 GHz channel sounder information available for various propagation 
morphologies, something that could greatly enhance your success.

> 
>  * insofar as "rooftop networks" have been deployed, it is only by
>    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
>    use technologies that are trade secrets, so I can draw no conclusions
>    from their experience

We (MeshNetworks) support many different radios.  Our patented radio technology
and  proprietary stuff (patent pending) are radios that work better in outdoor
multi-path fading environments at higher data rates (have RAKE and doppler
compensation for high speed mobiles).  

> I have the ear of some researchers in ad hoc networks on this mailing
> list, so I ask you, are they any of your findings that speak directly to
> the problem of networking communities from rooftops?

Range will be a problem.  Security will be a problem.  Also, the telcos are trying
to squeeze money out of "free" spectrum by disallowing DSL/Cable backhaul.
I can't wait till that hits the courts see http://www.tmcnet.com/tmcnet/columns/laura071902.htm

> Will anyone advocate for a particular combination of protocols to build
> a rooftop network?

I believe Rooftop uses RIP, but their system is not truly ad hoc (or mobile) and
is intended for stationary subscribers.  I also believe it using 802.11 (original not
8 but the 2 Mbps FHSS radios).  There may be a possibility to use our products,
but some of the "carrier class" stuff would be of no use to you.  I would recommend
you start out on a small scale and do some measurements of your own.  I think you will
be disatisfied with the acheivable range of 802.11b on omnis pretty quickly.  This means
you will have to deploy more infrastructure then you might have wanted to.  As for
protocols, I recommend AODV or DSR.  I am sure that there are lots of people on 
the list (also read the archives) that would be happy to recommend one over the
other to you! :-)

Cheers!

Phil Neumiller


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 23 17:33:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04842
	for ; Tue, 23 Jul 2002 17:33:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18702;
	Tue, 23 Jul 2002 17:10:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18680
	for ; Tue, 23 Jul 2002 17:10:08 -0400 (EDT)
Received: from lax-gate5.raytheon.com (lax-gate5.raytheon.com [199.46.200.234])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04271
	for ; Tue, 23 Jul 2002 17:09:05 -0400 (EDT)
Received: from ds02w00.directory.ray.com (ds02w00.directory.ray.com [147.25.146.118])
	by lax-gate5.raytheon.com (8.12.5/8.12.5) with ESMTP id g6NLA06w014061;
	Tue, 23 Jul 2002 14:10:00 -0700 (PDT)
Received: from ds02w00.directory.ray.com (root@localhost)
	by ds02w00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g6NL9wxv018756;
	Tue, 23 Jul 2002 14:09:58 -0700 (PDT)
Received: from mailhub.fal.us.ray.com (mailhub.fal.us.ray.com [147.18.176.59])
	by ds02w00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g6NL9rar018693;
	Tue, 23 Jul 2002 14:09:57 -0700 (PDT)
Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31])
	by mailhub.fal.us.ray.com (8.9.3/8.9.3) with ESMTP id RAA07656;
	Tue, 23 Jul 2002 17:07:14 -0400 (EDT)
Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Jul 2002 17:07:15 -0400
Message-ID: <72F06A8F0165D611AD2A00508BCFF60003537510@fcexchange.fal.us.ray.com>
From: "Su, William" 
To: mullenjp.contractor@trac.wsmr.army.mil
Cc: manet@ietf.org
Subject: RE: [manet] Concerning reactive protocols
Date: Tue, 23 Jul 2002 17:07:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi John,

"Mullen, John P. (Contractor)" wrote:

>
>I hesitate to suggest the MANET equivalent of Spam, but would it be
>appropriate for such special nodes to send out some sort of beacon to
>advertise both their IP and the useful resource available at that IP, even
>if the underlying protocol is reactive?
>
>I suppose an alternative could be to have a RREQ for any node with a given
>capability, rather than a specific IP address.
>

If I understand your description correctly , I believe what you're looking
for is anycast.  Some example work include the NRL ARMS project, see
http://tonnant.itd.nrl.navy.mil/anycast/arms.html.


Bill


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Tue Jul 23 17:33:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04849
	for ; Tue, 23 Jul 2002 17:33:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20404
	for manet-archive@odin.ietf.org; Tue, 23 Jul 2002 17:34:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18702;
	Tue, 23 Jul 2002 17:10:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18680
	for ; Tue, 23 Jul 2002 17:10:08 -0400 (EDT)
Received: from lax-gate5.raytheon.com (lax-gate5.raytheon.com [199.46.200.234])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04271
	for ; Tue, 23 Jul 2002 17:09:05 -0400 (EDT)
Received: from ds02w00.directory.ray.com (ds02w00.directory.ray.com [147.25.146.118])
	by lax-gate5.raytheon.com (8.12.5/8.12.5) with ESMTP id g6NLA06w014061;
	Tue, 23 Jul 2002 14:10:00 -0700 (PDT)
Received: from ds02w00.directory.ray.com (root@localhost)
	by ds02w00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g6NL9wxv018756;
	Tue, 23 Jul 2002 14:09:58 -0700 (PDT)
Received: from mailhub.fal.us.ray.com (mailhub.fal.us.ray.com [147.18.176.59])
	by ds02w00.directory.ray.com (8.12.1/8.12.1) with ESMTP id g6NL9rar018693;
	Tue, 23 Jul 2002 14:09:57 -0700 (PDT)
Received: from fcexchange.fal.us.ray.com (fcexchange.fal.us.ray.com [147.18.176.31])
	by mailhub.fal.us.ray.com (8.9.3/8.9.3) with ESMTP id RAA07656;
	Tue, 23 Jul 2002 17:07:14 -0400 (EDT)
Received: by fcexchange.fal.us.ray.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Jul 2002 17:07:15 -0400
Message-ID: <72F06A8F0165D611AD2A00508BCFF60003537510@fcexchange.fal.us.ray.com>
From: "Su, William" 
To: mullenjp.contractor@trac.wsmr.army.mil
Cc: manet@ietf.org
Subject: RE: [manet] Concerning reactive protocols
Date: Tue, 23 Jul 2002 17:07:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi John,

"Mullen, John P. (Contractor)" wrote:

>
>I hesitate to suggest the MANET equivalent of Spam, but would it be
>appropriate for such special nodes to send out some sort of beacon to
>advertise both their IP and the useful resource available at that IP, even
>if the underlying protocol is reactive?
>
>I suppose an alternative could be to have a RREQ for any node with a given
>capability, rather than a specific IP address.
>

If I understand your description correctly , I believe what you're looking
for is anycast.  Some example work include the NRL ARMS project, see
http://tonnant.itd.nrl.navy.mil/anycast/arms.html.


Bill


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 01:34:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16029
	for ; Wed, 24 Jul 2002 01:34:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18034;
	Wed, 24 Jul 2002 01:20:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18003
	for ; Wed, 24 Jul 2002 01:20:36 -0400 (EDT)
Received: from ep_mailout1 ([203.254.224.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15589
	for ; Wed, 24 Jul 2002 01:19:32 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 id <0GZQ00M01MX7QL@mailout1.samsung.com> for manet@ietf.org; Wed,
 24 Jul 2002 14:22:19 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZQ00M2WMX6KS@mailout1.samsung.com> for manet@ietf.org; Wed,
 24 Jul 2002 14:22:18 +0900 (KST)
Received: from zbin ([75.2.47.220])
 by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTPA id <0GZQ00283MXCXU@mmp2.samsung.com> for manet@ietf.org; Wed,
 24 Jul 2002 14:22:24 +0900 (KST)
Date: Wed, 24 Jul 2002 14:22:21 +0900
From: zb 
Subject: [manet] how does ad hoc network do something?
To: manet@ietf.org
Message-id: <005101c232d2$170c2cb0$dc2f024b@zbin>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20020723135047.A31977@che.onthejob.net>
 <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com>
Content-Transfer-Encoding: 7BIT
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7BIT

Hi,

I have a question on how does the ad hoc network begin to work? When device
A and device B are in a MANET, they do not know IP address and service
ability of each other. There can be multihop between device A and device B.
How does the device A know it can get required service from device B and
communicate with device B?

Thanx.

bin
*************************************
Zhen Bin

i-Networking lab,
Samsung Advanced Institute of Technology,
San14-1, NongSeo-ri, Kiheung-Eup,
Yongin, Kyungki-do, 440600, Korea

82-31-2809569 (fax)
82-31-2809534 (o)
82-31-2122268 (h)
*************************************



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Wed Jul 24 01:34:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16038
	for ; Wed, 24 Jul 2002 01:34:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA19473
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 01:35:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18034;
	Wed, 24 Jul 2002 01:20:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18003
	for ; Wed, 24 Jul 2002 01:20:36 -0400 (EDT)
Received: from ep_mailout1 ([203.254.224.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15589
	for ; Wed, 24 Jul 2002 01:19:32 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 id <0GZQ00M01MX7QL@mailout1.samsung.com> for manet@ietf.org; Wed,
 24 Jul 2002 14:22:19 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZQ00M2WMX6KS@mailout1.samsung.com> for manet@ietf.org; Wed,
 24 Jul 2002 14:22:18 +0900 (KST)
Received: from zbin ([75.2.47.220])
 by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTPA id <0GZQ00283MXCXU@mmp2.samsung.com> for manet@ietf.org; Wed,
 24 Jul 2002 14:22:24 +0900 (KST)
Date: Wed, 24 Jul 2002 14:22:21 +0900
From: zb 
Subject: [manet] how does ad hoc network do something?
To: manet@ietf.org
Message-id: <005101c232d2$170c2cb0$dc2f024b@zbin>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20020723135047.A31977@che.onthejob.net>
 <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com>
Content-Transfer-Encoding: 7BIT
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7BIT

Hi,

I have a question on how does the ad hoc network begin to work? When device
A and device B are in a MANET, they do not know IP address and service
ability of each other. There can be multihop between device A and device B.
How does the device A know it can get required service from device B and
communicate with device B?

Thanx.

bin
*************************************
Zhen Bin

i-Networking lab,
Samsung Advanced Institute of Technology,
San14-1, NongSeo-ri, Kiheung-Eup,
Yongin, Kyungki-do, 440600, Korea

82-31-2809569 (fax)
82-31-2809534 (o)
82-31-2122268 (h)
*************************************



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Wed Jul 24 08:34:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09775
	for ; Wed, 24 Jul 2002 08:34:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA21117
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 08:35:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18028;
	Wed, 24 Jul 2002 08:14:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17975
	for ; Wed, 24 Jul 2002 08:13:56 -0400 (EDT)
Received: from smtp.web.de (smtp02.web.de [217.72.192.151])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03878
	for ; Wed, 24 Jul 2002 08:12:51 -0400 (EDT)
Received: from [217.227.149.95] (helo=navayo)
	by smtp.web.de with esmtp (WEB.DE(Exim) 4.75 #2)
	id 17XIyU-0006PZ-00; Wed, 24 Jul 2002 12:02:30 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Frank Dinies 
To: zb 
Subject: Re: [manet] how does ad hoc network do something?
Date: Wed, 24 Jul 2002 12:01:41 +0200
User-Agent: KMail/1.4.2
References: <20020723135047.A31977@che.onthejob.net> <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com> <005101c232d2$170c2cb0$dc2f024b@zbin>
In-Reply-To: <005101c232d2$170c2cb0$dc2f024b@zbin>
Cc: manet@ietf.org
MIME-Version: 1.0
Message-Id: <200207241201.42027.FrankDinies@web.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA17979
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly because 
this algorithmens rely on periodically sent advertisments. So after a short 
boot-up-time, when a new device wants to participate, it knows about his 
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens  this is not true. This 
algorithmens rely on special information or mechanismens for the boot-uptime 
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid 
change and much participants. On-demand-ones roughly for the contrary. For 
sensors that transmit from time to time small amounts of data for example is 
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem 
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22 schrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 09:34:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09769
	for ; Wed, 24 Jul 2002 08:34:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18028;
	Wed, 24 Jul 2002 08:14:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17975
	for ; Wed, 24 Jul 2002 08:13:56 -0400 (EDT)
Received: from smtp.web.de (smtp02.web.de [217.72.192.151])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03878
	for ; Wed, 24 Jul 2002 08:12:51 -0400 (EDT)
Received: from [217.227.149.95] (helo=navayo)
	by smtp.web.de with esmtp (WEB.DE(Exim) 4.75 #2)
	id 17XIyU-0006PZ-00; Wed, 24 Jul 2002 12:02:30 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Frank Dinies 
To: zb 
Subject: Re: [manet] how does ad hoc network do something?
Date: Wed, 24 Jul 2002 12:01:41 +0200
User-Agent: KMail/1.4.2
References: <20020723135047.A31977@che.onthejob.net> <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com> <005101c232d2$170c2cb0$dc2f024b@zbin>
In-Reply-To: <005101c232d2$170c2cb0$dc2f024b@zbin>
Cc: manet@ietf.org
MIME-Version: 1.0
Message-Id: <200207241201.42027.FrankDinies@web.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA17979
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly because 
this algorithmens rely on periodically sent advertisments. So after a short 
boot-up-time, when a new device wants to participate, it knows about his 
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens  this is not true. This 
algorithmens rely on special information or mechanismens for the boot-uptime 
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid 
change and much participants. On-demand-ones roughly for the contrary. For 
sensors that transmit from time to time small amounts of data for example is 
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem 
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22 schrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Wed Jul 24 09:43:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16462
	for ; Wed, 24 Jul 2002 09:43:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24694;
	Wed, 24 Jul 2002 09:27:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24616
	for ; Wed, 24 Jul 2002 09:27:00 -0400 (EDT)
Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [192.80.55.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15383
	for ; Wed, 24 Jul 2002 09:25:55 -0400 (EDT)
Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4])
	by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g6ODQwL12986
	for ; Wed, 24 Jul 2002 09:26:58 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18])
	by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g6ODQvl19970
	for ; Wed, 24 Jul 2002 09:26:57 -0400 (EDT)
Received: from cbrooks.mitre.org (128.29.222.142) by mailhub2.mitre.org with SMTP
        id 10936547; Wed, 24 Jul 2002 09:26:50 -0400
Message-ID: <3D3EAD6A.42FB5498@mitre.org>
Date: Wed, 24 Jul 2002 09:36:43 -0400
From: Charles Brooks 
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.78 [en]C-20010724M  (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: manet@ietf.org
Content-Type: multipart/mixed;
 boundary="------------B5B932046870BA751341E72A"
Subject: [manet] Simulation Models for Ad Hoc Multicast Routing
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.
--------------B5B932046870BA751341E72A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

My organization has been tasked to do a simulation-based comparative
evaluation of ad hoc multicast routing protocols for use in tactical
(military) communications.  For this study we're looking to leverage
existing simulation models (preferably OPNET models) of ad hoc multicast
routing protocols, particularly ADMR and CAMP.

Does anyone know of existing simulation models?  Any leads towards
obtaining these models would be greatly appreciated.

Thanks in advance,
-Charles
--------------B5B932046870BA751341E72A
Content-Type: text/x-vcard; charset=us-ascii;
 name="cbrooks.vcf"
Content-Description: Card for Charles Brooks
Content-Disposition: attachment;
 filename="cbrooks.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Brooks;Charles
tel;fax:(732) 389-6761
tel;work:(732) 544-6265
x-mozilla-html:FALSE
org:The MITRE Corporation;W302 - Comms and Networks
adr:;;12 Christopher Way;Eatontown;NJ;07724;USA
version:2.1
email;internet:cbrooks@mitre.org
title:Lead Communcations Eng.
fn:Dr. Charles A. Brooks
end:vcard

--------------B5B932046870BA751341E72A--



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 24 09:43:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16471
	for ; Wed, 24 Jul 2002 09:43:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA26570
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 09:45:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24694;
	Wed, 24 Jul 2002 09:27:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24616
	for ; Wed, 24 Jul 2002 09:27:00 -0400 (EDT)
Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [192.80.55.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15383
	for ; Wed, 24 Jul 2002 09:25:55 -0400 (EDT)
Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4])
	by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g6ODQwL12986
	for ; Wed, 24 Jul 2002 09:26:58 -0400 (EDT)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18])
	by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g6ODQvl19970
	for ; Wed, 24 Jul 2002 09:26:57 -0400 (EDT)
Received: from cbrooks.mitre.org (128.29.222.142) by mailhub2.mitre.org with SMTP
        id 10936547; Wed, 24 Jul 2002 09:26:50 -0400
Message-ID: <3D3EAD6A.42FB5498@mitre.org>
Date: Wed, 24 Jul 2002 09:36:43 -0400
From: Charles Brooks 
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.78 [en]C-20010724M  (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: manet@ietf.org
Content-Type: multipart/mixed;
 boundary="------------B5B932046870BA751341E72A"
Subject: [manet] Simulation Models for Ad Hoc Multicast Routing
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.
--------------B5B932046870BA751341E72A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

My organization has been tasked to do a simulation-based comparative
evaluation of ad hoc multicast routing protocols for use in tactical
(military) communications.  For this study we're looking to leverage
existing simulation models (preferably OPNET models) of ad hoc multicast
routing protocols, particularly ADMR and CAMP.

Does anyone know of existing simulation models?  Any leads towards
obtaining these models would be greatly appreciated.

Thanks in advance,
-Charles
--------------B5B932046870BA751341E72A
Content-Type: text/x-vcard; charset=us-ascii;
 name="cbrooks.vcf"
Content-Description: Card for Charles Brooks
Content-Disposition: attachment;
 filename="cbrooks.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Brooks;Charles
tel;fax:(732) 389-6761
tel;work:(732) 544-6265
x-mozilla-html:FALSE
org:The MITRE Corporation;W302 - Comms and Networks
adr:;;12 Christopher Way;Eatontown;NJ;07724;USA
version:2.1
email;internet:cbrooks@mitre.org
title:Lead Communcations Eng.
fn:Dr. Charles A. Brooks
end:vcard

--------------B5B932046870BA751341E72A--



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 10:55:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20205
	for ; Wed, 24 Jul 2002 10:55:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28978;
	Wed, 24 Jul 2002 10:29:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28910
	for ; Wed, 24 Jul 2002 10:28:55 -0400 (EDT)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18842
	for ; Wed, 24 Jul 2002 10:27:52 -0400 (EDT)
Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58])
	by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g6OESJH12479;
	Wed, 24 Jul 2002 16:28:19 +0200 (MET DST)
Message-ID: <002501c23321$a0c81640$3ac033c1@inria.fr>
From: "Philippe Jacquet" 
To: , 
References: <20020723135047.A31977@che.onthejob.net>
Subject: Re: [manet] research for ad hoc community networks?
Date: Wed, 24 Jul 2002 16:51:43 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Dave,

I think there are many communities using IEEE 802.11b. For example look at
wireless seattle (dev@seattlewireless.net). It seems that the technology
works well enough for them. You may need high gain antennas sometimes (far
roofs).
A priori I don't see any problem with ad hoc architecture, but to my
knowledge it will be the first time it will be used in a community. I don't
see any specific problem in the choice of the routing protocol (you will
fight more with
the deployment than with the routing protocol). AODV has probably the more
choice in available codes. I have a secret preference for proactive
protocols (e.g. OLSR) because they are easier to deploy and are more
compatible with existing internet technology (IP stack, etc).

Regards,
Philippe
----- Original Message -----
From: David Young 
To: 
Sent: Tuesday, July 23, 2002 8:50 PM
Subject: [manet] research for ad hoc community networks?


>
> In my community, a small band of community organizers and computer geeks
> is trying to build a community network using inexpensive 802.11 radios. I
> feel certain that our success will depend on our adoption of ad hoc
> networking principles: We do not anticipate the magnitude of private
> or governmental investment that will help us afford to individually
> configure stations on the network, to buy space on radio towers for
> wireless base stations, to point antennas from rooftop to base station,
> or to administrate hundreds or thousands of stations. But with stations
> that auto-configure their IP numbers, that tolerate ever-changing link
> topologies, that discover and choose Internet gateways, we will be able to
> build a network by modest expenditures (such as the cost of a computer,
> radio, and omni antenna) and we will keep network administration costs
> under control.
>
> As I read the commercial literature and the scientific literature
> on ad hoc networks, I am struck by two things:
>
>  * it is difficult (for me) to infer from a routing protocol's performance
>    in a "random waypoint" test how it will perform on rooftops in compact,
>    semi-wooded neighborhoods of two-story homes
>
>  * insofar as "rooftop networks" have been deployed, it is only by
>    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
>    use technologies that are trade secrets, so I can draw no conclusions
>    from their experience
>
> I have the ear of some researchers in ad hoc networks on this mailing
> list, so I ask you, are they any of your findings that speak directly to
> the problem of networking communities from rooftops?
>
> Will anyone advocate for a particular combination of protocols to build
> a rooftop network?
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung@onthejob.net     Engineering from the Right Brain
>                         Urbana, IL * (217) 278-3933
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 24 10:55:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20213
	for ; Wed, 24 Jul 2002 10:55:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA01212
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 10:56:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28978;
	Wed, 24 Jul 2002 10:29:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28910
	for ; Wed, 24 Jul 2002 10:28:55 -0400 (EDT)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18842
	for ; Wed, 24 Jul 2002 10:27:52 -0400 (EDT)
Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58])
	by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g6OESJH12479;
	Wed, 24 Jul 2002 16:28:19 +0200 (MET DST)
Message-ID: <002501c23321$a0c81640$3ac033c1@inria.fr>
From: "Philippe Jacquet" 
To: , 
References: <20020723135047.A31977@che.onthejob.net>
Subject: Re: [manet] research for ad hoc community networks?
Date: Wed, 24 Jul 2002 16:51:43 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Dave,

I think there are many communities using IEEE 802.11b. For example look at
wireless seattle (dev@seattlewireless.net). It seems that the technology
works well enough for them. You may need high gain antennas sometimes (far
roofs).
A priori I don't see any problem with ad hoc architecture, but to my
knowledge it will be the first time it will be used in a community. I don't
see any specific problem in the choice of the routing protocol (you will
fight more with
the deployment than with the routing protocol). AODV has probably the more
choice in available codes. I have a secret preference for proactive
protocols (e.g. OLSR) because they are easier to deploy and are more
compatible with existing internet technology (IP stack, etc).

Regards,
Philippe
----- Original Message -----
From: David Young 
To: 
Sent: Tuesday, July 23, 2002 8:50 PM
Subject: [manet] research for ad hoc community networks?


>
> In my community, a small band of community organizers and computer geeks
> is trying to build a community network using inexpensive 802.11 radios. I
> feel certain that our success will depend on our adoption of ad hoc
> networking principles: We do not anticipate the magnitude of private
> or governmental investment that will help us afford to individually
> configure stations on the network, to buy space on radio towers for
> wireless base stations, to point antennas from rooftop to base station,
> or to administrate hundreds or thousands of stations. But with stations
> that auto-configure their IP numbers, that tolerate ever-changing link
> topologies, that discover and choose Internet gateways, we will be able to
> build a network by modest expenditures (such as the cost of a computer,
> radio, and omni antenna) and we will keep network administration costs
> under control.
>
> As I read the commercial literature and the scientific literature
> on ad hoc networks, I am struck by two things:
>
>  * it is difficult (for me) to infer from a routing protocol's performance
>    in a "random waypoint" test how it will perform on rooftops in compact,
>    semi-wooded neighborhoods of two-story homes
>
>  * insofar as "rooftop networks" have been deployed, it is only by
>    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
>    use technologies that are trade secrets, so I can draw no conclusions
>    from their experience
>
> I have the ear of some researchers in ad hoc networks on this mailing
> list, so I ask you, are they any of your findings that speak directly to
> the problem of networking communities from rooftops?
>
> Will anyone advocate for a particular combination of protocols to build
> a rooftop network?
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung@onthejob.net     Engineering from the Right Brain
>                         Urbana, IL * (217) 278-3933
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 12:38:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23346
	for ; Wed, 24 Jul 2002 12:38:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07613;
	Wed, 24 Jul 2002 12:19:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07584
	for ; Wed, 24 Jul 2002 12:19:11 -0400 (EDT)
Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22713
	for ; Wed, 24 Jul 2002 12:18:07 -0400 (EDT)
Received: from adhoc.rhod.uc.edu (adhoc.rhod.uc.edu [10.63.10.100])
	by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g6OGIamM029637;
	Wed, 24 Jul 2002 12:18:36 -0400 (EDT)
Received: from localhost (jains@localhost)
	by adhoc.rhod.uc.edu (8.11.6/8.9.1) with ESMTP id g6OGIZx10472;
	Wed, 24 Jul 2002 12:18:35 -0400
X-Authentication-Warning: adhoc.rhod.uc.edu: jains owned process doing -bs
Date: Wed, 24 Jul 2002 12:18:35 -0400 (EDT)
From: Saurabh Jain 
X-X-Sender: jains@adhoc.rhod.uc.edu
To: dyoung@pobox.com
cc: manet@ietf.org
Subject: Re: [manet] research for ad hoc community networks?
In-Reply-To: <20020723135047.A31977@che.onthejob.net>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dave

I suggest you view the Master's thesis of Benjamin A. Chambers. It's title
is "The Grid Roofnet: a Rooftop Ad Hoc Wireless Network". He has worked on
community ad hoc networks, using the Grid routing system. The thesis is
available for download from the Grid website at
http://www.pdos.lcs.mit.edu/grid/

Regards,
Saurabh

On Tue, 23 Jul 2002, David Young wrote:

> 
> In my community, a small band of community organizers and computer geeks
> is trying to build a community network using inexpensive 802.11 radios. I
> feel certain that our success will depend on our adoption of ad hoc
> networking principles: We do not anticipate the magnitude of private
> or governmental investment that will help us afford to individually
> configure stations on the network, to buy space on radio towers for
> wireless base stations, to point antennas from rooftop to base station,
> or to administrate hundreds or thousands of stations. But with stations
> that auto-configure their IP numbers, that tolerate ever-changing link
> topologies, that discover and choose Internet gateways, we will be able to
> build a network by modest expenditures (such as the cost of a computer,
> radio, and omni antenna) and we will keep network administration costs
> under control.
> 
> As I read the commercial literature and the scientific literature
> on ad hoc networks, I am struck by two things:
> 
>  * it is difficult (for me) to infer from a routing protocol's performance
>    in a "random waypoint" test how it will perform on rooftops in compact,
>    semi-wooded neighborhoods of two-story homes
> 
>  * insofar as "rooftop networks" have been deployed, it is only by
>    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
>    use technologies that are trade secrets, so I can draw no conclusions
>    from their experience
> 
> I have the ear of some researchers in ad hoc networks on this mailing
> list, so I ask you, are they any of your findings that speak directly to
> the problem of networking communities from rooftops?
> 
> Will anyone advocate for a particular combination of protocols to build
> a rooftop network?
> 
> Dave
> 
> -- 
> David Young             OJC Technologies
> dyoung@onthejob.net     Engineering from the Right Brain
>                         Urbana, IL * (217) 278-3933
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
saurabh@ee.iitm.ernet.in    Home: +1-513-556-7447, Lab: 556-3437
#511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219
SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42
Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 24 13:34:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23353
	for ; Wed, 24 Jul 2002 12:38:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA09467
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 12:39:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07613;
	Wed, 24 Jul 2002 12:19:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07584
	for ; Wed, 24 Jul 2002 12:19:11 -0400 (EDT)
Received: from mail.ececs.uc.edu (ececs.uc.edu [129.137.4.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22713
	for ; Wed, 24 Jul 2002 12:18:07 -0400 (EDT)
Received: from adhoc.rhod.uc.edu (adhoc.rhod.uc.edu [10.63.10.100])
	by mail.ececs.uc.edu (8.12.3/8.12.2) with ESMTP id g6OGIamM029637;
	Wed, 24 Jul 2002 12:18:36 -0400 (EDT)
Received: from localhost (jains@localhost)
	by adhoc.rhod.uc.edu (8.11.6/8.9.1) with ESMTP id g6OGIZx10472;
	Wed, 24 Jul 2002 12:18:35 -0400
X-Authentication-Warning: adhoc.rhod.uc.edu: jains owned process doing -bs
Date: Wed, 24 Jul 2002 12:18:35 -0400 (EDT)
From: Saurabh Jain 
X-X-Sender: jains@adhoc.rhod.uc.edu
To: dyoung@pobox.com
cc: manet@ietf.org
Subject: Re: [manet] research for ad hoc community networks?
In-Reply-To: <20020723135047.A31977@che.onthejob.net>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Dave

I suggest you view the Master's thesis of Benjamin A. Chambers. It's title
is "The Grid Roofnet: a Rooftop Ad Hoc Wireless Network". He has worked on
community ad hoc networks, using the Grid routing system. The thesis is
available for download from the Grid website at
http://www.pdos.lcs.mit.edu/grid/

Regards,
Saurabh

On Tue, 23 Jul 2002, David Young wrote:

> 
> In my community, a small band of community organizers and computer geeks
> is trying to build a community network using inexpensive 802.11 radios. I
> feel certain that our success will depend on our adoption of ad hoc
> networking principles: We do not anticipate the magnitude of private
> or governmental investment that will help us afford to individually
> configure stations on the network, to buy space on radio towers for
> wireless base stations, to point antennas from rooftop to base station,
> or to administrate hundreds or thousands of stations. But with stations
> that auto-configure their IP numbers, that tolerate ever-changing link
> topologies, that discover and choose Internet gateways, we will be able to
> build a network by modest expenditures (such as the cost of a computer,
> radio, and omni antenna) and we will keep network administration costs
> under control.
> 
> As I read the commercial literature and the scientific literature
> on ad hoc networks, I am struck by two things:
> 
>  * it is difficult (for me) to infer from a routing protocol's performance
>    in a "random waypoint" test how it will perform on rooftops in compact,
>    semi-wooded neighborhoods of two-story homes
> 
>  * insofar as "rooftop networks" have been deployed, it is only by
>    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
>    use technologies that are trade secrets, so I can draw no conclusions
>    from their experience
> 
> I have the ear of some researchers in ad hoc networks on this mailing
> list, so I ask you, are they any of your findings that speak directly to
> the problem of networking communities from rooftops?
> 
> Will anyone advocate for a particular combination of protocols to build
> a rooftop network?
> 
> Dave
> 
> -- 
> David Young             OJC Technologies
> dyoung@onthejob.net     Engineering from the Right Brain
>                         Urbana, IL * (217) 278-3933
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
saurabh@ee.iitm.ernet.in    Home: +1-513-556-7447, Lab: 556-3437
#511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219
SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42
Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 16:31:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01629
	for ; Wed, 24 Jul 2002 16:31:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21029;
	Wed, 24 Jul 2002 15:57:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21000
	for ; Wed, 24 Jul 2002 15:57:36 -0400 (EDT)
Received: from smtp.web.de (smtp03.web.de [217.72.192.158])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00049
	for ; Wed, 24 Jul 2002 15:56:31 -0400 (EDT)
Received: from [217.227.149.95] (helo=navayo)
	by smtp.web.de with esmtp (WEB.DE(Exim) 4.75 #2)
	id 17XOUl-0005Ym-00; Wed, 24 Jul 2002 17:56:11 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Frank Dinies 
To: Einar Vollset 
Subject: Re: [manet] how does ad hoc network do something?
Date: Wed, 24 Jul 2002 17:55:23 +0200
User-Agent: KMail/1.4.2
References: <3D3E98EE@webmail.ncl.ac.uk>
In-Reply-To: <3D3E98EE@webmail.ncl.ac.uk>
Cc: manet@ietf.org
MIME-Version: 1.0
Message-Id: <200207241755.23122.FrankDinies@web.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA21001
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Einar,

have you seen the approach from Fisheye-State-Routing ? It is a proactive 
algorithmen with maintains a global routing table. But it maintains the 
information in respect to the distance. To do this it sends periodically 
beacons to its neighbours only. Every neighbour accumulates this information 
and send the information in different update times. Information about nearer 
nodes much more often than information about nodes farer away. In this way 
this algorithmen scales pretty well with large networks and positionchanges 
not nescessarily triggers update information. 

On-demand protocols have the problem the route-prechaching is unsufficient for 
high mobility. Another point is that a route could even be absolute before a 
sender gets the route-information back.

unfortunalety there is no silver bullet for all kind of situations ;)

regards

frank     


> Hi Frank,
>
> >But keep in mind. Proactive algorithmens are best in enviroments with
> > rapid change and much participants. On-demand-ones roughly for the
> > contrary. For sensors that transmit from time to time small amounts of
> > data for example is an on-demand-one perfect.
>
> I was under the impression that it was the other way around, with proactive
> protocols performing worse in environments with rapid change, as the
> overhead with maintaining the (global) routing information would be
> prohibitive. Where as an on-demand protocol would perform better in this
> scenario?
>
> Or am I confused? :-)
>
> Cheers,
>
> Einar


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 24 16:31:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01638
	for ; Wed, 24 Jul 2002 16:31:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA23447
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 16:32:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21029;
	Wed, 24 Jul 2002 15:57:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21000
	for ; Wed, 24 Jul 2002 15:57:36 -0400 (EDT)
Received: from smtp.web.de (smtp03.web.de [217.72.192.158])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00049
	for ; Wed, 24 Jul 2002 15:56:31 -0400 (EDT)
Received: from [217.227.149.95] (helo=navayo)
	by smtp.web.de with esmtp (WEB.DE(Exim) 4.75 #2)
	id 17XOUl-0005Ym-00; Wed, 24 Jul 2002 17:56:11 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Frank Dinies 
To: Einar Vollset 
Subject: Re: [manet] how does ad hoc network do something?
Date: Wed, 24 Jul 2002 17:55:23 +0200
User-Agent: KMail/1.4.2
References: <3D3E98EE@webmail.ncl.ac.uk>
In-Reply-To: <3D3E98EE@webmail.ncl.ac.uk>
Cc: manet@ietf.org
MIME-Version: 1.0
Message-Id: <200207241755.23122.FrankDinies@web.de>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA21001
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

Hi Einar,

have you seen the approach from Fisheye-State-Routing ? It is a proactive 
algorithmen with maintains a global routing table. But it maintains the 
information in respect to the distance. To do this it sends periodically 
beacons to its neighbours only. Every neighbour accumulates this information 
and send the information in different update times. Information about nearer 
nodes much more often than information about nodes farer away. In this way 
this algorithmen scales pretty well with large networks and positionchanges 
not nescessarily triggers update information. 

On-demand protocols have the problem the route-prechaching is unsufficient for 
high mobility. Another point is that a route could even be absolute before a 
sender gets the route-information back.

unfortunalety there is no silver bullet for all kind of situations ;)

regards

frank     


> Hi Frank,
>
> >But keep in mind. Proactive algorithmens are best in enviroments with
> > rapid change and much participants. On-demand-ones roughly for the
> > contrary. For sensors that transmit from time to time small amounts of
> > data for example is an on-demand-one perfect.
>
> I was under the impression that it was the other way around, with proactive
> protocols performing worse in environments with rapid change, as the
> overhead with maintaining the (global) routing information would be
> prohibitive. Where as an on-demand protocol would perform better in this
> scenario?
>
> Or am I confused? :-)
>
> Cheers,
>
> Einar


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 18:27:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04304
	for ; Wed, 24 Jul 2002 18:27:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28367;
	Wed, 24 Jul 2002 17:58:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28338
	for ; Wed, 24 Jul 2002 17:57:56 -0400 (EDT)
Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03568
	for ; Wed, 24 Jul 2002 17:56:51 -0400 (EDT)
Received: from CASABLANCA.ccs.neu.edu (crypt.ccs.neu.edu [129.10.115.162])
	by amber.ccs.neu.edu (Postfix) with ESMTP
	id 3B96A1AA22; Wed, 24 Jul 2002 17:57:53 -0400 (EDT)
Message-Id: <5.0.2.1.0.20020724174459.0253fca0@mail.ccs.neu.edu>
X-Sender: noubir@mail.ccs.neu.edu
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 24 Jul 2002 17:47:57 -0400
To: manet@ietf.org
From: "G. Noubir" 
Cc: Nitin H Vaidya 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [manet] Preliminary Program: ACM Workshop on Wireless Security (WiSe)
 [in conjunction with MobiCom'02]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--------------------------------------------------------------------------------------------------
         Please Accept Our Sincere Apologies Should you Receive
                       Multiple Copies of this Announcement
--------------------------------------------------------------------------------------------------



              ANNOUNCEMENT AND CALL FOR PARTICIPATION


                    ACM Workshop on Wireless Security (WiSe)


                                   in conjunction with
                                 ACM MobiCom 2002


                                 September 28, 2002
                               Atlanta, Georgia, U.S.A.


                        http://www.crhc.uiuc.edu/~nhv/wise


                             Sponsored by SIGMOBILE



A workshop on Wireless Security will be held in conjunction with
ACM MobiCom 2002. The objective of this workshop is to bring together
researchers from research communities in wireless networking,
security, and dependability, with the goal of fostering interaction among
them. With the increasing reliance on wireless networks, issues related to
secure and dependable operation of such networks are gaining importance.
Topics of interest include, but are not limited to:


         * Key management in wireless/mobile environments
         * Intrusion detection
         * Secure MAC protocols
         * Secure routing
         * Denial of service
         * Privacy and anonymity
         * Prevention of traffic analysis
         * Dependable wireless networking
         * Monitoring and surveillance
         * Disaster response


Important dates:


         Paper submissions due: May 30, 2002
         Notification of acceptance: July 5, 2002
         Camera-ready papers due: July 31, 2002
         Workshop date: September 28, 2002



Workshop Co-Chairs:


         * Douglas Maughan, Defense Advanced Research Projects Agency
                         (dmaughan@darpa.mil)
         * Nitin Vaidya, University of Illinois at Urbana-Champaign
                         (nhv@uiuc.edu)


Program Committee:


         Yair Amir, Johns Hopkins University
         Pete Dinsmore, NAI
         Chip Elliott, BBN Technologies
         Zygmunt Haas, Cornell University
         Jean-Pierre Hubaux, EPFL-Lausanne
         David B. Johnson, Rice University
         Douglas Maughan, Defense Advanced Research Projects Agency (co-chair)
         Brian Noble, University of Michigan
         Ranga Ramanujan, Architecture Technology Corporation
         Frank Stajano, University of Cambridge
         Brian Van Leeuwen, Sandia National Laboratories
         Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair)
         Wei Zhao, Texas A&M University
         Taieb Znati, National Science Foundation, and University of Pittsburgh



Publicity Co-Chairs:


         Mohsen Guizani, University of West Florida
         Guevara Noubir, Northeastern University


Publication Chair:


         Saad Biaz, Auburn University


Registration Chair:


         Robin Kravets, University of Illinois at Urbana-Champaign


Treasurer:


         Yongguang Zhang, HRL Labs and UT-Austin


--------------------------------------------------------------------------------------------------------
Preliminary Program


Paper Session 1 (8:30 - 10:00 a.m.)


Securing Ad-Hoc Routing Protocols,
    M. Guerrero Zapata and N. Asokan (Nokia Research Center, Finland)

Self-Organized Network Layer Security in Mobile Ad Hoc Networks,
    H. Yang, X. Meng and S. Lu (University of California at Los Angeles)

An On-Demand Secure Routing Protocol Resilent to Byzantine Failures,
    B. Awerbuch, D. Holmer, C. Nita-Rotaru and H. Rubens
    (Johns Hopkins University)


Paper Session 2 (10:30 a.m. - 12:00 noon)


Survivable Mobile Wireless Networks: Issues, Challenges, and Research 
Directions,
    R. Krishnan, R. Rosales Hain, A. W. Jackson, D. Levin, R. Ramanathan, 
J. Zao and
    J. P. G. Sterbenz (BBN Technologies)

Secure Wireless Gateway,
    A. Godber and P. Dasgupta (Arizona State University)

DoS and Authentication in Wireless Public Access Networks,
    D. B. Faria and D. R. Cheriton (Stanford University)


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

Poster session (1:00 - 2:15 p.m.)

             List of posters will be made available here closer to  the 
workshop date.

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


Perspectives from Funding Agencies (2:15 - 3:00)


Information Assurance and Research Opportunities,
    D. Maughan, Defence Advanced Research Projects Agency


    T. Znati, National Science Foundation and University of Pittsburgh


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


Paper Session 3 (3:30 - 5:30)


A Distributed Monitoring Mechanism in Wireless Sensor Networks,
    C.-F. Hsin and M. Liu (University of Michigan at Ann Arbor)

Using Signal Processing to Analyze Wireless Data Traffic,
    C. Partridge, D. Cousins, A. W. Jackson, R. Krishnan, T. Saxena, and
    W. T. Strayer (BBN Technologies)

Securing IPv6 Neighor Discovery,
    J. Arkko (Ericsson Research NomadicLab), T. Aura (DoCoMoLabs U.S.A.),
    J. Kempf (Microsoft Research Cambridge),
    V.-M. Mantyla, P. Nikander (Ericsson Research NomadicLab) and M. Roe 
(DoCoMoLabs USA.)

Performance Analysis of Elliptic Curve Cryptography for SSL,
    V. Gupta, S. Gupta, Sh. Chang and D. Stebila (Sun Microsystems) 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 24 18:27:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04312
	for ; Wed, 24 Jul 2002 18:27:59 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00412
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 18:29:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28367;
	Wed, 24 Jul 2002 17:58:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28338
	for ; Wed, 24 Jul 2002 17:57:56 -0400 (EDT)
Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03568
	for ; Wed, 24 Jul 2002 17:56:51 -0400 (EDT)
Received: from CASABLANCA.ccs.neu.edu (crypt.ccs.neu.edu [129.10.115.162])
	by amber.ccs.neu.edu (Postfix) with ESMTP
	id 3B96A1AA22; Wed, 24 Jul 2002 17:57:53 -0400 (EDT)
Message-Id: <5.0.2.1.0.20020724174459.0253fca0@mail.ccs.neu.edu>
X-Sender: noubir@mail.ccs.neu.edu
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 24 Jul 2002 17:47:57 -0400
To: manet@ietf.org
From: "G. Noubir" 
Cc: Nitin H Vaidya 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [manet] Preliminary Program: ACM Workshop on Wireless Security (WiSe)
 [in conjunction with MobiCom'02]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--------------------------------------------------------------------------------------------------
         Please Accept Our Sincere Apologies Should you Receive
                       Multiple Copies of this Announcement
--------------------------------------------------------------------------------------------------



              ANNOUNCEMENT AND CALL FOR PARTICIPATION


                    ACM Workshop on Wireless Security (WiSe)


                                   in conjunction with
                                 ACM MobiCom 2002


                                 September 28, 2002
                               Atlanta, Georgia, U.S.A.


                        http://www.crhc.uiuc.edu/~nhv/wise


                             Sponsored by SIGMOBILE



A workshop on Wireless Security will be held in conjunction with
ACM MobiCom 2002. The objective of this workshop is to bring together
researchers from research communities in wireless networking,
security, and dependability, with the goal of fostering interaction among
them. With the increasing reliance on wireless networks, issues related to
secure and dependable operation of such networks are gaining importance.
Topics of interest include, but are not limited to:


         * Key management in wireless/mobile environments
         * Intrusion detection
         * Secure MAC protocols
         * Secure routing
         * Denial of service
         * Privacy and anonymity
         * Prevention of traffic analysis
         * Dependable wireless networking
         * Monitoring and surveillance
         * Disaster response


Important dates:


         Paper submissions due: May 30, 2002
         Notification of acceptance: July 5, 2002
         Camera-ready papers due: July 31, 2002
         Workshop date: September 28, 2002



Workshop Co-Chairs:


         * Douglas Maughan, Defense Advanced Research Projects Agency
                         (dmaughan@darpa.mil)
         * Nitin Vaidya, University of Illinois at Urbana-Champaign
                         (nhv@uiuc.edu)


Program Committee:


         Yair Amir, Johns Hopkins University
         Pete Dinsmore, NAI
         Chip Elliott, BBN Technologies
         Zygmunt Haas, Cornell University
         Jean-Pierre Hubaux, EPFL-Lausanne
         David B. Johnson, Rice University
         Douglas Maughan, Defense Advanced Research Projects Agency (co-chair)
         Brian Noble, University of Michigan
         Ranga Ramanujan, Architecture Technology Corporation
         Frank Stajano, University of Cambridge
         Brian Van Leeuwen, Sandia National Laboratories
         Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair)
         Wei Zhao, Texas A&M University
         Taieb Znati, National Science Foundation, and University of Pittsburgh



Publicity Co-Chairs:


         Mohsen Guizani, University of West Florida
         Guevara Noubir, Northeastern University


Publication Chair:


         Saad Biaz, Auburn University


Registration Chair:


         Robin Kravets, University of Illinois at Urbana-Champaign


Treasurer:


         Yongguang Zhang, HRL Labs and UT-Austin


--------------------------------------------------------------------------------------------------------
Preliminary Program


Paper Session 1 (8:30 - 10:00 a.m.)


Securing Ad-Hoc Routing Protocols,
    M. Guerrero Zapata and N. Asokan (Nokia Research Center, Finland)

Self-Organized Network Layer Security in Mobile Ad Hoc Networks,
    H. Yang, X. Meng and S. Lu (University of California at Los Angeles)

An On-Demand Secure Routing Protocol Resilent to Byzantine Failures,
    B. Awerbuch, D. Holmer, C. Nita-Rotaru and H. Rubens
    (Johns Hopkins University)


Paper Session 2 (10:30 a.m. - 12:00 noon)


Survivable Mobile Wireless Networks: Issues, Challenges, and Research 
Directions,
    R. Krishnan, R. Rosales Hain, A. W. Jackson, D. Levin, R. Ramanathan, 
J. Zao and
    J. P. G. Sterbenz (BBN Technologies)

Secure Wireless Gateway,
    A. Godber and P. Dasgupta (Arizona State University)

DoS and Authentication in Wireless Public Access Networks,
    D. B. Faria and D. R. Cheriton (Stanford University)


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

Poster session (1:00 - 2:15 p.m.)

             List of posters will be made available here closer to  the 
workshop date.

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


Perspectives from Funding Agencies (2:15 - 3:00)


Information Assurance and Research Opportunities,
    D. Maughan, Defence Advanced Research Projects Agency


    T. Znati, National Science Foundation and University of Pittsburgh


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


Paper Session 3 (3:30 - 5:30)


A Distributed Monitoring Mechanism in Wireless Sensor Networks,
    C.-F. Hsin and M. Liu (University of Michigan at Ann Arbor)

Using Signal Processing to Analyze Wireless Data Traffic,
    C. Partridge, D. Cousins, A. W. Jackson, R. Krishnan, T. Saxena, and
    W. T. Strayer (BBN Technologies)

Securing IPv6 Neighor Discovery,
    J. Arkko (Ericsson Research NomadicLab), T. Aura (DoCoMoLabs U.S.A.),
    J. Kempf (Microsoft Research Cambridge),
    V.-M. Mantyla, P. Nikander (Ericsson Research NomadicLab) and M. Roe 
(DoCoMoLabs USA.)

Performance Analysis of Elliptic Curve Cryptography for SSL,
    V. Gupta, S. Gupta, Sh. Chang and D. Stebila (Sun Microsystems) 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 24 20:00:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06503
	for ; Wed, 24 Jul 2002 20:00:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04491;
	Wed, 24 Jul 2002 19:41:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04460
	for ; Wed, 24 Jul 2002 19:41:02 -0400 (EDT)
Received: from ep_mailout1 ([203.254.224.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05970
	for ; Wed, 24 Jul 2002 19:39:57 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 id <0GZS00H011VB9L@mailout1.samsung.com> for manet@ietf.org; Thu,
 25 Jul 2002 08:42:47 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZS00GAH1VBU0@mailout1.samsung.com> for manet@ietf.org; Thu,
 25 Jul 2002 08:42:47 +0900 (KST)
Received: from zbin ([75.2.47.220])
 by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTPA id <0GZS00E021VJV7@mmp2.samsung.com> for manet@ietf.org; Thu,
 25 Jul 2002 08:42:56 +0900 (KST)
Date: Thu, 25 Jul 2002 08:43:07 +0900
From: zb 
Subject: Re: [manet] how does ad hoc network do something?
To: Frank Dinies 
Cc: manet@ietf.org
Message-id: <001a01c2336b$dd4bba00$dc2f024b@zbin>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20020723135047.A31977@che.onthejob.net>
 <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com>
 <005101c232d2$170c2cb0$dc2f024b@zbin> <200207241201.42027.FrankDinies@web.de>
Content-Transfer-Encoding: 7BIT
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7BIT

Hi, Frank,

  Thanks your reply.

  I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its IP
address
Then, the data can be exchanged between the two nodes. In MANET, there are
drafts on routing and IP address autoconfiguration. But, how to do service
discovery in ad hoc network? It seems there is no working group on service
discovery. Does it belong to upper layer which is out of  IETF? Besides, how
does the service discovery collaborate with the routing in ad hoc network?

regard,

bin
----- Original Message -----
From: "Frank Dinies" 
To: "zb" 
Cc: 
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do something?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a short
boot-up-time, when a new device wants to participate, it knows about his
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens  this is not true. This
algorithmens rely on special information or mechanismens for the boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid
change and much participants. On-demand-ones roughly for the contrary. For
sensors that transmit from time to time small amounts of data for example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22 schrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device
B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 24 20:00:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06511
	for ; Wed, 24 Jul 2002 20:00:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA06030
	for manet-archive@odin.ietf.org; Wed, 24 Jul 2002 20:01:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04491;
	Wed, 24 Jul 2002 19:41:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04460
	for ; Wed, 24 Jul 2002 19:41:02 -0400 (EDT)
Received: from ep_mailout1 ([203.254.224.24])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05970
	for ; Wed, 24 Jul 2002 19:39:57 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
 (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 id <0GZS00H011VB9L@mailout1.samsung.com> for manet@ietf.org; Thu,
 25 Jul 2002 08:42:47 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1])
 by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GZS00GAH1VBU0@mailout1.samsung.com> for manet@ietf.org; Thu,
 25 Jul 2002 08:42:47 +0900 (KST)
Received: from zbin ([75.2.47.220])
 by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTPA id <0GZS00E021VJV7@mmp2.samsung.com> for manet@ietf.org; Thu,
 25 Jul 2002 08:42:56 +0900 (KST)
Date: Thu, 25 Jul 2002 08:43:07 +0900
From: zb 
Subject: Re: [manet] how does ad hoc network do something?
To: Frank Dinies 
Cc: manet@ietf.org
Message-id: <001a01c2336b$dd4bba00$dc2f024b@zbin>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20020723135047.A31977@che.onthejob.net>
 <00d501c2327e$80dcfe70$ab0110ac@meshnetworks.com>
 <005101c232d2$170c2cb0$dc2f024b@zbin> <200207241201.42027.FrankDinies@web.de>
Content-Transfer-Encoding: 7BIT
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7BIT

Hi, Frank,

  Thanks your reply.

  I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its IP
address
Then, the data can be exchanged between the two nodes. In MANET, there are
drafts on routing and IP address autoconfiguration. But, how to do service
discovery in ad hoc network? It seems there is no working group on service
discovery. Does it belong to upper layer which is out of  IETF? Besides, how
does the service discovery collaborate with the routing in ad hoc network?

regard,

bin
----- Original Message -----
From: "Frank Dinies" 
To: "zb" 
Cc: 
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do something?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a short
boot-up-time, when a new device wants to participate, it knows about his
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens  this is not true. This
algorithmens rely on special information or mechanismens for the boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid
change and much participants. On-demand-ones roughly for the contrary. For
sensors that transmit from time to time small amounts of data for example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22 schrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device
B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 04:02:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25759
	for ; Thu, 25 Jul 2002 04:02:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05720;
	Thu, 25 Jul 2002 03:29:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05695
	for ; Thu, 25 Jul 2002 03:29:25 -0400 (EDT)
Received: from WS0005.indiatimes.com ([203.199.93.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25249
	for ; Thu, 25 Jul 2002 03:28:21 -0400 (EDT)
Received: from 192.168.57.15 (a1 [192.168.57.21])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA21197;
	Thu, 25 Jul 2002 12:16:26 +0530
From: "naveen_bits" 
Message-Id: <200207250646.MAA21197@WS0005.indiatimes.com>
To: "zb", "Frank Dinies"
CC: 
Reply-To: "naveen_bits"
Subject: Re: Re: [manet] how does ad hoc network do something?
Date: Thu, 25 Jul 2002 12:23:54 +0530
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434"
MIME-Version: 1.0
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434
Content-Type: text/plain; charset=us-ascii


Hi Bin,


Please correct me , If I am wrong , but this is what I think about the concerned problem described below.


Let there be some nodes A & B , such that A is the node that requires services of B


Logically speaking there can be following ways to depict the information:-


First, If A knows the services it wants to use it may ask the node B that "is this service is provided by you"? If yes then B can act as a serverand provide these services. B Acknowledges yes or no by 


acknowledgement or A waits some randomn amount of time & inquires other nodes in the vicinity.In extention to this B can also ask the node in the vicinity if they can provide with the service that A wants 


Definately security has to be kept in mind before going for this kind of protocol.
 
Second, For performance reasons A can broadcast and ask "Is there any node that provides this services"?. Then the node providing the services that A requires is send as an acknowledgement containing the 


IP address. If multiple nodes provides the same then the best path can be choosen. This is kind of flooding. This can be done in some controlled manner.


Third if A doesnot know the services and want to use the services than the nodes in the vicinity can broadcast "Do you want this service"? If yes then it can use the service if wants to...


Actually, as far as I think in normal scinarios the combination of second & third scheme is used? It broadcast for some periof´ds with certain no retries(may be configurable). If fails then then there is no option 


but to use third option......


 


 



Regards
Naveen Kumar Lall 


"zb" wrote:



Hi, Frank,

Thanks your reply.

I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its IP
address
Then, the data can be exchanged between the two nodes. In MANET, there are
drafts on routing and IP address autoconfiguration. But, how to do service
discovery in ad hoc network? It seems there is no working group on service
discovery. Does it belong to upper layer which is out of IETF? Besides, how
does the service discovery collaborate with the routing in ad hoc network?

regard,

bin
----- Original Message -----
From: "Frank Dinies" 
To: "zb" 
Cc: 
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do something?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a short
boot-up-time, when a new device wants to participate, it knows about his
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens this is not true. This
algorithmens rely on special information or mechanismens for the boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid
change and much participants. On-demand-ones roughly for the contrary. For
sensors that transmit from time to time small amounts of data for example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22 schrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device
B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

--=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434
Content-Type: text/html; charset=us-ascii



Hi Bin,


Please correct me , If I am wrong , but this is what I think about the concerned problem described below.


Let there be some nodes A & B , such that A is the node that requires services of B


Logically speaking there can be following ways to depict the information:-


First, If A knows the services it wants to use it may ask the node B that "is this service is provided by you"? If yes then B can act as a serverand provide these services. B Acknowledges yes or no by 


acknowledgement or A waits some randomn amount of time & inquires other nodes in the vicinity.In extention to this B can also ask the node in the vicinity if they can provide with the service that A wants 


Definately security has to be kept in mind before going for this kind of protocol.
 
Second, For performance reasons A can broadcast and ask "Is there any node that provides this services"?. Then the node providing the services that A requires is send as an acknowledgement containing the 


IP address. If multiple nodes provides the same then the best path can be choosen. This is kind of flooding. This can be done in some controlled manner.


Third if A doesnot know the services and want to use the services than the nodes in the vicinity can broadcast "Do you want this service"? If yes then it can use the service if wants to...


Actually, as far as I think in normal scinarios the combination of second & third scheme is used? It broadcast for some periof´ds with certain no retries(may be configurable). If fails then then there is no option 


but to use third option......


 


 



Regards
Naveen Kumar Lall 


"zb" wrote:




Hi, Frank,

Thanks your reply.

I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its IP
address
Then, the data can be exchanged between the two nodes. In MANET, there are
drafts on routing and IP address autoconfiguration. But, how to do service
discovery in ad hoc network? It seems there is no working group on service
discovery. Does it belong to upper layer which is out of IETF? Besides, how
does the service discovery collaborate with the routing in ad hoc network?

regard,

bin
----- Original Message -----
From: "Frank Dinies" 
To: "zb" 
Cc: 
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do somethi!
 ng!
?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a short
boot-up-time, when a new device wants to participate, it knows about his
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens this is not true. This
algorithmens rely on special information or mechanismens for the boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid
change and much participants. On-demand-ones roughly for the contrary. For
sensors that transmit from time to time small amounts of data for example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22!
  s!
chrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device
B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/mane!
 t


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

--=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 25 04:02:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25767
	for ; Thu, 25 Jul 2002 04:02:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA08564
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 04:03:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05720;
	Thu, 25 Jul 2002 03:29:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05695
	for ; Thu, 25 Jul 2002 03:29:25 -0400 (EDT)
Received: from WS0005.indiatimes.com ([203.199.93.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25249
	for ; Thu, 25 Jul 2002 03:28:21 -0400 (EDT)
Received: from 192.168.57.15 (a1 [192.168.57.21])
	by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA21197;
	Thu, 25 Jul 2002 12:16:26 +0530
From: "naveen_bits" 
Message-Id: <200207250646.MAA21197@WS0005.indiatimes.com>
To: "zb", "Frank Dinies"
CC: 
Reply-To: "naveen_bits"
Subject: Re: Re: [manet] how does ad hoc network do something?
Date: Thu, 25 Jul 2002 12:23:54 +0530
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
	   boundary="=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434"
MIME-Version: 1.0
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

--=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434
Content-Type: text/plain; charset=us-ascii


Hi Bin,


Please correct me , If I am wrong , but this is what I think about the concerned problem described below.


Let there be some nodes A & B , such that A is the node that requires services of B


Logically speaking there can be following ways to depict the information:-


First, If A knows the services it wants to use it may ask the node B that "is this service is provided by you"? If yes then B can act as a serverand provide these services. B Acknowledges yes or no by 


acknowledgement or A waits some randomn amount of time & inquires other nodes in the vicinity.In extention to this B can also ask the node in the vicinity if they can provide with the service that A wants 


Definately security has to be kept in mind before going for this kind of protocol.
 
Second, For performance reasons A can broadcast and ask "Is there any node that provides this services"?. Then the node providing the services that A requires is send as an acknowledgement containing the 


IP address. If multiple nodes provides the same then the best path can be choosen. This is kind of flooding. This can be done in some controlled manner.


Third if A doesnot know the services and want to use the services than the nodes in the vicinity can broadcast "Do you want this service"? If yes then it can use the service if wants to...


Actually, as far as I think in normal scinarios the combination of second & third scheme is used? It broadcast for some periof´ds with certain no retries(may be configurable). If fails then then there is no option 


but to use third option......


 


 



Regards
Naveen Kumar Lall 


"zb" wrote:



Hi, Frank,

Thanks your reply.

I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its IP
address
Then, the data can be exchanged between the two nodes. In MANET, there are
drafts on routing and IP address autoconfiguration. But, how to do service
discovery in ad hoc network? It seems there is no working group on service
discovery. Does it belong to upper layer which is out of IETF? Besides, how
does the service discovery collaborate with the routing in ad hoc network?

regard,

bin
----- Original Message -----
From: "Frank Dinies" 
To: "zb" 
Cc: 
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do something?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a short
boot-up-time, when a new device wants to participate, it knows about his
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens this is not true. This
algorithmens rely on special information or mechanismens for the boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid
change and much participants. On-demand-ones roughly for the contrary. For
sensors that transmit from time to time small amounts of data for example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22 schrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device
B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

--=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434
Content-Type: text/html; charset=us-ascii



Hi Bin,


Please correct me , If I am wrong , but this is what I think about the concerned problem described below.


Let there be some nodes A & B , such that A is the node that requires services of B


Logically speaking there can be following ways to depict the information:-


First, If A knows the services it wants to use it may ask the node B that "is this service is provided by you"? If yes then B can act as a serverand provide these services. B Acknowledges yes or no by 


acknowledgement or A waits some randomn amount of time & inquires other nodes in the vicinity.In extention to this B can also ask the node in the vicinity if they can provide with the service that A wants 


Definately security has to be kept in mind before going for this kind of protocol.
 
Second, For performance reasons A can broadcast and ask "Is there any node that provides this services"?. Then the node providing the services that A requires is send as an acknowledgement containing the 


IP address. If multiple nodes provides the same then the best path can be choosen. This is kind of flooding. This can be done in some controlled manner.


Third if A doesnot know the services and want to use the services than the nodes in the vicinity can broadcast "Do you want this service"? If yes then it can use the service if wants to...


Actually, as far as I think in normal scinarios the combination of second & third scheme is used? It broadcast for some periof´ds with certain no retries(may be configurable). If fails then then there is no option 


but to use third option......


 


 



Regards
Naveen Kumar Lall 


"zb" wrote:




Hi, Frank,

Thanks your reply.

I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its IP
address
Then, the data can be exchanged between the two nodes. In MANET, there are
drafts on routing and IP address autoconfiguration. But, how to do service
discovery in ad hoc network? It seems there is no working group on service
discovery. Does it belong to upper layer which is out of IETF? Besides, how
does the service discovery collaborate with the routing in ad hoc network?

regard,

bin
----- Original Message -----
From: "Frank Dinies" 
To: "zb" 
Cc: 
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do somethi!
 ng!
?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a short
boot-up-time, when a new device wants to participate, it knows about his
enviroment and vice versa. But this is only true for proactive algorithmens.

For reactive algorithmens or on-demand-algorithmens this is not true. This
algorithmens rely on special information or mechanismens for the boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with rapid
change and much participants. On-demand-ones roughly for the contrary. For
sensors that transmit from time to time small amounts of data for example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22!
  s!
chrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and service
> ability of each other. There can be multihop between device A and device
B.
> How does the device A know it can get required service from device B and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/mane!
 t


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in

--=_MAILER_ATTACH_BOUNDARY1_20027254122354610515434--


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 04:17:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26101
	for ; Thu, 25 Jul 2002 04:17:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07298;
	Thu, 25 Jul 2002 03:52:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07200
	for ; Thu, 25 Jul 2002 03:52:17 -0400 (EDT)
Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25543
	for ; Thu, 25 Jul 2002 03:51:13 -0400 (EDT)
Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 25 Jul 2002 09:52:15 +0200
Subject: RE : Re: [manet] how does ad hoc network do something?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C233B0.314C5698"
Date: Thu, 25 Jul 2002 09:52:15 +0200
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <0489A7888F080B4BA73B53F7E145F29A03C098@LANMHS20.rd.francetelecom.fr>
Thread-Topic: Re: [manet] how does ad hoc network do something?
Thread-Index: AcIzr18PodlJPZFkRpu+cHXUK0/7PAAADEpQ
From: "MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN" 
To: "naveen_bits" , "zb" ,
        "Frank Dinies" 
Cc: 
X-OriginalArrivalTime: 25 Jul 2002 07:52:15.0882 (UTC) FILETIME=[3193B6A0:01C233B0]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C233B0.314C5698
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all

I have two questions about this subject:

=20

Which type of services we need (or car provided) at MANET?=20

Which node will act as service provider?

=20

regards

=20

=20

-----Message d'origine-----
De : naveen_bits [mailto:naveen_bits@indiatimes.com]=20
Envoy=E9 : jeudi 25 juillet 2002 08:54
=C0 : zb; Frank Dinies
Cc : manet@ietf.org
Objet : Re: Re: [manet] how does ad hoc network do something?

=20


Hi Bin,

Please correct me , If I am wrong , but this is what I think about the =
concerned problem described below.

Let there be some nodes A & B , such that A is the node that requires =
services of B

Logically speaking there can be following ways to depict the =
information:-

First, If A knows the services it wants to use it may ask the node B =
that "is this service is provided by you"? If yes then B can act as a =
serverand provide these services. B Acknowledges yes or no by=20

acknowledgement or A waits some randomn amount of time & inquires other =
nodes in the vicinity.In extention to this B can also ask the node in =
the vicinity if they can provide with the service that A wants=20

Definately security has to be kept in mind before going for this kind of =
protocol.
=20
Second, For performance reasons A can broadcast and ask "Is there any =
node that provides this services"?. Then the node providing the services =
that A requires is send as an acknowledgement containing the=20

IP address. If multiple nodes provides the same then the best path can =
be choosen. This is kind of flooding. This can be done in some =
controlled manner.

Third if A doesnot know the services and want to use the services than =
the nodes in the vicinity can broadcast "Do you want this service"? If =
yes then it can use the service if wants to...

Actually, as far as I think in normal scinarios the combination of =
second & third scheme is used? It broadcast for some periof4ds with =
certain no retries(may be configurable). If fails then then there is no =
option=20

but to use third option......

=20

=20


Regards
Naveen Kumar Lall=20


"zb" wrote:

=09
	Hi, Frank,
=09
	Thanks your reply.
=09
	I think, to make an ad hoc network to do something, two thing must be
	done:
	1) to get an IP address of itself
	2) to find the node which can provide the required service and get its =
IP
	address
	Then, the data can be exchanged between the two nodes. In MANET, there =
are
	drafts on routing and IP address autoconfiguration. But, how to do =
service
	discovery in ad hoc network? It seems there is no working group on =
service
	discovery. Does it belong to upper layer which is out of IETF? Besides, =
how
	does the service discovery collaborate with the routing in ad hoc =
network?
=09
	regard,
=09
	bin
	----- Original Message -----
	From: "Frank Dinies"=20
	To: "zb"=20
	Cc:=20
	Sent: Wednesday, July 24, 2002 7:01 PM
	Subject: Re: [manet] how does ad hoc network do somethi! ng! ?
=09
=09
	Hi Zhen,
=09
	for proactive algorithmens like ADV or FSR there is no problem. Mainly
	because
	this algorithmens rely on periodically sent advertisments. So after a =
short
	boot-up-time, when a new device wants to participate, it knows about =
his
	enviroment and vice versa. But this is only true for proactive =
algorithmens.
=09
	For reactive algorithmens or on-demand-algorithmens this is not true. =
This
	algorithmens rely on special information or mechanismens for the =
boot-uptime
	to scan their enviroment.
=09
	But keep in mind. Proactive algorithmens are best in enviroments with =
rapid
	change and much participants. On-demand-ones roughly for the contrary. =
For
	sensors that transmit from time to time small amounts of data for =
example is
	an on-demand-one perfect.
=09
	hope this helps
=09
	frank
=09
	looking in the RFCs or drafts could give you an idea. the bootup =
problem
	mostly is not trivial !
=09
	Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:
	> Hi,
	>
	> I have a question on how does the ad hoc network begin to work? When
	device
	> A and device B are in a MANET, they do not know IP address and =
service
	> ability of each other. There can be multihop between device A and =
device
	B.
	> How does the device A know it can get required service from device B =
and
	> communicate with device B?
	>
	> Thanx.
	>
	> bin
	> *************************************
	> Zhen Bin
	>
	> i-Networking lab,
	> Samsung Advanced Institute of Technology,
	> San14-1, NongSeo-ri, Kiheung-Eup,
	> Yongin, Kyungki-do, 440600, Korea
	>
	> 82-31-2809569 (fax)
	> 82-31-2809534 (o)
	> 82-31-2122268 (h)
	> *************************************
	>
	>
	>
	> _______________________________________________
	> manet mailing list
	> manet@ietf.org
	> https://www1.ietf.org/mailman/listinfo/mane! t
=09
=09
	_______________________________________________
	manet mailing list
	manet@ietf.org
	https://www1.ietf.org/mailman/listinfo/manet

=20

  _____ =20

Get Your Private, Free E-mail from Indiatimes at =
http://email.indiatimes.com =20
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from =
http://www.planetm.co.in=20


------_=_NextPart_001_01C233B0.314C5698
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

















Hi =
all



I have two =
questions
about this subject:



 



Which type of =
services we
need (or car provided) at MANET? 



Which node will =
act as
service provider?



 



regards



 



 



-----Message =
d'origine-----

De : naveen_bits
[mailto:naveen_bits@indiatimes.com] 

Envoy=E9 : jeudi 25 =
juillet
2002 08:54

=C0 : zb; Frank =
Dinies

Cc : =
manet@ietf.org

Objet : Re: Re: =
[manet] how
does ad hoc network do something?



 





Hi Bin,



Please correct me , If I am wrong , but this =
is what I
think about the concerned problem described below.



Let there be some nodes A & B , such that =
A is the
node that requires services of B



Logically speaking there can be following =
ways to
depict the information:-



First, If A knows the services it wants to =
use it may
ask the node B that "is this service is provided by you"? If =
yes then
B can act as a serverand provide these services. B Acknowledges yes or =
no by 



acknowledgement or A waits some randomn =
amount of time
& inquires other nodes in the vicinity.In extention to this B can =
also ask
the node in the vicinity if they can provide with the service that A =
wants 



Definately security has to be kept in mind =
before
going for this kind of protocol.

 

Second, For performance reasons A can broadcast and ask "Is there =
any node
that provides this services"?. Then the node providing the services =
that A
requires is send as an acknowledgement containing the 



IP address. If multiple nodes provides the =
same then
the best path can be choosen. This is kind of flooding. This can be done =
in
some controlled manner.



Third if A doesnot know the services and want =
to use
the services than the nodes in the vicinity can broadcast "Do you =
want
this service"? If yes then it can use the service if wants =
to...



Actually, as far as I think in normal =
scinarios the
combination of second & third scheme is used? It broadcast for some
periof4ds with certain no retries(may be configurable). If fails then =
then
there is no option 



but to use third =
option......



 



 





Regards

Naveen Kumar Lall 





"zb"
wrote:








Hi, Frank,



Thanks your reply.



I think, to make an ad hoc network to do something, two thing must =
be

done:

1) to get an IP address of itself

2) to find the node which can provide the required service and get its =
IP

address

Then, the data can be exchanged between the two nodes. In MANET, there =
are

drafts on routing and IP address autoconfiguration. But, how to do =
service

discovery in ad hoc network? It seems there is no working group on =
service

discovery. Does it belong to upper layer which is out of IETF? Besides, =
how

does the service discovery collaborate with the routing in ad hoc =
network?



regard,



bin

----- Original Message -----

From: "Frank Dinies" 

To: "zb" 

Cc: 

Sent: Wednesday, July 24, 2002 7:01 PM

Subject: Re: [manet] how does ad hoc network do somethi! ng! ?





Hi Zhen,



for proactive algorithmens like ADV or FSR there is no problem. =
Mainly

because

this algorithmens rely on periodically sent advertisments. So after a =
short

boot-up-time, when a new device wants to participate, it knows about =
his

enviroment and vice versa. But this is only true for proactive =
algorithmens.



For reactive algorithmens or on-demand-algorithmens this is not true. =
This

algorithmens rely on special information or mechanismens for the =
boot-uptime

to scan their enviroment.



But keep in mind. Proactive algorithmens are best in enviroments with =
rapid

change and much participants. On-demand-ones roughly for the contrary. =
For

sensors that transmit from time to time small amounts of data for =
example is

an on-demand-one perfect.



hope this helps



frank



looking in the RFCs or drafts could give you an idea. the bootup =
problem

mostly is not trivial !



Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:

> Hi,

>

> I have a question on how does the ad hoc network begin to work? =
When

device

> A and device B are in a MANET, they do not know IP address and =
service

> ability of each other. There can be multihop between device A and =
device

B.

> How does the device A know it can get required service from device =
B and

> communicate with device B?

>

> Thanx.

>

> bin

> *************************************

> Zhen Bin

>

> i-Networking lab,

> Samsung Advanced Institute of Technology,

> San14-1, NongSeo-ri, Kiheung-Eup,

> Yongin, Kyungki-do, 440600, Korea

>

> 82-31-2809569 (fax)

> 82-31-2809534 (o)

> 82-31-2122268 (h)

> *************************************

>

>

>

> _______________________________________________

> manet mailing list

> manet@ietf.org

> https://www1.ietf.org/mailman/listinfo/mane! t





_______________________________________________

manet mailing list

manet@ietf.org

https://www1.ietf.org/mailman/listinfo/manet






 












Get Your =
Private,
Free E-mail from Indiatimes at http://email.indiatimes.com<=
/span>

Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in 








=00
------_=_NextPart_001_01C233B0.314C5698--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 25 04:17:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26108
	for ; Thu, 25 Jul 2002 04:17:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA09814
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 04:18:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07298;
	Thu, 25 Jul 2002 03:52:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07200
	for ; Thu, 25 Jul 2002 03:52:17 -0400 (EDT)
Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25543
	for ; Thu, 25 Jul 2002 03:51:13 -0400 (EDT)
Received: from LANMHS20.rd.francetelecom.fr ([10.193.21.60]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 25 Jul 2002 09:52:15 +0200
Subject: RE : Re: [manet] how does ad hoc network do something?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C233B0.314C5698"
Date: Thu, 25 Jul 2002 09:52:15 +0200
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <0489A7888F080B4BA73B53F7E145F29A03C098@LANMHS20.rd.francetelecom.fr>
Thread-Topic: Re: [manet] how does ad hoc network do something?
Thread-Index: AcIzr18PodlJPZFkRpu+cHXUK0/7PAAADEpQ
From: "MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN" 
To: "naveen_bits" , "zb" ,
        "Frank Dinies" 
Cc: 
X-OriginalArrivalTime: 25 Jul 2002 07:52:15.0882 (UTC) FILETIME=[3193B6A0:01C233B0]
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C233B0.314C5698
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all

I have two questions about this subject:

=20

Which type of services we need (or car provided) at MANET?=20

Which node will act as service provider?

=20

regards

=20

=20

-----Message d'origine-----
De : naveen_bits [mailto:naveen_bits@indiatimes.com]=20
Envoy=E9 : jeudi 25 juillet 2002 08:54
=C0 : zb; Frank Dinies
Cc : manet@ietf.org
Objet : Re: Re: [manet] how does ad hoc network do something?

=20


Hi Bin,

Please correct me , If I am wrong , but this is what I think about the =
concerned problem described below.

Let there be some nodes A & B , such that A is the node that requires =
services of B

Logically speaking there can be following ways to depict the =
information:-

First, If A knows the services it wants to use it may ask the node B =
that "is this service is provided by you"? If yes then B can act as a =
serverand provide these services. B Acknowledges yes or no by=20

acknowledgement or A waits some randomn amount of time & inquires other =
nodes in the vicinity.In extention to this B can also ask the node in =
the vicinity if they can provide with the service that A wants=20

Definately security has to be kept in mind before going for this kind of =
protocol.
=20
Second, For performance reasons A can broadcast and ask "Is there any =
node that provides this services"?. Then the node providing the services =
that A requires is send as an acknowledgement containing the=20

IP address. If multiple nodes provides the same then the best path can =
be choosen. This is kind of flooding. This can be done in some =
controlled manner.

Third if A doesnot know the services and want to use the services than =
the nodes in the vicinity can broadcast "Do you want this service"? If =
yes then it can use the service if wants to...

Actually, as far as I think in normal scinarios the combination of =
second & third scheme is used? It broadcast for some periof4ds with =
certain no retries(may be configurable). If fails then then there is no =
option=20

but to use third option......

=20

=20


Regards
Naveen Kumar Lall=20


"zb" wrote:

=09
	Hi, Frank,
=09
	Thanks your reply.
=09
	I think, to make an ad hoc network to do something, two thing must be
	done:
	1) to get an IP address of itself
	2) to find the node which can provide the required service and get its =
IP
	address
	Then, the data can be exchanged between the two nodes. In MANET, there =
are
	drafts on routing and IP address autoconfiguration. But, how to do =
service
	discovery in ad hoc network? It seems there is no working group on =
service
	discovery. Does it belong to upper layer which is out of IETF? Besides, =
how
	does the service discovery collaborate with the routing in ad hoc =
network?
=09
	regard,
=09
	bin
	----- Original Message -----
	From: "Frank Dinies"=20
	To: "zb"=20
	Cc:=20
	Sent: Wednesday, July 24, 2002 7:01 PM
	Subject: Re: [manet] how does ad hoc network do somethi! ng! ?
=09
=09
	Hi Zhen,
=09
	for proactive algorithmens like ADV or FSR there is no problem. Mainly
	because
	this algorithmens rely on periodically sent advertisments. So after a =
short
	boot-up-time, when a new device wants to participate, it knows about =
his
	enviroment and vice versa. But this is only true for proactive =
algorithmens.
=09
	For reactive algorithmens or on-demand-algorithmens this is not true. =
This
	algorithmens rely on special information or mechanismens for the =
boot-uptime
	to scan their enviroment.
=09
	But keep in mind. Proactive algorithmens are best in enviroments with =
rapid
	change and much participants. On-demand-ones roughly for the contrary. =
For
	sensors that transmit from time to time small amounts of data for =
example is
	an on-demand-one perfect.
=09
	hope this helps
=09
	frank
=09
	looking in the RFCs or drafts could give you an idea. the bootup =
problem
	mostly is not trivial !
=09
	Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:
	> Hi,
	>
	> I have a question on how does the ad hoc network begin to work? When
	device
	> A and device B are in a MANET, they do not know IP address and =
service
	> ability of each other. There can be multihop between device A and =
device
	B.
	> How does the device A know it can get required service from device B =
and
	> communicate with device B?
	>
	> Thanx.
	>
	> bin
	> *************************************
	> Zhen Bin
	>
	> i-Networking lab,
	> Samsung Advanced Institute of Technology,
	> San14-1, NongSeo-ri, Kiheung-Eup,
	> Yongin, Kyungki-do, 440600, Korea
	>
	> 82-31-2809569 (fax)
	> 82-31-2809534 (o)
	> 82-31-2122268 (h)
	> *************************************
	>
	>
	>
	> _______________________________________________
	> manet mailing list
	> manet@ietf.org
	> https://www1.ietf.org/mailman/listinfo/mane! t
=09
=09
	_______________________________________________
	manet mailing list
	manet@ietf.org
	https://www1.ietf.org/mailman/listinfo/manet

=20

  _____ =20

Get Your Private, Free E-mail from Indiatimes at =
http://email.indiatimes.com =20
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from =
http://www.planetm.co.in=20


------_=_NextPart_001_01C233B0.314C5698
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

















Hi =
all



I have two =
questions
about this subject:



 



Which type of =
services we
need (or car provided) at MANET? 



Which node will =
act as
service provider?



 



regards



 



 



-----Message =
d'origine-----

De : naveen_bits
[mailto:naveen_bits@indiatimes.com] 

Envoy=E9 : jeudi 25 =
juillet
2002 08:54

=C0 : zb; Frank =
Dinies

Cc : =
manet@ietf.org

Objet : Re: Re: =
[manet] how
does ad hoc network do something?



 





Hi Bin,



Please correct me , If I am wrong , but this =
is what I
think about the concerned problem described below.



Let there be some nodes A & B , such that =
A is the
node that requires services of B



Logically speaking there can be following =
ways to
depict the information:-



First, If A knows the services it wants to =
use it may
ask the node B that "is this service is provided by you"? If =
yes then
B can act as a serverand provide these services. B Acknowledges yes or =
no by 



acknowledgement or A waits some randomn =
amount of time
& inquires other nodes in the vicinity.In extention to this B can =
also ask
the node in the vicinity if they can provide with the service that A =
wants 



Definately security has to be kept in mind =
before
going for this kind of protocol.

 

Second, For performance reasons A can broadcast and ask "Is there =
any node
that provides this services"?. Then the node providing the services =
that A
requires is send as an acknowledgement containing the 



IP address. If multiple nodes provides the =
same then
the best path can be choosen. This is kind of flooding. This can be done =
in
some controlled manner.



Third if A doesnot know the services and want =
to use
the services than the nodes in the vicinity can broadcast "Do you =
want
this service"? If yes then it can use the service if wants =
to...



Actually, as far as I think in normal =
scinarios the
combination of second & third scheme is used? It broadcast for some
periof4ds with certain no retries(may be configurable). If fails then =
then
there is no option 



but to use third =
option......



 



 





Regards

Naveen Kumar Lall 





"zb"
wrote:








Hi, Frank,



Thanks your reply.



I think, to make an ad hoc network to do something, two thing must =
be

done:

1) to get an IP address of itself

2) to find the node which can provide the required service and get its =
IP

address

Then, the data can be exchanged between the two nodes. In MANET, there =
are

drafts on routing and IP address autoconfiguration. But, how to do =
service

discovery in ad hoc network? It seems there is no working group on =
service

discovery. Does it belong to upper layer which is out of IETF? Besides, =
how

does the service discovery collaborate with the routing in ad hoc =
network?



regard,



bin

----- Original Message -----

From: "Frank Dinies" 

To: "zb" 

Cc: 

Sent: Wednesday, July 24, 2002 7:01 PM

Subject: Re: [manet] how does ad hoc network do somethi! ng! ?





Hi Zhen,



for proactive algorithmens like ADV or FSR there is no problem. =
Mainly

because

this algorithmens rely on periodically sent advertisments. So after a =
short

boot-up-time, when a new device wants to participate, it knows about =
his

enviroment and vice versa. But this is only true for proactive =
algorithmens.



For reactive algorithmens or on-demand-algorithmens this is not true. =
This

algorithmens rely on special information or mechanismens for the =
boot-uptime

to scan their enviroment.



But keep in mind. Proactive algorithmens are best in enviroments with =
rapid

change and much participants. On-demand-ones roughly for the contrary. =
For

sensors that transmit from time to time small amounts of data for =
example is

an on-demand-one perfect.



hope this helps



frank



looking in the RFCs or drafts could give you an idea. the bootup =
problem

mostly is not trivial !



Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:

> Hi,

>

> I have a question on how does the ad hoc network begin to work? =
When

device

> A and device B are in a MANET, they do not know IP address and =
service

> ability of each other. There can be multihop between device A and =
device

B.

> How does the device A know it can get required service from device =
B and

> communicate with device B?

>

> Thanx.

>

> bin

> *************************************

> Zhen Bin

>

> i-Networking lab,

> Samsung Advanced Institute of Technology,

> San14-1, NongSeo-ri, Kiheung-Eup,

> Yongin, Kyungki-do, 440600, Korea

>

> 82-31-2809569 (fax)

> 82-31-2809534 (o)

> 82-31-2122268 (h)

> *************************************

>

>

>

> _______________________________________________

> manet mailing list

> manet@ietf.org

> https://www1.ietf.org/mailman/listinfo/mane! t





_______________________________________________

manet mailing list

manet@ietf.org

https://www1.ietf.org/mailman/listinfo/manet






 












Get Your =
Private,
Free E-mail from Indiatimes at http://email.indiatimes.com<=
/span>

Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in 








=00
------_=_NextPart_001_01C233B0.314C5698--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 09:30:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03251
	for ; Thu, 25 Jul 2002 09:30:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25578;
	Thu, 25 Jul 2002 09:00:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25546
	for ; Thu, 25 Jul 2002 09:00:51 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01970
	for ; Thu, 25 Jul 2002 08:59:48 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117123>; Thu, 25 Jul 2002 07:00:47 -0600
Message-Id: <02Jul25.070047mdt.117123@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: naveen_bits 
Cc: manet@ietf.org
Subject: RE: RE : Re: [manet] how does ad hoc network do something?
Date:  Thu, 25 Jul 2002 07:00:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C233DB.49DD00B0"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C233DB.49DD00B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
The answer would depend on the MANET.
=20
In the general definition of a MANET, nodes are free to join or leave =
the
MANET without any central control.  Security may be an issue, but that =
would
depend on the MANET as well.  The key thing is that at any time, a node =
may
join the MANET and that the node in question might offer some sort of
service that other nodes do not generally offer or possess.  Examples =
would
include:

*	A shared printer, say at a conference or hotel,
*	A gateway to the Internet
*	Emergency Medical services
*	Information services, such as a directory or technical database

When such a node enters, existing nodes may not be aware that the =
services
it offers even exist on the MANET.  In addition, even if a node =
suspected
that a service existed, it has the problem of finding the IP of a node =
that
offers such a service. =20
=20
Bear in mind that in wired nets, the existence and location of such =
services
is known to the network administrators, who take care of both problems =
at
initial node setup and propagate changes as they occur.  However, in a
MANET, these things are supposed to happen automatically.
=20
John Mullen

-----Original Message-----
From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN
[mailto:djamaleddine.meddour@rd.francetelecom.com]
Sent: Thursday, July 25, 2002 1:52 AM
To: naveen_bits; zb; Frank Dinies
Cc: manet@ietf.org
Subject: RE : Re: [manet] how does ad hoc network do something?



Hi all

I have two questions about this subject:

=20

Which type of services we need (or car provided) at MANET?=20

Which node will act as service provider?

=20

regards

=20

=20

-----Message d'origine-----
De : naveen_bits [mailto:naveen_bits@indiatimes.com]=20
Envoy=E9 : jeudi 25 juillet 2002 08:54
=C0 : zb; Frank Dinies
Cc : manet@ietf.org
Objet : Re: Re: [manet] how does ad hoc network do something?

=20


Hi Bin,

Please correct me , If I am wrong , but this is what I think about the
concerned problem described below.

Let there be some nodes A & B , such that A is the node that requires
services of B

Logically speaking there can be following ways to depict the =
information:-

First, If A knows the services it wants to use it may ask the node B =
that
"is this service is provided by you"? If yes then B can act as a =
serverand
provide these services. B Acknowledges yes or no by=20

acknowledgement or A waits some randomn amount of time & inquires other
nodes in the vicinity.In extention to this B can also ask the node in =
the
vicinity if they can provide with the service that A wants=20

Definately security has to be kept in mind before going for this kind =
of
protocol.
=20
Second, For performance reasons A can broadcast and ask "Is there any =
node
that provides this services"?. Then the node providing the services =
that A
requires is send as an acknowledgement containing the=20

IP address. If multiple nodes provides the same then the best path can =
be
choosen. This is kind of flooding. This can be done in some controlled
manner.

Third if A doesnot know the services and want to use the services than =
the
nodes in the vicinity can broadcast "Do you want this service"? If yes =
then
it can use the service if wants to...

Actually, as far as I think in normal scinarios the combination of =
second &
third scheme is used? It broadcast for some periof4ds with certain no
retries(may be configurable). If fails then then there is no option=20

but to use third option......

=20

=20


Regards
Naveen Kumar Lall=20


"zb" wrote:


Hi, Frank,

Thanks your reply.

I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its =
IP
address
Then, the data can be exchanged between the two nodes. In MANET, there =
are
drafts on routing and IP address autoconfiguration. But, how to do =
service
discovery in ad hoc network? It seems there is no working group on =
service
discovery. Does it belong to upper layer which is out of IETF? Besides, =
how
does the service discovery collaborate with the routing in ad hoc =
network?

regard,

bin
----- Original Message -----
From: "Frank Dinies"=20
To: "zb"=20
Cc:=20
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do somethi! ng! ?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a =
short
boot-up-time, when a new device wants to participate, it knows about =
his
enviroment and vice versa. But this is only true for proactive =
algorithmens.

For reactive algorithmens or on-demand-algorithmens this is not true. =
This
algorithmens rely on special information or mechanismens for the =
boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with =
rapid
change and much participants. On-demand-ones roughly for the contrary. =
For
sensors that transmit from time to time small amounts of data for =
example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup =
problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and =
service
> ability of each other. There can be multihop between device A and =
device
B.
> How does the device A know it can get required service from device B =
and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/mane! t


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

=20


  _____ =20


Get Your Private, Free E-mail from Indiatimes at
 http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from
http://www.planetm.co.in  =20


------_=_NextPart_001_01C233DB.49DD00B0
Content-Type: text/html;
	charset="iso-8859-1"











Hi,


 


The 
answer would depend on the MANET.


 


In the 
general definition of a MANET, nodes are free to join or leave the MANET without 
any central control.  Security may be an issue, but that would depend on 
the MANET as well.  The key thing is that at any time, a node may join the 
MANET and that the node in question might offer some sort of service that other 
nodes do not generally offer or possess.  Examples would 
include:


    
  
  • A shared printer, say at a conference or 
  hotel,
    • 
  
  • A 
  gateway to the Internet
    • 
  
  • Emergency Medical services
    • 
  
  • Information services, such as a directory or 
  technical database


When 
such a node enters, existing nodes may not be aware that the services it offers 
even exist on the MANET.  In addition, even if a node suspected that a 
service existed, it has the problem of finding the IP of a node that offers such 
a service.  


 


Bear 
in mind that in wired nets, the existence and location of such services is known 
to the network administrators, who take care of both problems at initial node 
setup and propagate changes as they occur.  However, in a MANET, these 
things are supposed to happen automatically.


 


John 
Mullen



  
-----Original Message-----
From: MEDDOUR Djamal Eddine 
  thesard FTRD/DAC/LAN 
  [mailto:djamaleddine.meddour@rd.francetelecom.com]
Sent: Thursday, 
  July 25, 2002 1:52 AM
To: naveen_bits; zb; Frank 
  Dinies
Cc: manet@ietf.org
Subject: RE : Re: [manet] how 
  does ad hoc network do something?


  

  
Hi 
  all

  
I have two questions 
  about this subject:

  
 

  
Which type of 
  services we need (or car provided) at MANET? 

  
Which node will act 
  as service provider?

  
 

  
regards

  
 

  
 

  
-----Message 
  d'origine-----
De : 
  naveen_bits [mailto:naveen_bits@indiatimes.com] 
Envoyé : jeudi 25 juillet 2002 
  08:54
À : zb; Frank 
  Dinies
Cc : 
  manet@ietf.org
Objet : 
  Re: Re: [manet] how does ad hoc network do something?

  
 

  

Hi Bin,

  
Please correct me , If I am wrong , but this is what I 
  think about the concerned problem described below.

  
Let there be some nodes A & B , such that A is the 
  node that requires services of B

  
Logically speaking there can be following ways to 
  depict the information:-

  
First, If A knows the services it wants to use it may 
  ask the node B that "is this service is provided by you"? If yes then B can 
  act as a serverand provide these services. B Acknowledges yes or no by 
  

  
acknowledgement or A waits some randomn amount of time 
  & inquires other nodes in the vicinity.In extention to this B can also ask 
  the node in the vicinity if they can provide with the service that A wants 
  

  
Definately security has to be kept in mind before 
  going for this kind of protocol.
 
Second, For performance reasons 
  A can broadcast and ask "Is there any node that provides this services"?. Then 
  the node providing the services that A requires is send as an acknowledgement 
  containing the 

  
IP address. If multiple nodes provides the same then 
  the best path can be choosen. This is kind of flooding. This can be done in 
  some controlled manner.

  
Third if A doesnot know the services and want to use 
  the services than the nodes in the vicinity can broadcast "Do you want this 
  service"? If yes then it can use the service if wants to...

  
Actually, as far as I think in normal scinarios the 
  combination of second & third scheme is used? It broadcast for some 
  periof4ds with certain no retries(may be configurable). If fails then then 
  there is no option 

  
but to use third option......

  
 

  
 

  

Regards
Naveen Kumar Lall 
  


"zb" 
  wrote:

  

    

Hi, Frank,

Thanks your 
    reply.

I think, to make an ad hoc network to do something, two thing 
    must be
done:
1) to get an IP address of itself
2) to find the node 
    which can provide the required service and get its IP
address
Then, 
    the data can be exchanged between the two nodes. In MANET, there 
    are
drafts on routing and IP address autoconfiguration. But, how to do 
    service
discovery in ad hoc network? It seems there is no working group 
    on service
discovery. Does it belong to upper layer which is out of IETF? 
    Besides, how
does the service discovery collaborate with the routing in 
    ad hoc network?

regard,

bin
----- Original Message 
    -----
From: "Frank Dinies" 
To: "zb" 
    
Cc: 
Sent: Wednesday, July 24, 2002 
    7:01 PM
Subject: Re: [manet] how does ad hoc network do somethi! ng! 
    ?


Hi Zhen,

for proactive algorithmens like ADV or FSR 
    there is no problem. Mainly
because
this algorithmens rely on 
    periodically sent advertisments. So after a short
boot-up-time, when a 
    new device wants to participate, it knows about his
enviroment and vice 
    versa. But this is only true for proactive algorithmens.

For reactive 
    algorithmens or on-demand-algorithmens this is not true. 
    This
algorithmens rely on special information or mechanismens for the 
    boot-uptime
to scan their enviroment.

But keep in mind. Proactive 
    algorithmens are best in enviroments with rapid
change and much 
    participants. On-demand-ones roughly for the contrary. For
sensors that 
    transmit from time to time small amounts of data for example is
an 
    on-demand-one perfect.

hope this helps

frank

looking in 
    the RFCs or drafts could give you an idea. the bootup problem
mostly is 
    not trivial !

Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:
> 
    Hi,
>
> I have a question on how does the ad hoc network begin 
    to work? When
device
> A and device B are in a MANET, they do not 
    know IP address and service
> ability of each other. There can be 
    multihop between device A and device
B.
> How does the device A 
    know it can get required service from device B and
> communicate with 
    device B?
>
> Thanx.
>
> bin
> 
    *************************************
> Zhen Bin
>
> 
    i-Networking lab,
> Samsung Advanced Institute of Technology,
> 
    San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, 
    Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 
    82-31-2122268 (h)
> 
    *************************************
>
>
>
> 
    _______________________________________________
> manet mailing 
    list
> manet@ietf.org
> 
    https://www1.ietf.org/mailman/listinfo/mane! 
    t


_______________________________________________
manet 
    mailing 
    list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

  
 

  

  

  

  
Get Your 
  Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy 
  Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in 



------_=_NextPart_001_01C233DB.49DD00B0--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 25 09:30:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03264
	for ; Thu, 25 Jul 2002 09:30:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA27945
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 09:31:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25578;
	Thu, 25 Jul 2002 09:00:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25546
	for ; Thu, 25 Jul 2002 09:00:51 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01970
	for ; Thu, 25 Jul 2002 08:59:48 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117123>; Thu, 25 Jul 2002 07:00:47 -0600
Message-Id: <02Jul25.070047mdt.117123@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: naveen_bits 
Cc: manet@ietf.org
Subject: RE: RE : Re: [manet] how does ad hoc network do something?
Date:  Thu, 25 Jul 2002 07:00:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C233DB.49DD00B0"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

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_01C233DB.49DD00B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
The answer would depend on the MANET.
=20
In the general definition of a MANET, nodes are free to join or leave =
the
MANET without any central control.  Security may be an issue, but that =
would
depend on the MANET as well.  The key thing is that at any time, a node =
may
join the MANET and that the node in question might offer some sort of
service that other nodes do not generally offer or possess.  Examples =
would
include:

*	A shared printer, say at a conference or hotel,
*	A gateway to the Internet
*	Emergency Medical services
*	Information services, such as a directory or technical database

When such a node enters, existing nodes may not be aware that the =
services
it offers even exist on the MANET.  In addition, even if a node =
suspected
that a service existed, it has the problem of finding the IP of a node =
that
offers such a service. =20
=20
Bear in mind that in wired nets, the existence and location of such =
services
is known to the network administrators, who take care of both problems =
at
initial node setup and propagate changes as they occur.  However, in a
MANET, these things are supposed to happen automatically.
=20
John Mullen

-----Original Message-----
From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN
[mailto:djamaleddine.meddour@rd.francetelecom.com]
Sent: Thursday, July 25, 2002 1:52 AM
To: naveen_bits; zb; Frank Dinies
Cc: manet@ietf.org
Subject: RE : Re: [manet] how does ad hoc network do something?



Hi all

I have two questions about this subject:

=20

Which type of services we need (or car provided) at MANET?=20

Which node will act as service provider?

=20

regards

=20

=20

-----Message d'origine-----
De : naveen_bits [mailto:naveen_bits@indiatimes.com]=20
Envoy=E9 : jeudi 25 juillet 2002 08:54
=C0 : zb; Frank Dinies
Cc : manet@ietf.org
Objet : Re: Re: [manet] how does ad hoc network do something?

=20


Hi Bin,

Please correct me , If I am wrong , but this is what I think about the
concerned problem described below.

Let there be some nodes A & B , such that A is the node that requires
services of B

Logically speaking there can be following ways to depict the =
information:-

First, If A knows the services it wants to use it may ask the node B =
that
"is this service is provided by you"? If yes then B can act as a =
serverand
provide these services. B Acknowledges yes or no by=20

acknowledgement or A waits some randomn amount of time & inquires other
nodes in the vicinity.In extention to this B can also ask the node in =
the
vicinity if they can provide with the service that A wants=20

Definately security has to be kept in mind before going for this kind =
of
protocol.
=20
Second, For performance reasons A can broadcast and ask "Is there any =
node
that provides this services"?. Then the node providing the services =
that A
requires is send as an acknowledgement containing the=20

IP address. If multiple nodes provides the same then the best path can =
be
choosen. This is kind of flooding. This can be done in some controlled
manner.

Third if A doesnot know the services and want to use the services than =
the
nodes in the vicinity can broadcast "Do you want this service"? If yes =
then
it can use the service if wants to...

Actually, as far as I think in normal scinarios the combination of =
second &
third scheme is used? It broadcast for some periof4ds with certain no
retries(may be configurable). If fails then then there is no option=20

but to use third option......

=20

=20


Regards
Naveen Kumar Lall=20


"zb" wrote:


Hi, Frank,

Thanks your reply.

I think, to make an ad hoc network to do something, two thing must be
done:
1) to get an IP address of itself
2) to find the node which can provide the required service and get its =
IP
address
Then, the data can be exchanged between the two nodes. In MANET, there =
are
drafts on routing and IP address autoconfiguration. But, how to do =
service
discovery in ad hoc network? It seems there is no working group on =
service
discovery. Does it belong to upper layer which is out of IETF? Besides, =
how
does the service discovery collaborate with the routing in ad hoc =
network?

regard,

bin
----- Original Message -----
From: "Frank Dinies"=20
To: "zb"=20
Cc:=20
Sent: Wednesday, July 24, 2002 7:01 PM
Subject: Re: [manet] how does ad hoc network do somethi! ng! ?


Hi Zhen,

for proactive algorithmens like ADV or FSR there is no problem. Mainly
because
this algorithmens rely on periodically sent advertisments. So after a =
short
boot-up-time, when a new device wants to participate, it knows about =
his
enviroment and vice versa. But this is only true for proactive =
algorithmens.

For reactive algorithmens or on-demand-algorithmens this is not true. =
This
algorithmens rely on special information or mechanismens for the =
boot-uptime
to scan their enviroment.

But keep in mind. Proactive algorithmens are best in enviroments with =
rapid
change and much participants. On-demand-ones roughly for the contrary. =
For
sensors that transmit from time to time small amounts of data for =
example is
an on-demand-one perfect.

hope this helps

frank

looking in the RFCs or drafts could give you an idea. the bootup =
problem
mostly is not trivial !

Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:
> Hi,
>
> I have a question on how does the ad hoc network begin to work? When
device
> A and device B are in a MANET, they do not know IP address and =
service
> ability of each other. There can be multihop between device A and =
device
B.
> How does the device A know it can get required service from device B =
and
> communicate with device B?
>
> Thanx.
>
> bin
> *************************************
> Zhen Bin
>
> i-Networking lab,
> Samsung Advanced Institute of Technology,
> San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 82-31-2122268 (h)
> *************************************
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/mane! t


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

=20


  _____ =20


Get Your Private, Free E-mail from Indiatimes at
 http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from
http://www.planetm.co.in  =20


------_=_NextPart_001_01C233DB.49DD00B0
Content-Type: text/html;
	charset="iso-8859-1"











Hi,


 


The 
answer would depend on the MANET.


 


In the 
general definition of a MANET, nodes are free to join or leave the MANET without 
any central control.  Security may be an issue, but that would depend on 
the MANET as well.  The key thing is that at any time, a node may join the 
MANET and that the node in question might offer some sort of service that other 
nodes do not generally offer or possess.  Examples would 
include:


    
  
  • A shared printer, say at a conference or 
  hotel,
    • 
  
  • A 
  gateway to the Internet
    • 
  
  • Emergency Medical services
    • 
  
  • Information services, such as a directory or 
  technical database


When 
such a node enters, existing nodes may not be aware that the services it offers 
even exist on the MANET.  In addition, even if a node suspected that a 
service existed, it has the problem of finding the IP of a node that offers such 
a service.  


 


Bear 
in mind that in wired nets, the existence and location of such services is known 
to the network administrators, who take care of both problems at initial node 
setup and propagate changes as they occur.  However, in a MANET, these 
things are supposed to happen automatically.


 


John 
Mullen



  
-----Original Message-----
From: MEDDOUR Djamal Eddine 
  thesard FTRD/DAC/LAN 
  [mailto:djamaleddine.meddour@rd.francetelecom.com]
Sent: Thursday, 
  July 25, 2002 1:52 AM
To: naveen_bits; zb; Frank 
  Dinies
Cc: manet@ietf.org
Subject: RE : Re: [manet] how 
  does ad hoc network do something?


  

  
Hi 
  all

  
I have two questions 
  about this subject:

  
 

  
Which type of 
  services we need (or car provided) at MANET? 

  
Which node will act 
  as service provider?

  
 

  
regards

  
 

  
 

  
-----Message 
  d'origine-----
De : 
  naveen_bits [mailto:naveen_bits@indiatimes.com] 
Envoyé : jeudi 25 juillet 2002 
  08:54
À : zb; Frank 
  Dinies
Cc : 
  manet@ietf.org
Objet : 
  Re: Re: [manet] how does ad hoc network do something?

  
 

  

Hi Bin,

  
Please correct me , If I am wrong , but this is what I 
  think about the concerned problem described below.

  
Let there be some nodes A & B , such that A is the 
  node that requires services of B

  
Logically speaking there can be following ways to 
  depict the information:-

  
First, If A knows the services it wants to use it may 
  ask the node B that "is this service is provided by you"? If yes then B can 
  act as a serverand provide these services. B Acknowledges yes or no by 
  

  
acknowledgement or A waits some randomn amount of time 
  & inquires other nodes in the vicinity.In extention to this B can also ask 
  the node in the vicinity if they can provide with the service that A wants 
  

  
Definately security has to be kept in mind before 
  going for this kind of protocol.
 
Second, For performance reasons 
  A can broadcast and ask "Is there any node that provides this services"?. Then 
  the node providing the services that A requires is send as an acknowledgement 
  containing the 

  
IP address. If multiple nodes provides the same then 
  the best path can be choosen. This is kind of flooding. This can be done in 
  some controlled manner.

  
Third if A doesnot know the services and want to use 
  the services than the nodes in the vicinity can broadcast "Do you want this 
  service"? If yes then it can use the service if wants to...

  
Actually, as far as I think in normal scinarios the 
  combination of second & third scheme is used? It broadcast for some 
  periof4ds with certain no retries(may be configurable). If fails then then 
  there is no option 

  
but to use third option......

  
 

  
 

  

Regards
Naveen Kumar Lall 
  


"zb" 
  wrote:

  

    

Hi, Frank,

Thanks your 
    reply.

I think, to make an ad hoc network to do something, two thing 
    must be
done:
1) to get an IP address of itself
2) to find the node 
    which can provide the required service and get its IP
address
Then, 
    the data can be exchanged between the two nodes. In MANET, there 
    are
drafts on routing and IP address autoconfiguration. But, how to do 
    service
discovery in ad hoc network? It seems there is no working group 
    on service
discovery. Does it belong to upper layer which is out of IETF? 
    Besides, how
does the service discovery collaborate with the routing in 
    ad hoc network?

regard,

bin
----- Original Message 
    -----
From: "Frank Dinies" 
To: "zb" 
    
Cc: 
Sent: Wednesday, July 24, 2002 
    7:01 PM
Subject: Re: [manet] how does ad hoc network do somethi! ng! 
    ?


Hi Zhen,

for proactive algorithmens like ADV or FSR 
    there is no problem. Mainly
because
this algorithmens rely on 
    periodically sent advertisments. So after a short
boot-up-time, when a 
    new device wants to participate, it knows about his
enviroment and vice 
    versa. But this is only true for proactive algorithmens.

For reactive 
    algorithmens or on-demand-algorithmens this is not true. 
    This
algorithmens rely on special information or mechanismens for the 
    boot-uptime
to scan their enviroment.

But keep in mind. Proactive 
    algorithmens are best in enviroments with rapid
change and much 
    participants. On-demand-ones roughly for the contrary. For
sensors that 
    transmit from time to time small amounts of data for example is
an 
    on-demand-one perfect.

hope this helps

frank

looking in 
    the RFCs or drafts could give you an idea. the bootup problem
mostly is 
    not trivial !

Am Mittwoch, 24. Juli 2002 07:22! s! chrieb zb:
> 
    Hi,
>
> I have a question on how does the ad hoc network begin 
    to work? When
device
> A and device B are in a MANET, they do not 
    know IP address and service
> ability of each other. There can be 
    multihop between device A and device
B.
> How does the device A 
    know it can get required service from device B and
> communicate with 
    device B?
>
> Thanx.
>
> bin
> 
    *************************************
> Zhen Bin
>
> 
    i-Networking lab,
> Samsung Advanced Institute of Technology,
> 
    San14-1, NongSeo-ri, Kiheung-Eup,
> Yongin, Kyungki-do, 440600, 
    Korea
>
> 82-31-2809569 (fax)
> 82-31-2809534 (o)
> 
    82-31-2122268 (h)
> 
    *************************************
>
>
>
> 
    _______________________________________________
> manet mailing 
    list
> manet@ietf.org
> 
    https://www1.ietf.org/mailman/listinfo/mane! 
    t


_______________________________________________
manet 
    mailing 
    list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet

  
 

  

  

  

  
Get Your 
  Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy 
  Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in 



------_=_NextPart_001_01C233DB.49DD00B0--

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 13:13:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13051
	for ; Thu, 25 Jul 2002 13:13:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10923;
	Thu, 25 Jul 2002 12:43:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10893
	for ; Thu, 25 Jul 2002 12:43:09 -0400 (EDT)
Received: from mailhub.Dartmouth.EDU (mailhub.dartmouth.edu [129.170.16.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11676
	for ; Thu, 25 Jul 2002 12:42:03 -0400 (EDT)
Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7])
	by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id MAA06981
	for ; Thu, 25 Jul 2002 12:42:55 -0400 (EDT)
Message-id: <41751353@dancer.Dartmouth.EDU>
Date: 25 Jul 2002 12:42:54 EDT
From: Noah.H.Miller@Dartmouth.EDU (Noah H. Miller)
Reply-To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories)
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [manet] DSR RREQs
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hello,

I have several questions about DSR Requests:

First, upon retransmission of a Request (in the case in which no Reply was received before timeout), does the ID number of the Request get incremented?  If not, that is if the same ID is used for successive Request retransmissions, other nodes will ignore
 all but the first transmission, which seems like a waste.

Second, the following line on page 20 of Draft 7 confuses me.  The Route Request table is expected to record "The number of consecutive Route Discoveries initiated for this target since receiving a valid Route Reply giving a route to that target."  If thi
s node already has a route, why would it initiate a new Route Discovery?

Third, what are default values for retransmission of a Request?  Section 9 of Draft 7 suggests 16 retransmissions, with the first delay of 500 milliseconds, and subsequent delays of 500*2^(number of retransmissions).  This exponential backoff would reach 
tens of thousands of seconds by retransmission #16.  But there is also a Max Request Period of 10 seconds listed, which would allow only 4 retransmissions.  Is that enough?

Thank you,
Noah Miller
ISTS, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 25 13:13:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13059
	for ; Thu, 25 Jul 2002 13:13:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA13345
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 13:14:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10923;
	Thu, 25 Jul 2002 12:43:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10893
	for ; Thu, 25 Jul 2002 12:43:09 -0400 (EDT)
Received: from mailhub.Dartmouth.EDU (mailhub.dartmouth.edu [129.170.16.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11676
	for ; Thu, 25 Jul 2002 12:42:03 -0400 (EDT)
Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7])
	by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id MAA06981
	for ; Thu, 25 Jul 2002 12:42:55 -0400 (EDT)
Message-id: <41751353@dancer.Dartmouth.EDU>
Date: 25 Jul 2002 12:42:54 EDT
From: Noah.H.Miller@Dartmouth.EDU (Noah H. Miller)
Reply-To: Noah.H.Miller@Dartmouth.EDU (TrustMeImTellingYouStories)
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [manet] DSR RREQs
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hello,

I have several questions about DSR Requests:

First, upon retransmission of a Request (in the case in which no Reply was received before timeout), does the ID number of the Request get incremented?  If not, that is if the same ID is used for successive Request retransmissions, other nodes will ignore
 all but the first transmission, which seems like a waste.

Second, the following line on page 20 of Draft 7 confuses me.  The Route Request table is expected to record "The number of consecutive Route Discoveries initiated for this target since receiving a valid Route Reply giving a route to that target."  If thi
s node already has a route, why would it initiate a new Route Discovery?

Third, what are default values for retransmission of a Request?  Section 9 of Draft 7 suggests 16 retransmissions, with the first delay of 500 milliseconds, and subsequent delays of 500*2^(number of retransmissions).  This exponential backoff would reach 
tens of thousands of seconds by retransmission #16.  But there is also a Max Request Period of 10 seconds listed, which would allow only 4 retransmissions.  Is that enough?

Thank you,
Noah Miller
ISTS, Dartmouth College

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 14:51:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16963
	for ; Thu, 25 Jul 2002 14:51:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17409;
	Thu, 25 Jul 2002 14:28:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17384
	for ; Thu, 25 Jul 2002 14:28:00 -0400 (EDT)
Received: from web12702.mail.yahoo.com (web12702.mail.yahoo.com [216.136.173.239])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15743
	for ; Thu, 25 Jul 2002 14:26:54 -0400 (EDT)
Message-ID: <20020725182759.18274.qmail@web12702.mail.yahoo.com>
Received: from [128.211.1.49] by web12702.mail.yahoo.com via HTTP; Thu, 25 Jul 2002 11:27:59 PDT
Date: Thu, 25 Jul 2002 11:27:59 -0700 (PDT)
From: Anna Saputera 
Subject: Re: [manet] DSR RREQs
To: manet@ietf.org
In-Reply-To: <41751353@dancer.Dartmouth.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Noah,
I was trying to think about your questions. But, I am
not sure how I can find the "draft" that you mentioned
several times. Would you tell me where I can read it?

Thanks,
Anna





--- "Noah H. Miller" 
wrote:
> Hello,
> 
> I have several questions about DSR Requests:
> 
> First, upon retransmission of a Request (in the case
> in which no Reply was received before timeout), does
> the ID number of the Request get incremented?  If
> not, that is if the same ID is used for successive
> Request retransmissions, other nodes will ignore
>  all but the first transmission, which seems like a
> waste.
> 
> Second, the following line on page 20 of Draft 7
> confuses me.  The Route Request table is expected to
> record "The number of consecutive Route Discoveries
> initiated for this target since receiving a valid
> Route Reply giving a route to that target."  If thi
> s node already has a route, why would it initiate a
> new Route Discovery?
> 
> Third, what are default values for retransmission of
> a Request?  Section 9 of Draft 7 suggests 16
> retransmissions, with the first delay of 500
> milliseconds, and subsequent delays of 500*2^(number
> of retransmissions).  This exponential backoff would
> reach 
> tens of thousands of seconds by retransmission #16. 
> But there is also a Max Request Period of 10 seconds
> listed, which would allow only 4 retransmissions. 
> Is that enough?
> 
> Thank you,
> Noah Miller
> ISTS, Dartmouth College
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet


=====
Anna Saputera

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Thu Jul 25 14:51:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16973
	for ; Thu, 25 Jul 2002 14:51:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA19628
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 14:52:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17409;
	Thu, 25 Jul 2002 14:28:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17384
	for ; Thu, 25 Jul 2002 14:28:00 -0400 (EDT)
Received: from web12702.mail.yahoo.com (web12702.mail.yahoo.com [216.136.173.239])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15743
	for ; Thu, 25 Jul 2002 14:26:54 -0400 (EDT)
Message-ID: <20020725182759.18274.qmail@web12702.mail.yahoo.com>
Received: from [128.211.1.49] by web12702.mail.yahoo.com via HTTP; Thu, 25 Jul 2002 11:27:59 PDT
Date: Thu, 25 Jul 2002 11:27:59 -0700 (PDT)
From: Anna Saputera 
Subject: Re: [manet] DSR RREQs
To: manet@ietf.org
In-Reply-To: <41751353@dancer.Dartmouth.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Noah,
I was trying to think about your questions. But, I am
not sure how I can find the "draft" that you mentioned
several times. Would you tell me where I can read it?

Thanks,
Anna





--- "Noah H. Miller" 
wrote:
> Hello,
> 
> I have several questions about DSR Requests:
> 
> First, upon retransmission of a Request (in the case
> in which no Reply was received before timeout), does
> the ID number of the Request get incremented?  If
> not, that is if the same ID is used for successive
> Request retransmissions, other nodes will ignore
>  all but the first transmission, which seems like a
> waste.
> 
> Second, the following line on page 20 of Draft 7
> confuses me.  The Route Request table is expected to
> record "The number of consecutive Route Discoveries
> initiated for this target since receiving a valid
> Route Reply giving a route to that target."  If thi
> s node already has a route, why would it initiate a
> new Route Discovery?
> 
> Third, what are default values for retransmission of
> a Request?  Section 9 of Draft 7 suggests 16
> retransmissions, with the first delay of 500
> milliseconds, and subsequent delays of 500*2^(number
> of retransmissions).  This exponential backoff would
> reach 
> tens of thousands of seconds by retransmission #16. 
> But there is also a Max Request Period of 10 seconds
> listed, which would allow only 4 retransmissions. 
> Is that enough?
> 
> Thank you,
> Noah Miller
> ISTS, Dartmouth College
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet


=====
Anna Saputera

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 17:24:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21853
	for ; Thu, 25 Jul 2002 17:24:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27613;
	Thu, 25 Jul 2002 17:04:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27588
	for ; Thu, 25 Jul 2002 17:04:29 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21225
	for ; Thu, 25 Jul 2002 17:03:23 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11367;
	Thu, 25 Jul 2002 14:03:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6PL3tA20573;
	Thu, 25 Jul 2002 14:03:55 -0700
X-mProtect: <200207252103> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdh7R6QZ; Thu, 25 Jul 2002 14:03:52 PDT
Message-ID: <3D40672B.F3AEB284@iprg.nokia.com>
Date: Thu, 25 Jul 2002 14:01:31 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Neumiller 
CC: Mobile Ad Hoc IETF working group 
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Phil,

Phil Neumiller wrote:

> Hi,
>
>
> The AODV draft 11 does not specifically say what a mobile router is to do with
> ICMP Router Discovery messages.  Specifically, it does not address the ICMP
> Router Advertisements or Router Solicitation messages that will be multicast
> ICMP broadcasts as used by OSPF, BGP, etc.  Right?

Is a mobile router the thing that is under consideration within [nemo]?

> I propose that as an ad hoc network node detects that its current default fixed
> network routing connection is failing (a matter of debate in PILC, mobileip,
> seamoby, etc), that it mcast a ICMP Router Solicatation.

What do you think about the proposal in Ryuji Wakikawa's draft?
It is specified how to find a default router.  Your suggestion is, indeed,
used within that draft.

Regards,
Charlie P.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Thu Jul 25 17:24:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21860
	for ; Thu, 25 Jul 2002 17:24:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA28714
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 17:25:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27613;
	Thu, 25 Jul 2002 17:04:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27588
	for ; Thu, 25 Jul 2002 17:04:29 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21225
	for ; Thu, 25 Jul 2002 17:03:23 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11367;
	Thu, 25 Jul 2002 14:03:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6PL3tA20573;
	Thu, 25 Jul 2002 14:03:55 -0700
X-mProtect: <200207252103> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdh7R6QZ; Thu, 25 Jul 2002 14:03:52 PDT
Message-ID: <3D40672B.F3AEB284@iprg.nokia.com>
Date: Thu, 25 Jul 2002 14:01:31 -0700
From: Charlie Perkins 
Organization: Nokia
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Neumiller 
CC: Mobile Ad Hoc IETF working group 
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Phil,

Phil Neumiller wrote:

> Hi,
>
>
> The AODV draft 11 does not specifically say what a mobile router is to do with
> ICMP Router Discovery messages.  Specifically, it does not address the ICMP
> Router Advertisements or Router Solicitation messages that will be multicast
> ICMP broadcasts as used by OSPF, BGP, etc.  Right?

Is a mobile router the thing that is under consideration within [nemo]?

> I propose that as an ad hoc network node detects that its current default fixed
> network routing connection is failing (a matter of debate in PILC, mobileip,
> seamoby, etc), that it mcast a ICMP Router Solicatation.

What do you think about the proposal in Ryuji Wakikawa's draft?
It is specified how to find a default router.  Your suggestion is, indeed,
used within that draft.

Regards,
Charlie P.



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Thu Jul 25 22:01:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27110
	for ; Thu, 25 Jul 2002 22:01:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09718;
	Thu, 25 Jul 2002 21:32:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09686
	for ; Thu, 25 Jul 2002 21:32:06 -0400 (EDT)
Received: from smtp.263.net ([211.157.130.147])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26218
	for ; Thu, 25 Jul 2002 21:30:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by smtp.263.net (Postfix) with SMTP id ECB951D5DB321
	for ; Fri, 26 Jul 2002 09:20:18 +0800 (CST)
Received: from befine (unknown [211.71.13.13])
	by 192.168.30.28 (Coremail) with SMTP id UxMAAM+jQD2BGw0N.1
	for ; Fri, 26 Jul 2002 09:20:18 +0800 (CST)
Date: Fri, 26 Jul 2002 9:27:46 +0800
From: "Harry" 
To: "manet@ietf.org" 
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20020726012018.ECB951D5DB321@smtp.263.net>
Content-Transfer-Encoding: 7bit
Subject: [manet] Give me some help
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

hi all, 
	I am a beginner in MANET. Can anybody tell me some resouces on internet ? And Can u also introduce some famouse research groups or projects allover the world ?
	Thank u in advance.


				Harry



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@ns.ietf.org  Thu Jul 25 22:01:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27118
	for ; Thu, 25 Jul 2002 22:01:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA11431
	for manet-archive@odin.ietf.org; Thu, 25 Jul 2002 22:02:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09718;
	Thu, 25 Jul 2002 21:32:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09686
	for ; Thu, 25 Jul 2002 21:32:06 -0400 (EDT)
Received: from smtp.263.net ([211.157.130.147])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26218
	for ; Thu, 25 Jul 2002 21:30:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by smtp.263.net (Postfix) with SMTP id ECB951D5DB321
	for ; Fri, 26 Jul 2002 09:20:18 +0800 (CST)
Received: from befine (unknown [211.71.13.13])
	by 192.168.30.28 (Coremail) with SMTP id UxMAAM+jQD2BGw0N.1
	for ; Fri, 26 Jul 2002 09:20:18 +0800 (CST)
Date: Fri, 26 Jul 2002 9:27:46 +0800
From: "Harry" 
To: "manet@ietf.org" 
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20020726012018.ECB951D5DB321@smtp.263.net>
Content-Transfer-Encoding: 7bit
Subject: [manet] Give me some help
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

hi all, 
	I am a beginner in MANET. Can anybody tell me some resouces on internet ? And Can u also introduce some famouse research groups or projects allover the world ?
	Thank u in advance.


				Harry



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 26 09:22:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18905
	for ; Fri, 26 Jul 2002 09:22:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19600;
	Fri, 26 Jul 2002 08:54:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19570
	for ; Fri, 26 Jul 2002 08:54:39 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17402
	for ; Fri, 26 Jul 2002 08:53:32 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF260STH; Fri, 26 Jul 2002 08:54:22 -0400
Message-ID: <01a701c234a3$9027b470$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Charlie Perkins" ,
        "Elizabeth M.Belding-Royer" , 
Cc: "Mobile Ad Hoc IETF working group" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D40672B.F3AEB284@iprg.nokia.com>
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
Date: Fri, 26 Jul 2002 08:54:22 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Charlie, Elizabeth, Yuan,

I have some comments on draft-royer-manet-globalv4-00.txt.  I did not
like some things about the draft so please be patient with my complaints.  :-)  
I have suggested a possible alternative approach that I believe is more "generic".

There seems to be a few different classes of things that use similar mechanisms to
Router Discovery as proposed in RFC 1256 (I am sticking with IPv4 in this letter).  

o Foreign Agent / Home Agent Advertisement uses RFC-1256 with extensions. 
o IGPs such as OSPF / EIGRP etc use RFC-1256 directly.
o Draft draft-royer-manet-globalv4-00.txt makes does not make direct use of RFC-1256.

A quote from draft-royer-manet-globalv4-00.txt states

    "Agent Advertisement messages initiated by foreign agents are re-broadcast
     by the nodes within the ad hoc network so that mobile nodes may learn of the
     presence of the FA".

1). This can only imply limited flooding, which should always be avoided if possible.

2).  The draft implies a change is needed for MIP FAs.  This does not seem like
      a good idea to me.  Furthermore, the suggested change only addresses AODV 
      not other MANET protocols.

3).  I believe a "clean use" of RFC 1256 is possible without any modification to 
      MIP.

4).  I believe the term access point should be avoided.  The industry trend for
      access points is towards dumb wireless to wireline bridges, i.e. 802.11b/a/g
      APs.  A more appropriate word might be fixed network /wireline router.

5).  The method also implies that AODV nodes are being proactive about 
       mobility agents and always putting a default route into to an FA when 
       they "hear" advertisements (or the flood occurs).

6).  It may be necessary to discover land-line IGP routers that are on the path 
      between the path of the AODV network and the FA/HA. 

7).  I believe its a very bad idea to force the MANET node to issue a RREQ
      to proactively discover a foreign agent.  A far more generic approach would
      be to use RFC-1256 directly.  That way all MANET protocols could use the
      same method (not just AODV).   The MANET nodes can proxy response
      Router/Agent solicitations over ICMP.

8).  The case where the MANET protocol does not support mulit-cast must be
      addressed in more detail.

9).  NETWORK_DIAMETER is not a stable number (I don't believe you can
       just set this to 10 and be happy).  In some cases this could completely swamp
       the ad hoc network.  An expanded ring search COULD work, but I like ICMP
       proxy responders much better (explained below).  

My proposal is to stick to RFC-1256.  Each MANET node (not just an AODV) node
will relay ICMP broadcasts and decrement the TTL field.  This provides the flood
limiting.  Furthermore, MANET nodes that have discovered a land line router OR a
mobility agent can proxy response for ICMP Router Solicitations.  This has the 
very same affect as does the RREQ (AODV specific) proposal.
   
BTW, the title of this draft is a bit presumptuous being called "manet-globalv4" since
it really advocates an AODV specific solution.  I think the technique can be more
generic if only ICMP messages are used.  Th

Best regards,

Phil

----- Original Message ----- 
From: "Charlie Perkins" 
To: "Phil Neumiller" 
Cc: "Mobile Ad Hoc IETF working group" 
Sent: Thursday, July 25, 2002 5:01 PM
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements


> Hello Phil,
> 
> Phil Neumiller wrote:
> 
> > Hi,
> >
> >
> > The AODV draft 11 does not specifically say what a mobile router is to do with
> > ICMP Router Discovery messages.  Specifically, it does not address the ICMP
> > Router Advertisements or Router Solicitation messages that will be multicast
> > ICMP broadcasts as used by OSPF, BGP, etc.  Right?
> 
> Is a mobile router the thing that is under consideration within [nemo]?
> 
> > I propose that as an ad hoc network node detects that its current default fixed
> > network routing connection is failing (a matter of debate in PILC, mobileip,
> > seamoby, etc), that it mcast a ICMP Router Solicatation.
> 
> What do you think about the proposal in Ryuji Wakikawa's draft?
> It is specified how to find a default router.  Your suggestion is, indeed,
> used within that draft.
> 
> Regards,
> Charlie P.
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 26 09:22:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18913
	for ; Fri, 26 Jul 2002 09:22:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA21753
	for manet-archive@odin.ietf.org; Fri, 26 Jul 2002 09:23:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19600;
	Fri, 26 Jul 2002 08:54:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19570
	for ; Fri, 26 Jul 2002 08:54:39 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17402
	for ; Fri, 26 Jul 2002 08:53:32 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF260STH; Fri, 26 Jul 2002 08:54:22 -0400
Message-ID: <01a701c234a3$9027b470$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Charlie Perkins" ,
        "Elizabeth M.Belding-Royer" , 
Cc: "Mobile Ad Hoc IETF working group" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D40672B.F3AEB284@iprg.nokia.com>
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
Date: Fri, 26 Jul 2002 08:54:22 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Charlie, Elizabeth, Yuan,

I have some comments on draft-royer-manet-globalv4-00.txt.  I did not
like some things about the draft so please be patient with my complaints.  :-)  
I have suggested a possible alternative approach that I believe is more "generic".

There seems to be a few different classes of things that use similar mechanisms to
Router Discovery as proposed in RFC 1256 (I am sticking with IPv4 in this letter).  

o Foreign Agent / Home Agent Advertisement uses RFC-1256 with extensions. 
o IGPs such as OSPF / EIGRP etc use RFC-1256 directly.
o Draft draft-royer-manet-globalv4-00.txt makes does not make direct use of RFC-1256.

A quote from draft-royer-manet-globalv4-00.txt states

    "Agent Advertisement messages initiated by foreign agents are re-broadcast
     by the nodes within the ad hoc network so that mobile nodes may learn of the
     presence of the FA".

1). This can only imply limited flooding, which should always be avoided if possible.

2).  The draft implies a change is needed for MIP FAs.  This does not seem like
      a good idea to me.  Furthermore, the suggested change only addresses AODV 
      not other MANET protocols.

3).  I believe a "clean use" of RFC 1256 is possible without any modification to 
      MIP.

4).  I believe the term access point should be avoided.  The industry trend for
      access points is towards dumb wireless to wireline bridges, i.e. 802.11b/a/g
      APs.  A more appropriate word might be fixed network /wireline router.

5).  The method also implies that AODV nodes are being proactive about 
       mobility agents and always putting a default route into to an FA when 
       they "hear" advertisements (or the flood occurs).

6).  It may be necessary to discover land-line IGP routers that are on the path 
      between the path of the AODV network and the FA/HA. 

7).  I believe its a very bad idea to force the MANET node to issue a RREQ
      to proactively discover a foreign agent.  A far more generic approach would
      be to use RFC-1256 directly.  That way all MANET protocols could use the
      same method (not just AODV).   The MANET nodes can proxy response
      Router/Agent solicitations over ICMP.

8).  The case where the MANET protocol does not support mulit-cast must be
      addressed in more detail.

9).  NETWORK_DIAMETER is not a stable number (I don't believe you can
       just set this to 10 and be happy).  In some cases this could completely swamp
       the ad hoc network.  An expanded ring search COULD work, but I like ICMP
       proxy responders much better (explained below).  

My proposal is to stick to RFC-1256.  Each MANET node (not just an AODV) node
will relay ICMP broadcasts and decrement the TTL field.  This provides the flood
limiting.  Furthermore, MANET nodes that have discovered a land line router OR a
mobility agent can proxy response for ICMP Router Solicitations.  This has the 
very same affect as does the RREQ (AODV specific) proposal.
   
BTW, the title of this draft is a bit presumptuous being called "manet-globalv4" since
it really advocates an AODV specific solution.  I think the technique can be more
generic if only ICMP messages are used.  Th

Best regards,

Phil

----- Original Message ----- 
From: "Charlie Perkins" 
To: "Phil Neumiller" 
Cc: "Mobile Ad Hoc IETF working group" 
Sent: Thursday, July 25, 2002 5:01 PM
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements


> Hello Phil,
> 
> Phil Neumiller wrote:
> 
> > Hi,
> >
> >
> > The AODV draft 11 does not specifically say what a mobile router is to do with
> > ICMP Router Discovery messages.  Specifically, it does not address the ICMP
> > Router Advertisements or Router Solicitation messages that will be multicast
> > ICMP broadcasts as used by OSPF, BGP, etc.  Right?
> 
> Is a mobile router the thing that is under consideration within [nemo]?
> 
> > I propose that as an ad hoc network node detects that its current default fixed
> > network routing connection is failing (a matter of debate in PILC, mobileip,
> > seamoby, etc), that it mcast a ICMP Router Solicatation.
> 
> What do you think about the proposal in Ryuji Wakikawa's draft?
> It is specified how to find a default router.  Your suggestion is, indeed,
> used within that draft.
> 
> Regards,
> Charlie P.
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 26 12:46:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29409
	for ; Fri, 26 Jul 2002 12:46:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04819;
	Fri, 26 Jul 2002 12:13:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04790
	for ; Fri, 26 Jul 2002 12:13:16 -0400 (EDT)
Received: from diver.doc.ic.ac.uk (diver.doc.ic.ac.uk [146.169.1.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27648
	for ; Fri, 26 Jul 2002 12:12:10 -0400 (EDT)
Received: from corby.doc.ic.ac.uk ([146.169.5.105] helo=CORBY)
	by diver.doc.ic.ac.uk with smtp (Exim 3.16 #7)
	id 17Y7iI-0001j9-00
	for manet@ietf.org; Fri, 26 Jul 2002 17:13:10 +0100
Reply-To: 
From: "Sye Loong Keoh" 
To: 
Date: Fri, 26 Jul 2002 17:13:08 +0100
Message-ID: <000001c234bf$55a611e0$6905a992@win.doc.ic.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <200207261600.MAA03431@optimus.ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [manet] Proem Development Kit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,
	Does anybody know where can I get a copy of Proem Development Kit and Proem
Runtime System developed by Weareables Computing Laboratory, University of
Oregon? I tried to download from their website
http://wearables.cs.uoregon.edu/proem but it is a password proteced site, I
also tried to request a copy from Mr. Gerd Kortuem, but I haven't receive
any reply from him.

	Proem is a development kit and runtime system for rapid development and
deployment of mobile ad-hoc network. I would like to take a look at the
architecture because I am a PhD student working on security for mobile
ad-hoc network.

	If anybody know about the alternative ways to get the software or contact
Wearable Computing Laboratory, U of Oregon, please let me know. Thanks and
regards.

Sye Loong


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 26 12:46:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29417
	for ; Fri, 26 Jul 2002 12:46:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA07323
	for manet-archive@odin.ietf.org; Fri, 26 Jul 2002 12:47:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04819;
	Fri, 26 Jul 2002 12:13:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04790
	for ; Fri, 26 Jul 2002 12:13:16 -0400 (EDT)
Received: from diver.doc.ic.ac.uk (diver.doc.ic.ac.uk [146.169.1.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27648
	for ; Fri, 26 Jul 2002 12:12:10 -0400 (EDT)
Received: from corby.doc.ic.ac.uk ([146.169.5.105] helo=CORBY)
	by diver.doc.ic.ac.uk with smtp (Exim 3.16 #7)
	id 17Y7iI-0001j9-00
	for manet@ietf.org; Fri, 26 Jul 2002 17:13:10 +0100
Reply-To: 
From: "Sye Loong Keoh" 
To: 
Date: Fri, 26 Jul 2002 17:13:08 +0100
Message-ID: <000001c234bf$55a611e0$6905a992@win.doc.ic.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <200207261600.MAA03431@optimus.ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [manet] Proem Development Kit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi,
	Does anybody know where can I get a copy of Proem Development Kit and Proem
Runtime System developed by Weareables Computing Laboratory, University of
Oregon? I tried to download from their website
http://wearables.cs.uoregon.edu/proem but it is a password proteced site, I
also tried to request a copy from Mr. Gerd Kortuem, but I haven't receive
any reply from him.

	Proem is a development kit and runtime system for rapid development and
deployment of mobile ad-hoc network. I would like to take a look at the
architecture because I am a PhD student working on security for mobile
ad-hoc network.

	If anybody know about the alternative ways to get the software or contact
Wearable Computing Laboratory, U of Oregon, please let me know. Thanks and
regards.

Sye Loong


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 26 13:08:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00333
	for ; Fri, 26 Jul 2002 13:08:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06567;
	Fri, 26 Jul 2002 12:35:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06539
	for ; Fri, 26 Jul 2002 12:35:05 -0400 (EDT)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28720
	for ; Fri, 26 Jul 2002 12:33:55 -0400 (EDT)
Received: from zidane.cc.vt.edu (IDENT:mirapoint@zidane-lb.cc.vt.edu [10.1.1.13])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g6QGZ0b498644
	for ; Fri, 26 Jul 2002 12:35:00 -0400 (EDT)
Received: from zathras (zathras.cc.vt.edu [198.82.162.117])
	by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AMC40987;
	Fri, 26 Jul 2002 12:35:00 -0400 (EDT)
X-WebMail-UserID:  knadkarn
Date: Fri, 26 Jul 2002 12:35:00 -0400
From: Ketan Nadkarni 
To: manet@ietf.org
X-EXP32-SerialNo: 00002964
Message-ID: <3D45AF20@zathras>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: WebMail (Hydra) SMTP v3.62
Content-Transfer-Encoding: 7bit
Subject: [manet] IP Address Allocation in CDMA-based Wireless Network
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi All

I am not sure if this is the right forum for my question but I thought of 
giving it a try.

Would any one be able to tell me where I can get material on IP address 
allocation, distribution and advertising schemes for a CDMA based wireless 
cellular network?

I would gladly appreciate it.
Thanks,
Ketan Nadkarni
______________________
Graduate Student
Virginia Tech


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 26 13:08:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00339
	for ; Fri, 26 Jul 2002 13:08:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA08927
	for manet-archive@odin.ietf.org; Fri, 26 Jul 2002 13:09:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06567;
	Fri, 26 Jul 2002 12:35:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06539
	for ; Fri, 26 Jul 2002 12:35:05 -0400 (EDT)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28720
	for ; Fri, 26 Jul 2002 12:33:55 -0400 (EDT)
Received: from zidane.cc.vt.edu (IDENT:mirapoint@zidane-lb.cc.vt.edu [10.1.1.13])
	by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g6QGZ0b498644
	for ; Fri, 26 Jul 2002 12:35:00 -0400 (EDT)
Received: from zathras (zathras.cc.vt.edu [198.82.162.117])
	by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AMC40987;
	Fri, 26 Jul 2002 12:35:00 -0400 (EDT)
X-WebMail-UserID:  knadkarn
Date: Fri, 26 Jul 2002 12:35:00 -0400
From: Ketan Nadkarni 
To: manet@ietf.org
X-EXP32-SerialNo: 00002964
Message-ID: <3D45AF20@zathras>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: WebMail (Hydra) SMTP v3.62
Content-Transfer-Encoding: 7bit
Subject: [manet] IP Address Allocation in CDMA-based Wireless Network
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi All

I am not sure if this is the right forum for my question but I thought of 
giving it a try.

Would any one be able to tell me where I can get material on IP address 
allocation, distribution and advertising schemes for a CDMA based wireless 
cellular network?

I would gladly appreciate it.
Thanks,
Ketan Nadkarni
______________________
Graduate Student
Virginia Tech


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 26 15:13:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04856
	for ; Fri, 26 Jul 2002 15:13:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14517;
	Fri, 26 Jul 2002 14:44:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14486
	for ; Fri, 26 Jul 2002 14:44:04 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03834
	for ; Fri, 26 Jul 2002 14:42:57 -0400 (EDT)
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA16498;
	Fri, 26 Jul 2002 11:44:01 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA11014;
	Fri, 26 Jul 2002 11:43:32 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6QIi0618262;
	Fri, 26 Jul 2002 11:44:00 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <37GW5A12>; Fri, 26 Jul 2002 14:43:59 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A53@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Phil Neumiller'" 
Cc: Mobile Ad Hoc IETF working group 
Subject: RE: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertiseme
	nts
Date: Fri, 26 Jul 2002 14:43:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

To the extent that "me too"s are worth anything, I second Phil's points. There is no need, IMO, for a special "foreign agent" advertisement. I'd also stick with existing standards, since they seem to provide all the required features as is, as far as what is required of the wired Internet. If Mobile IP doesn't need a FA advertisement, I really fail to see why MANET would.

Bert


> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Friday, July 26, 2002 8:54 AM
> To: Charlie Perkins; Elizabeth M.Belding-Royer; suny@cs.ucsb.edu
> Cc: Mobile Ad Hoc IETF working group
> Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway
> Advertisements
> 
> 
> Hi Charlie, Elizabeth, Yuan,
> 
> I have some comments on draft-royer-manet-globalv4-00.txt.  I did not
> like some things about the draft so please be patient with my 
> complaints.  :-)  
> I have suggested a possible alternative approach that I 
> believe is more "generic".
> 
> There seems to be a few different classes of things that use 
> similar mechanisms to
> Router Discovery as proposed in RFC 1256 (I am sticking with 
> IPv4 in this letter).  
> 
> o Foreign Agent / Home Agent Advertisement uses RFC-1256 with 
> extensions. 
> o IGPs such as OSPF / EIGRP etc use RFC-1256 directly.
> o Draft draft-royer-manet-globalv4-00.txt makes does not make 
> direct use of RFC-1256.
> 
> A quote from draft-royer-manet-globalv4-00.txt states
> 
>     "Agent Advertisement messages initiated by foreign agents 
> are re-broadcast
>      by the nodes within the ad hoc network so that mobile 
> nodes may learn of the
>      presence of the FA".
> 
> 1). This can only imply limited flooding, which should always 
> be avoided if possible.
> 
> 2).  The draft implies a change is needed for MIP FAs.  This 
> does not seem like
>       a good idea to me.  Furthermore, the suggested change 
> only addresses AODV 
>       not other MANET protocols.
> 
> 3).  I believe a "clean use" of RFC 1256 is possible without 
> any modification to 
>       MIP.
> 
> 4).  I believe the term access point should be avoided.  The 
> industry trend for
>       access points is towards dumb wireless to wireline 
> bridges, i.e. 802.11b/a/g
>       APs.  A more appropriate word might be fixed network 
> /wireline router.
> 
> 5).  The method also implies that AODV nodes are being 
> proactive about 
>        mobility agents and always putting a default route 
> into to an FA when 
>        they "hear" advertisements (or the flood occurs).
> 
> 6).  It may be necessary to discover land-line IGP routers 
> that are on the path 
>       between the path of the AODV network and the FA/HA. 
> 
> 7).  I believe its a very bad idea to force the MANET node to 
> issue a RREQ
>       to proactively discover a foreign agent.  A far more 
> generic approach would
>       be to use RFC-1256 directly.  That way all MANET 
> protocols could use the
>       same method (not just AODV).   The MANET nodes can 
> proxy response
>       Router/Agent solicitations over ICMP.
> 
> 8).  The case where the MANET protocol does not support 
> mulit-cast must be
>       addressed in more detail.
> 
> 9).  NETWORK_DIAMETER is not a stable number (I don't believe you can
>        just set this to 10 and be happy).  In some cases this 
> could completely swamp
>        the ad hoc network.  An expanded ring search COULD 
> work, but I like ICMP
>        proxy responders much better (explained below).  
> 
> My proposal is to stick to RFC-1256.  Each MANET node (not 
> just an AODV) node
> will relay ICMP broadcasts and decrement the TTL field.  This 
> provides the flood
> limiting.  Furthermore, MANET nodes that have discovered a 
> land line router OR a
> mobility agent can proxy response for ICMP Router 
> Solicitations.  This has the 
> very same affect as does the RREQ (AODV specific) proposal.
>    
> BTW, the title of this draft is a bit presumptuous being 
> called "manet-globalv4" since
> it really advocates an AODV specific solution.  I think the 
> technique can be more
> generic if only ICMP messages are used.  Th
> 
> Best regards,
> 
> Phil
> 
> ----- Original Message ----- 
> From: "Charlie Perkins" 
> To: "Phil Neumiller" 
> Cc: "Mobile Ad Hoc IETF working group" 
> Sent: Thursday, July 25, 2002 5:01 PM
> Subject: Re: OSPF to AODV bridging was Re: [manet] RE: 
> Gateway Advertisements
> 
> 
> > Hello Phil,
> > 
> > Phil Neumiller wrote:
> > 
> > > Hi,
> > >
> > >
> > > The AODV draft 11 does not specifically say what a mobile 
> router is to do with
> > > ICMP Router Discovery messages.  Specifically, it does 
> not address the ICMP
> > > Router Advertisements or Router Solicitation messages 
> that will be multicast
> > > ICMP broadcasts as used by OSPF, BGP, etc.  Right?
> > 
> > Is a mobile router the thing that is under consideration 
> within [nemo]?
> > 
> > > I propose that as an ad hoc network node detects that its 
> current default fixed
> > > network routing connection is failing (a matter of debate 
> in PILC, mobileip,
> > > seamoby, etc), that it mcast a ICMP Router Solicatation.
> > 
> > What do you think about the proposal in Ryuji Wakikawa's draft?
> > It is specified how to find a default router.  Your 
> suggestion is, indeed,
> > used within that draft.
> > 
> > Regards,
> > Charlie P.
> > 
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 26 15:13:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04865
	for ; Fri, 26 Jul 2002 15:13:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA16725
	for manet-archive@odin.ietf.org; Fri, 26 Jul 2002 15:14:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14517;
	Fri, 26 Jul 2002 14:44:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14486
	for ; Fri, 26 Jul 2002 14:44:04 -0400 (EDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03834
	for ; Fri, 26 Jul 2002 14:42:57 -0400 (EDT)
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA16498;
	Fri, 26 Jul 2002 11:44:01 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA11014;
	Fri, 26 Jul 2002 11:43:32 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6QIi0618262;
	Fri, 26 Jul 2002 11:44:00 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <37GW5A12>; Fri, 26 Jul 2002 14:43:59 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A53@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'Phil Neumiller'" 
Cc: Mobile Ad Hoc IETF working group 
Subject: RE: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertiseme
	nts
Date: Fri, 26 Jul 2002 14:43:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

To the extent that "me too"s are worth anything, I second Phil's points. There is no need, IMO, for a special "foreign agent" advertisement. I'd also stick with existing standards, since they seem to provide all the required features as is, as far as what is required of the wired Internet. If Mobile IP doesn't need a FA advertisement, I really fail to see why MANET would.

Bert


> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@meshnetworks.com]
> Sent: Friday, July 26, 2002 8:54 AM
> To: Charlie Perkins; Elizabeth M.Belding-Royer; suny@cs.ucsb.edu
> Cc: Mobile Ad Hoc IETF working group
> Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway
> Advertisements
> 
> 
> Hi Charlie, Elizabeth, Yuan,
> 
> I have some comments on draft-royer-manet-globalv4-00.txt.  I did not
> like some things about the draft so please be patient with my 
> complaints.  :-)  
> I have suggested a possible alternative approach that I 
> believe is more "generic".
> 
> There seems to be a few different classes of things that use 
> similar mechanisms to
> Router Discovery as proposed in RFC 1256 (I am sticking with 
> IPv4 in this letter).  
> 
> o Foreign Agent / Home Agent Advertisement uses RFC-1256 with 
> extensions. 
> o IGPs such as OSPF / EIGRP etc use RFC-1256 directly.
> o Draft draft-royer-manet-globalv4-00.txt makes does not make 
> direct use of RFC-1256.
> 
> A quote from draft-royer-manet-globalv4-00.txt states
> 
>     "Agent Advertisement messages initiated by foreign agents 
> are re-broadcast
>      by the nodes within the ad hoc network so that mobile 
> nodes may learn of the
>      presence of the FA".
> 
> 1). This can only imply limited flooding, which should always 
> be avoided if possible.
> 
> 2).  The draft implies a change is needed for MIP FAs.  This 
> does not seem like
>       a good idea to me.  Furthermore, the suggested change 
> only addresses AODV 
>       not other MANET protocols.
> 
> 3).  I believe a "clean use" of RFC 1256 is possible without 
> any modification to 
>       MIP.
> 
> 4).  I believe the term access point should be avoided.  The 
> industry trend for
>       access points is towards dumb wireless to wireline 
> bridges, i.e. 802.11b/a/g
>       APs.  A more appropriate word might be fixed network 
> /wireline router.
> 
> 5).  The method also implies that AODV nodes are being 
> proactive about 
>        mobility agents and always putting a default route 
> into to an FA when 
>        they "hear" advertisements (or the flood occurs).
> 
> 6).  It may be necessary to discover land-line IGP routers 
> that are on the path 
>       between the path of the AODV network and the FA/HA. 
> 
> 7).  I believe its a very bad idea to force the MANET node to 
> issue a RREQ
>       to proactively discover a foreign agent.  A far more 
> generic approach would
>       be to use RFC-1256 directly.  That way all MANET 
> protocols could use the
>       same method (not just AODV).   The MANET nodes can 
> proxy response
>       Router/Agent solicitations over ICMP.
> 
> 8).  The case where the MANET protocol does not support 
> mulit-cast must be
>       addressed in more detail.
> 
> 9).  NETWORK_DIAMETER is not a stable number (I don't believe you can
>        just set this to 10 and be happy).  In some cases this 
> could completely swamp
>        the ad hoc network.  An expanded ring search COULD 
> work, but I like ICMP
>        proxy responders much better (explained below).  
> 
> My proposal is to stick to RFC-1256.  Each MANET node (not 
> just an AODV) node
> will relay ICMP broadcasts and decrement the TTL field.  This 
> provides the flood
> limiting.  Furthermore, MANET nodes that have discovered a 
> land line router OR a
> mobility agent can proxy response for ICMP Router 
> Solicitations.  This has the 
> very same affect as does the RREQ (AODV specific) proposal.
>    
> BTW, the title of this draft is a bit presumptuous being 
> called "manet-globalv4" since
> it really advocates an AODV specific solution.  I think the 
> technique can be more
> generic if only ICMP messages are used.  Th
> 
> Best regards,
> 
> Phil
> 
> ----- Original Message ----- 
> From: "Charlie Perkins" 
> To: "Phil Neumiller" 
> Cc: "Mobile Ad Hoc IETF working group" 
> Sent: Thursday, July 25, 2002 5:01 PM
> Subject: Re: OSPF to AODV bridging was Re: [manet] RE: 
> Gateway Advertisements
> 
> 
> > Hello Phil,
> > 
> > Phil Neumiller wrote:
> > 
> > > Hi,
> > >
> > >
> > > The AODV draft 11 does not specifically say what a mobile 
> router is to do with
> > > ICMP Router Discovery messages.  Specifically, it does 
> not address the ICMP
> > > Router Advertisements or Router Solicitation messages 
> that will be multicast
> > > ICMP broadcasts as used by OSPF, BGP, etc.  Right?
> > 
> > Is a mobile router the thing that is under consideration 
> within [nemo]?
> > 
> > > I propose that as an ad hoc network node detects that its 
> current default fixed
> > > network routing connection is failing (a matter of debate 
> in PILC, mobileip,
> > > seamoby, etc), that it mcast a ICMP Router Solicatation.
> > 
> > What do you think about the proposal in Ryuji Wakikawa's draft?
> > It is specified how to find a default router.  Your 
> suggestion is, indeed,
> > used within that draft.
> > 
> > Regards,
> > Charlie P.
> > 
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Fri Jul 26 20:40:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13239
	for ; Fri, 26 Jul 2002 20:40:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01306;
	Fri, 26 Jul 2002 20:03:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01281
	for ; Fri, 26 Jul 2002 20:03:29 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12567
	for ; Fri, 26 Jul 2002 20:02:21 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27980;
	Fri, 26 Jul 2002 17:02:54 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6R02r630455;
	Fri, 26 Jul 2002 17:02:53 -0700
X-mProtect: <200207270002> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdzKdZ27; Fri, 26 Jul 2002 17:02:50 PDT
Message-ID: <3D41E32B.F23FD36F@iprg.nokia.com>
Date: Fri, 26 Jul 2002 17:02:51 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Neumiller 
CC: "Elizabeth M.Belding-Royer" , suny@cs.ucsb.edu,
        Mobile Ad Hoc IETF working group 
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Phil,

I have just a few comments.  If you've been tuning in, you'll
remember that there are many different opinions on this subject.
I reckon that it largely depends on one's assumptions, and I am
hoping we can find a good generic solution for the widest
class of applications (still not universal).

Phil Neumiller wrote:
> 
> Hi Charlie, Elizabeth, Yuan,

> There seems to be a few different classes of things that use similar mechanisms to
> Router Discovery as proposed in RFC 1256 (I am sticking with IPv4 in this letter).

RFC 1256 has various restrictions that orient it towards working on
a "link" (e.g., TTL=1).  That's a problem, albeit one not hard to
overcome.

> o Foreign Agent / Home Agent Advertisement uses RFC-1256 with extensions.
> o IGPs such as OSPF / EIGRP etc use RFC-1256 directly.
> o Draft draft-royer-manet-globalv4-00.txt makes does not make direct use of RFC-1256.

Whether to model the advertisements as RFC-1256 or something else
is a matter of taste, not protocol correctness.  Plus, my own
experience with Mobile IP is that using RFC 1256 was a mistake.

> A quote from draft-royer-manet-globalv4-00.txt states
> 
>     "Agent Advertisement messages initiated by foreign agents are re-broadcast
>      by the nodes within the ad hoc network so that mobile nodes may learn of the
>      presence of the FA".

> 1). This can only imply limited flooding, which should always be avoided if possible.

So you're saying no flooding?  Others say flooding is the "only answer".

> 2).  The draft implies a change is needed for MIP FAs.  This does not seem like
>       a good idea to me.  Furthermore, the suggested change only addresses AODV
>       not other MANET protocols.

I agree that other protocols should be addressed also.  This draft,
I think we can agree, needs further development.

Furthermore, I think that any such Internet Gateway node, as a
foreign agent would be here, needs to obey the routing protocol
in use in the ad hoc network.

> 3).  I believe a "clean use" of RFC 1256 is possible without any modification to
>       MIP.

MIP already modifies RFC 1256.  I'm not clear where you're heading on this.

> 4).  I believe the term access point should be avoided.  The industry trend for
>       access points is towards dumb wireless to wireline bridges, i.e. 802.11b/a/g
>       APs.  A more appropriate word might be fixed network /wireline router.

How about "access router", or "Internet Gateway"?

> 5).  The method also implies that AODV nodes are being proactive about
>        mobility agents and always putting a default route into to an FA when
>        they "hear" advertisements (or the flood occurs).

Sentiment so far is that accessibility to the Internet is more
special than accessibility to random ad-hoc nodes.

> 6).  It may be necessary to discover land-line IGP routers that are on the path
>       between the path of the AODV network and the FA/HA.

Running co-located, the only thing that is important is to get
the prefix advertisement from the Internet Gateway.  If you're
gateway is a foreign agent, then the mobile node has more options.
Any [manet] draft for IPv4 connectivity ought not to be restrictive
on this point.

> 7).  I believe its a very bad idea to force the MANET node to issue a RREQ
>       to proactively discover a foreign agent.  A far more generic approach would
>       be to use RFC-1256 directly.  That way all MANET protocols could use the
>       same method (not just AODV).   The MANET nodes can proxy response
>       Router/Agent solicitations over ICMP.

As long as you "fix" RFC 1256, O.K.  And then there is the discussion
about proactive vs. reactive.  But I think that it's strange to describe
an "on-demand" discovery operation as "proactive".

I definitely agree that we should try to find something that works
for all [manet] protocols.

> 8).  The case where the MANET protocol does not support mulit-cast must be
>       addressed in more detail.

Let me pass on this one for now, while merely noting that I would
like to see additional multicast work for mobile ad hoc networks.

> 9).  NETWORK_DIAMETER is not a stable number (I don't believe you can
>        just set this to 10 and be happy).  In some cases this could completely swamp
>        the ad hoc network.  An expanded ring search COULD work, but I like ICMP
>        proxy responders much better (explained below).

I thought it should be used for timing purposes, and selected
to be stable (i.e., "too-large").

> My proposal is to stick to RFC-1256.  Each MANET node (not just an AODV) node
> will relay ICMP broadcasts and decrement the TTL field.  This provides the flood
> limiting.  Furthermore, MANET nodes that have discovered a land line router OR a
> mobility agent can proxy response for ICMP Router Solicitations.  This has the
> very same affect as does the RREQ (AODV specific) proposal.

Fine with me!

> BTW, the title of this draft is a bit presumptuous being called "manet-globalv4" since
> it really advocates an AODV specific solution.  I think the technique can be more
> generic if only ICMP messages are used.  Th

Perhaps instead of "presumptuous", one should say "optimistic".
A little optimism never hurts, especially if it's backed up by
good intentions and hard work.

Regards,
Charlie P.

PS. I did not specifically discuss items within the Wakikawa draft here.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Fri Jul 26 20:40:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13247
	for ; Fri, 26 Jul 2002 20:40:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA02739
	for manet-archive@odin.ietf.org; Fri, 26 Jul 2002 20:41:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01306;
	Fri, 26 Jul 2002 20:03:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01281
	for ; Fri, 26 Jul 2002 20:03:29 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12567
	for ; Fri, 26 Jul 2002 20:02:21 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27980;
	Fri, 26 Jul 2002 17:02:54 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6R02r630455;
	Fri, 26 Jul 2002 17:02:53 -0700
X-mProtect: <200207270002> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdzKdZ27; Fri, 26 Jul 2002 17:02:50 PDT
Message-ID: <3D41E32B.F23FD36F@iprg.nokia.com>
Date: Fri, 26 Jul 2002 17:02:51 -0700
From: "Charles E. Perkins" 
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Neumiller 
CC: "Elizabeth M.Belding-Royer" , suny@cs.ucsb.edu,
        Mobile Ad Hoc IETF working group 
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit


Hello Phil,

I have just a few comments.  If you've been tuning in, you'll
remember that there are many different opinions on this subject.
I reckon that it largely depends on one's assumptions, and I am
hoping we can find a good generic solution for the widest
class of applications (still not universal).

Phil Neumiller wrote:
> 
> Hi Charlie, Elizabeth, Yuan,

> There seems to be a few different classes of things that use similar mechanisms to
> Router Discovery as proposed in RFC 1256 (I am sticking with IPv4 in this letter).

RFC 1256 has various restrictions that orient it towards working on
a "link" (e.g., TTL=1).  That's a problem, albeit one not hard to
overcome.

> o Foreign Agent / Home Agent Advertisement uses RFC-1256 with extensions.
> o IGPs such as OSPF / EIGRP etc use RFC-1256 directly.
> o Draft draft-royer-manet-globalv4-00.txt makes does not make direct use of RFC-1256.

Whether to model the advertisements as RFC-1256 or something else
is a matter of taste, not protocol correctness.  Plus, my own
experience with Mobile IP is that using RFC 1256 was a mistake.

> A quote from draft-royer-manet-globalv4-00.txt states
> 
>     "Agent Advertisement messages initiated by foreign agents are re-broadcast
>      by the nodes within the ad hoc network so that mobile nodes may learn of the
>      presence of the FA".

> 1). This can only imply limited flooding, which should always be avoided if possible.

So you're saying no flooding?  Others say flooding is the "only answer".

> 2).  The draft implies a change is needed for MIP FAs.  This does not seem like
>       a good idea to me.  Furthermore, the suggested change only addresses AODV
>       not other MANET protocols.

I agree that other protocols should be addressed also.  This draft,
I think we can agree, needs further development.

Furthermore, I think that any such Internet Gateway node, as a
foreign agent would be here, needs to obey the routing protocol
in use in the ad hoc network.

> 3).  I believe a "clean use" of RFC 1256 is possible without any modification to
>       MIP.

MIP already modifies RFC 1256.  I'm not clear where you're heading on this.

> 4).  I believe the term access point should be avoided.  The industry trend for
>       access points is towards dumb wireless to wireline bridges, i.e. 802.11b/a/g
>       APs.  A more appropriate word might be fixed network /wireline router.

How about "access router", or "Internet Gateway"?

> 5).  The method also implies that AODV nodes are being proactive about
>        mobility agents and always putting a default route into to an FA when
>        they "hear" advertisements (or the flood occurs).

Sentiment so far is that accessibility to the Internet is more
special than accessibility to random ad-hoc nodes.

> 6).  It may be necessary to discover land-line IGP routers that are on the path
>       between the path of the AODV network and the FA/HA.

Running co-located, the only thing that is important is to get
the prefix advertisement from the Internet Gateway.  If you're
gateway is a foreign agent, then the mobile node has more options.
Any [manet] draft for IPv4 connectivity ought not to be restrictive
on this point.

> 7).  I believe its a very bad idea to force the MANET node to issue a RREQ
>       to proactively discover a foreign agent.  A far more generic approach would
>       be to use RFC-1256 directly.  That way all MANET protocols could use the
>       same method (not just AODV).   The MANET nodes can proxy response
>       Router/Agent solicitations over ICMP.

As long as you "fix" RFC 1256, O.K.  And then there is the discussion
about proactive vs. reactive.  But I think that it's strange to describe
an "on-demand" discovery operation as "proactive".

I definitely agree that we should try to find something that works
for all [manet] protocols.

> 8).  The case where the MANET protocol does not support mulit-cast must be
>       addressed in more detail.

Let me pass on this one for now, while merely noting that I would
like to see additional multicast work for mobile ad hoc networks.

> 9).  NETWORK_DIAMETER is not a stable number (I don't believe you can
>        just set this to 10 and be happy).  In some cases this could completely swamp
>        the ad hoc network.  An expanded ring search COULD work, but I like ICMP
>        proxy responders much better (explained below).

I thought it should be used for timing purposes, and selected
to be stable (i.e., "too-large").

> My proposal is to stick to RFC-1256.  Each MANET node (not just an AODV) node
> will relay ICMP broadcasts and decrement the TTL field.  This provides the flood
> limiting.  Furthermore, MANET nodes that have discovered a land line router OR a
> mobility agent can proxy response for ICMP Router Solicitations.  This has the
> very same affect as does the RREQ (AODV specific) proposal.

Fine with me!

> BTW, the title of this draft is a bit presumptuous being called "manet-globalv4" since
> it really advocates an AODV specific solution.  I think the technique can be more
> generic if only ICMP messages are used.  Th

Perhaps instead of "presumptuous", one should say "optimistic".
A little optimism never hurts, especially if it's backed up by
good intentions and hard work.

Regards,
Charlie P.

PS. I did not specifically discuss items within the Wakikawa draft here.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Sun Jul 28 13:20:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29903
	for ; Sun, 28 Jul 2002 13:20:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08632;
	Sun, 28 Jul 2002 12:51:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08603
	for ; Sun, 28 Jul 2002 12:51:20 -0400 (EDT)
Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29523
	for ; Sun, 28 Jul 2002 12:50:14 -0400 (EDT)
From: haas@ece.cornell.edu
Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71])
	by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g6SGjpa02564;
	Sun, 28 Jul 2002 12:45:52 -0400
Date: Sun, 28 Jul 2002 12:51:01 -0400 (EDT)
X-Sender: haas@verdi.ee.cornell.edu
To: Frank Dinies 
cc: Einar Vollset , manet@ietf.org
Subject: Re: [manet] how does ad hoc network do something?
In-Reply-To: <200207241755.23122.FrankDinies@web.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Frank,

> unfortunalety there is no silver bullet for all kind of situations ;)

Yes, there is. Hybrid protocols adjust their behavior *dynamically* based
on the rate of changes (mobility) and the activity (rate of queries). They
optimize the total volume of control traffic, as to match the specific 
mobility/activity ratio.

Also, it is correct - higher rate of changes (higher mobility) and
lower activity favor on-demand (reactive) routing, ... and vice versa
for proactive protocols.

For more about this, see our publications on ZRP (http://wnl.ece.cornell.edu)
- but you're probably aware of this already.

Cheers,

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

> Hi Einar,
> 
> have you seen the approach from Fisheye-State-Routing ? It is a proactive 
> algorithmen with maintains a global routing table. But it maintains the 
> information in respect to the distance. To do this it sends periodically 
> beacons to its neighbours only. Every neighbour accumulates this information 
> and send the information in different update times. Information about nearer 
> nodes much more often than information about nodes farer away. In this way 
> this algorithmen scales pretty well with large networks and positionchanges 
> not nescessarily triggers update information. 
> 
> On-demand protocols have the problem the route-prechaching is unsufficient for 
> high mobility. Another point is that a route could even be absolute before a 
> sender gets the route-information back.
> 
> unfortunalety there is no silver bullet for all kind of situations ;)
> 
> regards
> 
> frank     
> 
> 
> > Hi Frank,
> >
> > >But keep in mind. Proactive algorithmens are best in enviroments with
> > > rapid change and much participants. On-demand-ones roughly for the
> > > contrary. For sensors that transmit from time to time small amounts of
> > > data for example is an on-demand-one perfect.
> >
> > I was under the impression that it was the other way around, with proactive
> > protocols performing worse in environments with rapid change, as the
> > overhead with maintaining the (global) routing information would be
> > prohibitive. Where as an on-demand protocol would perform better in this
> > scenario?
> >
> > Or am I confused? :-)
> >
> > Cheers,
> >
> > Einar
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Sun Jul 28 13:20:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29911
	for ; Sun, 28 Jul 2002 13:20:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA09954
	for manet-archive@odin.ietf.org; Sun, 28 Jul 2002 13:21:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08632;
	Sun, 28 Jul 2002 12:51:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08603
	for ; Sun, 28 Jul 2002 12:51:20 -0400 (EDT)
Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29523
	for ; Sun, 28 Jul 2002 12:50:14 -0400 (EDT)
From: haas@ece.cornell.edu
Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71])
	by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g6SGjpa02564;
	Sun, 28 Jul 2002 12:45:52 -0400
Date: Sun, 28 Jul 2002 12:51:01 -0400 (EDT)
X-Sender: haas@verdi.ee.cornell.edu
To: Frank Dinies 
cc: Einar Vollset , manet@ietf.org
Subject: Re: [manet] how does ad hoc network do something?
In-Reply-To: <200207241755.23122.FrankDinies@web.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi Frank,

> unfortunalety there is no silver bullet for all kind of situations ;)

Yes, there is. Hybrid protocols adjust their behavior *dynamically* based
on the rate of changes (mobility) and the activity (rate of queries). They
optimize the total volume of control traffic, as to match the specific 
mobility/activity ratio.

Also, it is correct - higher rate of changes (higher mobility) and
lower activity favor on-demand (reactive) routing, ... and vice versa
for proactive protocols.

For more about this, see our publications on ZRP (http://wnl.ece.cornell.edu)
- but you're probably aware of this already.

Cheers,

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

> Hi Einar,
> 
> have you seen the approach from Fisheye-State-Routing ? It is a proactive 
> algorithmen with maintains a global routing table. But it maintains the 
> information in respect to the distance. To do this it sends periodically 
> beacons to its neighbours only. Every neighbour accumulates this information 
> and send the information in different update times. Information about nearer 
> nodes much more often than information about nodes farer away. In this way 
> this algorithmen scales pretty well with large networks and positionchanges 
> not nescessarily triggers update information. 
> 
> On-demand protocols have the problem the route-prechaching is unsufficient for 
> high mobility. Another point is that a route could even be absolute before a 
> sender gets the route-information back.
> 
> unfortunalety there is no silver bullet for all kind of situations ;)
> 
> regards
> 
> frank     
> 
> 
> > Hi Frank,
> >
> > >But keep in mind. Proactive algorithmens are best in enviroments with
> > > rapid change and much participants. On-demand-ones roughly for the
> > > contrary. For sensors that transmit from time to time small amounts of
> > > data for example is an on-demand-one perfect.
> >
> > I was under the impression that it was the other way around, with proactive
> > protocols performing worse in environments with rapid change, as the
> > overhead with maintaining the (global) routing information would be
> > prohibitive. Where as an on-demand protocol would perform better in this
> > scenario?
> >
> > Or am I confused? :-)
> >
> > Cheers,
> >
> > Einar
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Mon Jul 29 17:03:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14867
	for ; Mon, 29 Jul 2002 17:03:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27172;
	Mon, 29 Jul 2002 16:24:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27141
	for ; Mon, 29 Jul 2002 16:24:34 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13776
	for ; Mon, 29 Jul 2002 16:23:24 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF260VA4; Mon, 29 Jul 2002 16:24:30 -0400
Message-ID: <00b701c2373d$f1c4bb50$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Charles E. Perkins" 
Cc: "Elizabeth M.Belding-Royer" , ,
        "Mobile Ad Hoc IETF working group" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D41E32B.F23FD36F@iprg.nokia.com>
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
Date: Mon, 29 Jul 2002 16:24:30 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Until it is possible to fix the ICMP TTL=1 we could interpret as "-1" and 
increment the TTL when a MANET node.  This would be a short term hack
until the MIP extension of ICMP Router Discovery allows a > 1 TTL value.

I don't see any other way to solicit a router or an agent over multiple hops
with the ICMP mechanism (NOTE:  the floods can be avoided by allowing
for Router/Agent discovery proxies to respond within some timeout period).



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Mon Jul 29 17:03:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14874
	for ; Mon, 29 Jul 2002 17:03:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA00371
	for manet-archive@odin.ietf.org; Mon, 29 Jul 2002 17:04:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27172;
	Mon, 29 Jul 2002 16:24:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27141
	for ; Mon, 29 Jul 2002 16:24:34 -0400 (EDT)
Received: from meshpdc.meshnetworks.com ([205.245.27.196])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13776
	for ; Mon, 29 Jul 2002 16:23:24 -0400 (EDT)
Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PF260VA4; Mon, 29 Jul 2002 16:24:30 -0400
Message-ID: <00b701c2373d$f1c4bb50$ab0110ac@meshnetworks.com>
Reply-To: "Phil Neumiller" 
From: "Phil Neumiller" 
To: "Charles E. Perkins" 
Cc: "Elizabeth M.Belding-Royer" , ,
        "Mobile Ad Hoc IETF working group" 
References: <1F55F6582266314A85A55F6241509B674180FF@Esealnt863.al.sw.ericsson.se> <1027327887.3d3bc78f26292@tc-mail.insa-lyon.fr> <3D3C10DB.2F963AF6@iprg.nokia.com> <1027349026.3d3c1a22dfb52@tc-mail.insa-lyon.fr> <3D3C23B6.DB3DED61@iprg.nokia.com> <102735 <3D41E32B.F23FD36F@iprg.nokia.com>
Subject: Re: OSPF to AODV bridging was Re: [manet] RE: Gateway Advertisements
Date: Mon, 29 Jul 2002 16:24:30 -0400
Organization: MeshNetworks, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Until it is possible to fix the ICMP TTL=1 we could interpret as "-1" and 
increment the TTL when a MANET node.  This would be a short term hack
until the MIP extension of ICMP Router Discovery allows a > 1 TTL value.

I don't see any other way to solicit a router or an agent over multiple hops
with the ICMP mechanism (NOTE:  the floods can be avoided by allowing
for Router/Agent discovery proxies to respond within some timeout period).



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 12:10:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26314
	for ; Tue, 30 Jul 2002 12:10:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04356;
	Tue, 30 Jul 2002 11:51:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04323
	for ; Tue, 30 Jul 2002 11:51:31 -0400 (EDT)
Received: from Tempo.Update.UU.SE (Tempo.Update.UU.SE [130.238.19.17])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25098
	for ; Tue, 30 Jul 2002 11:50:23 -0400 (EDT)
Received: from Tempo.Update.UU.SE (localhost [127.0.0.1])
	by Tempo.Update.UU.SE (8.12.3/8.12.3/Update-Iltempogigante) with ESMTP id g6UFpRj2019854
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 30 Jul 2002 17:51:28 +0200
Received: from localhost (davidl@localhost)
	by Tempo.Update.UU.SE (8.12.3/8.12.3/Update-Iltempogigante-submit) with ESMTP id g6UFpQEe019851;
	Tue, 30 Jul 2002 17:51:27 +0200
X-Authentication-Warning: Tempo.Update.UU.SE: davidl owned process doing -bs
Date: Tue, 30 Jul 2002 17:51:26 +0200 (CEST)
From: David Lundberg 
To: manet@ietf.org
cc: perg@docs.uu.se
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id LAA04324
Subject: [manet] Protocol reference list
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit


During the work with my MSc thesis i have created a list with the
protocols I've come across. Comments on categories, sorting and of course
errors are very welcome. It would be usefull to have a discussion if it
really is possible to have ONE protocol serving all needs...

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


Pro-active: (Table-driven)

CGSR Clusterhead Gateway Switch Routing protocol
DBF Distributed Bellman-Ford routing protocol
DSDV Distance Source Distance Vector routing protcol
DTDV Higly Dynamic Destination-Sequenced Distance Vector routing protocol
HSR Hierarchical State Routing protocol
HSLS Hazy Sighted Link State routing protocol
LCA Linked Cluster Architecture
OLSR Optimized Link State Routing Protocol
STAR Source Tree Adaptive routing protocol
TBRPF Topology Broadcast based on Reverse-Path Forwarding routing protocol
WRP Wireless Routing Protocol 

Reactive: (On-demand)

AODV Ad hoc On Demand Distance Vector routing protocol
ABR Associativity Based Routing protcol
BSR Backup Source Routing protocol 
DSR Dynamic Source Routing protocol
DSRFLOW Flow State in the Dynamic Source Routing protocol
FORP Flow Oriented Routing Protocol
LMR Lightweight Mobile Routing protcol
LUNAR Lightweight Underlay Network Ad hoc Routing
RDMAR Relative-Distance Micro-discovery Ad hoc Routing protocol
SSR Signal Stability Routing protocol
TORA Temporally-Ordered Routing Algorithm routing protocol

Hierarchical:

CBRP Cluster Based Routing Protocol
CEDAR Core Extraction Distributed Ad hoc Routing
GSR Global State Routing protocol
FSR Fisheye State Routing protocol
HARP Hybrid Ad Hoc Routing Protocol
HSR Host Specific Routing protocol
LANMAR Landmark Routing Protocol for Large Scale Networks (table?)
ZRP Zone Routing Protocol protocol
BRP Bordercast Resolution Protocol
IARP Intrazone Routing Protocol
IERP Interzone Routing Protocol

Geographical:

DREAM Distance Routing Effect Algorithm for Mobility
GLS(Grid) Geographic Location Service
LAR Location-Aided Routing protocol
ZHLS Zone-Based Hierarchical Link State Routing

Multicast:

ADMR Adaptive Demand-Driven Multicast Routing protocol

AMRIS Ad hoc Multicast Routing protocol utilising Increasing id-numbers
AMRoute Ad hoc Multicast Routing Protocol
CAMP Core-Assisted Mesh Protocol
DDM Differential Destination Multicast
LAM Lightweight Adaptive Multicast protocol
DSR-MB Simple Protocol for Multicast and Broadcast using DSR
MAODV Multicast Ad hoc On-Demand Distance Vector routing
MZR Multicast Zone Routing protocol
ODMRP On-Demand Multicast Routing Protocol
SRMP Source Routing-based Multicast Protocol

Still assorted:

PARO Power-Aware Routing Optimization Protocol (table?)
DDR Distributed Dynamic Routing Algorithm


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


My final draft on my thesis can be found on the locations below for those
intrested in references etc.

http://www.docs.uu.se/~davidlu/thesis.pdf
http://www.docs.uu.se/~davidlu/thesis.ps
http://www.docs.uu.se/~davidlu/thesis/ (HTML)


Regards,

// David //


--------------------------------------------------------------
David Lundberg            Phone: Home(Uppsala)  +46-018-460356
Mail: davidl@update.uu.se        Home(Gävle)    +46-026-146743
Http: www.update.uu.se/~davidl   Cellular      +46-070-3531696
ICQ:  13440550                   DoCS @ UU     +46-018-4716231
--------------------------------------------------------------



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 12:10:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26323
	for ; Tue, 30 Jul 2002 12:10:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA06757
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 12:11:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04356;
	Tue, 30 Jul 2002 11:51:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04323
	for ; Tue, 30 Jul 2002 11:51:31 -0400 (EDT)
Received: from Tempo.Update.UU.SE (Tempo.Update.UU.SE [130.238.19.17])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25098
	for ; Tue, 30 Jul 2002 11:50:23 -0400 (EDT)
Received: from Tempo.Update.UU.SE (localhost [127.0.0.1])
	by Tempo.Update.UU.SE (8.12.3/8.12.3/Update-Iltempogigante) with ESMTP id g6UFpRj2019854
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 30 Jul 2002 17:51:28 +0200
Received: from localhost (davidl@localhost)
	by Tempo.Update.UU.SE (8.12.3/8.12.3/Update-Iltempogigante-submit) with ESMTP id g6UFpQEe019851;
	Tue, 30 Jul 2002 17:51:27 +0200
X-Authentication-Warning: Tempo.Update.UU.SE: davidl owned process doing -bs
Date: Tue, 30 Jul 2002 17:51:26 +0200 (CEST)
From: David Lundberg 
To: manet@ietf.org
cc: perg@docs.uu.se
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id LAA04324
Subject: [manet] Protocol reference list
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit


During the work with my MSc thesis i have created a list with the
protocols I've come across. Comments on categories, sorting and of course
errors are very welcome. It would be usefull to have a discussion if it
really is possible to have ONE protocol serving all needs...

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


Pro-active: (Table-driven)

CGSR Clusterhead Gateway Switch Routing protocol
DBF Distributed Bellman-Ford routing protocol
DSDV Distance Source Distance Vector routing protcol
DTDV Higly Dynamic Destination-Sequenced Distance Vector routing protocol
HSR Hierarchical State Routing protocol
HSLS Hazy Sighted Link State routing protocol
LCA Linked Cluster Architecture
OLSR Optimized Link State Routing Protocol
STAR Source Tree Adaptive routing protocol
TBRPF Topology Broadcast based on Reverse-Path Forwarding routing protocol
WRP Wireless Routing Protocol 

Reactive: (On-demand)

AODV Ad hoc On Demand Distance Vector routing protocol
ABR Associativity Based Routing protcol
BSR Backup Source Routing protocol 
DSR Dynamic Source Routing protocol
DSRFLOW Flow State in the Dynamic Source Routing protocol
FORP Flow Oriented Routing Protocol
LMR Lightweight Mobile Routing protcol
LUNAR Lightweight Underlay Network Ad hoc Routing
RDMAR Relative-Distance Micro-discovery Ad hoc Routing protocol
SSR Signal Stability Routing protocol
TORA Temporally-Ordered Routing Algorithm routing protocol

Hierarchical:

CBRP Cluster Based Routing Protocol
CEDAR Core Extraction Distributed Ad hoc Routing
GSR Global State Routing protocol
FSR Fisheye State Routing protocol
HARP Hybrid Ad Hoc Routing Protocol
HSR Host Specific Routing protocol
LANMAR Landmark Routing Protocol for Large Scale Networks (table?)
ZRP Zone Routing Protocol protocol
BRP Bordercast Resolution Protocol
IARP Intrazone Routing Protocol
IERP Interzone Routing Protocol

Geographical:

DREAM Distance Routing Effect Algorithm for Mobility
GLS(Grid) Geographic Location Service
LAR Location-Aided Routing protocol
ZHLS Zone-Based Hierarchical Link State Routing

Multicast:

ADMR Adaptive Demand-Driven Multicast Routing protocol

AMRIS Ad hoc Multicast Routing protocol utilising Increasing id-numbers
AMRoute Ad hoc Multicast Routing Protocol
CAMP Core-Assisted Mesh Protocol
DDM Differential Destination Multicast
LAM Lightweight Adaptive Multicast protocol
DSR-MB Simple Protocol for Multicast and Broadcast using DSR
MAODV Multicast Ad hoc On-Demand Distance Vector routing
MZR Multicast Zone Routing protocol
ODMRP On-Demand Multicast Routing Protocol
SRMP Source Routing-based Multicast Protocol

Still assorted:

PARO Power-Aware Routing Optimization Protocol (table?)
DDR Distributed Dynamic Routing Algorithm


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


My final draft on my thesis can be found on the locations below for those
intrested in references etc.

http://www.docs.uu.se/~davidlu/thesis.pdf
http://www.docs.uu.se/~davidlu/thesis.ps
http://www.docs.uu.se/~davidlu/thesis/ (HTML)


Regards,

// David //


--------------------------------------------------------------
David Lundberg            Phone: Home(Uppsala)  +46-018-460356
Mail: davidl@update.uu.se        Home(Gävle)    +46-026-146743
Http: www.update.uu.se/~davidl   Cellular      +46-070-3531696
ICQ:  13440550                   DoCS @ UU     +46-018-4716231
--------------------------------------------------------------



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 13:12:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29589
	for ; Tue, 30 Jul 2002 13:12:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09101;
	Tue, 30 Jul 2002 12:51:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09072
	for ; Tue, 30 Jul 2002 12:51:37 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28059
	for ; Tue, 30 Jul 2002 12:50:29 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117123>; Tue, 30 Jul 2002 10:51:26 -0600
Message-Id: <02Jul30.105126mdt.117123@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: manet@ietf.org
Date:  Tue, 30 Jul 2002 10:51:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] Distribution of end-to-end distance in the Waypoint model
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I've worked out the theoretical distribution of the end-to-end distance
between two randomly-selected nodes when nodes are uniformly distributed in
a w by h rectangle.  I was unable to find this computation, so I ended up
working it out for myself.  If there is any general interest in this
particular distribution, I'd be willing to write up the procedure.  On the
other hand, if this has been published before, I'd appreciate a citation so
I can check my work.

Thanks,

John P. Mullen,  Ph.D.
Contractor at TRAC/WSMR while on sabbatical from New Mexico State University

Mail to:
    Director
    USATRAC-WSMR
    Attn: ATRC-WBC (John Mullen)
    White Sands Missile Range, NM  88002-5502

Phone:  
    (505) 678-5275
    DSN 258-5275

After 12/31/02
   Tel: (505) 646-2958
   Email: jomullen@nmsu.edu


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 13:12:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29594
	for ; Tue, 30 Jul 2002 13:12:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA11742
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 13:13:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09101;
	Tue, 30 Jul 2002 12:51:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09072
	for ; Tue, 30 Jul 2002 12:51:37 -0400 (EDT)
Received: from trac.wsmr.army.mil (trac.wsmr.army.mil [155.148.36.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28059
	for ; Tue, 30 Jul 2002 12:50:29 -0400 (EDT)
Received: by gw.trac.wsmr.army.mil id <117123>; Tue, 30 Jul 2002 10:51:26 -0600
Message-Id: <02Jul30.105126mdt.117123@gw.trac.wsmr.army.mil>
From: "Mullen, John P. (Contractor)" 
To: manet@ietf.org
Date:  Tue, 30 Jul 2002 10:51:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [manet] Distribution of end-to-end distance in the Waypoint model
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,

I've worked out the theoretical distribution of the end-to-end distance
between two randomly-selected nodes when nodes are uniformly distributed in
a w by h rectangle.  I was unable to find this computation, so I ended up
working it out for myself.  If there is any general interest in this
particular distribution, I'd be willing to write up the procedure.  On the
other hand, if this has been published before, I'd appreciate a citation so
I can check my work.

Thanks,

John P. Mullen,  Ph.D.
Contractor at TRAC/WSMR while on sabbatical from New Mexico State University

Mail to:
    Director
    USATRAC-WSMR
    Attn: ATRC-WBC (John Mullen)
    White Sands Missile Range, NM  88002-5502

Phone:  
    (505) 678-5275
    DSN 258-5275

After 12/31/02
   Tel: (505) 646-2958
   Email: jomullen@nmsu.edu


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 14:03:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02276
	for ; Tue, 30 Jul 2002 14:03:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13264;
	Tue, 30 Jul 2002 13:41:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13234
	for ; Tue, 30 Jul 2002 13:41:09 -0400 (EDT)
Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01517
	for ; Tue, 30 Jul 2002 13:40:01 -0400 (EDT)
Received: from hoffman.INRS-Telecom.UQuebec.CA (hoffman [192.26.211.190])
	by ozias.inrs-telecom.uquebec.ca (8.11.3/8.11.3) with ESMTP id g6UHdv307166;
	Tue, 30 Jul 2002 13:39:58 -0400 (EDT)
Received: from hoffman by hoffman.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4)
	id NAA25023; Tue, 30 Jul 2002 13:39:52 -0400 (EDT)
Message-Id: <200207301739.NAA25023@hoffman.INRS-Telecom.UQuebec.CA>
Date: Tue, 30 Jul 2002 13:39:52 -0400 (EDT)
From: Jorge Nuevo 
Reply-To: Jorge Nuevo 
Subject: Re: [manet] Protocol reference list
To: manet@ietf.org, davidl@update.uu.se
Cc: perg@docs.uu.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4RS9pCirj4yUBI+kCelr0Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hello David,

Some protocols that can be added to your complete list may be the following

Geographical Multicast (Geocasting):

 LBM - Location Based Multicast (Y.Ko and Vaidya 1998)
 GeoGRID (Liao, Tseng, Lo and Sheu 2000)
 GeoTORA 
 Mesh-Based Geocast Routing (Boleng, Camp and Tolety 2001)
 
 

Multicast

 FGMP - Forwarding Group Multicast Protocol (Chiang, Gerla, Zhang 1998)
 ABAM - On-Demand Associativity-Based Multicast 
 MCEDAR - Multicast CEDAR (Sinha and Bharghavan 1999)
 
 
 
 Jorge
 nuevo@inrs-telecom.uquebec.ca


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 14:03:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02289
	for ; Tue, 30 Jul 2002 14:03:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA15301
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 14:04:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13264;
	Tue, 30 Jul 2002 13:41:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13234
	for ; Tue, 30 Jul 2002 13:41:09 -0400 (EDT)
Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01517
	for ; Tue, 30 Jul 2002 13:40:01 -0400 (EDT)
Received: from hoffman.INRS-Telecom.UQuebec.CA (hoffman [192.26.211.190])
	by ozias.inrs-telecom.uquebec.ca (8.11.3/8.11.3) with ESMTP id g6UHdv307166;
	Tue, 30 Jul 2002 13:39:58 -0400 (EDT)
Received: from hoffman by hoffman.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4)
	id NAA25023; Tue, 30 Jul 2002 13:39:52 -0400 (EDT)
Message-Id: <200207301739.NAA25023@hoffman.INRS-Telecom.UQuebec.CA>
Date: Tue, 30 Jul 2002 13:39:52 -0400 (EDT)
From: Jorge Nuevo 
Reply-To: Jorge Nuevo 
Subject: Re: [manet] Protocol reference list
To: manet@ietf.org, davidl@update.uu.se
Cc: perg@docs.uu.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4RS9pCirj4yUBI+kCelr0Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hello David,

Some protocols that can be added to your complete list may be the following

Geographical Multicast (Geocasting):

 LBM - Location Based Multicast (Y.Ko and Vaidya 1998)
 GeoGRID (Liao, Tseng, Lo and Sheu 2000)
 GeoTORA 
 Mesh-Based Geocast Routing (Boleng, Camp and Tolety 2001)
 
 

Multicast

 FGMP - Forwarding Group Multicast Protocol (Chiang, Gerla, Zhang 1998)
 ABAM - On-Demand Associativity-Based Multicast 
 MCEDAR - Multicast CEDAR (Sinha and Bharghavan 1999)
 
 
 
 Jorge
 nuevo@inrs-telecom.uquebec.ca


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 15:09:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05251
	for ; Tue, 30 Jul 2002 15:09:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18095;
	Tue, 30 Jul 2002 14:51:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18065
	for ; Tue, 30 Jul 2002 14:51:24 -0400 (EDT)
Received: from mailFA11.rediffmail.com ([203.199.83.246])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04413
	for ; Tue, 30 Jul 2002 14:50:15 -0400 (EDT)
Received: (qmail 28881 invoked by uid 510); 30 Jul 2002 18:51:29 -0000
Date: 30 Jul 2002 18:51:29 -0000
Message-ID: <20020730185129.28880.qmail@mailFA11.rediffmail.com>
Received: from unknown (61.1.132.88) by rediffmail.com via HTTP; 30 Jul 2002 18:51:29 -0000
MIME-Version: 1.0
From: "sabeel ansari" 
Reply-To: "sabeel ansari" 
To: manet@ietf.org
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Subject: [manet] IEEE 802.11 MAC collision implementation in NS2
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi
I was going through the IEEE 802.11 MAC source code in the NS2. 
Here, it says that when a collision takes place,
check the two packets and discard the packet which is going to end 
earlier. Shouldnt it be the other way around.

void
Mac802_11::collision(Packet *p)
{
 	switch(rx_state_) {
 	case MAC_RECV:
 		SET_RX_STATE(MAC_COLL);
 		/* fall through */
 	case MAC_COLL:
 		assert(pktRx_);
 		assert(mhRecv_.busy());
 		/*
 		 *  Since a collision has occurred, figure out
  		 *  which packet that caused the collision will
  		 *  "last" the longest.  Make this packet,
  		 *  pktRx_ and reset the Recv Timer if necessary.
  		 */
 		if(TX_Time(p) > mhRecv_.expire()) {
 			mhRecv_.stop();
 			discard(pktRx_, DROP_MAC_COLLISION);
 			pktRx_ = p;
 			mhRecv_.start(TX_Time(pktRx_));
 		}
 		else {
 			discard(p, DROP_MAC_COLLISION);
 		}
 		break;
 	default:
 		assert(0);
 	}
}


sabeel

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 15:09:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05260
	for ; Tue, 30 Jul 2002 15:09:13 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA19549
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 15:10:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18095;
	Tue, 30 Jul 2002 14:51:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18065
	for ; Tue, 30 Jul 2002 14:51:24 -0400 (EDT)
Received: from mailFA11.rediffmail.com ([203.199.83.246])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04413
	for ; Tue, 30 Jul 2002 14:50:15 -0400 (EDT)
Received: (qmail 28881 invoked by uid 510); 30 Jul 2002 18:51:29 -0000
Date: 30 Jul 2002 18:51:29 -0000
Message-ID: <20020730185129.28880.qmail@mailFA11.rediffmail.com>
Received: from unknown (61.1.132.88) by rediffmail.com via HTTP; 30 Jul 2002 18:51:29 -0000
MIME-Version: 1.0
From: "sabeel ansari" 
Reply-To: "sabeel ansari" 
To: manet@ietf.org
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Subject: [manet] IEEE 802.11 MAC collision implementation in NS2
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi
I was going through the IEEE 802.11 MAC source code in the NS2. 
Here, it says that when a collision takes place,
check the two packets and discard the packet which is going to end 
earlier. Shouldnt it be the other way around.

void
Mac802_11::collision(Packet *p)
{
 	switch(rx_state_) {
 	case MAC_RECV:
 		SET_RX_STATE(MAC_COLL);
 		/* fall through */
 	case MAC_COLL:
 		assert(pktRx_);
 		assert(mhRecv_.busy());
 		/*
 		 *  Since a collision has occurred, figure out
  		 *  which packet that caused the collision will
  		 *  "last" the longest.  Make this packet,
  		 *  pktRx_ and reset the Recv Timer if necessary.
  		 */
 		if(TX_Time(p) > mhRecv_.expire()) {
 			mhRecv_.stop();
 			discard(pktRx_, DROP_MAC_COLLISION);
 			pktRx_ = p;
 			mhRecv_.start(TX_Time(pktRx_));
 		}
 		else {
 			discard(p, DROP_MAC_COLLISION);
 		}
 		break;
 	default:
 		assert(0);
 	}
}


sabeel

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 15:49:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06680
	for ; Tue, 30 Jul 2002 15:49:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20915;
	Tue, 30 Jul 2002 15:34:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20884
	for ; Tue, 30 Jul 2002 15:34:53 -0400 (EDT)
Received: from web12901.mail.yahoo.com (web12901.mail.yahoo.com [216.136.174.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06089
	for ; Tue, 30 Jul 2002 15:33:43 -0400 (EDT)
Message-ID: <20020730193451.61562.qmail@web12901.mail.yahoo.com>
Received: from [216.69.69.214] by web12901.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 12:34:51 PDT
Date: Tue, 30 Jul 2002 12:34:51 -0700 (PDT)
From: feng zhu 
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [manet] a list of papers on security for ad hoc networks
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, All,

I made a webpage to contain a list of papers on
security for ad hoc networks.

http://www.ccs.neu.edu/home/zhufeng/security_manet.html

If you wrote and/or know of any papers concerning
security for ad hoc networks that are not listed here,
please let me know.

Contract me: zf_manet@yahoo.com

Best,
Feng

The following is a part of the list.
========================================


Key Exchange and Distribution:

[AG] N. Asokan, Philip Ginzboorg Key agreement in ad
hoc networks  

[H] Maarit Hietalahti  Key Establishment in Ad-hoc
Networks

[CBH]Srdjan Capkuny, Levente Buttyan and Jean-Pierre
Hubaux Self-Organized Public-Key Management for Mobile
Ad Hoc Networks

 

Secure Routing:

[BT] Jim Brinkley William Trost Authenticated Ad Hoc
Routing at the Link Layer for Mobile Systems 1996 

[DLRS]Bridget Dahill, Brian Neil Levine, Elizabeth
Royer, Clay Shields. A Secure Routing Protocol for Ad
Hoc Networks

[HPJ] Yih-Chun Hu, Adrian Perrig, David B. Johnson.
Ariadne: A secure On-Demand Routing Protocol for Ad
hoc Networks

[MGLB] Sergio Marti and T. J. Giuli and Kevin Lai and
Mary Baker. Mitigating routing misbehavior in mobile
ad hoc networks. Mobile Computing and Networking
(2000): 

[PH] Panagiotis Papadimitratos and Zygmunt J. Haas
Secure Routing for Mobile Ad hoc Networks and  
[slides]

[SMG] Bradley R. Smith, Shree Murthy, J.J.
Garcia-Luna-Aceves Securing Distance-Vector Routing
Protocols

[YNK] Seung Yi, Prasad Naldurg, Robin Kravets. A
Security-Aware Ad Hoc Routing Protocol for Wireless
Networks [2]

[L] Janne Lundberg Routing Security in Ad Hoc Networks

[HJP] Yih-Chun Hu, David B. Johnson, and Adrian
Perrig. SEAD: Secure Efficient Distance Vector Routing
for Mobile Wireless Ad Hoc Networks. Proceedings of
the 4th IEEE Workshop on Mobile Computing Systems &
Applications (WMCSA 2002), pp. 3-13, IEEE, Calicoon,
NY, June 2002.

[Z]Manel Guerrero Zapata Secure Ad hoc On-Demand
Distance Vector (SAODV) Routing

 

Group Communication:

[YD] Alec Yasinsac Jim Davis. Modeling Protocols for
Secure Group Communication in Ad Hoc Networks
(Extended Abstract)

[MAH ]Silja Mäki, Tuomas Aura, Maarit Hietalahti
Robust Membership Management for Ad-hoc Groups

 

Other Security issues: 

[CK] Candolin, H. Kari, A Security Architecture for
Wireless Ad hoc Networks, to be published at IEEE
Milcom 2002, Anaheim, California, October 7-10, 2002

[EGN] Pasi Eronen, Christian Gehrmann, Pekka Nikander
Securing ad hoc Jini services

[HBC} Jean-Pierre Hubaux, Levente Buttyan, Srdjan
Capkun (Swiss Federal Institute of Technology) The
Quest for Security in Mobile Ad Hoc Networks

[LKZLZ] Haiyun Luo, Jiejun Kong, Petros Zerfos, Songwu
Lu and Lixia Zhang, Self-securing Ad Hoc Wireless
Networks  

[K] Vesa Karpijoki Security in Ad Hoc Networks 

[SA] Frank Stajano and Ross Anderson The Resurrecting
Duckling: Security Issues for Ad-hoc Wireless Networks

[SH] Christian Schwingenschlögl and Marc-Philipp Horn
Build Blocks for Secure Communication in Ad-hoc
Networks

[V] Anne Vanhala Security in Ad-hoc Networks 

[ZH] Lidong Zhou, Zygmunt J. Haas. Securing ad hoc
networks. IEEE Communications, Vol. 13 No. 6

[ZL] Yongguang Zhang & Wenke Lee, Intrusion Detection
in Wireless Ad-Hoc Networks

[LL] Haiyun Luo, Songwu Lu Ubiquitous and Robust
Authentication Services for Ad Hoc Wireless Networks, 

[KZLLZ] Jiejun Kong, Petros Zerfos, Haiyun Luo, Songwu
Lu and Lixia Zhang.  Providing Robust and Ubiquitous
Security Support for Mobile Ad-Hoc Networks

[GN] Christian Gehrmann (Ericsson Research), and Pekka
Nikander (Helsinki Institute of Technology) Securing
Ad Hoc Services, a Jini View

[KLXGGL] Jiejun Kong, Haiyun Luo, Kaixin Xu, Daniel
Lihui Gu, Mario Gerla, Songwu Lu Adaptive Security for
Multi-layer Ad-hoc Networks

[BH]Levente Buttyan and Jean-Pierre Hubaux  Enforcing
Service Availability in Mobile Ad-Hoc WANs  

[VA]Lakshmi Venkatraman and Dharma P. Agrawal  A Novel
Authentication scheme for Ad hoc Networks

[BSSW]Dirk Balfanz, D. K. Smetters, Paul Stewart and
H. Chi Wong Talking To Strangers: Authentication in
Ad-Hoc Wireless Networks

[J]Stuart Jacobs MANET Authentication Architecture
 (slides)

 

 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 16:34:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06686
	for ; Tue, 30 Jul 2002 15:49:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA21839
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 15:50:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20915;
	Tue, 30 Jul 2002 15:34:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20884
	for ; Tue, 30 Jul 2002 15:34:53 -0400 (EDT)
Received: from web12901.mail.yahoo.com (web12901.mail.yahoo.com [216.136.174.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06089
	for ; Tue, 30 Jul 2002 15:33:43 -0400 (EDT)
Message-ID: <20020730193451.61562.qmail@web12901.mail.yahoo.com>
Received: from [216.69.69.214] by web12901.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 12:34:51 PDT
Date: Tue, 30 Jul 2002 12:34:51 -0700 (PDT)
From: feng zhu 
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [manet] a list of papers on security for ad hoc networks
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, All,

I made a webpage to contain a list of papers on
security for ad hoc networks.

http://www.ccs.neu.edu/home/zhufeng/security_manet.html

If you wrote and/or know of any papers concerning
security for ad hoc networks that are not listed here,
please let me know.

Contract me: zf_manet@yahoo.com

Best,
Feng

The following is a part of the list.
========================================


Key Exchange and Distribution:

[AG] N. Asokan, Philip Ginzboorg Key agreement in ad
hoc networks  

[H] Maarit Hietalahti  Key Establishment in Ad-hoc
Networks

[CBH]Srdjan Capkuny, Levente Buttyan and Jean-Pierre
Hubaux Self-Organized Public-Key Management for Mobile
Ad Hoc Networks

 

Secure Routing:

[BT] Jim Brinkley William Trost Authenticated Ad Hoc
Routing at the Link Layer for Mobile Systems 1996 

[DLRS]Bridget Dahill, Brian Neil Levine, Elizabeth
Royer, Clay Shields. A Secure Routing Protocol for Ad
Hoc Networks

[HPJ] Yih-Chun Hu, Adrian Perrig, David B. Johnson.
Ariadne: A secure On-Demand Routing Protocol for Ad
hoc Networks

[MGLB] Sergio Marti and T. J. Giuli and Kevin Lai and
Mary Baker. Mitigating routing misbehavior in mobile
ad hoc networks. Mobile Computing and Networking
(2000): 

[PH] Panagiotis Papadimitratos and Zygmunt J. Haas
Secure Routing for Mobile Ad hoc Networks and  
[slides]

[SMG] Bradley R. Smith, Shree Murthy, J.J.
Garcia-Luna-Aceves Securing Distance-Vector Routing
Protocols

[YNK] Seung Yi, Prasad Naldurg, Robin Kravets. A
Security-Aware Ad Hoc Routing Protocol for Wireless
Networks [2]

[L] Janne Lundberg Routing Security in Ad Hoc Networks

[HJP] Yih-Chun Hu, David B. Johnson, and Adrian
Perrig. SEAD: Secure Efficient Distance Vector Routing
for Mobile Wireless Ad Hoc Networks. Proceedings of
the 4th IEEE Workshop on Mobile Computing Systems &
Applications (WMCSA 2002), pp. 3-13, IEEE, Calicoon,
NY, June 2002.

[Z]Manel Guerrero Zapata Secure Ad hoc On-Demand
Distance Vector (SAODV) Routing

 

Group Communication:

[YD] Alec Yasinsac Jim Davis. Modeling Protocols for
Secure Group Communication in Ad Hoc Networks
(Extended Abstract)

[MAH ]Silja Mäki, Tuomas Aura, Maarit Hietalahti
Robust Membership Management for Ad-hoc Groups

 

Other Security issues: 

[CK] Candolin, H. Kari, A Security Architecture for
Wireless Ad hoc Networks, to be published at IEEE
Milcom 2002, Anaheim, California, October 7-10, 2002

[EGN] Pasi Eronen, Christian Gehrmann, Pekka Nikander
Securing ad hoc Jini services

[HBC} Jean-Pierre Hubaux, Levente Buttyan, Srdjan
Capkun (Swiss Federal Institute of Technology) The
Quest for Security in Mobile Ad Hoc Networks

[LKZLZ] Haiyun Luo, Jiejun Kong, Petros Zerfos, Songwu
Lu and Lixia Zhang, Self-securing Ad Hoc Wireless
Networks  

[K] Vesa Karpijoki Security in Ad Hoc Networks 

[SA] Frank Stajano and Ross Anderson The Resurrecting
Duckling: Security Issues for Ad-hoc Wireless Networks

[SH] Christian Schwingenschlögl and Marc-Philipp Horn
Build Blocks for Secure Communication in Ad-hoc
Networks

[V] Anne Vanhala Security in Ad-hoc Networks 

[ZH] Lidong Zhou, Zygmunt J. Haas. Securing ad hoc
networks. IEEE Communications, Vol. 13 No. 6

[ZL] Yongguang Zhang & Wenke Lee, Intrusion Detection
in Wireless Ad-Hoc Networks

[LL] Haiyun Luo, Songwu Lu Ubiquitous and Robust
Authentication Services for Ad Hoc Wireless Networks, 

[KZLLZ] Jiejun Kong, Petros Zerfos, Haiyun Luo, Songwu
Lu and Lixia Zhang.  Providing Robust and Ubiquitous
Security Support for Mobile Ad-Hoc Networks

[GN] Christian Gehrmann (Ericsson Research), and Pekka
Nikander (Helsinki Institute of Technology) Securing
Ad Hoc Services, a Jini View

[KLXGGL] Jiejun Kong, Haiyun Luo, Kaixin Xu, Daniel
Lihui Gu, Mario Gerla, Songwu Lu Adaptive Security for
Multi-layer Ad-hoc Networks

[BH]Levente Buttyan and Jean-Pierre Hubaux  Enforcing
Service Availability in Mobile Ad-Hoc WANs  

[VA]Lakshmi Venkatraman and Dharma P. Agrawal  A Novel
Authentication scheme for Ad hoc Networks

[BSSW]Dirk Balfanz, D. K. Smetters, Paul Stewart and
H. Chi Wong Talking To Strangers: Authentication in
Ad-Hoc Wireless Networks

[J]Stuart Jacobs MANET Authentication Architecture
 (slides)

 

 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 18:26:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11426
	for ; Tue, 30 Jul 2002 18:26:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29664;
	Tue, 30 Jul 2002 18:01:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29608
	for ; Tue, 30 Jul 2002 18:01:26 -0400 (EDT)
Received: from mithrandir.scalable-networks.com (qmailr@adsl-63-205-33-203.fang-fashion.com [63.205.33.203] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10644
	for ; Tue, 30 Jul 2002 18:00:18 -0400 (EDT)
Received: (qmail 6423 invoked from network); 30 Jul 2002 22:03:31 -0000
Received: from gateway.scalable-networks.com (HELO cs.ucla.edu) (mineo@63.205.33.202)
  by 192.168.0.160 with SMTP; 30 Jul 2002 22:03:31 -0000
Message-ID: <3D470D1B.EBBD8136@cs.ucla.edu>
Date: Tue, 30 Jul 2002 15:03:07 -0700
From: Mineo Takai 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sabeel ansari 
CC: manet@ietf.org
Subject: Re: [manet] IEEE 802.11 MAC collision implementation in NS2
References: <20020730185129.28880.qmail@mailFA11.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Sabeel,

This question may be more appropriate for the ns-2 users mailing list,
but I am describing what that piece of ns-2 code does because I know
many people on this list use ns-2. When a collision happens at a node,
the model keeps a pointer to the packet that lasts longer than the other
in order to use its power (Pi) as the basis of interference. When
another signal (packet) comes in, it checks the power of the new signal
(Ps), and computes Ps/Pi. Each node can receive each packet only when
there was no interference, or Ps/Pi was always above a certain threshold
(I think it is 10 dB by default) during the packet reception.

The model keeps a pointer to the packet whose transmission lasts longer
because it may interfere with more forthcoming packets. However, there
are many problems with it:
- It does not consider the power value. The model simply chooses the
packet that lasts longer even if the reception power of the other packet
whose transmission ends sooner by 1 nanosecond is 100 times stronger.
- The actual interference is cumulative. When multiple signals other
than the signal of interest are present, SIR (Signal to Interference
Ratio) must be calculated using power from all signals currently on the
channel. The model abstracts out this effect, and is inaccurate when
there are multiple interference sources (transmitters or jammers) in the
network. There is no consideration of noise in the model either.

One of my papers may be useful to understand these issues:

Effects of Wireless Physical Layer Modeling in Mobile Ad Hoc Networks
Mineo Takai, Jay Martin and Rajive Bagrodia
Proceedings of the 2001 ACM International Symposium on Mobile Ad Hoc
Networking & Computing (MobiHoc 2001), pp. 87-94, October 2001. 
(ftp://pcl.cs.ucla.edu/pub/papers/mobihoc.ps) 

After this publication, I noticed ns folks fixed another problem pointed
out in the paper (preamble length), but this interference modeling have
not been fixed yet. It is much harder to fix it than the other, and the
modification may significantly slow down ns-2. However, in my opinion,
it should be worth fixing.

Regards,

Mineo

sabeel ansari wrote:
> 
> Hi
> I was going through the IEEE 802.11 MAC source code in the NS2.
> Here, it says that when a collision takes place,
> check the two packets and discard the packet which is going to end
> earlier. Shouldnt it be the other way around.
> 
> void
> Mac802_11::collision(Packet *p)
> {
>         switch(rx_state_) {
>         case MAC_RECV:
>                 SET_RX_STATE(MAC_COLL);
>                 /* fall through */
>         case MAC_COLL:
>                 assert(pktRx_);
>                 assert(mhRecv_.busy());
>                 /*
>                  *  Since a collision has occurred, figure out
>                  *  which packet that caused the collision will
>                  *  "last" the longest.  Make this packet,
>                  *  pktRx_ and reset the Recv Timer if necessary.
>                  */
>                 if(TX_Time(p) > mhRecv_.expire()) {
>                         mhRecv_.stop();
>                         discard(pktRx_, DROP_MAC_COLLISION);
>                         pktRx_ = p;
>                         mhRecv_.start(TX_Time(pktRx_));
>                 }
>                 else {
>                         discard(p, DROP_MAC_COLLISION);
>                 }
>                 break;
>         default:
>                 assert(0);
>         }
> }
> 
> sabeel
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 18:26:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11438
	for ; Tue, 30 Jul 2002 18:26:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00822
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 18:28:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29664;
	Tue, 30 Jul 2002 18:01:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29608
	for ; Tue, 30 Jul 2002 18:01:26 -0400 (EDT)
Received: from mithrandir.scalable-networks.com (qmailr@adsl-63-205-33-203.fang-fashion.com [63.205.33.203] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10644
	for ; Tue, 30 Jul 2002 18:00:18 -0400 (EDT)
Received: (qmail 6423 invoked from network); 30 Jul 2002 22:03:31 -0000
Received: from gateway.scalable-networks.com (HELO cs.ucla.edu) (mineo@63.205.33.202)
  by 192.168.0.160 with SMTP; 30 Jul 2002 22:03:31 -0000
Message-ID: <3D470D1B.EBBD8136@cs.ucla.edu>
Date: Tue, 30 Jul 2002 15:03:07 -0700
From: Mineo Takai 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sabeel ansari 
CC: manet@ietf.org
Subject: Re: [manet] IEEE 802.11 MAC collision implementation in NS2
References: <20020730185129.28880.qmail@mailFA11.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Sabeel,

This question may be more appropriate for the ns-2 users mailing list,
but I am describing what that piece of ns-2 code does because I know
many people on this list use ns-2. When a collision happens at a node,
the model keeps a pointer to the packet that lasts longer than the other
in order to use its power (Pi) as the basis of interference. When
another signal (packet) comes in, it checks the power of the new signal
(Ps), and computes Ps/Pi. Each node can receive each packet only when
there was no interference, or Ps/Pi was always above a certain threshold
(I think it is 10 dB by default) during the packet reception.

The model keeps a pointer to the packet whose transmission lasts longer
because it may interfere with more forthcoming packets. However, there
are many problems with it:
- It does not consider the power value. The model simply chooses the
packet that lasts longer even if the reception power of the other packet
whose transmission ends sooner by 1 nanosecond is 100 times stronger.
- The actual interference is cumulative. When multiple signals other
than the signal of interest are present, SIR (Signal to Interference
Ratio) must be calculated using power from all signals currently on the
channel. The model abstracts out this effect, and is inaccurate when
there are multiple interference sources (transmitters or jammers) in the
network. There is no consideration of noise in the model either.

One of my papers may be useful to understand these issues:

Effects of Wireless Physical Layer Modeling in Mobile Ad Hoc Networks
Mineo Takai, Jay Martin and Rajive Bagrodia
Proceedings of the 2001 ACM International Symposium on Mobile Ad Hoc
Networking & Computing (MobiHoc 2001), pp. 87-94, October 2001. 
(ftp://pcl.cs.ucla.edu/pub/papers/mobihoc.ps) 

After this publication, I noticed ns folks fixed another problem pointed
out in the paper (preamble length), but this interference modeling have
not been fixed yet. It is much harder to fix it than the other, and the
modification may significantly slow down ns-2. However, in my opinion,
it should be worth fixing.

Regards,

Mineo

sabeel ansari wrote:
> 
> Hi
> I was going through the IEEE 802.11 MAC source code in the NS2.
> Here, it says that when a collision takes place,
> check the two packets and discard the packet which is going to end
> earlier. Shouldnt it be the other way around.
> 
> void
> Mac802_11::collision(Packet *p)
> {
>         switch(rx_state_) {
>         case MAC_RECV:
>                 SET_RX_STATE(MAC_COLL);
>                 /* fall through */
>         case MAC_COLL:
>                 assert(pktRx_);
>                 assert(mhRecv_.busy());
>                 /*
>                  *  Since a collision has occurred, figure out
>                  *  which packet that caused the collision will
>                  *  "last" the longest.  Make this packet,
>                  *  pktRx_ and reset the Recv Timer if necessary.
>                  */
>                 if(TX_Time(p) > mhRecv_.expire()) {
>                         mhRecv_.stop();
>                         discard(pktRx_, DROP_MAC_COLLISION);
>                         pktRx_ = p;
>                         mhRecv_.start(TX_Time(pktRx_));
>                 }
>                 else {
>                         discard(p, DROP_MAC_COLLISION);
>                 }
>                 break;
>         default:
>                 assert(0);
>         }
> }
> 
> sabeel
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 18:52:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12032
	for ; Tue, 30 Jul 2002 18:52:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00863;
	Tue, 30 Jul 2002 18:28:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00834
	for ; Tue, 30 Jul 2002 18:28:29 -0400 (EDT)
Received: from che.onthejob.net (che.onthejob.net [63.146.38.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11455
	for ; Tue, 30 Jul 2002 18:27:23 -0400 (EDT)
Received: (from dyoung@localhost)
	by che.onthejob.net (8.9.3/8.9.3) id RAA11494
	for manet@ietf.org; Tue, 30 Jul 2002 17:27:59 -0500
Date: Tue, 30 Jul 2002 17:27:59 -0500
From: David Young 
To: manet@ietf.org
Subject: Re: [manet] research for ad hoc community networks?
Message-ID: <20020730172759.A11406@che.onthejob.net>
Reply-To: dyoung@pobox.com
Mail-Followup-To: David Young , manet@ietf.org
References: <20020723135047.A31977@che.onthejob.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: ; from jains@ECECS.UC.EDU on Wed, Jul 24, 2002 at 12:18:35PM -0400
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Thank you, this was enormously useful.

Has anyone else built a test-bed like Mr. Chambers'?

Dave

On Wed, Jul 24, 2002 at 12:18:35PM -0400, Saurabh Jain wrote:
> Dave
> 
> I suggest you view the Master's thesis of Benjamin A. Chambers. It's title
> is "The Grid Roofnet: a Rooftop Ad Hoc Wireless Network". He has worked on
> community ad hoc networks, using the Grid routing system. The thesis is
> available for download from the Grid website at
> http://www.pdos.lcs.mit.edu/grid/
> 
> Regards,
> Saurabh
> 
> On Tue, 23 Jul 2002, David Young wrote:
> 
> > 
> > In my community, a small band of community organizers and computer geeks
> > is trying to build a community network using inexpensive 802.11 radios. I
> > feel certain that our success will depend on our adoption of ad hoc
> > networking principles: We do not anticipate the magnitude of private
> > or governmental investment that will help us afford to individually
> > configure stations on the network, to buy space on radio towers for
> > wireless base stations, to point antennas from rooftop to base station,
> > or to administrate hundreds or thousands of stations. But with stations
> > that auto-configure their IP numbers, that tolerate ever-changing link
> > topologies, that discover and choose Internet gateways, we will be able to
> > build a network by modest expenditures (such as the cost of a computer,
> > radio, and omni antenna) and we will keep network administration costs
> > under control.
> > 
> > As I read the commercial literature and the scientific literature
> > on ad hoc networks, I am struck by two things:
> > 
> >  * it is difficult (for me) to infer from a routing protocol's performance
> >    in a "random waypoint" test how it will perform on rooftops in compact,
> >    semi-wooded neighborhoods of two-story homes
> > 
> >  * insofar as "rooftop networks" have been deployed, it is only by
> >    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
> >    use technologies that are trade secrets, so I can draw no conclusions
> >    from their experience
> > 
> > I have the ear of some researchers in ad hoc networks on this mailing
> > list, so I ask you, are they any of your findings that speak directly to
> > the problem of networking communities from rooftops?
> > 
> > Will anyone advocate for a particular combination of protocols to build
> > a rooftop network?
> > 
> > Dave
> > 
> > -- 
> > David Young             OJC Technologies
> > dyoung@onthejob.net     Engineering from the Right Brain
> >                         Urbana, IL * (217) 278-3933
> > 
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> > 
> 
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> saurabh@ee.iitm.ernet.in    Home: +1-513-556-7447, Lab: 556-3437
> #511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219
> SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42
> Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN
> 
> 
> 

-- 
David Young             OJC Technologies
dyoung@onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 18:52:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12041
	for ; Tue, 30 Jul 2002 18:52:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA02616
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 18:53:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00863;
	Tue, 30 Jul 2002 18:28:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00834
	for ; Tue, 30 Jul 2002 18:28:29 -0400 (EDT)
Received: from che.onthejob.net (che.onthejob.net [63.146.38.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11455
	for ; Tue, 30 Jul 2002 18:27:23 -0400 (EDT)
Received: (from dyoung@localhost)
	by che.onthejob.net (8.9.3/8.9.3) id RAA11494
	for manet@ietf.org; Tue, 30 Jul 2002 17:27:59 -0500
Date: Tue, 30 Jul 2002 17:27:59 -0500
From: David Young 
To: manet@ietf.org
Subject: Re: [manet] research for ad hoc community networks?
Message-ID: <20020730172759.A11406@che.onthejob.net>
Reply-To: dyoung@pobox.com
Mail-Followup-To: David Young , manet@ietf.org
References: <20020723135047.A31977@che.onthejob.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: ; from jains@ECECS.UC.EDU on Wed, Jul 24, 2002 at 12:18:35PM -0400
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Thank you, this was enormously useful.

Has anyone else built a test-bed like Mr. Chambers'?

Dave

On Wed, Jul 24, 2002 at 12:18:35PM -0400, Saurabh Jain wrote:
> Dave
> 
> I suggest you view the Master's thesis of Benjamin A. Chambers. It's title
> is "The Grid Roofnet: a Rooftop Ad Hoc Wireless Network". He has worked on
> community ad hoc networks, using the Grid routing system. The thesis is
> available for download from the Grid website at
> http://www.pdos.lcs.mit.edu/grid/
> 
> Regards,
> Saurabh
> 
> On Tue, 23 Jul 2002, David Young wrote:
> 
> > 
> > In my community, a small band of community organizers and computer geeks
> > is trying to build a community network using inexpensive 802.11 radios. I
> > feel certain that our success will depend on our adoption of ad hoc
> > networking principles: We do not anticipate the magnitude of private
> > or governmental investment that will help us afford to individually
> > configure stations on the network, to buy space on radio towers for
> > wireless base stations, to point antennas from rooftop to base station,
> > or to administrate hundreds or thousands of stations. But with stations
> > that auto-configure their IP numbers, that tolerate ever-changing link
> > topologies, that discover and choose Internet gateways, we will be able to
> > build a network by modest expenditures (such as the cost of a computer,
> > radio, and omni antenna) and we will keep network administration costs
> > under control.
> > 
> > As I read the commercial literature and the scientific literature
> > on ad hoc networks, I am struck by two things:
> > 
> >  * it is difficult (for me) to infer from a routing protocol's performance
> >    in a "random waypoint" test how it will perform on rooftops in compact,
> >    semi-wooded neighborhoods of two-story homes
> > 
> >  * insofar as "rooftop networks" have been deployed, it is only by
> >    commercial ventures (MeshNetworks.com, Nokia RoofTop, others) who
> >    use technologies that are trade secrets, so I can draw no conclusions
> >    from their experience
> > 
> > I have the ear of some researchers in ad hoc networks on this mailing
> > list, so I ask you, are they any of your findings that speak directly to
> > the problem of networking communities from rooftops?
> > 
> > Will anyone advocate for a particular combination of protocols to build
> > a rooftop network?
> > 
> > Dave
> > 
> > -- 
> > David Young             OJC Technologies
> > dyoung@onthejob.net     Engineering from the Right Brain
> >                         Urbana, IL * (217) 278-3933
> > 
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> > 
> 
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> saurabh@ee.iitm.ernet.in    Home: +1-513-556-7447, Lab: 556-3437
> #511, 2930 Scioto St, Univ of Cincinnati, Cincinnati, Ohio 45219
> SF3/B, Vasanth Apts, 58 Velachery Main Rd, Velachery, Chennai 42
> Office: Dept of Electrical Engg, IIT Madras, Chennai 600 036, IN
> 
> 
> 

-- 
David Young             OJC Technologies
dyoung@onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Tue Jul 30 21:45:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15668
	for ; Tue, 30 Jul 2002 21:45:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09209;
	Tue, 30 Jul 2002 21:24:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09180
	for ; Tue, 30 Jul 2002 21:24:28 -0400 (EDT)
Received: from smtp.263.net ([211.157.130.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15165
	for ; Tue, 30 Jul 2002 21:23:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by smtp.263.net (Postfix) with SMTP id 8EC161DC82950
	for ; Wed, 31 Jul 2002 09:14:31 +0800 (CST)
Received: from befine (unknown [211.71.13.13])
	by 192.168.30.29 (Coremail) with SMTP id 9g0AAPM5Rz3yLA0N.1
	for ; Wed, 31 Jul 2002 09:14:31 +0800 (CST)
Date: Wed, 31 Jul 2002 9:20:34 +0800
From: "Harry" 
To: "manet@ietf.org" 
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20020731011431.8EC161DC82950@smtp.263.net>
Content-Transfer-Encoding: 7bit
Subject: [manet] about simulation
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

hi all, 
	As for our mobile ad hoc network research , anybody know which simulation software is suitable ,NS2 or GloMoSim ,or anything else?

	Harry




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Tue Jul 30 21:58:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16274
	for ; Tue, 30 Jul 2002 21:58:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10654;
	Tue, 30 Jul 2002 21:41:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10624
	for ; Tue, 30 Jul 2002 21:40:56 -0400 (EDT)
Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15455
	for ; Tue, 30 Jul 2002 21:39:47 -0400 (EDT)
Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23])
	by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id JAA12220;
	Wed, 31 Jul 2002 09:40:53 +0800 (GMT-8)
Received: from sf3.comp.nus.edu.sg(137.132.90.55) by e500a.comp.nus.edu.sg via csmap 
	 id 25507; Wed, 31 Jul 2002 09:36:48 +0800 (SGT)
Received: from localhost (sridhark@localhost)
	by sf3.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id JAA04467;
	Wed, 31 Jul 2002 09:40:52 +0800 (GMT-8)
Date: Wed, 31 Jul 2002 09:40:52 +0800 (GMT-8)
From: Sridhar K N 
To: feng zhu 
cc: manet@ietf.org
Subject: Re: [manet] a list of papers on security for ad hoc networks
In-Reply-To: <20020730193451.61562.qmail@web12901.mail.yahoo.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id VAA10625
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

here are some other papers.

1. A distributed Light-weight AUthentication Model for Ad-Hoc Networks, 
by ANdre Weimerskirch and Gilles Thonet.

2. Nodes Bearing Grudges: Towards Routing Security, Fairness and
Roubustness in Mobile Ad Hoc Networks. by Sonja Buchegger and Jean-Yves Le
Boudec.


3. AT&T Labs Technical Report, Using the Fluhrer, Mantin, and Shamir
Attack to Break WEP.

Regards
Sridhar


#############################################################################

On Tue, 30 Jul 2002, feng zhu wrote:

> Hi, All,
> 
> I made a webpage to contain a list of papers on
> security for ad hoc networks.
> 
> http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> 
> If you wrote and/or know of any papers concerning
> security for ad hoc networks that are not listed here,
> please let me know.
> 
> Contract me: zf_manet@yahoo.com
> 
> Best,
> Feng
> 
> The following is a part of the list.
> ========================================
> 
> 
> Key Exchange and Distribution:
> 
> [AG] N. Asokan, Philip Ginzboorg Key agreement in ad
> hoc networks  
> 
> [H] Maarit Hietalahti  Key Establishment in Ad-hoc
> Networks
> 
> [CBH]Srdjan Capkuny, Levente Buttyan and Jean-Pierre
> Hubaux Self-Organized Public-Key Management for Mobile
> Ad Hoc Networks
> 
>  
> 
> Secure Routing:
> 
> [BT] Jim Brinkley William Trost Authenticated Ad Hoc
> Routing at the Link Layer for Mobile Systems 1996 
> 
> [DLRS]Bridget Dahill, Brian Neil Levine, Elizabeth
> Royer, Clay Shields. A Secure Routing Protocol for Ad
> Hoc Networks
> 
> [HPJ] Yih-Chun Hu, Adrian Perrig, David B. Johnson.
> Ariadne: A secure On-Demand Routing Protocol for Ad
> hoc Networks
> 
> [MGLB] Sergio Marti and T. J. Giuli and Kevin Lai and
> Mary Baker. Mitigating routing misbehavior in mobile
> ad hoc networks. Mobile Computing and Networking
> (2000): 
> 
> [PH] Panagiotis Papadimitratos and Zygmunt J. Haas
> Secure Routing for Mobile Ad hoc Networks and  
> [slides]
> 
> [SMG] Bradley R. Smith, Shree Murthy, J.J.
> Garcia-Luna-Aceves Securing Distance-Vector Routing
> Protocols
> 
> [YNK] Seung Yi, Prasad Naldurg, Robin Kravets. A
> Security-Aware Ad Hoc Routing Protocol for Wireless
> Networks [2]
> 
> [L] Janne Lundberg Routing Security in Ad Hoc Networks
> 
> [HJP] Yih-Chun Hu, David B. Johnson, and Adrian
> Perrig. SEAD: Secure Efficient Distance Vector Routing
> for Mobile Wireless Ad Hoc Networks. Proceedings of
> the 4th IEEE Workshop on Mobile Computing Systems &
> Applications (WMCSA 2002), pp. 3-13, IEEE, Calicoon,
> NY, June 2002.
> 
> [Z]Manel Guerrero Zapata Secure Ad hoc On-Demand
> Distance Vector (SAODV) Routing
> 
>  
> 
> Group Communication:
> 
> [YD] Alec Yasinsac Jim Davis. Modeling Protocols for
> Secure Group Communication in Ad Hoc Networks
> (Extended Abstract)
> 
> [MAH ]Silja Mäki, Tuomas Aura, Maarit Hietalahti
> Robust Membership Management for Ad-hoc Groups
> 
>  
> 
> Other Security issues: 
> 
> [CK] Candolin, H. Kari, A Security Architecture for
> Wireless Ad hoc Networks, to be published at IEEE
> Milcom 2002, Anaheim, California, October 7-10, 2002
> 
> [EGN] Pasi Eronen, Christian Gehrmann, Pekka Nikander
> Securing ad hoc Jini services
> 
> [HBC} Jean-Pierre Hubaux, Levente Buttyan, Srdjan
> Capkun (Swiss Federal Institute of Technology) The
> Quest for Security in Mobile Ad Hoc Networks
> 
> [LKZLZ] Haiyun Luo, Jiejun Kong, Petros Zerfos, Songwu
> Lu and Lixia Zhang, Self-securing Ad Hoc Wireless
> Networks  
> 
> [K] Vesa Karpijoki Security in Ad Hoc Networks 
> 
> [SA] Frank Stajano and Ross Anderson The Resurrecting
> Duckling: Security Issues for Ad-hoc Wireless Networks
> 
> [SH] Christian Schwingenschlögl and Marc-Philipp Horn
> Build Blocks for Secure Communication in Ad-hoc
> Networks
> 
> [V] Anne Vanhala Security in Ad-hoc Networks 
> 
> [ZH] Lidong Zhou, Zygmunt J. Haas. Securing ad hoc
> networks. IEEE Communications, Vol. 13 No. 6
> 
> [ZL] Yongguang Zhang & Wenke Lee, Intrusion Detection
> in Wireless Ad-Hoc Networks
> 
> [LL] Haiyun Luo, Songwu Lu Ubiquitous and Robust
> Authentication Services for Ad Hoc Wireless Networks, 
> 
> [KZLLZ] Jiejun Kong, Petros Zerfos, Haiyun Luo, Songwu
> Lu and Lixia Zhang.  Providing Robust and Ubiquitous
> Security Support for Mobile Ad-Hoc Networks
> 
> [GN] Christian Gehrmann (Ericsson Research), and Pekka
> Nikander (Helsinki Institute of Technology) Securing
> Ad Hoc Services, a Jini View
> 
> [KLXGGL] Jiejun Kong, Haiyun Luo, Kaixin Xu, Daniel
> Lihui Gu, Mario Gerla, Songwu Lu Adaptive Security for
> Multi-layer Ad-hoc Networks
> 
> [BH]Levente Buttyan and Jean-Pierre Hubaux  Enforcing
> Service Availability in Mobile Ad-Hoc WANs  
> 
> [VA]Lakshmi Venkatraman and Dharma P. Agrawal  A Novel
> Authentication scheme for Ad hoc Networks
> 
> [BSSW]Dirk Balfanz, D. K. Smetters, Paul Stewart and
> H. Chi Wong Talking To Strangers: Authentication in
> Ad-Hoc Wireless Networks
> 
> [J]Stuart Jacobs MANET Authentication Architecture
>  (slides)
> 
>  
> 
>  
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Tue Jul 30 21:58:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16284
	for ; Tue, 30 Jul 2002 21:58:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA11539
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 21:59:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10654;
	Tue, 30 Jul 2002 21:41:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10624
	for ; Tue, 30 Jul 2002 21:40:56 -0400 (EDT)
Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15455
	for ; Tue, 30 Jul 2002 21:39:47 -0400 (EDT)
Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23])
	by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id JAA12220;
	Wed, 31 Jul 2002 09:40:53 +0800 (GMT-8)
Received: from sf3.comp.nus.edu.sg(137.132.90.55) by e500a.comp.nus.edu.sg via csmap 
	 id 25507; Wed, 31 Jul 2002 09:36:48 +0800 (SGT)
Received: from localhost (sridhark@localhost)
	by sf3.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id JAA04467;
	Wed, 31 Jul 2002 09:40:52 +0800 (GMT-8)
Date: Wed, 31 Jul 2002 09:40:52 +0800 (GMT-8)
From: Sridhar K N 
To: feng zhu 
cc: manet@ietf.org
Subject: Re: [manet] a list of papers on security for ad hoc networks
In-Reply-To: <20020730193451.61562.qmail@web12901.mail.yahoo.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id VAA10625
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 8bit

here are some other papers.

1. A distributed Light-weight AUthentication Model for Ad-Hoc Networks, 
by ANdre Weimerskirch and Gilles Thonet.

2. Nodes Bearing Grudges: Towards Routing Security, Fairness and
Roubustness in Mobile Ad Hoc Networks. by Sonja Buchegger and Jean-Yves Le
Boudec.


3. AT&T Labs Technical Report, Using the Fluhrer, Mantin, and Shamir
Attack to Break WEP.

Regards
Sridhar


#############################################################################

On Tue, 30 Jul 2002, feng zhu wrote:

> Hi, All,
> 
> I made a webpage to contain a list of papers on
> security for ad hoc networks.
> 
> http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> 
> If you wrote and/or know of any papers concerning
> security for ad hoc networks that are not listed here,
> please let me know.
> 
> Contract me: zf_manet@yahoo.com
> 
> Best,
> Feng
> 
> The following is a part of the list.
> ========================================
> 
> 
> Key Exchange and Distribution:
> 
> [AG] N. Asokan, Philip Ginzboorg Key agreement in ad
> hoc networks  
> 
> [H] Maarit Hietalahti  Key Establishment in Ad-hoc
> Networks
> 
> [CBH]Srdjan Capkuny, Levente Buttyan and Jean-Pierre
> Hubaux Self-Organized Public-Key Management for Mobile
> Ad Hoc Networks
> 
>  
> 
> Secure Routing:
> 
> [BT] Jim Brinkley William Trost Authenticated Ad Hoc
> Routing at the Link Layer for Mobile Systems 1996 
> 
> [DLRS]Bridget Dahill, Brian Neil Levine, Elizabeth
> Royer, Clay Shields. A Secure Routing Protocol for Ad
> Hoc Networks
> 
> [HPJ] Yih-Chun Hu, Adrian Perrig, David B. Johnson.
> Ariadne: A secure On-Demand Routing Protocol for Ad
> hoc Networks
> 
> [MGLB] Sergio Marti and T. J. Giuli and Kevin Lai and
> Mary Baker. Mitigating routing misbehavior in mobile
> ad hoc networks. Mobile Computing and Networking
> (2000): 
> 
> [PH] Panagiotis Papadimitratos and Zygmunt J. Haas
> Secure Routing for Mobile Ad hoc Networks and  
> [slides]
> 
> [SMG] Bradley R. Smith, Shree Murthy, J.J.
> Garcia-Luna-Aceves Securing Distance-Vector Routing
> Protocols
> 
> [YNK] Seung Yi, Prasad Naldurg, Robin Kravets. A
> Security-Aware Ad Hoc Routing Protocol for Wireless
> Networks [2]
> 
> [L] Janne Lundberg Routing Security in Ad Hoc Networks
> 
> [HJP] Yih-Chun Hu, David B. Johnson, and Adrian
> Perrig. SEAD: Secure Efficient Distance Vector Routing
> for Mobile Wireless Ad Hoc Networks. Proceedings of
> the 4th IEEE Workshop on Mobile Computing Systems &
> Applications (WMCSA 2002), pp. 3-13, IEEE, Calicoon,
> NY, June 2002.
> 
> [Z]Manel Guerrero Zapata Secure Ad hoc On-Demand
> Distance Vector (SAODV) Routing
> 
>  
> 
> Group Communication:
> 
> [YD] Alec Yasinsac Jim Davis. Modeling Protocols for
> Secure Group Communication in Ad Hoc Networks
> (Extended Abstract)
> 
> [MAH ]Silja Mäki, Tuomas Aura, Maarit Hietalahti
> Robust Membership Management for Ad-hoc Groups
> 
>  
> 
> Other Security issues: 
> 
> [CK] Candolin, H. Kari, A Security Architecture for
> Wireless Ad hoc Networks, to be published at IEEE
> Milcom 2002, Anaheim, California, October 7-10, 2002
> 
> [EGN] Pasi Eronen, Christian Gehrmann, Pekka Nikander
> Securing ad hoc Jini services
> 
> [HBC} Jean-Pierre Hubaux, Levente Buttyan, Srdjan
> Capkun (Swiss Federal Institute of Technology) The
> Quest for Security in Mobile Ad Hoc Networks
> 
> [LKZLZ] Haiyun Luo, Jiejun Kong, Petros Zerfos, Songwu
> Lu and Lixia Zhang, Self-securing Ad Hoc Wireless
> Networks  
> 
> [K] Vesa Karpijoki Security in Ad Hoc Networks 
> 
> [SA] Frank Stajano and Ross Anderson The Resurrecting
> Duckling: Security Issues for Ad-hoc Wireless Networks
> 
> [SH] Christian Schwingenschlögl and Marc-Philipp Horn
> Build Blocks for Secure Communication in Ad-hoc
> Networks
> 
> [V] Anne Vanhala Security in Ad-hoc Networks 
> 
> [ZH] Lidong Zhou, Zygmunt J. Haas. Securing ad hoc
> networks. IEEE Communications, Vol. 13 No. 6
> 
> [ZL] Yongguang Zhang & Wenke Lee, Intrusion Detection
> in Wireless Ad-Hoc Networks
> 
> [LL] Haiyun Luo, Songwu Lu Ubiquitous and Robust
> Authentication Services for Ad Hoc Wireless Networks, 
> 
> [KZLLZ] Jiejun Kong, Petros Zerfos, Haiyun Luo, Songwu
> Lu and Lixia Zhang.  Providing Robust and Ubiquitous
> Security Support for Mobile Ad-Hoc Networks
> 
> [GN] Christian Gehrmann (Ericsson Research), and Pekka
> Nikander (Helsinki Institute of Technology) Securing
> Ad Hoc Services, a Jini View
> 
> [KLXGGL] Jiejun Kong, Haiyun Luo, Kaixin Xu, Daniel
> Lihui Gu, Mario Gerla, Songwu Lu Adaptive Security for
> Multi-layer Ad-hoc Networks
> 
> [BH]Levente Buttyan and Jean-Pierre Hubaux  Enforcing
> Service Availability in Mobile Ad-Hoc WANs  
> 
> [VA]Lakshmi Venkatraman and Dharma P. Agrawal  A Novel
> Authentication scheme for Ad hoc Networks
> 
> [BSSW]Dirk Balfanz, D. K. Smetters, Paul Stewart and
> H. Chi Wong Talking To Strangers: Authentication in
> Ad-Hoc Wireless Networks
> 
> [J]Stuart Jacobs MANET Authentication Architecture
>  (slides)
> 
>  
> 
>  
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Tue Jul 30 22:34:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15678
	for ; Tue, 30 Jul 2002 21:45:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA11102
	for manet-archive@odin.ietf.org; Tue, 30 Jul 2002 21:46:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09209;
	Tue, 30 Jul 2002 21:24:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09180
	for ; Tue, 30 Jul 2002 21:24:28 -0400 (EDT)
Received: from smtp.263.net ([211.157.130.148])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15165
	for ; Tue, 30 Jul 2002 21:23:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by smtp.263.net (Postfix) with SMTP id 8EC161DC82950
	for ; Wed, 31 Jul 2002 09:14:31 +0800 (CST)
Received: from befine (unknown [211.71.13.13])
	by 192.168.30.29 (Coremail) with SMTP id 9g0AAPM5Rz3yLA0N.1
	for ; Wed, 31 Jul 2002 09:14:31 +0800 (CST)
Date: Wed, 31 Jul 2002 9:20:34 +0800
From: "Harry" 
To: "manet@ietf.org" 
X-mailer: Foxmail 4.1 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20020731011431.8EC161DC82950@smtp.263.net>
Content-Transfer-Encoding: 7bit
Subject: [manet] about simulation
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

hi all, 
	As for our mobile ad hoc network research , anybody know which simulation software is suitable ,NS2 or GloMoSim ,or anything else?

	Harry




_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 01:38:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21695
	for ; Wed, 31 Jul 2002 01:38:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29142;
	Wed, 31 Jul 2002 01:24:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29034
	for ; Wed, 31 Jul 2002 01:24:21 -0400 (EDT)
Received: from web12908.mail.yahoo.com (web12908.mail.yahoo.com [216.136.174.75])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21341
	for ; Wed, 31 Jul 2002 01:23:12 -0400 (EDT)
Message-ID: <20020731052419.9616.qmail@web12908.mail.yahoo.com>
Received: from [12.235.38.65] by web12908.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 22:24:19 PDT
Date: Tue, 30 Jul 2002 22:24:19 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Sridhar K N 
Cc: manet@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, 

Thank you for your information.

I have updated the web page

http://www.ccs.neu.edu/home/zhufeng/security_manet.html

The first two papers have been listed in the web page.
But the 3rd paper is about WEP and IEEE802.11, not ad
hoc network. So I did not add it into the web page.

Best,
Feng
 

--- Sridhar K N  wrote:
> here are some other papers.
> 
> 1. A distributed Light-weight AUthentication Model
> for Ad-Hoc Networks, 
> by ANdre Weimerskirch and Gilles Thonet.
> 
> 2. Nodes Bearing Grudges: Towards Routing Security,
> Fairness and
> Roubustness in Mobile Ad Hoc Networks. by Sonja
> Buchegger and Jean-Yves Le
> Boudec.
> 
> 
> 3. AT&T Labs Technical Report, Using the Fluhrer,
> Mantin, and Shamir
> Attack to Break WEP.
> 
> Regards
> Sridhar
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 01:38:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21708
	for ; Wed, 31 Jul 2002 01:38:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA00651
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 01:40:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29142;
	Wed, 31 Jul 2002 01:24:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29034
	for ; Wed, 31 Jul 2002 01:24:21 -0400 (EDT)
Received: from web12908.mail.yahoo.com (web12908.mail.yahoo.com [216.136.174.75])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21341
	for ; Wed, 31 Jul 2002 01:23:12 -0400 (EDT)
Message-ID: <20020731052419.9616.qmail@web12908.mail.yahoo.com>
Received: from [12.235.38.65] by web12908.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 22:24:19 PDT
Date: Tue, 30 Jul 2002 22:24:19 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Sridhar K N 
Cc: manet@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, 

Thank you for your information.

I have updated the web page

http://www.ccs.neu.edu/home/zhufeng/security_manet.html

The first two papers have been listed in the web page.
But the 3rd paper is about WEP and IEEE802.11, not ad
hoc network. So I did not add it into the web page.

Best,
Feng
 

--- Sridhar K N  wrote:
> here are some other papers.
> 
> 1. A distributed Light-weight AUthentication Model
> for Ad-Hoc Networks, 
> by ANdre Weimerskirch and Gilles Thonet.
> 
> 2. Nodes Bearing Grudges: Towards Routing Security,
> Fairness and
> Roubustness in Mobile Ad Hoc Networks. by Sonja
> Buchegger and Jean-Yves Le
> Boudec.
> 
> 
> 3. AT&T Labs Technical Report, Using the Fluhrer,
> Mantin, and Shamir
> Attack to Break WEP.
> 
> Regards
> Sridhar
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 01:40:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21748
	for ; Wed, 31 Jul 2002 01:40:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28926;
	Wed, 31 Jul 2002 01:22:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28883
	for ; Wed, 31 Jul 2002 01:22:24 -0400 (EDT)
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21308;
	Wed, 31 Jul 2002 01:21:11 -0400 (EDT)
Received: from d23rh902.au.ibm.com (d23rh902.au.ibm.com [9.185.167.101])
	by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id g6V5Eahh246178;
	Wed, 31 Jul 2002 15:14:36 +1000
Received: from d23m0061.in.ibm.com (d23m0061.in.ibm.com [9.184.208.100])
	by d23rh902.au.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6V5IRJI017730;
	Wed, 31 Jul 2002 15:18:28 +1000
Subject: Re: [manet] IEEE 802.11 MAC collision implementation in NS2
To: Mineo Takai 
Cc: manet@ietf.org, manet-admin@ietf.org,
        sabeel ansari , ns-users@isi.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: 
From: "Sorav Bansal" 
Date: Wed, 31 Jul 2002 10:47:06 +0530
X-MIMETrack: Serialize by Router on d23m0061/23/M/IBM(Release 5.0.9a |January 7, 2002) at
 31/07/2002 10:47:08 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi Mineo,

    I had a chance to go through your paper and I agree with both the
points you have mentioned. In one of my works, in case of a collision, I
kept a pointer to the packet that lasts longer and also set the receive
power of that packet to the sum of the receive powers of the two packets.
This is a conservative approach (Though this implementation is not
absolutely correct, I chose this just due to the ease of implementation).

    I would like to point to another issue in the MAC implementation. As
you mention, each receiver can receive a packet only if there was no
interference or Ps/Pi was always above a certain threshold (10 dB by
default) during the packet reception. If the packet with the higher power
(Ps) arrives later than the packet with rxpower Pi, the second packet is
dropped even though it is 100 times stronger than the first signal. This
seems like an implementation bug. After talking to a few people, I gathered
that it is because if the receiver is tuned to the chip rate of the first
packet, it cannot decipher the second packet no matter how strong the
second packet signal is. Even if this is true, the problem however is:
      If the first packet (Pi) is only being carrier-sensed (not being
received), then it makes no sense to "capture" the second packet if Ps/Pi >
10dB (since the first packet is not actually being received-it is just
acting as noise for the receiver).

      It would be great if this could be corrected (assuming this is a
valid error) by the ns people (I would be glad to volunteer to make these
changes in ns).

Regards,
Sorav

PS: Please let me know if this is not the right place to be discussing
this. As Mineo said, I believe many people on this list use ns-2



                                                                                                                               
                      Mineo Takai                                                                                              
                                                
                      u>                       cc:       manet@ietf.org                                                        
                      Sent by:                 Subject:  Re: [manet] IEEE 802.11 MAC collision implementation in NS2           
                      manet-admin@ietf.                                                                                        
                      org                                                                                                      
                                                                                                                               
                                                                                                                               
                      07/31/02 03:33 AM                                                                                        
                                                                                                                               
                                                                                                                               



Hello Sabeel,

This question may be more appropriate for the ns-2 users mailing list,
but I am describing what that piece of ns-2 code does because I know
many people on this list use ns-2. When a collision happens at a node,
the model keeps a pointer to the packet that lasts longer than the other
in order to use its power (Pi) as the basis of interference. When
another signal (packet) comes in, it checks the power of the new signal
(Ps), and computes Ps/Pi. Each node can receive each packet only when
there was no interference, or Ps/Pi was always above a certain threshold
(I think it is 10 dB by default) during the packet reception.

The model keeps a pointer to the packet whose transmission lasts longer
because it may interfere with more forthcoming packets. However, there
are many problems with it:
- It does not consider the power value. The model simply chooses the
packet that lasts longer even if the reception power of the other packet
whose transmission ends sooner by 1 nanosecond is 100 times stronger.
- The actual interference is cumulative. When multiple signals other
than the signal of interest are present, SIR (Signal to Interference
Ratio) must be calculated using power from all signals currently on the
channel. The model abstracts out this effect, and is inaccurate when
there are multiple interference sources (transmitters or jammers) in the
network. There is no consideration of noise in the model either.

One of my papers may be useful to understand these issues:

Effects of Wireless Physical Layer Modeling in Mobile Ad Hoc Networks
Mineo Takai, Jay Martin and Rajive Bagrodia
Proceedings of the 2001 ACM International Symposium on Mobile Ad Hoc
Networking & Computing (MobiHoc 2001), pp. 87-94, October 2001.
(ftp://pcl.cs.ucla.edu/pub/papers/mobihoc.ps)

After this publication, I noticed ns folks fixed another problem pointed
out in the paper (preamble length), but this interference modeling have
not been fixed yet. It is much harder to fix it than the other, and the
modification may significantly slow down ns-2. However, in my opinion,
it should be worth fixing.

Regards,

Mineo

sabeel ansari wrote:
>
> Hi
> I was going through the IEEE 802.11 MAC source code in the NS2.
> Here, it says that when a collision takes place,
> check the two packets and discard the packet which is going to end
> earlier. Shouldnt it be the other way around.
>
> void
> Mac802_11::collision(Packet *p)
> {
>         switch(rx_state_) {
>         case MAC_RECV:
>                 SET_RX_STATE(MAC_COLL);
>                 /* fall through */
>         case MAC_COLL:
>                 assert(pktRx_);
>                 assert(mhRecv_.busy());
>                 /*
>                  *  Since a collision has occurred, figure out
>                  *  which packet that caused the collision will
>                  *  "last" the longest.  Make this packet,
>                  *  pktRx_ and reset the Recv Timer if necessary.
>                  */
>                 if(TX_Time(p) > mhRecv_.expire()) {
>                         mhRecv_.stop();
>                         discard(pktRx_, DROP_MAC_COLLISION);
>                         pktRx_ = p;
>                         mhRecv_.start(TX_Time(pktRx_));
>                 }
>                 else {
>                         discard(p, DROP_MAC_COLLISION);
>                 }
>                 break;
>         default:
>                 assert(0);
>         }
> }
>
> sabeel
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 01:40:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21761
	for ; Wed, 31 Jul 2002 01:40:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA00704
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 01:41:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28926;
	Wed, 31 Jul 2002 01:22:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28883
	for ; Wed, 31 Jul 2002 01:22:24 -0400 (EDT)
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21308;
	Wed, 31 Jul 2002 01:21:11 -0400 (EDT)
Received: from d23rh902.au.ibm.com (d23rh902.au.ibm.com [9.185.167.101])
	by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id g6V5Eahh246178;
	Wed, 31 Jul 2002 15:14:36 +1000
Received: from d23m0061.in.ibm.com (d23m0061.in.ibm.com [9.184.208.100])
	by d23rh902.au.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6V5IRJI017730;
	Wed, 31 Jul 2002 15:18:28 +1000
Subject: Re: [manet] IEEE 802.11 MAC collision implementation in NS2
To: Mineo Takai 
Cc: manet@ietf.org, manet-admin@ietf.org,
        sabeel ansari , ns-users@isi.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: 
From: "Sorav Bansal" 
Date: Wed, 31 Jul 2002 10:47:06 +0530
X-MIMETrack: Serialize by Router on d23m0061/23/M/IBM(Release 5.0.9a |January 7, 2002) at
 31/07/2002 10:47:08 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org


Hi Mineo,

    I had a chance to go through your paper and I agree with both the
points you have mentioned. In one of my works, in case of a collision, I
kept a pointer to the packet that lasts longer and also set the receive
power of that packet to the sum of the receive powers of the two packets.
This is a conservative approach (Though this implementation is not
absolutely correct, I chose this just due to the ease of implementation).

    I would like to point to another issue in the MAC implementation. As
you mention, each receiver can receive a packet only if there was no
interference or Ps/Pi was always above a certain threshold (10 dB by
default) during the packet reception. If the packet with the higher power
(Ps) arrives later than the packet with rxpower Pi, the second packet is
dropped even though it is 100 times stronger than the first signal. This
seems like an implementation bug. After talking to a few people, I gathered
that it is because if the receiver is tuned to the chip rate of the first
packet, it cannot decipher the second packet no matter how strong the
second packet signal is. Even if this is true, the problem however is:
      If the first packet (Pi) is only being carrier-sensed (not being
received), then it makes no sense to "capture" the second packet if Ps/Pi >
10dB (since the first packet is not actually being received-it is just
acting as noise for the receiver).

      It would be great if this could be corrected (assuming this is a
valid error) by the ns people (I would be glad to volunteer to make these
changes in ns).

Regards,
Sorav

PS: Please let me know if this is not the right place to be discussing
this. As Mineo said, I believe many people on this list use ns-2



                                                                                                                               
                      Mineo Takai                                                                                              
                                                
                      u>                       cc:       manet@ietf.org                                                        
                      Sent by:                 Subject:  Re: [manet] IEEE 802.11 MAC collision implementation in NS2           
                      manet-admin@ietf.                                                                                        
                      org                                                                                                      
                                                                                                                               
                                                                                                                               
                      07/31/02 03:33 AM                                                                                        
                                                                                                                               
                                                                                                                               



Hello Sabeel,

This question may be more appropriate for the ns-2 users mailing list,
but I am describing what that piece of ns-2 code does because I know
many people on this list use ns-2. When a collision happens at a node,
the model keeps a pointer to the packet that lasts longer than the other
in order to use its power (Pi) as the basis of interference. When
another signal (packet) comes in, it checks the power of the new signal
(Ps), and computes Ps/Pi. Each node can receive each packet only when
there was no interference, or Ps/Pi was always above a certain threshold
(I think it is 10 dB by default) during the packet reception.

The model keeps a pointer to the packet whose transmission lasts longer
because it may interfere with more forthcoming packets. However, there
are many problems with it:
- It does not consider the power value. The model simply chooses the
packet that lasts longer even if the reception power of the other packet
whose transmission ends sooner by 1 nanosecond is 100 times stronger.
- The actual interference is cumulative. When multiple signals other
than the signal of interest are present, SIR (Signal to Interference
Ratio) must be calculated using power from all signals currently on the
channel. The model abstracts out this effect, and is inaccurate when
there are multiple interference sources (transmitters or jammers) in the
network. There is no consideration of noise in the model either.

One of my papers may be useful to understand these issues:

Effects of Wireless Physical Layer Modeling in Mobile Ad Hoc Networks
Mineo Takai, Jay Martin and Rajive Bagrodia
Proceedings of the 2001 ACM International Symposium on Mobile Ad Hoc
Networking & Computing (MobiHoc 2001), pp. 87-94, October 2001.
(ftp://pcl.cs.ucla.edu/pub/papers/mobihoc.ps)

After this publication, I noticed ns folks fixed another problem pointed
out in the paper (preamble length), but this interference modeling have
not been fixed yet. It is much harder to fix it than the other, and the
modification may significantly slow down ns-2. However, in my opinion,
it should be worth fixing.

Regards,

Mineo

sabeel ansari wrote:
>
> Hi
> I was going through the IEEE 802.11 MAC source code in the NS2.
> Here, it says that when a collision takes place,
> check the two packets and discard the packet which is going to end
> earlier. Shouldnt it be the other way around.
>
> void
> Mac802_11::collision(Packet *p)
> {
>         switch(rx_state_) {
>         case MAC_RECV:
>                 SET_RX_STATE(MAC_COLL);
>                 /* fall through */
>         case MAC_COLL:
>                 assert(pktRx_);
>                 assert(mhRecv_.busy());
>                 /*
>                  *  Since a collision has occurred, figure out
>                  *  which packet that caused the collision will
>                  *  "last" the longest.  Make this packet,
>                  *  pktRx_ and reset the Recv Timer if necessary.
>                  */
>                 if(TX_Time(p) > mhRecv_.expire()) {
>                         mhRecv_.stop();
>                         discard(pktRx_, DROP_MAC_COLLISION);
>                         pktRx_ = p;
>                         mhRecv_.start(TX_Time(pktRx_));
>                 }
>                 else {
>                         discard(p, DROP_MAC_COLLISION);
>                 }
>                 break;
>         default:
>                 assert(0);
>         }
> }
>
> sabeel
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet





_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 03:42:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17442
	for ; Wed, 31 Jul 2002 03:42:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18449;
	Wed, 31 Jul 2002 03:23:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18420
	for ; Wed, 31 Jul 2002 03:23:32 -0400 (EDT)
Received: from nue002.nue.et-inf.uni-siegen.de (nue002.nue.et-inf.Uni-Siegen.DE [141.99.152.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17018
	for ; Wed, 31 Jul 2002 03:22:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by nue002.nue.et-inf.uni-siegen.de (Postfix) with ESMTP
	id F0DEA120030; Wed, 31 Jul 2002 08:43:11 +0200 (CEST)
Received: from nue.et-inf.uni-siegen.de (linux.nue.et-inf.uni-siegen.de [141.99.152.2])
	by nue002.nue.et-inf.uni-siegen.de (Postfix) with ESMTP
	id F382A120025; Wed, 31 Jul 2002 08:43:10 +0200 (CEST)
Message-ID: <3D479058.8010605@nue.et-inf.uni-siegen.de>
Date: Wed, 31 Jul 2002 09:23:04 +0200
From: Michael Schmidt 
Organization: University of Siegen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.0.0) Gecko/20020530
X-Accept-Language: de-DE, de, en, en-us
MIME-Version: 1.0
To: zf_manet@yahoo.com
Cc: manet@ietf.org
Subject: Re: [manet] a list of papers on security for ad hoc networks
X-Enigmail-Version: 0.62.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Feng,

You may want to add my paper(s) about "Subscriptionless Mobile 
Networking" which deal with security and privacy aspects in Personal 
Area Networks:


"Subscriptionless Mobile Networking: Anonymity and Privacy Aspects 
within Personal Area Networks",
research paper presented at the IEEE WCNC 2002,
by Michael Schmidt


or (better, because more comprehensive, but not presented at a conference):

"Subscriptionless Mobile Networking: Security and Privacy Aspects within 
Personal Area Networks",
by Michael Schmidt


Both papers are available at:
http://www.nue.et-inf.uni-siegen.de/~schmidt/english/literat.html


Thanks,

Michael


> Hi, All,
> 
> I made a webpage to contain a list of papers on
> security for ad hoc networks.
> 
> http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> 
> If you wrote and/or know of any papers concerning
> security for ad hoc networks that are not listed here,
> please let me know.
> 
> Contract me: zf_manet@yahoo.com
> 
> Best,
> Feng
> 


-- 
=================================================
Michael Schmidt
-------------------------------------------------
Institute for Data Communications Systems
University of Siegen, Germany
-------------------------------------------------
http:   www.nue.et-inf.uni-siegen.de/~schmidt/
e-mail: schmidt@nue.et-inf.uni-siegen.de
phone:  +49 271 740-2332  fax:   +49 271 740-2536
mobile: +49 179 7810214
=================================================


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 04:35:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17448
	for ; Wed, 31 Jul 2002 03:42:30 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA20139
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 03:43:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18449;
	Wed, 31 Jul 2002 03:23:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18420
	for ; Wed, 31 Jul 2002 03:23:32 -0400 (EDT)
Received: from nue002.nue.et-inf.uni-siegen.de (nue002.nue.et-inf.Uni-Siegen.DE [141.99.152.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17018
	for ; Wed, 31 Jul 2002 03:22:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by nue002.nue.et-inf.uni-siegen.de (Postfix) with ESMTP
	id F0DEA120030; Wed, 31 Jul 2002 08:43:11 +0200 (CEST)
Received: from nue.et-inf.uni-siegen.de (linux.nue.et-inf.uni-siegen.de [141.99.152.2])
	by nue002.nue.et-inf.uni-siegen.de (Postfix) with ESMTP
	id F382A120025; Wed, 31 Jul 2002 08:43:10 +0200 (CEST)
Message-ID: <3D479058.8010605@nue.et-inf.uni-siegen.de>
Date: Wed, 31 Jul 2002 09:23:04 +0200
From: Michael Schmidt 
Organization: University of Siegen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.0.0) Gecko/20020530
X-Accept-Language: de-DE, de, en, en-us
MIME-Version: 1.0
To: zf_manet@yahoo.com
Cc: manet@ietf.org
Subject: Re: [manet] a list of papers on security for ad hoc networks
X-Enigmail-Version: 0.62.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Feng,

You may want to add my paper(s) about "Subscriptionless Mobile 
Networking" which deal with security and privacy aspects in Personal 
Area Networks:


"Subscriptionless Mobile Networking: Anonymity and Privacy Aspects 
within Personal Area Networks",
research paper presented at the IEEE WCNC 2002,
by Michael Schmidt


or (better, because more comprehensive, but not presented at a conference):

"Subscriptionless Mobile Networking: Security and Privacy Aspects within 
Personal Area Networks",
by Michael Schmidt


Both papers are available at:
http://www.nue.et-inf.uni-siegen.de/~schmidt/english/literat.html


Thanks,

Michael


> Hi, All,
> 
> I made a webpage to contain a list of papers on
> security for ad hoc networks.
> 
> http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> 
> If you wrote and/or know of any papers concerning
> security for ad hoc networks that are not listed here,
> please let me know.
> 
> Contract me: zf_manet@yahoo.com
> 
> Best,
> Feng
> 


-- 
=================================================
Michael Schmidt
-------------------------------------------------
Institute for Data Communications Systems
University of Siegen, Germany
-------------------------------------------------
http:   www.nue.et-inf.uni-siegen.de/~schmidt/
e-mail: schmidt@nue.et-inf.uni-siegen.de
phone:  +49 271 740-2332  fax:   +49 271 740-2536
mobile: +49 179 7810214
=================================================


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 06:00:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19383
	for ; Wed, 31 Jul 2002 06:00:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25823;
	Wed, 31 Jul 2002 05:40:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25794
	for ; Wed, 31 Jul 2002 05:40:01 -0400 (EDT)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19008
	for ; Wed, 31 Jul 2002 05:38:51 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6V9dS2E029912;
	Wed, 31 Jul 2002 11:39:28 +0200
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with SMTP id g6V9dPwa037786;
	Wed, 31 Jul 2002 11:39:27 +0200
Received: from dhcp70-135.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA50142 from ; Wed, 31 Jul 2002 11:39:24 +0200
Subject: Re: [manet] a list of papers on security for ad hoc networks
From: Sonja Buchegger 
To: feng zhu 
Cc: manet@ietf.org
In-Reply-To: <20020731052419.9616.qmail@web12908.mail.yahoo.com>
References: <20020731052419.9616.qmail@web12908.mail.yahoo.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) 
Date: 31 Jul 2002 11:39:23 +0200
Message-Id: <1028108363.8846.164.camel@donoratico>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Feng,

some more references: the following is a more detailed description of
our approach outlined in the 'nodes bearing grudges' paper as listed on
your site, and it also gives simulation results.

Sonja Buchegger and Jean-Yves Le Boudec. Performance Analysis of the
CONFIDANT Protocol: Cooperation Of Nodes - Fairness In Distributed
Ad-hoc NeTworks. In Proceedings of the Third ACM International Symposium
on Mobile Ad Hoc Networking and Computing MobiHOC 2002, p.226-236,
Lausanne, CH, June 2002. 

And here's a short overview paper i wrote on security in ad-hoc
networks, you'll probably find more references for your website in
there:

Sonja Buchegger and Jean-Yves Le Boudec. Cooperative Routing in Mobile
Ad-hoc Networks: Current Efforts Against Malice and Selfishness. In
Lecture Notes on Informatics, Mobile Internet Workshop, Informatik 2002,
Dortmund, Germany, October 2002. Springer.

It is yet to appear, but you can download it e.g. from
http://lcawww.epfl.ch , where you can also find the papers on your list
and more by Levente Buttyan, Srdjan Capcun, and Jean-Pierre Hubaux. Also
there are relevant papers coming out of the terminodes project, keep
checking out the terminodes page at http://www.terminodes.org .

Best regards,
Sonja

_/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  

 Sonja Buchegger
 IBM Zurich Research Lab    email: sob@zurich.ibm.com
 Saeumerstr. 4              phone: +41/1/724 82 37
 CH-8803 Rueschlikon        fax : +41/1/724 89 55
 Switzerland                http://www.zurich.ibm.com/~sob


On Wed, 2002-07-31 at 07:24, feng zhu wrote:
> Hi, 
> 
> Thank you for your information.
> 
> I have updated the web page
> 
> http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> 
> The first two papers have been listed in the web page.
> But the 3rd paper is about WEP and IEEE802.11, not ad
> hoc network. So I did not add it into the web page.
> 
> Best,
> Feng
>  
> 
> --- Sridhar K N  wrote:
> > here are some other papers.
> > 
> > 1. A distributed Light-weight AUthentication Model
> > for Ad-Hoc Networks, 
> > by ANdre Weimerskirch and Gilles Thonet.
> > 
> > 2. Nodes Bearing Grudges: Towards Routing Security,
> > Fairness and
> > Roubustness in Mobile Ad Hoc Networks. by Sonja
> > Buchegger and Jean-Yves Le
> > Boudec.
> > 
> > 
> > 3. AT&T Labs Technical Report, Using the Fluhrer,
> > Mantin, and Shamir
> > Attack to Break WEP.
> > 
> > Regards
> > Sridhar
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


                            


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 06:00:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19392
	for ; Wed, 31 Jul 2002 06:00:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA27165
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 06:01:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25823;
	Wed, 31 Jul 2002 05:40:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25794
	for ; Wed, 31 Jul 2002 05:40:01 -0400 (EDT)
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19008
	for ; Wed, 31 Jul 2002 05:38:51 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6V9dS2E029912;
	Wed, 31 Jul 2002 11:39:28 +0200
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with SMTP id g6V9dPwa037786;
	Wed, 31 Jul 2002 11:39:27 +0200
Received: from dhcp70-135.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA50142 from ; Wed, 31 Jul 2002 11:39:24 +0200
Subject: Re: [manet] a list of papers on security for ad hoc networks
From: Sonja Buchegger 
To: feng zhu 
Cc: manet@ietf.org
In-Reply-To: <20020731052419.9616.qmail@web12908.mail.yahoo.com>
References: <20020731052419.9616.qmail@web12908.mail.yahoo.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) 
Date: 31 Jul 2002 11:39:23 +0200
Message-Id: <1028108363.8846.164.camel@donoratico>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Feng,

some more references: the following is a more detailed description of
our approach outlined in the 'nodes bearing grudges' paper as listed on
your site, and it also gives simulation results.

Sonja Buchegger and Jean-Yves Le Boudec. Performance Analysis of the
CONFIDANT Protocol: Cooperation Of Nodes - Fairness In Distributed
Ad-hoc NeTworks. In Proceedings of the Third ACM International Symposium
on Mobile Ad Hoc Networking and Computing MobiHOC 2002, p.226-236,
Lausanne, CH, June 2002. 

And here's a short overview paper i wrote on security in ad-hoc
networks, you'll probably find more references for your website in
there:

Sonja Buchegger and Jean-Yves Le Boudec. Cooperative Routing in Mobile
Ad-hoc Networks: Current Efforts Against Malice and Selfishness. In
Lecture Notes on Informatics, Mobile Internet Workshop, Informatik 2002,
Dortmund, Germany, October 2002. Springer.

It is yet to appear, but you can download it e.g. from
http://lcawww.epfl.ch , where you can also find the papers on your list
and more by Levente Buttyan, Srdjan Capcun, and Jean-Pierre Hubaux. Also
there are relevant papers coming out of the terminodes project, keep
checking out the terminodes page at http://www.terminodes.org .

Best regards,
Sonja

_/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  

 Sonja Buchegger
 IBM Zurich Research Lab    email: sob@zurich.ibm.com
 Saeumerstr. 4              phone: +41/1/724 82 37
 CH-8803 Rueschlikon        fax : +41/1/724 89 55
 Switzerland                http://www.zurich.ibm.com/~sob


On Wed, 2002-07-31 at 07:24, feng zhu wrote:
> Hi, 
> 
> Thank you for your information.
> 
> I have updated the web page
> 
> http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> 
> The first two papers have been listed in the web page.
> But the 3rd paper is about WEP and IEEE802.11, not ad
> hoc network. So I did not add it into the web page.
> 
> Best,
> Feng
>  
> 
> --- Sridhar K N  wrote:
> > here are some other papers.
> > 
> > 1. A distributed Light-weight AUthentication Model
> > for Ad-Hoc Networks, 
> > by ANdre Weimerskirch and Gilles Thonet.
> > 
> > 2. Nodes Bearing Grudges: Towards Routing Security,
> > Fairness and
> > Roubustness in Mobile Ad Hoc Networks. by Sonja
> > Buchegger and Jean-Yves Le
> > Boudec.
> > 
> > 
> > 3. AT&T Labs Technical Report, Using the Fluhrer,
> > Mantin, and Shamir
> > Attack to Break WEP.
> > 
> > Regards
> > Sridhar
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 


                            


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 09:21:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25423
	for ; Wed, 31 Jul 2002 09:21:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06650;
	Wed, 31 Jul 2002 09:03:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14535
	for ; Thu, 25 Jul 2002 05:47:35 -0400 (EDT)
Received: from cheviot2.ncl.ac.uk (IDENT:root@cheviot2.ncl.ac.uk [128.240.229.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27338
	for ; Thu, 25 Jul 2002 05:46:30 -0400 (EDT)
Received: from cheviot5.ncl.ac.uk (root@cheviot5.ncl.ac.uk [128.240.233.122])
	by cheviot2.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id g6P9l1n14267;
	Thu, 25 Jul 2002 10:47:01 +0100
Received: from webmail.ncl.ac.uk (tarantula.ncl.ac.uk [128.240.234.132])
	by cheviot5.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id g6P9l1q11227;
	Thu, 25 Jul 2002 10:47:01 +0100 (BST)
X-WebMail-UserID:  n8533106
Date: Thu, 25 Jul 2002 10:47:00 +0100
From: Einar Vollset 
To: Frank Dinies 
Cc: manet 
X-EXP32-SerialNo: 00104934
Subject: RE: [manet] how does ad hoc network do something?
Message-ID: <3D3F5D25@webmail.ncl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: InterChange (Hydra) SMTP v3.62
X-Newcastle-MailScanner: Found to be clean (of known viruses)
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Frank,


>have you seen the approach from Fisheye-State-Routing ? It is a proactive
>algorithmen with maintains a global routing table. But it maintains the
>information in respect to the distance. To do this it sends periodically
>beacons to its neighbours only. Every neighbour accumulates this information
>and send the information in different update times. Information about nearer
>nodes much more often than information about nodes farer away.

Yes I have. I believe FSR is also used as part of LANMAR.

>In this way
>this algorithmen scales pretty well with large networks and positionchanges
>not nescessarily triggers update information.

I agree that only keeping a distance based routing table will reduce the
overhead of maintaining routing information in FSR. And there are other
proactive protocols that have mechanisms to reduce the number of nodes
it needs to maintain routing information to as well(LANMAR that I
metioned uses group mobility). 
However, I think that proactive protocols in the general case will perform
worse than on-demand protocols in a high mobility scenario simply because
the overhead of updating routes to all (or a selected subset) of the nodes
in the network will congest the network sufficently to render it useless
(at least at the high mobility scenarios you suggest, and if we assume that
bandwidth isn't abundant).

>
>On-demand protocols have the problem the route-prechaching is unsufficient 
for
>high mobility.


That's true, and if the overhead of maintaining routes to all nodes can be
kept at an acceptable level, then pro-active protocols have an edge on 
on-demand ones.
However, in the case where mobility is high, this is hard to achieve.

>Another point is that a route could even be absolute before a
>sender gets the route-information back.

I agree, but the same thing can be said for proactive protocols if
the mobility is sufficiently high. One way of alleviating this would
be for the protocol to find multiple routes, and hope that not all
these become obsolete. This of course adds to the processing and
communication overhead of the manet.. :-(


>unfortunalety there is no silver bullet for all kind of situations ;)


Not yet :-)

Cheers,

Einar

>
>> Hi Frank,
>>
>> >But keep in mind. Proactive algorithmens are best in enviroments with
>> > rapid change and much participants. On-demand-ones roughly for the
>> > contrary. For sensors that transmit from time to time small amounts of
>> > data for example is an on-demand-one perfect.
>>
>> I was under the impression that it was the other way around, with proactive
>> protocols performing worse in environments with rapid change, as the
>> overhead with maintaining the (global) routing information would be
>> prohibitive. Where as an on-demand protocol would perform better in this
>> scenario?
>>
>> Or am I confused? :-)
>>
>> Cheers,
>>
>> Einar
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 09:21:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25432
	for ; Wed, 31 Jul 2002 09:21:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA07877
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 09:22:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06650;
	Wed, 31 Jul 2002 09:03:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14535
	for ; Thu, 25 Jul 2002 05:47:35 -0400 (EDT)
Received: from cheviot2.ncl.ac.uk (IDENT:root@cheviot2.ncl.ac.uk [128.240.229.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27338
	for ; Thu, 25 Jul 2002 05:46:30 -0400 (EDT)
Received: from cheviot5.ncl.ac.uk (root@cheviot5.ncl.ac.uk [128.240.233.122])
	by cheviot2.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id g6P9l1n14267;
	Thu, 25 Jul 2002 10:47:01 +0100
Received: from webmail.ncl.ac.uk (tarantula.ncl.ac.uk [128.240.234.132])
	by cheviot5.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id g6P9l1q11227;
	Thu, 25 Jul 2002 10:47:01 +0100 (BST)
X-WebMail-UserID:  n8533106
Date: Thu, 25 Jul 2002 10:47:00 +0100
From: Einar Vollset 
To: Frank Dinies 
Cc: manet 
X-EXP32-SerialNo: 00104934
Subject: RE: [manet] how does ad hoc network do something?
Message-ID: <3D3F5D25@webmail.ncl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: InterChange (Hydra) SMTP v3.62
X-Newcastle-MailScanner: Found to be clean (of known viruses)
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi Frank,


>have you seen the approach from Fisheye-State-Routing ? It is a proactive
>algorithmen with maintains a global routing table. But it maintains the
>information in respect to the distance. To do this it sends periodically
>beacons to its neighbours only. Every neighbour accumulates this information
>and send the information in different update times. Information about nearer
>nodes much more often than information about nodes farer away.

Yes I have. I believe FSR is also used as part of LANMAR.

>In this way
>this algorithmen scales pretty well with large networks and positionchanges
>not nescessarily triggers update information.

I agree that only keeping a distance based routing table will reduce the
overhead of maintaining routing information in FSR. And there are other
proactive protocols that have mechanisms to reduce the number of nodes
it needs to maintain routing information to as well(LANMAR that I
metioned uses group mobility). 
However, I think that proactive protocols in the general case will perform
worse than on-demand protocols in a high mobility scenario simply because
the overhead of updating routes to all (or a selected subset) of the nodes
in the network will congest the network sufficently to render it useless
(at least at the high mobility scenarios you suggest, and if we assume that
bandwidth isn't abundant).

>
>On-demand protocols have the problem the route-prechaching is unsufficient 
for
>high mobility.


That's true, and if the overhead of maintaining routes to all nodes can be
kept at an acceptable level, then pro-active protocols have an edge on 
on-demand ones.
However, in the case where mobility is high, this is hard to achieve.

>Another point is that a route could even be absolute before a
>sender gets the route-information back.

I agree, but the same thing can be said for proactive protocols if
the mobility is sufficiently high. One way of alleviating this would
be for the protocol to find multiple routes, and hope that not all
these become obsolete. This of course adds to the processing and
communication overhead of the manet.. :-(


>unfortunalety there is no silver bullet for all kind of situations ;)


Not yet :-)

Cheers,

Einar

>
>> Hi Frank,
>>
>> >But keep in mind. Proactive algorithmens are best in enviroments with
>> > rapid change and much participants. On-demand-ones roughly for the
>> > contrary. For sensors that transmit from time to time small amounts of
>> > data for example is an on-demand-one perfect.
>>
>> I was under the impression that it was the other way around, with proactive
>> protocols performing worse in environments with rapid change, as the
>> overhead with maintaining the (global) routing information would be
>> prohibitive. Where as an on-demand protocol would perform better in this
>> scenario?
>>
>> Or am I confused? :-)
>>
>> Cheers,
>>
>> Einar
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 12:42:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06187
	for ; Wed, 31 Jul 2002 12:42:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19436;
	Wed, 31 Jul 2002 12:21:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19406
	for ; Wed, 31 Jul 2002 12:21:16 -0400 (EDT)
Received: from dagger.nd.edu (dagger.nd.edu [129.74.250.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05094
	for ; Wed, 31 Jul 2002 12:20:09 -0400 (EDT)
Received: from webmail.nd.edu (webmail.nd.edu [129.74.250.146])
	by dagger.nd.edu (8.12.2/8.12.2) with ESMTP id g6VGLCcw027567;
	Wed, 31 Jul 2002 11:21:12 -0500 (EST)
X-WebMail-UserID:  mhaenggi
Date: Wed, 31 Jul 2002 11:20:12 -0500
From: "mhaenggi@nd.edu" 
To: "Mullen, John P. (Contractor)" 
Cc: manet@ietf.org
X-EXP32-SerialNo: 00002313
Subject: RE: [manet] Interference in ad hoc network
Message-ID: <3D491953@webmail.nd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: WebMail (Hydra) SMTP v3.61
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi John,

sorry for the delayed response. This belongs to a thread that
is two weeks old.

>Well, This might work in Ethernet, but I doubt it will in radio nets.
>
>In theory you can ignore noise, but it is quite evident in wireless
>communications and any discussion that ignores its effect is a bit too
>theoretical for me.

I agree, noise can't be ignored. But you can look at noise issues
and interference issues separately. If you use a Rayleigh fading
model for the physical channel, the probability that the packet gets
through is a product of two probabilities, one that only depends on
the noise, and one that only depends on the interference. This permits
the separate analysis of the effects caused by noise and by interference.
So, to determine the interference part, the noise is put to zero,
and vice versa.

Best,
Martin


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 12:42:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06195
	for ; Wed, 31 Jul 2002 12:42:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA21102
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 12:43:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19436;
	Wed, 31 Jul 2002 12:21:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19406
	for ; Wed, 31 Jul 2002 12:21:16 -0400 (EDT)
Received: from dagger.nd.edu (dagger.nd.edu [129.74.250.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05094
	for ; Wed, 31 Jul 2002 12:20:09 -0400 (EDT)
Received: from webmail.nd.edu (webmail.nd.edu [129.74.250.146])
	by dagger.nd.edu (8.12.2/8.12.2) with ESMTP id g6VGLCcw027567;
	Wed, 31 Jul 2002 11:21:12 -0500 (EST)
X-WebMail-UserID:  mhaenggi
Date: Wed, 31 Jul 2002 11:20:12 -0500
From: "mhaenggi@nd.edu" 
To: "Mullen, John P. (Contractor)" 
Cc: manet@ietf.org
X-EXP32-SerialNo: 00002313
Subject: RE: [manet] Interference in ad hoc network
Message-ID: <3D491953@webmail.nd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: WebMail (Hydra) SMTP v3.61
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hi John,

sorry for the delayed response. This belongs to a thread that
is two weeks old.

>Well, This might work in Ethernet, but I doubt it will in radio nets.
>
>In theory you can ignore noise, but it is quite evident in wireless
>communications and any discussion that ignores its effect is a bit too
>theoretical for me.

I agree, noise can't be ignored. But you can look at noise issues
and interference issues separately. If you use a Rayleigh fading
model for the physical channel, the probability that the packet gets
through is a product of two probabilities, one that only depends on
the noise, and one that only depends on the interference. This permits
the separate analysis of the effects caused by noise and by interference.
So, to determine the interference part, the noise is put to zero,
and vice versa.

Best,
Martin


_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 13:59:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10503
	for ; Wed, 31 Jul 2002 13:59:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24367;
	Wed, 31 Jul 2002 13:37:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24338
	for ; Wed, 31 Jul 2002 13:37:09 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09074
	for ; Wed, 31 Jul 2002 13:36:01 -0400 (EDT)
Received: from slb-av-02.boeing.com ([129.172.13.7])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA25183;
	Wed, 31 Jul 2002 10:37:07 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA10007;
	Wed, 31 Jul 2002 10:37:07 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6VHb5626335;
	Wed, 31 Jul 2002 10:37:05 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <37GW554T>; Wed, 31 Jul 2002 13:37:04 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A65@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'mhaenggi@nd.edu'" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Wed, 31 Jul 2002 13:37:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

mhaenggi@nd.edu (Martin) wrote:

> Hi John,
> 
> sorry for the delayed response. This belongs to a thread that
> is two weeks old.
> 
> >Well, This might work in Ethernet, but I doubt it will in radio nets.
> >
> >In theory you can ignore noise, but it is quite evident in wireless
> >communications and any discussion that ignores its effect is 
> a bit too
> >theoretical for me.
> 
> I agree, noise can't be ignored. But you can look at noise issues
> and interference issues separately. If you use a Rayleigh fading
> model for the physical channel, the probability that the packet gets
> through is a product of two probabilities, one that only depends on
> the noise, and one that only depends on the interference. This permits
> the separate analysis of the effects caused by noise and by 
> interference.
> So, to determine the interference part, the noise is put to zero,
> and vice versa.

Martin, I agree that there's a difference between noise and interference. And that in a Rayleigh propagation channel, interference is usually the biggest problem. But this Rayleigh channel you mention is typically a problem in short range situations, where the echo paths equal the strength of the direct signal path.

At longer range between hosts, two things happen. First, echo energy is reduced compared with the main signal path, because those longer-traveled echoes paths will dissipate more quickly than the direct signal path. And second, the main signal at the frequencies we're talking about here (at or above UHF frequencies) will soon start going off into space. So signal or carrier energy of the interfering and the wanted transmitters are reduced dramatically, and noise becomes the only concern when dealing with C/(N+I) reception thesholds. The propagation path goes to Ricean (echo energy less than direct path) and then Gaussian (direct signal and white noise only) as range between hosts increases. At these longer ranges, C/(N+I) --> C/N rather than C/I.

So unless you worry only about short range effects, I think reducing transmitter power will have a significant effect in reducing interference between MANET hosts that are, say, several miles apart anyway. But not close together hosts, I agree.

About saving battery life, I have not seen a good answer to this. Reducing transmitter output theoretically increases battery life, right? Not necessarily. If everyone reduces transmitter power to the lowest possible, the MANET routing protocol will involve many more hops. So more MANET hosts are going to be providing relay services for other communications than their own, and their battery will deplete unexpectedly. Just another one of those "it depends" MANET things.

There's an article that covers this battery power problem in the June 2001 IEEE Communications Magazine, Maximum Battery Life Routing to Support Ubiquitous Mobile Computing in Wireless Ad Hoc Networks, by C.K. Toh. This article talks among other things about using a "sleep" mode in MANET hosts, to conserve battery power. But, depending on traffic patterns, hosts would have less chance of going into "sleep" mode if virtually every host has to provide relay services. The article introduces something they call "minimum battery cost routing," then a min-max battery cost routing, then a conditional min-max battery cost routing, where the path cost in a Dijkstra shortest path algorithm includes a battery power metric for reception and transmission. Cool. They keep elaborating the problem statement, with things like not asking too much of any one node, and considering the battery capacity of each node, rather than just the instantaneous power consumption.

As to increasing the MANET aggregate throughput, seems to me that reducing the transmitter power should certainly increase aggregate throughout on average, as we already discussed.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 13:59:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10512
	for ; Wed, 31 Jul 2002 13:59:59 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA26583
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 14:01:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24367;
	Wed, 31 Jul 2002 13:37:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24338
	for ; Wed, 31 Jul 2002 13:37:09 -0400 (EDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09074
	for ; Wed, 31 Jul 2002 13:36:01 -0400 (EDT)
Received: from slb-av-02.boeing.com ([129.172.13.7])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA25183;
	Wed, 31 Jul 2002 10:37:07 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA10007;
	Wed, 31 Jul 2002 10:37:07 -0700 (PDT)
Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4])
	by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g6VHb5626335;
	Wed, 31 Jul 2002 10:37:05 -0700 (PDT)
Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21)
	id <37GW554T>; Wed, 31 Jul 2002 13:37:04 -0400
Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A3A65@xch-ne-02.ne.nos.boeing.com>
From: "Manfredi, Albert E" 
To: "'mhaenggi@nd.edu'" 
Cc: manet@ietf.org
Subject: RE: [manet] Interference in ad hoc network
Date: Wed, 31 Jul 2002 13:37:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

mhaenggi@nd.edu (Martin) wrote:

> Hi John,
> 
> sorry for the delayed response. This belongs to a thread that
> is two weeks old.
> 
> >Well, This might work in Ethernet, but I doubt it will in radio nets.
> >
> >In theory you can ignore noise, but it is quite evident in wireless
> >communications and any discussion that ignores its effect is 
> a bit too
> >theoretical for me.
> 
> I agree, noise can't be ignored. But you can look at noise issues
> and interference issues separately. If you use a Rayleigh fading
> model for the physical channel, the probability that the packet gets
> through is a product of two probabilities, one that only depends on
> the noise, and one that only depends on the interference. This permits
> the separate analysis of the effects caused by noise and by 
> interference.
> So, to determine the interference part, the noise is put to zero,
> and vice versa.

Martin, I agree that there's a difference between noise and interference. And that in a Rayleigh propagation channel, interference is usually the biggest problem. But this Rayleigh channel you mention is typically a problem in short range situations, where the echo paths equal the strength of the direct signal path.

At longer range between hosts, two things happen. First, echo energy is reduced compared with the main signal path, because those longer-traveled echoes paths will dissipate more quickly than the direct signal path. And second, the main signal at the frequencies we're talking about here (at or above UHF frequencies) will soon start going off into space. So signal or carrier energy of the interfering and the wanted transmitters are reduced dramatically, and noise becomes the only concern when dealing with C/(N+I) reception thesholds. The propagation path goes to Ricean (echo energy less than direct path) and then Gaussian (direct signal and white noise only) as range between hosts increases. At these longer ranges, C/(N+I) --> C/N rather than C/I.

So unless you worry only about short range effects, I think reducing transmitter power will have a significant effect in reducing interference between MANET hosts that are, say, several miles apart anyway. But not close together hosts, I agree.

About saving battery life, I have not seen a good answer to this. Reducing transmitter output theoretically increases battery life, right? Not necessarily. If everyone reduces transmitter power to the lowest possible, the MANET routing protocol will involve many more hops. So more MANET hosts are going to be providing relay services for other communications than their own, and their battery will deplete unexpectedly. Just another one of those "it depends" MANET things.

There's an article that covers this battery power problem in the June 2001 IEEE Communications Magazine, Maximum Battery Life Routing to Support Ubiquitous Mobile Computing in Wireless Ad Hoc Networks, by C.K. Toh. This article talks among other things about using a "sleep" mode in MANET hosts, to conserve battery power. But, depending on traffic patterns, hosts would have less chance of going into "sleep" mode if virtually every host has to provide relay services. The article introduces something they call "minimum battery cost routing," then a min-max battery cost routing, then a conditional min-max battery cost routing, where the path cost in a Dijkstra shortest path algorithm includes a battery power metric for reception and transmission. Cool. They keep elaborating the problem statement, with things like not asking too much of any one node, and considering the battery capacity of each node, rather than just the instantaneous power consumption.

As to increasing the MANET aggregate throughput, seems to me that reducing the transmitter power should certainly increase aggregate throughout on average, as we already discussed.

Bert

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 14:05:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10936
	for ; Wed, 31 Jul 2002 14:05:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24957;
	Wed, 31 Jul 2002 13:44:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24928
	for ; Wed, 31 Jul 2002 13:44:44 -0400 (EDT)
Received: from aspen.cs.ucla.edu (Aspen.CS.UCLA.EDU [131.179.120.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09441
	for ; Wed, 31 Jul 2002 13:43:35 -0400 (EDT)
Received: from cs.ucla.edu (Buck.CS.UCLA.EDU [131.179.120.25])
	by aspen.cs.ucla.edu (8.11.2/UCLACS-5.0) with ESMTP id g6VHgIU02869;
	Wed, 31 Jul 2002 10:42:23 -0700 (PDT)
Message-ID: <3D482625.E8D14FBB@cs.ucla.edu>
Date: Wed, 31 Jul 2002 11:02:13 -0700
From: Mineo Takai 
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Harry 
CC: "manet@ietf.org" 
Subject: Re: [manet] about simulation
References: <20020731011431.8EC161DC82950@smtp.263.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Harry,

As far as I know, there are 4 common simulation tools for manet:
ns-2(http://www.isi.edu/nsnam/ns/),
GloMoSim(http://pcl.cs.ucla.edu/projects/glomosim/),
Opnet(http://www.opnet.com/) and
QualNet(http://www.scalable-networks.com/). I think the suitability of
each tool depends on your research interest, time and money.

Mineo

Harry wrote:
> 
> hi all,
>         As for our mobile ad hoc network research , anybody know
> which simulation software is suitable ,NS2 or GloMoSim ,or anything
> else?
> 
>         Harry
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From manet-admin@ietf.org  Wed Jul 31 14:21:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11741
	for ; Wed, 31 Jul 2002 14:21:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27133;
	Wed, 31 Jul 2002 14:05:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27104
	for ; Wed, 31 Jul 2002 14:05:10 -0400 (EDT)
Received: from web12908.mail.yahoo.com (web12908.mail.yahoo.com [216.136.174.75])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10852
	for ; Wed, 31 Jul 2002 14:04:02 -0400 (EDT)
Message-ID: <20020731180509.12428.qmail@web12908.mail.yahoo.com>
Received: from [216.69.69.214] by web12908.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 11:05:09 PDT
Date: Wed, 31 Jul 2002 11:05:09 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Nita-Rotaru Cristina 
Cc: manet@ietf.org
In-Reply-To: <20020731012954.D44158-100000@commedia.cnds.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, 

Thank you for your information. I will update the
web page today.

BTW, it seems that most of those papers for the
workshop are not available on the web. Right?

If you know where I can download one/some of those
papers, please let me know.

Thanks.

Best,
Feng
 
--- Nita-Rotaru Cristina 
wrote:
> 
> Dear Feng,
> 
> Great idea to have that list !
> 
> You might want to take a look at the program of
> the ACM Workshop on Wireless Security (Sept 2002).
> http://www.crhc.uiuc.edu/~nhv/wise/program.html
> 
> take care,
> 
> 
> Cristina
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 14:21:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11748
	for ; Wed, 31 Jul 2002 14:21:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA28444
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 14:22:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27133;
	Wed, 31 Jul 2002 14:05:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27104
	for ; Wed, 31 Jul 2002 14:05:10 -0400 (EDT)
Received: from web12908.mail.yahoo.com (web12908.mail.yahoo.com [216.136.174.75])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10852
	for ; Wed, 31 Jul 2002 14:04:02 -0400 (EDT)
Message-ID: <20020731180509.12428.qmail@web12908.mail.yahoo.com>
Received: from [216.69.69.214] by web12908.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 11:05:09 PDT
Date: Wed, 31 Jul 2002 11:05:09 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Nita-Rotaru Cristina 
Cc: manet@ietf.org
In-Reply-To: <20020731012954.D44158-100000@commedia.cnds.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, 

Thank you for your information. I will update the
web page today.

BTW, it seems that most of those papers for the
workshop are not available on the web. Right?

If you know where I can download one/some of those
papers, please let me know.

Thanks.

Best,
Feng
 
--- Nita-Rotaru Cristina 
wrote:
> 
> Dear Feng,
> 
> Great idea to have that list !
> 
> You might want to take a look at the program of
> the ACM Workshop on Wireless Security (Sept 2002).
> http://www.crhc.uiuc.edu/~nhv/wise/program.html
> 
> take care,
> 
> 
> Cristina
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 14:45:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12702
	for ; Wed, 31 Jul 2002 14:45:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27925;
	Wed, 31 Jul 2002 14:15:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27894
	for ; Wed, 31 Jul 2002 14:15:41 -0400 (EDT)
Received: from web12901.mail.yahoo.com (web12901.mail.yahoo.com [216.136.174.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11479
	for ; Wed, 31 Jul 2002 14:14:32 -0400 (EDT)
Message-ID: <20020731181540.20537.qmail@web12901.mail.yahoo.com>
Received: from [216.69.69.214] by web12901.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 11:15:40 PDT
Date: Wed, 31 Jul 2002 11:15:40 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Michael Schmidt 
Cc: manet@ietf.org
In-Reply-To: <3D479058.8010605@nue.et-inf.uni-siegen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
Thank you for your information. I will update the web
page today and add your paper into the list.

Best
Feng

--- Michael Schmidt 
wrote:
> Hi Feng,
> 
> You may want to add my paper(s) about
> "Subscriptionless Mobile 
> Networking" which deal with security and privacy
> aspects in Personal 
> Area Networks:
> 
> 
> "Subscriptionless Mobile Networking: Anonymity and
> Privacy Aspects 
> within Personal Area Networks",
> research paper presented at the IEEE WCNC 2002,
> by Michael Schmidt
> 
> 
> or (better, because more comprehensive, but not
> presented at a conference):
> 
> "Subscriptionless Mobile Networking: Security and
> Privacy Aspects within 
> Personal Area Networks",
> by Michael Schmidt
> 
> 
> Both papers are available at:
>
http://www.nue.et-inf.uni-siegen.de/~schmidt/english/literat.html
> 
> 
> Thanks,
> 
> Michael
> 
> 
> > Hi, All,
> > 
> > I made a webpage to contain a list of papers on
> > security for ad hoc networks.
> > 
> >
>
http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> > 
> > If you wrote and/or know of any papers concerning
> > security for ad hoc networks that are not listed
> here,
> > please let me know.
> > 
> > Contract me: zf_manet@yahoo.com
> > 
> > Best,
> > Feng
> > 
> 
> 
> -- 
> =================================================
> Michael Schmidt
> -------------------------------------------------
> Institute for Data Communications Systems
> University of Siegen, Germany
> -------------------------------------------------
> http:   www.nue.et-inf.uni-siegen.de/~schmidt/
> e-mail: schmidt@nue.et-inf.uni-siegen.de
> phone:  +49 271 740-2332  fax:   +49 271 740-2536
> mobile: +49 179 7810214
> =================================================
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 14:45:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12707
	for ; Wed, 31 Jul 2002 14:45:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA00586
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 14:46:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27925;
	Wed, 31 Jul 2002 14:15:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27894
	for ; Wed, 31 Jul 2002 14:15:41 -0400 (EDT)
Received: from web12901.mail.yahoo.com (web12901.mail.yahoo.com [216.136.174.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11479
	for ; Wed, 31 Jul 2002 14:14:32 -0400 (EDT)
Message-ID: <20020731181540.20537.qmail@web12901.mail.yahoo.com>
Received: from [216.69.69.214] by web12901.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 11:15:40 PDT
Date: Wed, 31 Jul 2002 11:15:40 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Michael Schmidt 
Cc: manet@ietf.org
In-Reply-To: <3D479058.8010605@nue.et-inf.uni-siegen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
Thank you for your information. I will update the web
page today and add your paper into the list.

Best
Feng

--- Michael Schmidt 
wrote:
> Hi Feng,
> 
> You may want to add my paper(s) about
> "Subscriptionless Mobile 
> Networking" which deal with security and privacy
> aspects in Personal 
> Area Networks:
> 
> 
> "Subscriptionless Mobile Networking: Anonymity and
> Privacy Aspects 
> within Personal Area Networks",
> research paper presented at the IEEE WCNC 2002,
> by Michael Schmidt
> 
> 
> or (better, because more comprehensive, but not
> presented at a conference):
> 
> "Subscriptionless Mobile Networking: Security and
> Privacy Aspects within 
> Personal Area Networks",
> by Michael Schmidt
> 
> 
> Both papers are available at:
>
http://www.nue.et-inf.uni-siegen.de/~schmidt/english/literat.html
> 
> 
> Thanks,
> 
> Michael
> 
> 
> > Hi, All,
> > 
> > I made a webpage to contain a list of papers on
> > security for ad hoc networks.
> > 
> >
>
http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> > 
> > If you wrote and/or know of any papers concerning
> > security for ad hoc networks that are not listed
> here,
> > please let me know.
> > 
> > Contract me: zf_manet@yahoo.com
> > 
> > Best,
> > Feng
> > 
> 
> 
> -- 
> =================================================
> Michael Schmidt
> -------------------------------------------------
> Institute for Data Communications Systems
> University of Siegen, Germany
> -------------------------------------------------
> http:   www.nue.et-inf.uni-siegen.de/~schmidt/
> e-mail: schmidt@nue.et-inf.uni-siegen.de
> phone:  +49 271 740-2332  fax:   +49 271 740-2536
> mobile: +49 179 7810214
> =================================================
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 14:46:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12879
	for ; Wed, 31 Jul 2002 14:46:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28687;
	Wed, 31 Jul 2002 14:25:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28649
	for ; Wed, 31 Jul 2002 14:25:50 -0400 (EDT)
Received: from web12903.mail.yahoo.com (web12903.mail.yahoo.com [216.136.174.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11851
	for ; Wed, 31 Jul 2002 14:24:40 -0400 (EDT)
Message-ID: <20020731182544.77738.qmail@web12903.mail.yahoo.com>
Received: from [216.69.69.214] by web12903.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 11:25:44 PDT
Date: Wed, 31 Jul 2002 11:25:44 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Stefano Basagni 
Cc: manet@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
Thank you for your information.I will update my
webpage today and add your paper into the list.

The paper is not available on the Web. Right?

Could you tell me where I can download it or send
me a copy via email.

Thanks

Best,
Feng


--- Stefano Basagni  wrote:
> Hi there, you might want to add the following paper
> from us, appeared at
> MobiHoc 2001.
> 
> @InProceedings{BasagniHBR01,
>   author =           {Basagni, S. and Herrin, K. and
> Bruschi, D. and
>                       Rosti, E.},
>   title =            {Secure Pebblenet},
>   booktitle =        {Proceedings of the 2001 ACM
> Iternational Symposium
>                       on Mobile Ad Hoc Networking \&
> Computing, MobiHoc 2001},
>   pages =            {156--163},
>   year =             {2001},
>   address =          {Long Beach, CA},
>   month =            {October 4--5}
> }
> 
> Cheers, St.
> 
> 
> 
> On Tue, 30 Jul 2002, feng zhu wrote:
> 
> > Hi, All,
> >
> > I made a webpage to contain a list of papers on
> > security for ad hoc networks.
> >
> >
>
http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> >
> > If you wrote and/or know of any papers concerning
> > security for ad hoc networks that are not listed
> here,
> > please let me know.
> >
> > Contract me: zf_manet@yahoo.com
> >
> > Best,
> > Feng
> >
> > The following is a part of the list.
> > ========================================
> >
> >
> > Key Exchange and Distribution:
> >
> > [AG] N. Asokan, Philip Ginzboorg Key agreement in
> ad
> > hoc networks
> >
> > [H] Maarit Hietalahti  Key Establishment in Ad-hoc
> > Networks
> >
> > [CBH]Srdjan Capkuny, Levente Buttyan and
> Jean-Pierre
> > Hubaux Self-Organized Public-Key Management for
> Mobile
> > Ad Hoc Networks
> >
> >
> >
> > Secure Routing:
> >
> > [BT] Jim Brinkley William Trost Authenticated Ad
> Hoc
> > Routing at the Link Layer for Mobile Systems 1996
> >
> > [DLRS]Bridget Dahill, Brian Neil Levine, Elizabeth
> > Royer, Clay Shields. A Secure Routing Protocol for
> Ad
> > Hoc Networks
> >
> > [HPJ] Yih-Chun Hu, Adrian Perrig, David B.
> Johnson.
> > Ariadne: A secure On-Demand Routing Protocol for
> Ad
> > hoc Networks
> >
> > [MGLB] Sergio Marti and T. J. Giuli and Kevin Lai
> and
> > Mary Baker. Mitigating routing misbehavior in
> mobile
> > ad hoc networks. Mobile Computing and Networking
> > (2000):
> >
> > [PH] Panagiotis Papadimitratos and Zygmunt J. Haas
> > Secure Routing for Mobile Ad hoc Networks and
> > [slides]
> >
> > [SMG] Bradley R. Smith, Shree Murthy, J.J.
> > Garcia-Luna-Aceves Securing Distance-Vector
> Routing
> > Protocols
> >
> > [YNK] Seung Yi, Prasad Naldurg, Robin Kravets. A
> > Security-Aware Ad Hoc Routing Protocol for
> Wireless
> > Networks [2]
> >
> > [L] Janne Lundberg Routing Security in Ad Hoc
> Networks
> >
> > [HJP] Yih-Chun Hu, David B. Johnson, and Adrian
> > Perrig. SEAD: Secure Efficient Distance Vector
> Routing
> > for Mobile Wireless Ad Hoc Networks. Proceedings
> of
> > the 4th IEEE Workshop on Mobile Computing Systems
> &
> > Applications (WMCSA 2002), pp. 3-13, IEEE,
> Calicoon,
> > NY, June 2002.
> >
> > [Z]Manel Guerrero Zapata Secure Ad hoc On-Demand
> > Distance Vector (SAODV) Routing
> >
> >
> >
> > Group Communication:
> >
> > [YD] Alec Yasinsac Jim Davis. Modeling Protocols
> for
> > Secure Group Communication in Ad Hoc Networks
> > (Extended Abstract)
> >
> > [MAH ]Silja M鋕i, Tuomas Aura, Maarit
Hietalahti
> > Robust Membership Management for Ad-hoc Groups
> >
> >
> >
> > Other Security issues:
> >
> > [CK] Candolin, H. Kari, A Security Architecture
> for
> > Wireless Ad hoc Networks, to be published at IEEE
> > Milcom 2002, Anaheim, California, October 7-10,
> 2002
> >
> > [EGN] Pasi Eronen, Christian Gehrmann, Pekka
> Nikander
> > Securing ad hoc Jini services
> >
> > [HBC} Jean-Pierre Hubaux, Levente Buttyan, Srdjan
> > Capkun (Swiss Federal Institute of Technology) The
> > Quest for Security in Mobile Ad Hoc Networks
> >
> > [LKZLZ] Haiyun Luo, Jiejun Kong, Petros Zerfos,
> Songwu
> > Lu and Lixia Zhang, Self-securing Ad Hoc Wireless
> > Networks
> >
> > [K] Vesa Karpijoki Security in Ad Hoc Networks
> >
> > [SA] Frank Stajano and Ross Anderson The
> Resurrecting
> > Duckling: Security Issues for Ad-hoc Wireless
> Networks
> >
> > [SH] Christian Schwingenschl鰃l and
Marc-Philipp
> Horn
> > Build Blocks for Secure Communication in Ad-hoc
> > Networks
> >
> > [V] Anne Vanhala Security in Ad-hoc Networks
> >
> > [ZH] Lidong Zhou, Zygmunt J. Haas. Securing ad hoc
> > networks. IEEE Communications, Vol. 13 No. 6
> >
> > [ZL] Yongguang Zhang & Wenke Lee, Intrusion
> Detection
> > in Wireless Ad-Hoc Networks
> >
> > [LL] Haiyun Luo, Songwu Lu Ubiquitous and Robust
> > Authentication Services for Ad Hoc Wireless
> Networks,
> >
> > [KZLLZ] Jiejun Kong, Petros Zerfos, Haiyun Luo,
> Songwu
> > Lu and Lixia Zhang.  Providing Robust and
> Ubiquitous
> > Security Support for Mobile Ad-Hoc Networks
> >
> > [GN] Christian Gehrmann (Ericsson Research), and
> Pekka
> > Nikander (Helsinki Institute of Technology)
> Securing
> > Ad Hoc Services, a Jini View
> >
> > [KLXGGL] Jiejun Kong, Haiyun Luo, Kaixin Xu,
> Daniel
> > Lihui Gu, Mario Gerla, Songwu Lu Adaptive Security
> for
> > Multi-layer Ad-hoc Networks
> >
> > [BH]Levente Buttyan and Jean-Pierre Hubaux 
> Enforcing
> > Service Availability in Mobile Ad-Hoc WANs
> >
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 14:46:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12886
	for ; Wed, 31 Jul 2002 14:46:59 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA00702
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 14:48:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28687;
	Wed, 31 Jul 2002 14:25:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28649
	for ; Wed, 31 Jul 2002 14:25:50 -0400 (EDT)
Received: from web12903.mail.yahoo.com (web12903.mail.yahoo.com [216.136.174.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11851
	for ; Wed, 31 Jul 2002 14:24:40 -0400 (EDT)
Message-ID: <20020731182544.77738.qmail@web12903.mail.yahoo.com>
Received: from [216.69.69.214] by web12903.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 11:25:44 PDT
Date: Wed, 31 Jul 2002 11:25:44 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Stefano Basagni 
Cc: manet@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi,
Thank you for your information.I will update my
webpage today and add your paper into the list.

The paper is not available on the Web. Right?

Could you tell me where I can download it or send
me a copy via email.

Thanks

Best,
Feng


--- Stefano Basagni  wrote:
> Hi there, you might want to add the following paper
> from us, appeared at
> MobiHoc 2001.
> 
> @InProceedings{BasagniHBR01,
>   author =           {Basagni, S. and Herrin, K. and
> Bruschi, D. and
>                       Rosti, E.},
>   title =            {Secure Pebblenet},
>   booktitle =        {Proceedings of the 2001 ACM
> Iternational Symposium
>                       on Mobile Ad Hoc Networking \&
> Computing, MobiHoc 2001},
>   pages =            {156--163},
>   year =             {2001},
>   address =          {Long Beach, CA},
>   month =            {October 4--5}
> }
> 
> Cheers, St.
> 
> 
> 
> On Tue, 30 Jul 2002, feng zhu wrote:
> 
> > Hi, All,
> >
> > I made a webpage to contain a list of papers on
> > security for ad hoc networks.
> >
> >
>
http://www.ccs.neu.edu/home/zhufeng/security_manet.html
> >
> > If you wrote and/or know of any papers concerning
> > security for ad hoc networks that are not listed
> here,
> > please let me know.
> >
> > Contract me: zf_manet@yahoo.com
> >
> > Best,
> > Feng
> >
> > The following is a part of the list.
> > ========================================
> >
> >
> > Key Exchange and Distribution:
> >
> > [AG] N. Asokan, Philip Ginzboorg Key agreement in
> ad
> > hoc networks
> >
> > [H] Maarit Hietalahti  Key Establishment in Ad-hoc
> > Networks
> >
> > [CBH]Srdjan Capkuny, Levente Buttyan and
> Jean-Pierre
> > Hubaux Self-Organized Public-Key Management for
> Mobile
> > Ad Hoc Networks
> >
> >
> >
> > Secure Routing:
> >
> > [BT] Jim Brinkley William Trost Authenticated Ad
> Hoc
> > Routing at the Link Layer for Mobile Systems 1996
> >
> > [DLRS]Bridget Dahill, Brian Neil Levine, Elizabeth
> > Royer, Clay Shields. A Secure Routing Protocol for
> Ad
> > Hoc Networks
> >
> > [HPJ] Yih-Chun Hu, Adrian Perrig, David B.
> Johnson.
> > Ariadne: A secure On-Demand Routing Protocol for
> Ad
> > hoc Networks
> >
> > [MGLB] Sergio Marti and T. J. Giuli and Kevin Lai
> and
> > Mary Baker. Mitigating routing misbehavior in
> mobile
> > ad hoc networks. Mobile Computing and Networking
> > (2000):
> >
> > [PH] Panagiotis Papadimitratos and Zygmunt J. Haas
> > Secure Routing for Mobile Ad hoc Networks and
> > [slides]
> >
> > [SMG] Bradley R. Smith, Shree Murthy, J.J.
> > Garcia-Luna-Aceves Securing Distance-Vector
> Routing
> > Protocols
> >
> > [YNK] Seung Yi, Prasad Naldurg, Robin Kravets. A
> > Security-Aware Ad Hoc Routing Protocol for
> Wireless
> > Networks [2]
> >
> > [L] Janne Lundberg Routing Security in Ad Hoc
> Networks
> >
> > [HJP] Yih-Chun Hu, David B. Johnson, and Adrian
> > Perrig. SEAD: Secure Efficient Distance Vector
> Routing
> > for Mobile Wireless Ad Hoc Networks. Proceedings
> of
> > the 4th IEEE Workshop on Mobile Computing Systems
> &
> > Applications (WMCSA 2002), pp. 3-13, IEEE,
> Calicoon,
> > NY, June 2002.
> >
> > [Z]Manel Guerrero Zapata Secure Ad hoc On-Demand
> > Distance Vector (SAODV) Routing
> >
> >
> >
> > Group Communication:
> >
> > [YD] Alec Yasinsac Jim Davis. Modeling Protocols
> for
> > Secure Group Communication in Ad Hoc Networks
> > (Extended Abstract)
> >
> > [MAH ]Silja M鋕i, Tuomas Aura, Maarit
Hietalahti
> > Robust Membership Management for Ad-hoc Groups
> >
> >
> >
> > Other Security issues:
> >
> > [CK] Candolin, H. Kari, A Security Architecture
> for
> > Wireless Ad hoc Networks, to be published at IEEE
> > Milcom 2002, Anaheim, California, October 7-10,
> 2002
> >
> > [EGN] Pasi Eronen, Christian Gehrmann, Pekka
> Nikander
> > Securing ad hoc Jini services
> >
> > [HBC} Jean-Pierre Hubaux, Levente Buttyan, Srdjan
> > Capkun (Swiss Federal Institute of Technology) The
> > Quest for Security in Mobile Ad Hoc Networks
> >
> > [LKZLZ] Haiyun Luo, Jiejun Kong, Petros Zerfos,
> Songwu
> > Lu and Lixia Zhang, Self-securing Ad Hoc Wireless
> > Networks
> >
> > [K] Vesa Karpijoki Security in Ad Hoc Networks
> >
> > [SA] Frank Stajano and Ross Anderson The
> Resurrecting
> > Duckling: Security Issues for Ad-hoc Wireless
> Networks
> >
> > [SH] Christian Schwingenschl鰃l and
Marc-Philipp
> Horn
> > Build Blocks for Secure Communication in Ad-hoc
> > Networks
> >
> > [V] Anne Vanhala Security in Ad-hoc Networks
> >
> > [ZH] Lidong Zhou, Zygmunt J. Haas. Securing ad hoc
> > networks. IEEE Communications, Vol. 13 No. 6
> >
> > [ZL] Yongguang Zhang & Wenke Lee, Intrusion
> Detection
> > in Wireless Ad-Hoc Networks
> >
> > [LL] Haiyun Luo, Songwu Lu Ubiquitous and Robust
> > Authentication Services for Ad Hoc Wireless
> Networks,
> >
> > [KZLLZ] Jiejun Kong, Petros Zerfos, Haiyun Luo,
> Songwu
> > Lu and Lixia Zhang.  Providing Robust and
> Ubiquitous
> > Security Support for Mobile Ad-Hoc Networks
> >
> > [GN] Christian Gehrmann (Ericsson Research), and
> Pekka
> > Nikander (Helsinki Institute of Technology)
> Securing
> > Ad Hoc Services, a Jini View
> >
> > [KLXGGL] Jiejun Kong, Haiyun Luo, Kaixin Xu,
> Daniel
> > Lihui Gu, Mario Gerla, Songwu Lu Adaptive Security
> for
> > Multi-layer Ad-hoc Networks
> >
> > [BH]Levente Buttyan and Jean-Pierre Hubaux 
> Enforcing
> > Service Availability in Mobile Ad-Hoc WANs
> >
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From daemon@optimus.ietf.org  Wed Jul 31 15:05:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10943
	for ; Wed, 31 Jul 2002 14:05:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA27342
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 14:06:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24957;
	Wed, 31 Jul 2002 13:44:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24928
	for ; Wed, 31 Jul 2002 13:44:44 -0400 (EDT)
Received: from aspen.cs.ucla.edu (Aspen.CS.UCLA.EDU [131.179.120.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09441
	for ; Wed, 31 Jul 2002 13:43:35 -0400 (EDT)
Received: from cs.ucla.edu (Buck.CS.UCLA.EDU [131.179.120.25])
	by aspen.cs.ucla.edu (8.11.2/UCLACS-5.0) with ESMTP id g6VHgIU02869;
	Wed, 31 Jul 2002 10:42:23 -0700 (PDT)
Message-ID: <3D482625.E8D14FBB@cs.ucla.edu>
Date: Wed, 31 Jul 2002 11:02:13 -0700
From: Mineo Takai 
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Harry 
CC: "manet@ietf.org" 
Subject: Re: [manet] about simulation
References: <20020731011431.8EC161DC82950@smtp.263.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org
Content-Transfer-Encoding: 7bit

Hello Harry,

As far as I know, there are 4 common simulation tools for manet:
ns-2(http://www.isi.edu/nsnam/ns/),
GloMoSim(http://pcl.cs.ucla.edu/projects/glomosim/),
Opnet(http://www.opnet.com/) and
QualNet(http://www.scalable-networks.com/). I think the suitability of
each tool depends on your research interest, time and money.

Mineo

Harry wrote:
> 
> hi all,
>         As for our mobile ad hoc network research , anybody know
> which simulation software is suitable ,NS2 or GloMoSim ,or anything
> else?
> 
>         Harry
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 15:17:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14109
	for ; Wed, 31 Jul 2002 15:17:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01845;
	Wed, 31 Jul 2002 15:02:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01816
	for ; Wed, 31 Jul 2002 15:02:26 -0400 (EDT)
Received: from web12906.mail.yahoo.com (web12906.mail.yahoo.com [216.136.174.73])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13441
	for ; Wed, 31 Jul 2002 15:01:17 -0400 (EDT)
Message-ID: <20020731190224.20251.qmail@web12906.mail.yahoo.com>
Received: from [216.69.69.214] by web12906.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 12:02:24 PDT
Date: Wed, 31 Jul 2002 12:02:24 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Yih-Chun Hu 
Cc: manet@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, Yih-Chun Hu

Thank you for your information. 

--- Yih-Chun Hu  wrote:
> 
> SAODV is to appear in WiSe, a workshop of MobiCom 02
> 	http://www.crhc.uiuc.edu/~nhv/wise/program.html
> 	http://www.crhc.uiuc.edu/~nhv/wise/

Is it this one? 
An On-Demand Secure Routing Protocol Resilent to
Byzantine Failures, Baruch Awerbuch, David Holmer,
Cristina Nita-Rotaru and Herbert Rubens (Johns Hopkins
University) 

I only can find this paper, which looks like the paper
you mentioned.

> Ariadne is to appear in MobiCom 02
> 	http://www.acm.org/sigmobile/mobicom/2002/program/

The papers has been included in the web pages.

> 
> We also wrote:
> 
> # Yih-Chun Hu, Adrian Perrig, and David B. Johnson.
> Wormhole Detection in
> Wireless Ad Hoc Networks. Technical Report TR01-384,
> Department of
> Computer Science, Rice University, December 2001.
> 
> which probably lives under either routing or other
> issues.
> 
> 
Thanks for your information. I will add it into the
web page today.

> I was actually working on a web page like this.  If
> I had ever finished my
> web site, I would have split out the wired and
> wireless secure routing,
> since the previous wired work really does stand on
> its own as important
> prior work. That work is as follows:
> 
> * Radia Perlman. Network Layer Protocols with
> Byzantine Robustness.
> Technical Report, MIT Laboratory for Computer
> Science #429, October 1988.
> 
> * Brijesh Kumar. Integration of Security in Network
> Routing Protocols.
> SIGSAC Review, 11(2):18-25, 1993.
> 
> * Brijesh Kumar and Jon Crowcroft. Integrating
> Security in Inter-Domain
> Routing Protocols. Computer Communication Review,
> 23(5):36-51, October
> 1993.
> 
> We also site several others in our Ariadne paper.
> (e.g. [SMG], which is
> not technically an ad hoc paper, you may want to
> split these out). They
> are (authors only)
> 
> # Bradley R. Smith and J.J. Garcia-Luna-Aceves.
> # Bradley R. Smith, Shree Murthy, and J.J.
> Garcia-Luna-Aceves.
> # Ralf Hauser, Tony Przygienda, and Gene Tsudik.
> # Steven Cheung and Karl N. Levitt.
> # Steven Cheung.
> # Stephen Kent, Charles Lynn, Joanne Mikkelson, and
> Karen Seo.
> 
> Other things you may want to look at
> * http://citeseer.nj.nec.com/maki00robust.html
> * http://citeseer.nj.nec.com/401077.html
> *
> http://citeseer.nj.nec.com/karpijoki01security.html
> * http://citeseer.nj.nec.com/400961.html
> 
> Hope this helps,
> Yih-Chun

Thanks a lot.

Best,
Feng

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 15:17:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14115
	for ; Wed, 31 Jul 2002 15:17:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA02644
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 15:18:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01845;
	Wed, 31 Jul 2002 15:02:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01816
	for ; Wed, 31 Jul 2002 15:02:26 -0400 (EDT)
Received: from web12906.mail.yahoo.com (web12906.mail.yahoo.com [216.136.174.73])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13441
	for ; Wed, 31 Jul 2002 15:01:17 -0400 (EDT)
Message-ID: <20020731190224.20251.qmail@web12906.mail.yahoo.com>
Received: from [216.69.69.214] by web12906.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 12:02:24 PDT
Date: Wed, 31 Jul 2002 12:02:24 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Yih-Chun Hu 
Cc: manet@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, Yih-Chun Hu

Thank you for your information. 

--- Yih-Chun Hu  wrote:
> 
> SAODV is to appear in WiSe, a workshop of MobiCom 02
> 	http://www.crhc.uiuc.edu/~nhv/wise/program.html
> 	http://www.crhc.uiuc.edu/~nhv/wise/

Is it this one? 
An On-Demand Secure Routing Protocol Resilent to
Byzantine Failures, Baruch Awerbuch, David Holmer,
Cristina Nita-Rotaru and Herbert Rubens (Johns Hopkins
University) 

I only can find this paper, which looks like the paper
you mentioned.

> Ariadne is to appear in MobiCom 02
> 	http://www.acm.org/sigmobile/mobicom/2002/program/

The papers has been included in the web pages.

> 
> We also wrote:
> 
> # Yih-Chun Hu, Adrian Perrig, and David B. Johnson.
> Wormhole Detection in
> Wireless Ad Hoc Networks. Technical Report TR01-384,
> Department of
> Computer Science, Rice University, December 2001.
> 
> which probably lives under either routing or other
> issues.
> 
> 
Thanks for your information. I will add it into the
web page today.

> I was actually working on a web page like this.  If
> I had ever finished my
> web site, I would have split out the wired and
> wireless secure routing,
> since the previous wired work really does stand on
> its own as important
> prior work. That work is as follows:
> 
> * Radia Perlman. Network Layer Protocols with
> Byzantine Robustness.
> Technical Report, MIT Laboratory for Computer
> Science #429, October 1988.
> 
> * Brijesh Kumar. Integration of Security in Network
> Routing Protocols.
> SIGSAC Review, 11(2):18-25, 1993.
> 
> * Brijesh Kumar and Jon Crowcroft. Integrating
> Security in Inter-Domain
> Routing Protocols. Computer Communication Review,
> 23(5):36-51, October
> 1993.
> 
> We also site several others in our Ariadne paper.
> (e.g. [SMG], which is
> not technically an ad hoc paper, you may want to
> split these out). They
> are (authors only)
> 
> # Bradley R. Smith and J.J. Garcia-Luna-Aceves.
> # Bradley R. Smith, Shree Murthy, and J.J.
> Garcia-Luna-Aceves.
> # Ralf Hauser, Tony Przygienda, and Gene Tsudik.
> # Steven Cheung and Karl N. Levitt.
> # Steven Cheung.
> # Stephen Kent, Charles Lynn, Joanne Mikkelson, and
> Karen Seo.
> 
> Other things you may want to look at
> * http://citeseer.nj.nec.com/maki00robust.html
> * http://citeseer.nj.nec.com/401077.html
> *
> http://citeseer.nj.nec.com/karpijoki01security.html
> * http://citeseer.nj.nec.com/400961.html
> 
> Hope this helps,
> Yih-Chun

Thanks a lot.

Best,
Feng

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet



From manet-admin@ietf.org  Wed Jul 31 15:43:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15223
	for ; Wed, 31 Jul 2002 15:43:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02774;
	Wed, 31 Jul 2002 15:20:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02736
	for ; Wed, 31 Jul 2002 15:20:48 -0400 (EDT)
Received: from web12907.mail.yahoo.com (web12907.mail.yahoo.com [216.136.174.74])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14203
	for ; Wed, 31 Jul 2002 15:19:38 -0400 (EDT)
Message-ID: <20020731192044.18767.qmail@web12907.mail.yahoo.com>
Received: from [216.69.69.214] by web12907.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 12:20:44 PDT
Date: Wed, 31 Jul 2002 12:20:44 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Sonja Buchegger 
Cc: manet@ietf.org
In-Reply-To: <1028108363.8846.164.camel@donoratico>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, Buchegger,
Thank you for your information.

I will update the web page today and add those papers
into the list.

Thanks

Best,
Feng


--- Sonja Buchegger  wrote:
> Hi Feng,
> 
> some more references: the following is a more
> detailed description of
> our approach outlined in the 'nodes bearing grudges'
> paper as listed on
> your site, and it also gives simulation results.
> 
> Sonja Buchegger and Jean-Yves Le Boudec. Performance
> Analysis of the
> CONFIDANT Protocol: Cooperation Of Nodes - Fairness
> In Distributed
> Ad-hoc NeTworks. In Proceedings of the Third ACM
> International Symposium
> on Mobile Ad Hoc Networking and Computing MobiHOC
> 2002, p.226-236,
> Lausanne, CH, June 2002. 
> 
> And here's a short overview paper i wrote on
> security in ad-hoc
> networks, you'll probably find more references for
> your website in
> there:
> 
> Sonja Buchegger and Jean-Yves Le Boudec. Cooperative
> Routing in Mobile
> Ad-hoc Networks: Current Efforts Against Malice and
> Selfishness. In
> Lecture Notes on Informatics, Mobile Internet
> Workshop, Informatik 2002,
> Dortmund, Germany, October 2002. Springer.
> 
> It is yet to appear, but you can download it e.g.
> from
> http://lcawww.epfl.ch , where you can also find the
> papers on your list
> and more by Levente Buttyan, Srdjan Capcun, and
> Jean-Pierre Hubaux. Also
> there are relevant papers coming out of the
> terminodes project, keep
> checking out the terminodes page at
> http://www.terminodes.org .
> 
> Best regards,
> Sonja
> 
> _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/ 
> _/  _/  _/  _/  _/  
> 

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet


From daemon@optimus.ietf.org  Wed Jul 31 15:43:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15229
	for ; Wed, 31 Jul 2002 15:43:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA05437
	for manet-archive@odin.ietf.org; Wed, 31 Jul 2002 15:44:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02774;
	Wed, 31 Jul 2002 15:20:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02736
	for ; Wed, 31 Jul 2002 15:20:48 -0400 (EDT)
Received: from web12907.mail.yahoo.com (web12907.mail.yahoo.com [216.136.174.74])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14203
	for ; Wed, 31 Jul 2002 15:19:38 -0400 (EDT)
Message-ID: <20020731192044.18767.qmail@web12907.mail.yahoo.com>
Received: from [216.69.69.214] by web12907.mail.yahoo.com via HTTP; Wed, 31 Jul 2002 12:20:44 PDT
Date: Wed, 31 Jul 2002 12:20:44 -0700 (PDT)
From: feng zhu 
Subject: Re: [manet] a list of papers on security for ad hoc networks
To: Sonja Buchegger 
Cc: manet@ietf.org
In-Reply-To: <1028108363.8846.164.camel@donoratico>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Mobile Ad-hoc Networks  
X-BeenThere: manet@ietf.org

Hi, Buchegger,
Thank you for your information.

I will update the web page today and add those papers
into the list.

Thanks

Best,
Feng


--- Sonja Buchegger  wrote:
> Hi Feng,
> 
> some more references: the following is a more
> detailed description of
> our approach outlined in the 'nodes bearing grudges'
> paper as listed on
> your site, and it also gives simulation results.
> 
> Sonja Buchegger and Jean-Yves Le Boudec. Performance
> Analysis of the
> CONFIDANT Protocol: Cooperation Of Nodes - Fairness
> In Distributed
> Ad-hoc NeTworks. In Proceedings of the Third ACM
> International Symposium
> on Mobile Ad Hoc Networking and Computing MobiHOC
> 2002, p.226-236,
> Lausanne, CH, June 2002. 
> 
> And here's a short overview paper i wrote on
> security in ad-hoc
> networks, you'll probably find more references for
> your website in
> there:
> 
> Sonja Buchegger and Jean-Yves Le Boudec. Cooperative
> Routing in Mobile
> Ad-hoc Networks: Current Efforts Against Malice and
> Selfishness. In
> Lecture Notes on Informatics, Mobile Internet
> Workshop, Informatik 2002,
> Dortmund, Germany, October 2002. Springer.
> 
> It is yet to appear, but you can download it e.g.
> from
> http://lcawww.epfl.ch , where you can also find the
> papers on your list
> and more by Levente Buttyan, Srdjan Capcun, and
> Jean-Pierre Hubaux. Also
> there are relevant papers coming out of the
> terminodes project, keep
> checking out the terminodes page at
> http://www.terminodes.org .
> 
> Best regards,
> Sonja
> 
> _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/  _/ 
> _/  _/  _/  _/  _/  
> 

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet