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

[Lou Berger <[e-mail]>]

Hi AB,

see below.


On 2/19/2018 9:19 PM, Abdussalam Baryun wrote:
> Hi Lou,
>
> I will try to clarify my concerns below, however, the main issue is 
> the question: Does the Range Latency item Cannot appear in any message 
> without Latency item?
This document doesn't make this requirement.  Per 8175, there are cases 
where the existing Latency Data Item is optional, so it is possible for 
an implementation to send the extension data item but not a latency data 
item.  This is up to the implementation.

> I prefer not, but please help me to know why if yes.
>


> On Tue, Feb 20, 2018 at 12:04 AM, Lou Berger <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>         <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> I think that Latency Range Data Item does not serve the same 
> purpose as the Latency Data Item, because by requests of the router 
> that data of Latency is used differently from Latency Range.
The text is "much the same"  - if you prefer we can change this to 
"parallel" not that this informative text not normative so no specific 
processing is implied.

>  If you agree,
I don't.  I think you are reading to much into this informative text.

> I may suggest deleting the words ''same purpose'', maybe replaced by 
> '' additional related information''. It will be good to show/add/write 
> about: the importance of range because the link may have same latency 
> but different ranges which affects performance of routing (maybe one 
> line to show that the range information is related to latency and give 
> it more meaning in terms of performance).
>
>
There is no parallel text in 8175 specifically for the latency DI so I'm 
not sure why we'd add it here.

>
>
>         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. 
>
>
> But IMO it is not clear where the Latency Range item operates within 
> 8175,
>
The draft currently says:

      The Latency Range Data Item MAY be carried in the same messages 
... as  the Latency Data Item defined in [RFC8175].

Is this not sufficient?


>  ...

>     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].
>
>
> I think it will be easier to understand, specially when we say in the 
> draft they follow same rules in 8175,
>
> so maybe better without section number,
>

sure...

> new note> the usage of the extension defined in this document does not 
> impact processing associated with the Latency Data Item.

>
>     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
>         <https://tools.ietf.org/html/rfc8175>>].
>
>
>     can you elaborate on what specific changes you'd like to see?
>
>
> AB> I mean in the draft says MAY be carried in same messages that 
> carry Latency item. I think this makes the Range item dependent some 
> how. The question is do you allow one message to carry Range item but 
> without Latency item.
yes. for example latency is optional in Session Update Message, e.g., 
this covers the case where the range changes but the base latency does 
not.  I don't see any issue with this.

> I think you don't mean that, but you mean MAY carry range item similar 
> to the messages types that MAY carry latency item.
>
>  AB> I prefer that this draft clarifies Range item independently in 
> all possible  messages as:
>
> *Session Initialization Response Message* (MUST carry)
> *Session Update Message *(MAY Carry)
> *Destination Up Message *(MAY Carry)
> *Destination Announce Response Message *(MAY Carry)
> *Destination Update Message *(MAY Carry)
> *Link Characteristics Response Message *(SHOULD carry)
> (.......may be others ,,,........)
>
>
If we had BNF in the document, I agree that the BNF would need to be 
updated.  Since we don't I think this is a bit redundant but of course 
defer to the WG on this.

> AB> also if the Latency Range is used as a metric, what is the
>
>
??

...

>         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?
>
>
> The addition maybe is what will happen when Range changes, we can say 
> it will follow similar rules in 8175 of the latency item.
>
  it says:
  The Latency Range Data Item ...  MUST be processed according to the
   same rules as the Latency Data Item defined in <xref
   target="RFC8175"/>.

Is this not sufficient?

Thanks,
Lou

>  thank for your explanation,
>
> Best Regards,
>
> AB
>
>