[manet] comments on draft-rogge-manet-dlep-channel-utilization-00

"Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl> Fri, 23 July 2021 17:18 UTC

Return-Path: <Ronald.intVelt@tno.nl>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 151433A0CEE for <manet@ietfa.amsl.com>; Fri, 23 Jul 2021 10:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tno.nl
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QsJnPVIWqID1 for <manet@ietfa.amsl.com>; Fri, 23 Jul 2021 10:18:33 -0700 (PDT)
Received: from fromintouta.tno.nl (fromintouta.tno.nl []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C3B3A0AD5 for <manet@ietf.org>; Fri, 23 Jul 2021 10:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tno.nl; l=18898; s=mta1; t=1627060712; h=from:to:subject:date:message-id:mime-version; bh=1v68599dZ57YiZoZfruUV/LiBWBJRv3SXGX3ZVxZ4os=; b=wVenZW+Ij0CFiAYCisn6Yde+2OqhMAKvdz7yqCvpfsxhzrchT2qcbKhe 38fzAn4lU12bDRL3Qhei7iRGPw7iqUoBv6HSlwcvUbT2PHYFpKCAJJjcm v6r9jLZ8Jmw7dHsJPzHe+87hWwNkKU1Ph4ivzaFihzBT+R609cC7+kT3e M=;
IronPort-SDR: GCVMwVjsy+2dJn06T1dXCIlr+nR2s8my3pX4yZl1ILNmBtJ16mrLX6wjU5V//uw56Q+Fnm8oXl 8DLJ7349pbFs+xuLcQvFjLhRKxYIHHUAYCPEfeVi51SdfaQFSQNalar8+bm0bomIEWXI5aOAZv 0bIKGat64vy/uiBoy153olLFMiQEssBD6GygySApYtj5lTAV1KmxE3ZdRbRJvT8rxa2c0d7dpp RgmN0JqSQ0FMELqLNUp8xdVR7LnD/YGTn24ZlPm7wQ+GxvPQaB5kKO8r1t+2LQWqz5aYeJywlg byUnpXBMFbF3HRSXpc1IgTvm
X-IronPort-AV: E=Sophos; i="5.84,264,1620684000"; d="scan'208,217"; a="32861277"
Received: from UCP13.tsn.tno.nl ( by UCP33.tsn.tno.nl ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Fri, 23 Jul 2021 19:18:27 +0200
Received: from UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298]) by UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298%7]) with mapi id 15.01.2242.012; Fri, 23 Jul 2021 19:18:27 +0200
From: "Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl>
To: "Rogge, Henning" <henning.rogge@fkie.fraunhofer.de>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: comments on draft-rogge-manet-dlep-channel-utilization-00
Thread-Index: Add/5OhgVCnGQe7jRUux1reNoQ4DHQ==
Date: Fri, 23 Jul 2021 17:18:27 +0000
Message-ID: <471c09250ce14638be24a01895cfa245@tno.nl>
Accept-Language: en-US, nl-NL
Content-Language: en-US
x-originating-ip: []
x-esetresult: clean, is OK
x-esetid: 37303A29F08AA76F677162
Content-Type: multipart/alternative; boundary="_000_471c09250ce14638be24a01895cfa245tnonl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/blxkAqXBK4CypgIm4wbI_o9Wi0I>
Subject: [manet] comments on draft-rogge-manet-dlep-channel-utilization-00
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 23 Jul 2021 17:18:40 -0000

Henning, all,

Please find below my comments and questions, as WG participant, on draft-rogge-manet-dlep-channel-utilization-00




  *   The introduction (Section 1) is rather terse. Some words of motivation for this extension could be added. In particular, I would be interested to know the reasoning behind the design decision to provide the router with the 'raw' parameter values of Active Time, Busy Time, Rx and Tx Time, thus leaving it up to the router to calculate channel utilization, instead of letting the modem do the calculation and have it present a single 'cooked' Channel Utilization Ratio value to the router  (by means of a Channel Utilization Ratio Data Item).

  *   Accepting for the moment that there is a good reason to have four 'raw' time parameter Data Items, I think the types of Message in which these Data Items can occur should be specified. Each of the sections (3, 4, 5, 6) defining a Data Item says: "This value is usually interface specific." I read that to mean: "This value is *not* Destination-specific." (If something else was meant, please correct me). I am guessing that these Data Items are intended to be carried in Session Update messages, rather than in Destination Up or Destination Update messages, but would like to see that explicitly stated.

  *   It should be specified whether the time values reported in the {Active, Busy, Rx, Tx} Data Items are cumulative or whether they are reset to zero after reporting.

  *   Section 2 says: "To indicate that the Channel Utilization Extension is to be used, an implementation MUST include the Radio Channel Active and Radio Channel Busy Value in the Extensions Supported Data Item." Is this correct? Why two values for one extension? This also appears to contradict section 8.1 , which mentions a single Extension Type value, named "Radio Channel Utilization".

  *   Section 4 seems to be saying that the local radio's Rx and Tx Time are not included in the Busy Time reported in the Radio Channel Busy Data Item. But whereas the Radio Channel Busy Data Item is mandatory, the Radio Channel Rx Data Item and the Radio Channel Tx Data Item are optional. How can the router accurately calculate the channel utilization in case the modem chooses not to send the Radio Channel Rx and Radio Channel Tx Data Items?

  *   With regard to the structure of this I-D, I would recommend to have a single section named "Radio Channel Data Items" (or similar), with the four Data Item specifications as subsections of this section. (However, that's just a matter of taste and therefore subjective).


Section 1

"dynamic Link Exchange Protocol" => "Dynamic Link Exchange Protocol"

Section 1.1

"NOT RECOMMENDED" is missing

Section 2

2nd para: "The Radio Band Extension Type Value is TBD; see Section TBD." This looks like a copy-paste error from the Radio Band Extension I-D. I would have expected; "The Radio Channel Utilization Extension Type Value is TBD1; see Section 8.1" (per current section numbering)

Section 3

2nd para: "The value in this item must be larger than the values in the other three Data Items this extensions define together." => "The value in this item must be larger than the values in the other three Data Items this extension defines together."

Definition of Active Time field: "Time in nanoseconds since the channel has been active." => "Time in nanoseconds the channel has been active." or "Time in nanoseconds since the channel became active."

Section 4

1st para: "Radio Channel Busy Item is mandatory and contains information how much time the radio channel has been busy but has not been, not including the time in the Channel Rx and Chanel Tx Data Item." Some words appear to be missing from this sentence, just before the comma.

2nd para: "The value in the Channel Active item must be larger than the values in the other three Data Items this extensions define together." => "The value in the Channel Active item must be larger than the values in the other three Data Items this extension defines together." (Also in Section 5, 2nd paragraph and Section 6, 2nd paragraph).

Section 8.2

Table 2: "Radio Channel busy" => "Radio Channel Busy"
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.