Re: [Autoconf] aspects of multi-hop wireless communication

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 19 December 2008 17:59 UTC

Return-Path: <autoconf-bounces@ietf.org>
X-Original-To: autoconf-archive@megatron.ietf.org
Delivered-To: ietfarch-autoconf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7AB28C170; Fri, 19 Dec 2008 09:59:01 -0800 (PST)
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB5D28C14C for <autoconf@core3.amsl.com>; Fri, 19 Dec 2008 09:59:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.155
X-Spam-Level:
X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVBhti6MaIn4 for <autoconf@core3.amsl.com>; Fri, 19 Dec 2008 09:59:00 -0800 (PST)
Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 13B8428C170 for <autoconf@ietf.org>; Fri, 19 Dec 2008 09:59:00 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-12.tower-153.messagelabs.com!1229709530!14014205!1
X-StarScan-Version: 6.0.0; banners=.,-,-
X-Originating-IP: [136.182.1.14]
Received: (qmail 2577 invoked from network); 19 Dec 2008 17:58:51 -0000
Received: from unknown (HELO motgate4.mot.com) (136.182.1.14) by server-12.tower-153.messagelabs.com with SMTP; 19 Dec 2008 17:58:51 -0000
Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id mBJHwos9003037; Fri, 19 Dec 2008 10:58:50 -0700 (MST)
Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id mBJHwofq014118; Fri, 19 Dec 2008 11:58:50 -0600 (CST)
Received: from [127.0.0.1] ([10.129.40.88]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id mBJHwmTe014114; Fri, 19 Dec 2008 11:58:49 -0600 (CST)
Message-ID: <494BE0D8.4070509@gmail.com>
Date: Fri, 19 Dec 2008 18:58:48 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
References: <be8c8d780812190119r200efceawef79c63766ea1a3f@mail.gmail.com> <494B8E7C.7000505@gmail.com> <be8c8d780812190504x98496egc37c25b21a799ceb@mail.gmail.com> <494BB75E.4050206@gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D016C3E14@GLKMS2100.GREENLNK.NET> <be8c8d780812190721r7ea9c43aif8aff7c83f44f43@mail.gmail.com> <494BC360.1000109@gmail.com> <be8c8d780812190810y4d891c44tfbec9cce43c3cee9@mail.gmail.com> <494BC927.1020400@gmail.com> <494BCCCC.6050206@earthlink.net> <494BCFEF.2010100@gmail.com> <494BD45A.2090106@earthlink.net>
In-Reply-To: <494BD45A.2090106@earthlink.net>
X-Antivirus: avast! (VPS 081218-0, 18/12/2008), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] aspects of multi-hop wireless communication
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: autoconf-bounces@ietf.org
Errors-To: autoconf-bounces@ietf.org

Charles E. Perkins wrote:
> Hello Alex,
> 
> I think we're approaching the point of having to agree to disagree.
 >
>> Errr... somehow yes, if I'm permitted.  I simply suggest a
>> link-layer solution to a link-layer problem.
> 
> IP is a solution that puts together different links.

Yes, provided IP knows what are those links, each one in particular detail.

> If you would like to suggest limiting the applicability of IP to 
> _only_ be allowed to work for links with specific characteristics, 
> then I think you should be explicit about it.

YEs, I'm explicit: it's wifi.

> Perhaps you would get some support, but I'm guessing it would not
> arise from the community of engineers and developers within autoconf
> or manet.
> 
> 
>> 
>>> What if I want to join a working ad hoc network of devices using
>>>  solutions that have already been developed without bridging?
>>> Why is this bad?
>> 
>> It's not bad.
> 
> Whew!
> 
>> 
>> One would first deploy bridges in networks that are partitioned and
>> in need of bridges.  Then any new terminal needing to join could do
>> so, without needing to be itself a bridge.
>> 
>> The question is why does one refuse the use of bridges when the
>> network is partitioned at link-layer?
> 
> That's not a question I have raised, nor do I think that the answer
> would be illuminating.  But my answer is that no one is making any
> such refusal.
> 
> The question is, why can't we use IP as a good tool to solve problems
> of connecting together wireless links into a network, even when
> bridging solutions are not available?

WE need to be able to know over what is IP supposed to run.  If we don't 
have a good under-IP then it can't run.  Actually we could think as much 
it will run as we think it won't run.  Sorry, I can't be clearer than that.

Alex

>>> What if there is a hurricane and some of the relief workers
>>> forgot to put their wireless bridging devices in their backpacks?
>>> 
>> 
>> No no... they won't, because they're trained to never forget these 
>> things at home.  And if they do, then there exist other
>> super-reliefs aids sending them trucks full of these devices.
> 
> Well, here is where we have stark disagreement.  I am surprised if 
> you truly suggest that IP should not be engineered to work because it
> is an "error condition" to not have truckloads of equipment.
> 
> 
> Regards, Charlie P.
> 
> 
> 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf