Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-01.txt

[Lou Berger <[e-mail]>]

Rick,

Thanks for the comments.  See below for responses in-line.

On 11/08/2017 09:18 AM, Rick Taylor wrote:
> Hi Lou, Bow-Nan.
> 
> Thanks for doing this work, but I have a concern, but it might indicate
> a lack of understanding of your intentions for this extension.
> 
> From my perspective, DLEP provides "near realtime" information about
> the state of links between destinations, so for example if the latency
> of the link changes, the updated latency metric is reported in a
> Destination Update message from modem to router.
> 
> If your intention with this draft is to supply a mechanism to allow a
> modem to report a rapidly fluctuating link latency (more than once per
> second) at a lower rate, i.e. "This link is flapping fast between X and
> Y ms" and report this every second with different X and Y, then I see
> the point (although I don't want to use that modem).
> 
> If your intention with this draft is to supply a mechanism to allow a
> modem to report a min and max latency for the link *once* (or very
> infrequently) at Destination Up, then I oppose it.  If this is the case
> I would suggest that the modem reporting Latency when it is known, and
> the router recording the min and max as it is reported is how DLEP was
> designed to be used.

My limited understanding is that certain types of radios will deliver
different latencies per frame delivered and that a single latency value
doesn't make sense for these radios.  Also this range does change based
on the state of the radio (network).

> 
> My other query, which I raised at the mic in Chicago, was why this
> extension only covers Latency.  Lou's response was that if people want
> the same functionality for a different metric, a new extension can be
> written.

Actually - my point was that unless you require an implementation to
support all metrics, the use of ranges needs to be negotiated per metric
- which means there is an extension (value) per metric.  So, to me this
means there's little value in covering all metrics here and that if
someone what's it per metric they can define it. Also give 2^16 DI types
I see little value in having a common format with two levels of parsing
it implies (DI=generic metric range, Metric Type=Metric type vs DI -
metric specific range).

I still have this opinion.  Of course, if the WG wants ranges for all
types, so be it and we'll document it as such.  I still will advocate
for a type specific DI in this case BTW.

>  I however suggest that it might be simpler to generalize the
> data item in this extension to 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 (TBD2)         | Length                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Metric Data Item Type (this DI type of the metric min/max)    :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Maximum Value                          :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                        Maximum Value (if 64bit)               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Minimum Value                          :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                        Minimum Value (if 64bit)               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The advantage of doing it this way would be that any metrics in future
> extensions could immediately have a "Min/Max" extension data item.

yes, but it's use would still need to be covered by an extension so I
still don't see a win.

something for discussion Next week...

Thanks,
Lou

> 
> Cheers,
> 
> Rick
>