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

["Ratliff, Stanley" <[e-mail]>]

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


> -----Original Message-----
> From: manet [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Wednesday, November 08, 2017 10:15 AM
> To: Rick Taylor <[e-mail]>; [e-mail]
> Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-
> 01.txt
> 
> 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.
> 

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



> 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
> >
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> 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.