Subject: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

From: Brian Carpenter <[email-masked]>
Date: Fri, 13 Oct 2017 21:39:51 -0700

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART *Last Call* review of draft-ietf-lime-yang-connectionless-oam-methods-09

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-lime-yang-connectionless-oam-methods-09.txt
Reviewer: Brian Carpenter
Review Date: 2017-10-14
IETF LC End Date: 2017-10-25
IESG Telechat date: 2017-10-26

Summary: Ready with issues
--------

Comment:
--------

The shepherd says:

> This includes at least two different implementations of
> the model, as well as product and demos at Bits-n-Bytes.

Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving
Awareness of Running Code: The Implementation Status Section"?

Minor Issues:
-------------

In the following:

         |  +--ro min-delay-value?         uint32
         |  +--ro max-delay-value?         uint32
         |  +--ro average-delay-value?     uint32
         +--ro session-jitter-statistics
         |  +--ro time-resolution-value?   identityref
         |  +--ro min-jitter-value?        uint32
         |  +--ro max-jitter-value?        uint32
         |  +--ro average-jitter-value?    uint32

what are the units for the delay-value and jitter-value
elements, and what definition of 'jitter' is intended?

  identity protocol-id-internet {
    base protocol-id;
    description
      "Internet Protocols.";
  }

It isn't clear what "Internet Protocols" means. It seems totally non-specific.

