Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt

Henning Rogge <henning.rogge@fkie.fraunhofer.de> Tue, 04 September 2012 13: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 F0C3C21F8568 for <manet@ietfa.amsl.com>; Tue, 4 Sep 2012 06:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=3.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 ZUCg-BeYY8LV for <manet@ietfa.amsl.com>; Tue, 4 Sep 2012 06:18:10 -0700 (PDT)
Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id D565821F8574 for <manet@ietf.org>; Tue, 4 Sep 2012 06:18:09 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.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 1T8t0k-0000OX-5e; Tue, 04 Sep 2012 15:17:46 +0200
Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1T8t0k-0005Bo-2x; Tue, 04 Sep 2012 15:17:46 +0200
Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 15:17:45 +0200
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Sep 2012 15:17:45 +0200
Message-ID: <5045FF72.6070101@fkie.fraunhofer.de>
Date: Tue, 04 Sep 2012 15:17:38 +0200
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: manet@ietf.org
References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <SUKNPT8109OJFjiDOhs0001bef2@SUKNPT8109.cogent-dsn.local> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local>
In-Reply-To: <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010703070103080507020707"
X-Originating-IP: [128.7.5.36]
X-OriginalArrivalTime: 04 Sep 2012 13:17:45.0904 (UTC) FILETIME=[AC511300:01CD8A9F]
X-Virus-Scanned: yes (ClamAV 0.97.5/15310/Tue Sep 4 12:41:15 2012) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46
Cc: Stan Ratliff <sratliff@cisco.com>, Bo Berry <boberry@cisco.com>, "Mercieca, Victoria" <Victoria.Mercieca@Cassidian.com>
Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt
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: Tue, 04 Sep 2012 13:18:11 -0000

On 09/04/2012 02:17 PM, Mercieca, Victoria wrote:
> Hi all,
>
> I've also spent some time looking at the new DLEP draft and here are
> my thoughts. I have divided my comments into notes on DLEP
> functionality and notes on the document itself.

Hi,

triggered by your comment about the credit window system of DLEP I got
another question.

If I understand DLEP right it handles a credit window per neighbor. How
do we handle the common usecase where we have a radio with a "sender
window", which means we have credits for sending data, but not to a
specified receiver.

Lets say our radio (because of some TDMA waveform) has an outgoing
credit window of 1000 bytes.

Do we set the credit window of every neighbor to 1000 bytes? This would
mean we might get 1000 bytes for every neighbor, which is too much.

Do we distribute the 1000 bytes among our neighbors? This would prevent
any outgoing traffic to use the full 1000 bytes.

I think this should be considered before we build a Credit Window Scheme 
into DLEP that is not applicable for this use case.

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