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

Hi Henning,

Sorry for the delayed reply. See inline.

[Still no hat]

> -----Original Message-----
> From: Henning Rogge <[email protected]>
> Sent: maandag 20 oktober 2025 12:38
> To: Velt, R. (Ronald) in 't <[email protected]>
> Cc: [email protected]
> Subject: Re: [manet] 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.

Different radio manufacturers appear to have different ideas about the radio parameters they can or are willing to make available across a management interface or via DLEP. It seems to me that having different extension types instead of one type with one mandatory Data Item and a few optional ones would be the most flexible solution.

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

Such a mapping would be based on statistics and would not necessarily reflect the current BER at the time the Data Item is sent to the router, right?

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

In a strictly controlled test environment, providing the SNR might give away some implementation details, perhaps. Other radio manufacturers don't seem to be worried about this. (I know of at least one counter-example). Customers may even demand to have this information. Hence my remark on your first point about different views from different manufacturers and making the case for maximum flexibility.

> 
> What do you think...

See inline comments above on your first, second and third points...

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

Ah, I had missed that you already submitted a new version while I was typing my review comments,  with thanks to Outlook's  "brilliant" two-tab Inbox organization and its seemingly arbitrary distribution of incoming mail messages over "Focused" and "Other".
> 
> Henning Rogge

Thanks,
Ronald

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