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

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 26 February 2009 18:10 UTC

Return-Path: <charles.perkins@earthlink.net>
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 CF44E3A69E2 for <autoconf@core3.amsl.com>; Thu, 26 Feb 2009 10:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 9b3F1TKts+e6 for <autoconf@core3.amsl.com>; Thu, 26 Feb 2009 10:10:11 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C2EE93A67A7 for <autoconf@ietf.org>; Thu, 26 Feb 2009 10:10:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=W0/r3n5pfaH0XwwPVJTaeKfjCwdShlBPqg/D1Y7GFTvMno5Qvp0vimHqvEn96B8A; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Lckgq-0001vI-LE; Thu, 26 Feb 2009 13:10:32 -0500
Message-ID: <49A6DB17.8010709@earthlink.net>
Date: Thu, 26 Feb 2009 10:10:31 -0800
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Rex Buddenberg <budden@nps.navy.mil>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> <49A44958.4090300@earthlink.net> <49A46732.1050706@nps.navy.mil>
In-Reply-To: <49A46732.1050706@nps.navy.mil>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5244a8b7e5d096c2b85e9751ccd39f1751350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.129.145
Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Autoconf] updated draft on 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/mail-archive/web/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>
X-List-Received-Date: Thu, 26 Feb 2009 18:10:12 -0000

Hello Rex,

... following up ...

Rex Buddenberg wrote:
>
> I'm genuinely confused regarding just what the order of business needs 
> to be and what the document artifacts that result from that should be.

I think that our small document on aspects of wireless communication is 
a good first step,
and aims to be quite non-controversial.  Even so, it appears to be 
controversial, which I
take to be a pretty good indicator that it is needed, and needed 
immediately.

> I've also been a much more intimate witness on how NOT to do such 
> things within DoD than I ever wanted to be.  Are there, perhaps, some 
> parallels?
>
> How to get it backwards:
>

...  I'd be curious to find out if you really think these steps are 
representative
of  a way forward that starts with our small "aspects" contribution.

>
> Aside from the steps (e.g. #4) that are missing altogether, this is 
> exactly the reverse order of business!  We can, and should, build the 
> reference model without reference to requirements.  Is that were we 
> are agreeing or disagreeing?  Or even on the same page?

Yes, this is a good question, but I think the answer would have to come 
from you.

Regards,
Charlie P.


>
>
>
>
>
>
> Charles E. Perkins wrote:
>>
>> Hello Rex,
>>
>> Thanks for the long email.  I think that I do have a good handle on 
>> the various
>> kinds of mobile communications scenarios as you have outlined below.
>>
>> You have raised the particular point that many nodes in an ad hoc 
>> network
>> do not have to be routers.  I certainly agree with this, and agree 
>> that any work
>> in [autoconf] needs to be able to configure addresses for wireless 
>> nodes in
>> an ad hoc network that are not routers.  Perhaps Emmanuel and I could 
>> better
>> emphasize this point in our draft, but even non-router nodes can be 
>> subject to
>> the problems noted in that draft.  So we have to find better language to
>> identify the wireless nodes that would be affected other than just 
>> calling
>> them "routers".
>>
>> However, I still maintain that this document under discussion is _not_ a
>> requirements document, and that Paul seems to be discussing various
>> requirements for ad hoc networks.  Don't you agree that requirements
>> should be located in a separate document?  The only "requirement" that
>> we have placed in our small document is a need to deal with reality.
>>
>> I'd also like to point out one somewhat unrelated point.  It is 
>> agreed, of
>> course, that MAC-layer problems can pre-empt the usefulness of
>> routing protocols.  However, routing protocols can themselves cause
>> congestion, and any techniques that we can bring to bear that reduce
>> congestion are likely to increase the overall effectiveness of the MAC
>> layer protocols also.  Furthermore, I think it is likely that people who
>> do not have good understanding about the nature of the wireless
>> medium are more likely to make design decisions for routing protocols
>> that would increase congestion.
>>
>> What do you think?
>>
>> Regards,
>> Charlie P.
>>
>>