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

Henning Rogge <> Tue, 24 November 2015 13:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F17771A6F11; Tue, 24 Nov 2015 05:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.136
X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IhZ3PJWxYuoa; Tue, 24 Nov 2015 05:16:56 -0800 (PST)
Received: from ( [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43B851A3BA1; Tue, 24 Nov 2015 05:16:55 -0800 (PST)
Received: from ([] by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1a1DSn-0004CE-I7; Tue, 24 Nov 2015 14:16:53 +0100
Received: from ([] by with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1a1DSn-0003aE-EG; Tue, 24 Nov 2015 14:16:53 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Tue, 24 Nov 2015 14:16:52 +0100
To: Paul Kyzivat <>, <>
References: <>
From: Henning Rogge <>
Message-ID: <>
Date: Tue, 24 Nov 2015 14:16:35 +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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040206080003020703000400"
X-Originating-IP: []
X-Virus-Scanned: yes (ClamAV 0.98.1/21091/Tue Nov 24 06:36:04 2015) by
X-Scan-Signature: e565a2c6194577b4a33546026e9f1a7b
Archived-At: <>
Cc: General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-manet-olsrv2-dat-metric-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2015 13:16:59 -0000

Am 20.11.2015 um 21:41 schrieb Paul Kyzivat:
> * Section 1:
> "Appendix A contains a few possible steps to improve the DAT metric."
> This is the first occurrence of the "DAT" acronym. It took me a bit to
> realize this must be referring to "Directional AirTime". Could you
> please define the acronym *before* the first use? (Perhaps in the prior
> paragraph where "Directional Airtime" is first used.)

DAT was explained in the Terminology section... I moved it to the first 
place in this section.

> * Section 2:
> "These networks employ link layer retransmission to increase the
> delivery probability and multiple unicast data rates."
> I'm not sure how to parse this sentence. Is it intended to be:
> "These networks employ link layer retransmission to increase (the
> delivery probability) and (multiple unicast data rates)."
> OR "These networks employ link layer retransmission to (increase the
> delivery probability) and (multiple unicast data rates)."

I will split the sentence apart into two parts to make this more clear.

> Either way I don't understand what "multiple unicast data rates" means.
> Can you clarify this?

Wifi (802.11) provides multiple datarates for unicast traffic. I will 
change the sentence to make it easier to understand.

> * Section 7:
> You call these *constants*, in contrast to the *parameters* defined in
> section 6. But you then suggest conditions under which they could be
> changed. Perhaps they should simply be included with the parameters, but
> with strong warnings about diverging from the recommended values.

Parameters can be chosen by a local implementation/installation... but 
constants need to be the same over the whole Mesh.

> Else, it would be good to define these *before* the parameters, because
> that would avoid the forward reference to DAT_MAXIMUM_LOSS.

I will switch the Parameter and the Constant section.

> * Section 9.3/9.4:
> Are you considering these to be mutually exclusive? Or is a HELLO
> message processed first by 9.3, and then by 9.4?

the RFC5444 packet (which contains the Hello Message, but that is 
unimportant for this processing part) is processed by 9.3

the Hello Message is processed by 9.4

> Since there is considerable overlap in processing between the two, and
> it would presumably be wrong to do that twice, I guess you must assume
> them to be mutually exclusive. But I presume HELLO messages arrive in
> incoming packets, so 9.3 sounds like it ought to apply to them.

The trouble is (thank you to Thomas Clausen for pointing this out) that 
some RFC5444 implementations don't have access to the packet sequence 
number. So this metric (which needs the validity time value of the Hello 
Message anyways) contains a fallback that provides a loss estimate based 
on Hello Intervals if a node does not provide a Packet sequence number.

> * Section 10.2:
> IIUC steps 5.3 & 5.4 are just the hard way of saying:
>    bitrate := MAX(L_DAT_rx_bitrate, DAT_MINIMUM_BITRATE)

I transformed both IF conditions into a MIN() and a MAX() statement.

Henning Rogge

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