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

"Rogge, Henning" <> Thu, 05 August 2021 08:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01AFF3A00C3 for <>; Thu, 5 Aug 2021 01:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xkrp5BW1Zs_N for <>; Thu, 5 Aug 2021 01:52:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E0973A00C4 for <>; Thu, 5 Aug 2021 01:52:05 -0700 (PDT)
IronPort-SDR: 9XdTx7fsGWkrdDXFvXnj0X05lSgwin/ApeDu13+eyAZSqzFXVBFS6xTmMA/GefPUheFFiRfhBn QpXRZNsbEpiA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.84,296,1620684000"; d="scan'208";a="30904663"
Received: from ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:52:03 +0200
IronPort-SDR: /ZNmrq8/0NLrCl8MEZ/vDdE6+JcSQRZnIW0d/ghglP1EP5jxu633r0Q5m8OSWuN/pzfIO98MfD 75sKnECd3rk8tPoTO4f/6URVSXzeZQbTI=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3APTzkdqxQf3UnZ3OecU3YKrPwS71zdoMgy1?= =?us-ascii?q?knxilNoHtuHfBw9vrCoB11726XtN98YhAdcLO7VJVoP0mslqKdiLN5VdzJYO?= =?us-ascii?q?CMggWVxe9Zjbff/w=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJCgB2pQth/wUDB4BaHgEBCxIMQIM?= =?us-ascii?q?sgiEIJRIxC4Q8iQSIZAOPbowIgWgLAQMBAQEBAQkEOwIEAQGEWAIXgmomOBM?= =?us-ascii?q?BAgQBAQESAQEBBAEBAQIBBgIBAYERE4VoAQyGQwEEASMRDAEBJRIBBAsCASI?= =?us-ascii?q?CBSECAgINIxUQAQEEDoVdIQGrTIExgQGCBwEBBoJZhT4JgRAqhwuCaIN8gg1?= =?us-ascii?q?DgRU2gy2EK4MwgmSCJWsGaDsIgSgtFQUKASkfCC6RR4NCqBUDBAOBfYErnkg?= =?us-ascii?q?rg2SLYIYNNZBjkFmFNoIcoyCBPzgkgVlxgzhQFwIOjh+EJIorczgCBgEKAQE?= =?us-ascii?q?DCXyHDQeBLwGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.84,296,1620684000"; d="scan'208";a="150084863"
X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown
Received: from (HELO ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2021 10:52:00 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=dkim202105; h=MIME-Version:Content-Transfer-Encoding: Content-Type:In-Reply-To:References:Message-ID:Date:Subject:CC:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qeq21i3P/iFx3gd65mng/qlNVHDO7K20gmvr+DEzFX8=; b=nZMFA+gy8UlJ65fJtNwuMTT6oJ TdC2B5nd2aRUhv+XEFvbmWRzjQ8LyPW1y+oL7RrubQuGd/BZK4MhIPQ0oCDGnKzSOxbodinRv2d0I xkWYqn3mAS7WpyJfC1oo4S9Gde4Mx4ahIXG/4/iNe8mxTEQmKuqZkrlLLEclZl3tlahfzAFMgkZAN JL7VvS08dMZyW1T+WBok+2KZoe8uqako2v07KKPvKb4boGmWobOwpNwY/u1yMA5wXuYHr98IVKGUt hUqwb0IS911iO6Sqs2cuBv9rf1LEG1XD5YVooxtMkLqwGRiD9AgrZFyP5lcc6VLnoQ0OT3Ty97nnd Da/WBZrQ==;
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1mBZ6e-00047G-Dt; Thu, 05 Aug 2021 10:52:00 +0200
Received: from ([] by with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from <>) id 1mBZ6a-0003W6-I0; Thu, 05 Aug 2021 10:51:56 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 5 Aug 2021 10:51:59 +0200
Received: from ([fe80::bdb5:83e4:9ad3:822f]) by ([fe80::bdb5:83e4:9ad3:822f%13]) with mapi id 15.00.1497.018; Thu, 5 Aug 2021 10:51:59 +0200
From: "Rogge, Henning" <>
To: "" <>
CC: "Velt, R. (Ronald) in 't" <>
Thread-Topic: comments on draft-rogge-manet-dlep-channel-utilization-00
Thread-Index: Add/5OhgVCnGQe7jRUux1reNoQ4DHQJ8HFZm
Date: Thu, 5 Aug 2021 08:51:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [manet] comments on draft-rogge-manet-dlep-channel-utilization-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Aug 2021 08:52:11 -0000

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

> Comments
> --------------
>  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).
My original motivation for this was that this is what the Linux kernel reports for Wifi... but I think there is good reason for NOT mixing these values together.

The problem of aggregating these values into a "cooked" ratio is that the radio will have to define a statistics for this... the values change over time and the router will never know how long back the cooked value goes or if its a "moving average" or just a "flat average over an interval". Giving the raw (cumulative) timings allow the router to do the statistics itself in a way its useful for the routers design goal.

> 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.

Yes, these values are channel/session specific, not destination specific. I will add this with a better explanation to a new draft release.
Typically the layer-1 of a radio doesn't even know about destinations and neighbors.
> 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.

My interpretation of this is that they are cumulative... they are never set to zero.
> 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".
This (single) extension defines two mandatory TLVs and two optional ones for Session Updates.

> 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?
I think the idea behind busy/rx/tx is that busy is "radio channel is doing something unspecified" while rx and tx are more precise...

If the radio can only report "busy" and "active time", the router can only calculate the fraction (and maybe pattern) of used/unused moments of the radio channel... if the radio also uses the rx/tx TLVs, the router gets a more specific view on the channel... still, there might still be times where the channel is not considered "free", but the radio is not receiving or transmitting symbols, e.g. when using the radio channels energy level to determine if its available or not. Some other radio sources might make the channel unavailable, but nothing can be received or transmitted.

> 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).

> Nits
> ----

I will address the nits in a new revision of the draft.

Thank you for the review.