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

From: Henning Rogge <[email-masked]>
Date: Wed, 8 Nov 2017 08:15:26 +0100

two nitpicks for Chapter 3:

the second sentence of the first paragraph should read

The Latency Range Item MAY be carried in the same
 messages and MUST be processed according to the same rules as the
 Latency Data Item defined in [RFC8175].

There is no "Latency Range Data Item" in RFC8175.

Second, maybe moving to nanoseconds is a good idea? The range is still
"longer than humans used radio", but we already have radios with
sub-microsecond timings I think.

Henning Rogge

On Mon, Oct 30, 2017 at 7:10 PM, Lou Berger <[email-masked]> wrote:
> Hi,
>
> This version included updated references and some minor editorial fixes.
>
> Lou (for authors)
>
>
> On 10/30/2017 2:07 PM, [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Mobile Ad-hoc Networks WG of the IETF.
>>
>>         Title           : DLEP Lantency Range Extension
>>         Authors         : Bow-Nan Cheng
>>                           Lou Berger
>>       Filename        : draft-ietf-manet-dlep-latency-extension-01.txt
>>       Pages           : 5
>>       Date            : 2017-10-30
>>
>> Abstract:
>>    This document defines an extension to the DLEP protocol to provide
>>    the range of latency that may be experienced on a link.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01
>> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-01
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-01
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Nov 2017 08:16:42 -0500

Henning,

    Thank you for the comments - please see below for in-line responses.

> There is no "Latency Range Data Item" in RFC8175.
Yes, cut-and-paste bug -- good catch!
> sub-microsecond timings I think.
I have no objections -- what do others think?

Lou

---

From: Rick Taylor <[email-masked]>
Date: Wed, 8 Nov 2017 14:18:10 +0000

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

Cheers,

Rick

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 8 Nov 2017 14:34:14 +0000

Hi Lou, all,

Also in the nitpicking department: What is "Lantency"? Latency of the LAN between router and radio, perhaps? 😝
(See I-D title).

Ronald

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
> Sent: woensdag 8 november 2017 8:15
> To: Lou Berger <[email-masked]>
> Cc: MANET IETF <[email-masked]>
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-
> 01.txt
> 
> The Latency Range Item MAY be carried in the same  messages and MUST be
> processed according to the same rules as the  Latency Data Item defined in
> [RFC8175].
> 
> "longer than humans used radio", but we already have radios with sub-
> microsecond timings I think.
> 
> Henning Rogge
> 
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Nov 2017 09:44:37 -0500

Hilarious! Thanks.
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Nov 2017 09:41:27 -0500

Rick,

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

> the router recording the min and max as it is reported is how DLEP was

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

> 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

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

---

From: Rick Taylor <[email-masked]>
Date: Wed, 8 Nov 2017 15:02:27 +0000

Lou,

Comments inline...

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

> >       |                        Maximum
> > Value                          :
> >       |                        Minimum
> > Value                          :

Absolutely, and it would be nice to hear others opinions on this!

Cheers,

Rick

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Nov 2017 10:15:08 -0500

Hi Rick,
See below

> 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

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 8 Nov 2017 21:05:42 +0000

Just pitching in my $0.02, and ruminating a little inline... 

> From: manet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Wednesday, November 08, 2017 10:15 AM
> To: Rick Taylor <[email-masked]>; [email-masked]
> >>> Thanks for doing this work, but I have a concern, but it might
> >>> indicate a lack of understanding of your intentions for this
> >>> extension.
> >>>
> >>> 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.
> >>
> >> 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).
> >
> 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.
> 

I can see a modem purposefully giving priority to certain traffic (e.g., based on DSCP encoding, or on packet size for optimal transmission, etc.) But I'm having a little difficulty (as Rick appears to be having as well) wrapping my head around the notion of a finite latency range, and what that would mean. For example, in the Satcom world, I know the current modulation used on the link to a specific remote sat terminal; I know the time plan for the burst; and I've got knowledge of how many retransmissions (at least on average) it's taking for a packet to get through.  So, I can calculate the amount of time for the physical transmission (plus average retransmit time). The remote terminal also has knowledge of how long a given frame is lying around in a transmission queue, so that can be added into the declaration of "latency". 

But what I'm not sure of is whether or not this terminal will be affected by rain fade, causing a switch in the modulation techniques used, or how long that fade will last. I could see picking some sort of "worst case scenario" for the modulation and retransmits, which would yield a kinda-sorta upper bound... And, in that scenario, also picking a "best case" (highest possible data bit/FEC bits encoding) could yield the lower bound on latency. But then I bump into the notion of "What, exactly, does this mean, and how would I use it to improve my network operation, or for SLAs, or Net management, or...?"

The original latency in RFC8175 was specified as a "running average". I can see benefit for a "running average latency PER traffic class type" on a given link, taking into consideration the additional time-in-queue for whatever prioritization is taking place. 

But as Lou and Rick have already mentioned, this is a good topic for some further discussion. 

Regards,
Stan

> >>> 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.
> >>
> >> - 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 however suggest that it might be simpler to generalize the data
> >>> item in this extension to something like:
> >>>
> >>>
> >>> 0                   1                   2                   3
> >>>       |                        Maximum Value
> >>> :
> >>>       |                        Minimum Value
> >>> :
> >>> The advantage of doing it this way would be that any metrics in
> >>> future extensions could immediately have a "Min/Max" extension data
> >>> item.
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_manet&d=DwIGaQ&c=LlUvidvlhStGUS
> xQl0giOA&r=QzgCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=jLccawMt8yqpHnqT7ELC9rdJDhFmjdK8BtGziILi4wk&s=LMLEq8u
> R6vMucA0XEBaCHBXjRxuK0OUUtJrNSmw0Rx8&e=

============================================================================================================================================
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.