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

"Charles E. Perkins" <> Thu, 26 February 2009 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF44E3A69E2 for <>; Thu, 26 Feb 2009 10:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9b3F1TKts+e6 for <>; Thu, 26 Feb 2009 10:10:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C2EE93A67A7 for <>; Thu, 26 Feb 2009 10:10:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; 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 [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <>) id 1Lckgq-0001vI-LE; Thu, 26 Feb 2009 13:10:32 -0500
Message-ID: <>
Date: Thu, 26 Feb 2009 10:10:31 -0800
From: "Charles E. Perkins" <>
Organization: Wichorus Inc.
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
To: Rex Buddenberg <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5244a8b7e5d096c2b85e9751ccd39f1751350badd9bab72f9c350badd9bab72f9c
Cc: "" <>, Emmanuel Baccelli <>
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

> 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 
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.

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.