Nits:
-----

  identity protocol-id-propreitary {
    base protocol-id;
    description
      "Propreitary protocol (eg.,IP SLA).";

s/propreitary/proprietary/
s/Propreitary/Proprietary/

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 14 Oct 2017 13:39:16 +0000

Brian,

Thank you for your GenART review!

I will let the authors comment on and propose edits for the “units” minor issue and the nits. 

However, please find one comment inline.

> On Oct 14, 2017, at 12:39 AM, Brian Carpenter <[email-masked]> wrote:
> 

Yes!!!

Although a section in an Internet-Draft is not the most convenient way of tracking running code, it is better than none. At least, it self-contains spec and code status within a single document. As an editor I tend to add it as much as it makes sense.

As shepherd/chair for this document, unfortunately, at this stage it is too late for these document to play catch-up with another section, given that:

   Since this information is necessarily time dependent, it is
   inappropriate for inclusion in a published RFC.  The authors should
   include a note to the RFC Editor requesting that the section be
   removed before publication.

That said, I would strongly encourage you to discuss this topic and find ways to make more intentional in-the-workflow use of the “”Implementation Status”. This is a good comment but a wrong target.

Your comment starts with “Shouldn't WGs”, so this is a comment that ought to be directed to the Wg-chairs mailer, the IESG, early reviewers and Directoragtes, and other more relevant vehicles.

Thanks,

— Carlos.

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Oct 2017 11:52:23 +0000

Thank Brian for valuable review to this document, please see my reply below.

-Qin
-----邮件原件-----
发件人: Brian Carpenter [mailto:[email-masked]] 
发送时间: 2017年10月14日 12:40
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Comment:
--------

The shepherd says:

> This includes at least two different implementations of the model, as 
> well as product and demos at Bits-n-Bytes.

Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving Awareness of Running Code: The Implementation Status Section"?

Minor Issues:
-------------

In the following:

what are the units for the delay-value and jitter-value elements, and what definition of 'jitter' is intended?

[Qin]: Delay supports various time units such as s,ms,ns and etc.
To represent this using YANG construct, we introduce a new parameter time-resolution-value as follows:
   |     +--ro session-delay-statistics
   |     |  +--ro time-resolution-value?   identityref
   |     |  +--ro min-delay-value?         uint32
   |     |  +--ro max-delay-value?         uint32
   |     |  +--ro average-delay-value?     uint32
With this time-resolution-value parameter, we can support various different time unit.
The same is applied to jitter. As clarified in the introduction, the definition of 'jitter' is used to 
monitor reachability of destinations, troubleshoot failures, monitor performance.

[Qin]: It is referred to a standard protocol (e.g., TCP/IP protocols, ICMP, IGMP,etc.,)
We can make this clear by adding a few clarification text in the description of protocol-id-internet.
Nits:
-----

[Qin]: Thanks and will get this fixed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Oct 2017 08:20:22 +1300

Qin,

Thanks for the reply, I have follow-up questions in line:

> Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving Awareness of Running Code: The Implementation Status Section"?

OK, because of my poor understanding of YANG, I still have to ask where
the possible values of time-resolution-value are defined. Is there
an enumeration somewhere that I have missed?

> monitor reachability of destinations, troubleshoot failures, monitor performance.

Yes, but what *is* jitter physically? There is no scientific definition of
'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something
else?

I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that seems
straightforward,  and so do the other metrics used in session-packet-statistics
and session-error-statistics.

Regards
    Brian

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Oct 2017 01:40:02 +0000

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2017年10月17日 3:20
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Qin,

On 17/10/2017 00:52, Qin Wu wrote:
> 主题: Genart telechat review of 
> draft-ietf-lime-yang-connectionless-oam-methods-09
> 
> Gen-ART *Last Call* review of 
> draft-ietf-lime-yang-connectionless-oam-methods-09
> 

OK, because of my poor understanding of YANG, I still have to ask where the possible values of time-resolution-value are defined. Is there an enumeration somewhere that I have missed?

[Qin]:Instead of using enum, we are using identity to define possible values of time-resolution-value
"
  identity time-resolution {
    description
      "Time interval resolution";
  }
  identity seconds {
    base time-resolution;
    description
      "Time resolution in Seconds";
  }
  identity milliseconds {
    base time-resolution;
    description
      "Time resolution in Milliseconds";
  }
  identity microseconds {
    base time-resolution;
    description
      "Time resolution in Microseconds";
"
And then we can use identityref to refer to these values of time-resolution values we have actually defined.

> The same is applied to jitter. As clarified in the introduction, the 
> definition of 'jitter' is used to monitor reachability of destinations, troubleshoot failures, monitor performance.

Yes, but what *is* jitter physically? There is no scientific definition of 'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something else?

[Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). You are right, one typical example of packet jitter is IPDV defined in RFC3393, but we don't want to limit it to IPDV, we also allow support other protocol and other measurement methodology,
e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what protocol is used and what methodology is used can be indicated by the parameter 'protocol-id' parameter and 'protocol-id-meta-data' in this model.

I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that seems straightforward,  and so do the other metrics used in session-packet-statistics and session-error-statistics.

[Qin]: Correct, it is one way delay instead of two way delay. Yes, the same is applied to session-packet-statistics and session-error-statistics.

Regards
    Brian

> [Qin]: It is referred to a standard protocol (e.g., TCP/IP protocols, 
> ICMP, IGMP,etc.,) We can make this clear by adding a few clarification text in the description of protocol-id-internet.
> Nits:
> -----
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Oct 2017 04:11:02 -0700

Hi Qin, et. al,
IEEE 1588-2008 in section 5.3.2 defines the TimeInterval type that
represents time interval as

struct TimeInterval
{

Integer64 scaledNanoseconds;

};
The scaledNanoseconds member is the time interval expressed in units of
nanoseconds and multiplied by
2+16.
Positive or negative time intervals outside the maximum range of this data
type shall be encoded as the
largest positive and negative values of the data type, respectively.
For example, 2.5 ns is expressed as 0000 0000 0002 800016.

TICTOC WG is discussing proposed PTP YANG model which includes

     typedef time-interval-type {
       type int64;
       description
         "Derived data type for time interval,
         represented in units of nanoseconds and
         multipled by 2^16";
       reference
         "IEEE Std 1588-2008: 5.3.2";
     }

Would the it be re-usable in LIME?

Regards,
Greg

On Mon, Oct 16, 2017 at 6:40 PM, Qin Wu <[email-masked]> wrote:

> Review Team (Gen-ART) reviews all IETF documents being processed by the
> IESG for the IETF Chair.  Please treat these comments just like any other
> last call comments.
> >
> > Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving Awareness
> of Running Code: The Implementation Status Section"?
> >
> > Minor Issues:
> > -------------
> >
> > In the following:
> >
> the possible values of time-resolution-value are defined. Is there an
> enumeration somewhere that I have missed?
>
> And then we can use identityref to refer to these values of
> time-resolution values we have actually defined.
>
> > definition of 'jitter' is used to monitor reachability of destinations,
> troubleshoot failures, monitor performance.
>
> [Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). You
> are right, one typical example of packet jitter is IPDV defined in RFC3393,
> but we don't want to limit it to IPDV, we also allow support other protocol
> and other measurement methodology,
> e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what
> protocol is used and what methodology is used can be indicated by the
> parameter 'protocol-id' parameter and 'protocol-id-meta-data' in this model.
>
> I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that
> seems straightforward,  and so do the other metrics used in
> session-packet-statistics and session-error-statistics.
>
> [Qin]: Correct, it is one way delay instead of two way delay. Yes, the
> same is applied to session-packet-statistics and session-error-statistics.
>
> Regards
>     Brian
>
> >
> > ICMP, IGMP,etc.,) We can make this clear by adding a few clarification
> text in the description of protocol-id-internet.
> > Nits:
> > -----
> >
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Oct 2017 08:26:29 +1300

On 17/10/2017 14:40, Qin Wu wrote:
...

> e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what protocol is used and what methodology is used can be indicated by the parameter 'protocol-id' parameter and 'protocol-id-m…

I don't see how this specification can be used for interoperable
implementations unless you define a specific meaning of 'jitter'.
If the network management system assumes RFC3393 but half the
routers in the network implement G.1020, there is no interoperability.

> [Qin]: Correct, it is one way delay instead of two way delay. 

Again - it is useful to specify one-way delay, for interoperability.
(Whether the routers can measure one-way delay is another question;
they might be forced to measure RTT and assume delay = RTT/2 .)

Regards
    Brian

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Oct 2017 01:09:39 +0000

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2017年10月19日 3:26
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; [email-masked]
主题: Re: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

> [Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). 
> You are right, one typical example of packet jitter is IPDV defined in RFC3393, but we don't want to limit it to IPDV, we also allow support other protocol and other measurement methodology, e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what protocol is used and what methodology is used can be indicated by the parameter 'protocol-id' parameter and 'protocol-id-meta-data' in this model.

I don't see how this specification can be used for interoperable implementations unless you define a specific meaning of 'jitter'.

If the network management system assumes RFC3393 but half the routers in the network implement G.1020, there is no interoperability.

[Qin]: Correct, Just to clarify, it is not our intent to encourage implementer to support various different mechanisms to measure jitter in one single solution.
In one single solution, we will restrict to use one mechanism, one protocol to measure jitter, but flexibility we allow here, you might choose different time units,
But again we might only allow one time unit in one single solution, introduce protocol-id parameter is used to allow future protocol and future mechanism to be created then we support different mechanism to measure 
Jitter with different time unit.

Again - it is useful to specify one-way delay, for interoperability.
(Whether the routers can measure one-way delay is another question; they might be forced to measure RTT and assume delay = RTT/2 .)

[Qin]: Agree, have a second thought, I think with protocol-id, we can decide which kind of delay we are meant to use? E.g.,if protocol-id is set to OWAMP defined in RFC4656, we will use one way delay, if protocol-id is set to TWAMP defined in RFC5357,We will use round trip delay, we allow such flexibility, I might be wrong, since earlier, I claim we only support one way delay, I need to confirm this from other authors.

Regards
    Brian

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Oct 2017 08:38:20 +0000

Thanks Greg, As I said, Delay supports various time units which include Nanoseconds. Nanosecond time unit has been supported by using identity in connectionless-oam-method model
“
  identity seconds {
    base time-resolution;
    description
      "Time resolution in Seconds";
  }
  identity milliseconds {
    base time-resolution;
    description
      "Time resolution in Milliseconds";
  }
  identity microseconds {
    base time-resolution;
    description
      "Time resolution in Microseconds";
  }
identity nanoseconds {
    base time-resolution;
    description
      "Time resolution in Nanoseconds";
  }
”
Thanks!

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年10月18日 19:11
收件人: Qin Wu
抄送: Brian E Carpenter; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Hi Qin, et. al,
IEEE 1588-2008 in section 5.3.2 defines the TimeInterval type that represents time interval as
struct TimeInterval
{
Integer64 scaledNanoseconds;
};
The scaledNanoseconds member is the time interval expressed in units of nanoseconds and multiplied by
2+16.
Positive or negative time intervals outside the maximum range of this data type shall be encoded as the
largest positive and negative values of the data type, respectively.
For example, 2.5 ns is expressed as 0000 0000 0002 800016.

       type int64;

       description

         multipled by 2^16";

       reference

     }

