[manet] Re: Rtgdir early review of draft-ietf-manet-dlep-cha nnel-utilization-01

Hi Donald and Russ,

ok, but needed to be sure because I wanted the reviewer to discuss with me
if I replied, usually in some WG I don't get much replies, however, my
reply is as follows below,

On Mon, May 5, 2025 at 12:45 AM Donald Eastlake <[email protected]> wrote:

> Hi Abdussalam,
>
> Any WG participant can post a review of any current WG documents to the WG
> list.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [email protected]
>
> On Sun, May 4, 2025 at 4:36 PM Abdussalam Baryun
> <[email protected]> wrote:
> >
> > Hi Russ,
> >
> > Thanks for your email, is this review only requesting the author to
> reply, or we could reply with our part comments for WG.
> >
> > Best Regards,
> > AB
> >
> > On Sat, Apr 26, 2025 at 11:18 PM Russ White via Datatracker <
> [email protected]> wrote:
> >>
> >> Document: draft-ietf-manet-dlep-channel-utilization
> >> Title: DLEP Radio Channel Utilization Extension
> >> Reviewer: Russ White
> >> Review result: Has Nits
> >>
> >> ==
> >> They are never reseted and will just increase monotonic.
> >>
> >> Maybe:
> >>
> >> These four data items monotonically increase for entire duration of the
> >> connection; they are never reset.
>

I agree it is MAY never be reseted and NOT MUST be never reseted, the
reason is not clear, however, resetting the active channel is reasonable
for the dynamic channel interferences.

> >>
> >> ==
> >> The first Data Item (Radio Channel Active) announces ...
> >>
> >> I think (?) this would be better as a bulleted list or some such,
> rather than
> >> paragraph text.
> >>
>
ok

> >> ==
> >> ... the channels livetime of the radio channel ..
> >>
> >> I think this means something like:
> >>
> >> ... the total time this channel has been used by the radio for any
> purpose
> >> (i.e., the total amount of time the radio has transmitted on this
> channel) ...
> >>
> >> ==
> >> A radio that doesn't track the time for receiving and transmitting data
> >> explicitly can just add all times the radio channel is not free into
> the Radio
> >> Channel Busy Data Item
> >>
> >> I think this might be clearer something like:
> >>
> >> If a radio does not track its send or receive times explicitly, it
> SHOULD still
> >> calculate and advertise the Radio Channel Busy Time data item.
>

Do we use MUST or SHOULD?
the last update -02 is using MUST, which I agree also, but not sure


> >>
> >> ==
> >> The router can calculate statistics on the channel usage ...
> >>
> >> Maybe:
> >>
> >> The router can calculate channel usage statistics ...
> >>
>

to calculate channel utilization (channel usage stat) we will also need to
define/calculate the total measure time, which can be different from busy
time or active time, what do you think?



> >> ==
> >> Is there a potential need for these calculations to apply to either
> spread
> >> spectrum or beam forming systems? I suppose these calculations could be
> "per
> >> reachable neighbor" in that case, but the document doesn't say anything
> about
> >> these situations, so I thought I'd ask.
>

The DLEP is at layer 2 as specified in RFC8175 so the draft may need to
define the radio channel. Usually beamforming is with the point-to-point
links and mostly related to layer 1, but this draft is specifying the
shared medium channel calculations.

> >>
> >> ==
> >> Radio Channel Active Item contains information how long the radio
> channel has
> >> been active.
> >>
> >> The diagram is a little confusing (?) ... it seems to imply there could
> be
> >> multiple "active time" sections in the TLV. Maybe something like:
> >>
> >> 0                   1                   2                   3
> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Data Item Type                | Length                        |
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |                          Active Time                          |
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |                          ...........                          |
> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >> ...and then explain the "active time" is one field?
> >>
>

ok


> >> ==
> >> Same thing for the busy and rx data item, etc. fields.
>

ok


> >>
> >> ==
> >> Active Time: Time in nanoseconds since the channel has been active.
> >>
> >> This could be read two different ways:
> >>
> >> - How long has it been since the last transmission on this channel
> >> - The total amount of time this channel has been in use
> >>
>

Agree, so the in-active is not in-use, but is the time the radio is enabled
or it is able to be used, so we can say active or Radio-channel Enabled.

>> >From the text, the latter is what's wanted, but the text above allows
> for
> >> either. Maybe:
> >>
> >> Active Time: Time in nanoseconds this channel has been in use.
>

Don't agree, because there are some ideal time that the radio-channel is
not used but active/enabled to be used by the DLEP-modems.

>>
> >> ==
> >> ... Time in nanoseconds the local radio was receiving data ...
> >>
> >> Maybe:
> >>
> >> ... Time in nanoseconds the local radio has received data ...
>
ok


Thanks

AB

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