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

[Lou Berger <[e-mail]>]

Hi Rick,
See below

On 11/08/2017 10:02 AM, Rick Taylor wrote:
> Lou,
> 
> Comments inline...
> 
> On Wed, 2017-11-08 at 09:41 -0500, Lou Berger wrote:
>> 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).
> 
> Aah, okay.  I'm not quite sure what on earth those devices are doing,
> but is it related to different types of traffic have different
> latencies (I have kit like this)?  If this is the case, perhaps a
> single Latency per queue is a better approach than a banded latency?

I'm not the radio guy here, so can't answer for sure, but I was told a
single latency doesn't make sense only a range does and the radio will
know what the range is.  It seems to me, that it would be better to have
the radio tell the router what it knows explicitly rather than the
router having to infer it.

Lou

> 
>>
>>>
>>> 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...
> 
> Absolutely, and it would be nice to hear others opinions on this!
> 
> Cheers,
> 
> Rick
>