[manet] Re: Review of draft-ietf-manet-dlep-radio-quality-02

On Mon, Oct 20, 2025 at 12:09 PM Velt, R. (Ronald) in 't
<[email protected]> wrote:
>
> Henning, all,
Hi Ronald...

> Major
> -------
> Section 3: I have a problem with the Bit Error Rate DI being specified as
> mandatory, whereas the other DIs related to radio quality are made optional.
> I know of radios ("modems") out there that will not be able to provide
> (through their current proprietary management interface, but presumably
> neither via DLEP, should they support that interface in future) a BER value
> (before FEC), but can provide a value for SNR/SINR and/or RSSI and/or Noise
> level. My suggestion would be to treat all four indicators of radio quality
> as equal. In fact, I would go so far as to allocate a separate DLEP
> Extension Type to each of them. This would allow a modem to signal during
> Session Initialization which types of Radio Quality indication it supports.
> (It is not as if we would exhaust the Extension Type space any time soon).

I talked about this a LOT with a few radio vendors...

- First, I think we need to make one of the TLVs mandatory...
otherwise we could get into the situation where a radio supports the
extension but doesn't deliver anything. Yes, splitting the extension
might also resolve this issue.
- Second, I think your worry about SNR available but biterror-rate not
is overestimating the issues with biterror-rate. As far as I can tell
for each modulation-coding-scheme the radio vendor should have a curve
(I SNR is often called "E0/N0" in this diagrams) that maps
biterror-rate of the channel against SNR budget... these curves can be
stored in the radio to easily calculate the biterror-rate from the
SNR.
- third, I have met at least two radio vendors who considered the
exact SNR measured in the radio as "company secret", because it would
provide details about the receiver in the radio. In both cases they
felt more "at easy" with providing biterror-rate instead.

What do you think...

> Minor
> -------
> 1) Section 3: It should be specified, in this section or elsewhere, in which
> DLEP Message Types the Data Items defined below MUST / SHOULD / MAY be
> present. See draft-ietf-manet-dlep-channel-utilization, where this
> information (although without using RFC 2119 key words) was added to Section
> 3 after an earlier review comment. (I understand that "interface specific"
> implies Session-oriented messages and "neighbor specific" implies
> Destination-oriented messages, but I would like to see this made explicit).
>
> 2) Section 3, section 5: Please enumerate the "TBD"s  for easier replacement
> by actual values later in the process. (If I counted correctly, there are 5:
> one Extension Type (but see major review comment above) and four Data Item
> Types, so TBD1, TBD2, TBD3, TBD4, TBD5).

Good points, I can easily address them after the IETF meeting.

Henning Rogge

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]