Re: [Gen-art] Gen-ART Last Call review of draft-ietf-manet-olsrv2-dat-metric-08

Henning Rogge <henning.rogge@fkie.fraunhofer.de> Thu, 26 November 2015 12:30 UTC

Return-Path: <henning.rogge@fkie.fraunhofer.de>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3111B2B20; Thu, 26 Nov 2015 04:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.564
X-Spam-Level:
X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3fqf2TN_vdl; Thu, 26 Nov 2015 04:30:33 -0800 (PST)
Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ECA1B2B24; Thu, 26 Nov 2015 04:30:33 -0800 (PST)
Received: from rufsun5.fkie.fraunhofer.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 1a1vgz-0005fB-Ty; Thu, 26 Nov 2015 13:30:29 +0100
Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1a1vgz-0002OB-Q1; Thu, 26 Nov 2015 13:30:29 +0100
Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 26 Nov 2015 13:30:29 +0100
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, <draft-ietf-manet-olsrv2-dat-metric.all@ietf.org>
References: <564F858B.4000105@alum.mit.edu> <56546333.6000004@fkie.fraunhofer.de> <56547B7B.8030206@alum.mit.edu> <56547DB1.3010403@fkie.fraunhofer.de> <56549131.6050202@alum.mit.edu> <56555DBF.1070808@fkie.fraunhofer.de> <5655CFA8.5020909@alum.mit.edu>
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Message-ID: <5656FB64.7070805@fkie.fraunhofer.de>
Date: Thu, 26 Nov 2015 13:30:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5655CFA8.5020909@alum.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080604070404040905000104"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.98.1/21099/Thu Nov 26 06:36:12 2015) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 676a75961403c53da43f811dd9e91d0e
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/qfVtd-_LtW2Q5ibcCjKDT8TUDHU>
Cc: General Area Review Team <gen-art@ietf.org>, Rogge Henning <hrogge@gmail.com>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-manet-olsrv2-dat-metric-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 12:30:37 -0000

Am 25.11.2015 um 16:11 schrieb Paul Kyzivat:
> Henning,
>
> I'm not trying to second guess the intent. My issues are solely with the
> presentation. And clearly this is not a subject I'm knowledgeable about,
> so I'm going solely from what I read in this draft without any other
> context. Somebody who has the proper context to be reading this may well
> not find it at all confusing. Nevertheless, see inline.

No problem...

> On 11/25/15 2:05 AM, Henning Rogge wrote:
>> Am 24.11.2015 um 17:32 schrieb Paul Kyzivat:
>>> So, if I do 9.3 for every packet, and then also do 9.4 for every HELLO
>>> message within that packet, then I could end up incrementing
>>> L_DAT_received[TAIL] *twice*.
>
>> If you look at the head of section 9.3 you will notice that this section
>> will only be processed in the presence of a packet sequence number. One
>> of the first things 9.3 does is to set the L_DAT_last_pkt_seqno variable.
>
> OK. My mistake. Because 9.3 sets L_DAT_last_pkt_seqno it won't get
> updated again in 9.4.
>
> But then, what is the purpose step 3 of 9.4? If 9.3 is always applied
> before 9.4, then L_DAT_last_pkt_seqno can never be undefined in 9.4.

It could be that you have a neighbor that will never deliver a packet 
sequence number, so 9.3 will never apply.

Because I am not sure if packet (9.3) or message (9.4) processing is 
done first, I make sure to overwrite the data in the current element of 
the queue in 9.3 when I discover the packet sequence number.

Henning Rogge

P.S.: I will be away from work in December, so I added my private email 
HRogge@gmail.com to this thread.


-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer 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