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

[Abdussalam Baryun <[e-mail]>]

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? 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]> 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/r
>> fc8175>] 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. If you agree, 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).

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



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

Yes, ok, so I understand that both items can be independent, (my first read
thought they are dependent some how).


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

ok,


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

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


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








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


ok

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


ok

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

 thank for your explanation,

Best Regards,

AB

>
>