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

[Lou Berger <[e-mail]>]

Hi AB,

See below.


On 2/18/2018 6:23 PM, Abdussalam Baryun wrote:
> Hi Lou,
>
> Thanks for your updates. I am sorry that I did not comment on the 
> draft before, however, this is my thought,
>
> in section 3:
>
>  draft>The Latency Range Data Item serves much the same purpose as the
>    Latency Data Item defined in [RFC8175 
> <https://tools.ietf.org/html/rfc8175>] with the addition of being
>    able to communicate the latency range that may be experienced by
>    traffic on a link.
>
> AB> IMO, or understanding,  latency range is not one value, but two 
> values, so how can two values be same in the purpose of one value of 
> latency? maybe the draft should discuss that for clarification, 
> because I did not understand.
>

So per 8175:


    The Latency Data Item is used to indicate the amount of latency, in
    microseconds, on the link.


so  8175 defines a single point definition of "the amount of latency ... 
on the link" while this draft defines a range for latency "that may be 
experienced by traffic on a link".  Nether say how this is to be used.

I'm not sure what more is to be said on this.  Do you have an proposed 
language?

>
> AB> this draft does not say what will happen to the data item latency 
> of RFC8175 (type code 16), because in RFC8175 says such messages MUST 
> contain one value of .... and states the latency item, not the 
> latency-range. Some sections after 12.6 does not mention the 
> dlep support of such extension what will happen, so IMO this darft 
> should say how the replacement of Latency item,

it's not a replacement.  It is sent in addition.  As is generally the 
case in extension RFCs, if a modification to an existing RFC is not 
stated explicitly, there is no such modification.  I do agree that if 
the new data item were to be sent in place of the old one (a) this 
should be made very explicit and (b) this document would be an update to 
RFC8175.

see the next response
>
> AB> as this draft may need to say that if the extension is supported 
> then latency range item replaces the latency item, or it may say that 
> the maximum latency value is used into the latency item value. Not 
> sure which approach is better.

The document doesn't modify the existing latency data item.

Is it worth adding a sentence to the end of section 2 along the lines of:

Note: the usage of the extension defined in this document does not 
impact processing associated with the Latency Data Item defined in 
Section 13.6 of [rfc8175].

Seems pretty obvious, but also a benign addition
>
> AB>  My problem in understanding the draft, is that if this draft is 
> supported as mentioned in section-12.6 in the RFC8175 then it MUST be 
> contained in that message. So this needs to be said again I think in 
> this draft (because the draft now says: MAY be carry).
>
> draft>  The Latency Range Data 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 
> <https://tools.ietf.org/html/rfc8175>].
>

can you elaborate on what specific changes you'd like to see?

> AB> same rules, but we have two values, one max-latency and one 
> min-latency, please clarify,
>
It's one data item.  RFC8179 defines when and how the data item is sent, 
not how the latency value is set or used.  This is the same for the 
extension.

> AB> as mentioned above ''same rules as latency'' but what will happen 
> to this latency item while it is a MUST in many messages, what will be 
> the value, but Latency range is a MAY.
>
Correct.  An implementation MAY choose to include a Latency Range Data 
Item where it includes a Latency Data Item.

> AB> so I may suggest the value of the range for the draft's item and 
> that the latecy iten in rfc8175 contains the max-latency, or any you 
> suggest to clarify it.
>
rfc8175 latency data item is intentionally not impacted by this 
document.  It remains (per 8179)

    The calculation
    of latency is implementation dependent.  For example, the latency may
    be a running average calculated from the internal queuing.


> AB> furthermore, the RFC8175 mentions change in metrics what kind of 
> reaction, so within this draft cases, if the latency was the metric 
> what value will be used (max, avg, min,...) may need to be specified 
> in the draft.

the draft says:

    Maximum Latency:

       A 64-bit unsigned integer, representing the longest transmission
       delay, in microseconds, that a packet encounters as it is
       transmitted over the link.

    Minimum Latency:

       A 64-bit unsigned integer, representing the shortest transmission
       delay, in microseconds, that a packet encounters as it is
       transmitted over the link.

What change/addition would you like to see?

Thanks,
Lou

>
>
> Best Regards
> AB
>
>
>
> On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     This version addresses all comments received (to date) during WG
>     LC with one exception.  The one exception was a private
>     question/comment on how to handle latency that may be queue
>     specific.  As this extension is independent of queue definition
>     (which introduced in pause and credit extensions) and the same
>     question applies to other link metrics, it was my opinion that
>     queue specific metrics are beyond the scope of this draft and
>     really warrants a new extension in its own rights.  Given this was
>     raised privately during LC and not specifically addressed in this
>     version, I thought it important to mention  on list.
>
>     All other comments were discussed on list. See below for a link to
>     see these diffs.
>
>     Lou
>
>
>     On 2/14/2018 6:27 PM, [e-mail]
>     <mailto:[e-mail]> 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 Latency Range Extension
>                  Authors         : Bow-Nan Cheng
>                                    Lou Berger
>                 Filename        :
>         draft-ietf-manet-dlep-latency-extension-02.txt
>                 Pages           : 5
>                 Date            : 2018-02-14
>
>         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/
>         <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-02
>         <https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-02>
>         https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02
>         <https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-latency-extension-02>
>
>         A diff from the previous version is available at:
>         https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02
>         <https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-extension-02>
>
>
>         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 <http://tools.ietf.org>.
>
>         Internet-Drafts are also available by anonymous FTP at:
>         ftp://ftp.ietf.org/internet-drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>
>
>         _______________________________________________
>         manet mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/manet
>         <https://www.ietf.org/mailman/listinfo/manet>
>
>
>     _______________________________________________
>     manet mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/manet
>     <https://www.ietf.org/mailman/listinfo/manet>
>
>