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

["Rogge, Henning" <[e-mail]>]

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

> Nits
> ----

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

Thank you for the review.