Regards,
Greg

On Mon, Oct 16, 2017 at 6:40 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年10月17日 3:20
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Qin,

On 17/10/2017 00:52, Qin Wu wrote:
> 发件人: Brian Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
> 发送时间: 2017年10月14日 12:40
> 收件人: [email-masked]<mailto:[email-masked]>
> 抄送: [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>

Regards
    Brian

_______________________________________________
Lime mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 25 Oct 2017 11:16:30 -0400

Brian, thank you for your review. Qin, thanks for your responses. I have entered a No Objection ballot that captures the remaining open issue concerning one-way vs. two-way delay. One further comment below.

> On Oct 18, 2017, at 9:09 PM, Qin Wu <[email-masked]> wrote:
> 
> -----邮件原件-----

I believe this is well-specified in draft-ietf-lime-yang-connectionless-oam:

grouping session-jitter-statistics {
    description
      "Grouping for per session jitter statistics";
    container session-jitter-statistics {
      description
        "Session jitter summarised information. By default,
         jitter is measured using IP Packet Delay Variation
         (IPDV) as defined in RFC3393 <https://tools.ietf.org/html/rfc3393>. When the other measurement
         method is used instead(e.g., Packet Delay Variation used in
         Y.1540, it can be indicated using protocol-id-meta-data
         defined in RPC operation of
         draft-ietf-lime-yang-connectionless-oam-methods <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-methods>. Note that
         only one measurement method for jitter is specified
         for interoperability reason.";

Alissa

> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 25 Oct 2017 11:21:01 -0400

> On Oct 19, 2017, at 4:38 AM, Qin Wu <[email-masked]> wrote:
> 

Qin, although you use the term “time-resolution” above, it does not appear in the LIME YANG models. The term in the models appears to be time-interval-type.

I sense that this might be confusing (based on Greg’s message) because what is actually being defined by time-interval-type is the unit of measurement (e.g., ns, ms, s). I realize that in a sense this is an interval, but it might be clearer if the type were called time-unit-type. If I’m understanding it properly, then the definition that Greg is pointing to in the TICTOC doc is for something different (i.e., an actual interval, always measured in nanoseconds).

But it’s also possible that I’m the one who is confused ...

Alissa

> Thanks!
>  
> -Qin
> 发件人: Greg Mirsky [mailto:[email-masked] <mailto:[email-masked]>] 
> 发送时间: 2017年10月18日 19:11
> 收件人: Qin Wu
> 抄送: Brian E Carpenter; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Mon, Oct 16, 2017 at 6:40 PM, Qin Wu <[email-masked] <mailto:[email-masked]>> wrote:
> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:[email-masked] <mailto:[email-masked]>]
> 发送时间: 2017年10月17日 3:20
> 收件人: Qin Wu; [email-masked] <mailto:[email-masked]>
> 抄送: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > 发件人: Brian Carpenter [mailto:[email-masked] <mailto:[email-masked]>]
> > 发送时间: 2017年10月14日 12:40
> > 收件人: [email-masked] <mailto:[email-masked]>
> > 抄送: [email-masked] <mailto:[email-masked]>;
> > [email-masked] <mailto:[email-masked]>
> > For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.
> >
> [Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter <https://en.wikipedia.org/wiki/Jitter>). You are right, one typical example of packet jitter is IPDV defined in RFC3393, but we don't want to limit it to IPDV, we also allow support other protocol and other measurement methodology,
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lime <https://www.ietf.org/mailman/listinfo/lime>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Oct 2017 08:23:11 +1300

A small response in line below:

> I believe this is well-specified in draft-ietf-lime-yang-connectionless-oam:

Yes. Maybe it would help to mention in the Introduction of ietf-lime-yang-connectionless-oam-methods that some elements of the data model are fully defined in ietf-lime-yang-connectionless-oam. The current text says "It is separated from the generic YANG model for connectionless OAM" but does not tell the reader to go and read the generic model!

    Brian

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Oct 2017 00:58:22 +0000

发件人: Alissa Cooper [mailto:[email-masked]]
发送时间: 2017年10月25日 23:21
收件人: Qin Wu
抄送: Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Gen-art] [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

On Oct 19, 2017, at 4:38 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

[Qin]: I agree with you the name “time-interval-type” is confusing which I was struggling as well when I posted  v-(10).
You are correct, we should change it to “time-unit-type”, I will fix this in the new version. Thanks for catching this.

Alissa

Thanks!

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年10月18日 19:11
收件人: Qin Wu
抄送: Brian E Carpenter; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Hi Qin, et. al,

       type int64;

       description

         multipled by 2^16";

       reference

     }

Regards,
Greg

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年10月17日 3:20
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Qin,

Regards
    Brian

_______________________________________________
Gen-art mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Oct 2017 07:03:29 +0000

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[email-masked]] 
发送时间: 2017年10月26日 3:23
收件人: Alissa Cooper; Qin Wu
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

On 26/10/2017 04:16, Alissa Cooper wrote:
>> 主题: Re: Genart telechat review of 
>>>> The same is applied to jitter. As clarified in the introduction, 
>>>> the definition of 'jitter' is used to monitor reachability of destinations, troubleshoot failures, monitor performance.
>>>

[Qin]: Good suggestion, we will consider this. Thanks.

    Brian

>> In one single solution, we will restrict to use one mechanism, one 
>> protocol to measure jitter, but flexibility we allow here, you might 
>> choose different time units, But again we might only allow one time unit in one single solution, introduce protocol-id parameter is used to allow future protocol and future mechanism to be created then we support different mechanism to measure Jitter with different time unit.
>>