Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01

Henning Rogge <henning.rogge@fkie.fraunhofer.de> Thu, 19 May 2011 06:18 UTC

Return-Path: <henning.rogge@fkie.fraunhofer.de>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6FE0724 for <manet@ietfa.amsl.com>; Wed, 18 May 2011 23:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level:
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XSq+R2EbSup for <manet@ietfa.amsl.com>; Wed, 18 May 2011 23:18:02 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id CE674E0713 for <manet@ietf.org>; Wed, 18 May 2011 23:18:01 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1QMwYa-0006mT-QZ; Thu, 19 May 2011 08:18:00 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1QMwYa-0005XW-GD; Thu, 19 May 2011 08:18:00 +0200
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
To: manet@ietf.org
Date: Thu, 19 May 2011 08:17:56 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; i686; ; )
References: <201105111610.58611.georg.wittenburg@inria.fr> <201105142033.10407.hrogge@googlemail.com> <20110518203539.GG20998@ojctech.com>
In-Reply-To: <20110518203539.GG20998@ojctech.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1437093.hKiTKlJmuN"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201105190817.57269.henning.rogge@fkie.fraunhofer.de>
X-Virus-Scanned: yes (ClamAV 0.97/13090/Thu May 19 02:18:37 2011) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 711cfe84e8f62d248cc13f80a51c6aa9
Cc: David Young <dyoung@pobox.com>
Subject: Re: [manet] Some comments on draft-funkfeuer-manet-olsrv2-etx-01
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2011 06:18:03 -0000

On Wed May 18 2011 22:35:39 David Young wrote:
> Let us cross our fingers and hope that each OS provides a uniform API.
And that all drivers use the API... ;)

> > If you rely on the rate control, you need to send unicast probing packets
> > to all of your neighbors regularly if you have no traffic in this
> > direction.
> 
> It seems to me, too, that that is a problem with using a rate
> adaptation.  One hopes that there are probe packets or else that the
> inherent background unicast traffic keeps the rate adaptation fresh.  I
> think that having to induce some unicast traffic may be a reasonable
> trade-off for being able to derive a link metric from the rate
> adaptation.
It would be necessary to do so if no unicast traffic is on a link.
 
> FWIW, I have lingering doubts whether or not a link metric can be
> updated or link metrics propagated nearly as quickly as the channel
> makes a substantial change of state.  From N hops away, a single metric
> for a link may not be nearly as useful in a routing decision as the
> historical range or distribution of metrics on a link.  People have
> experimented with "opportunistic" routing/forwarding, I think this is
> why.
I think this hysteresis/history of a link could be directly included into 
metric calculation of a link. The Draft is doing it in a very limited way by 
averaging over a certain period of time.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0