Subject: [lmap] Timer: Poisson distribution question

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sat, 19 Apr 2014 19:23:33 +0000

Team,

The BBF is looking at standardizing the model for Timers as suggested by the IETF LMAP information model.

During the review of the timers we had addition questions regarding Trevors response to the Poisson distribution for the Randomness of the Periodic Timer.

Trevor responded:

"Yes this does need to be clarified. I was assuming a distribution about the mean (i.e. the timing given is the mean). The spread would be the standard deviation (could use mean deviation or something else but I see no advantage as long as we all know what it refers to) and need to change to a float. The upper and lower cuts would be in seconds +/- the mean (also needs to change to float) and are simply used to trim the function - obviously needed on a uniform distribution but useful to constrain other functions.

I will make all this clear in the next release.

As for poisson I think there are 3 options:

-          Use a continuous form instead

-          Have the discrete interval implicit in the function choice e.g."poisson_1_sec"

-          Add an interval to the information model.

I was really thinking about the first, but I don't see the problem with the second. However I wouldn't do the third unless they was a demonstrable value to supporting discrete functions (rather than continuous versions of them).
 "

But as people looked at Trevors response there were additional questions:

I don't understand what Trevor means about the Poisson distribution.  As far as I know, it is a discrete distribution, so a "continuous form" would be a different distribution and not Poisson.  And I believe that we do need a continuous distribution.  But what matters is that the definition is clear, not the particular distribution (I don't have an opinion on that).

Could some please clarify this for us - Are we planning something other than Poisson method; better yet is there a definition for the types of distribution:
Poisson, Normal and Uniform.

Thanks,
Tim

---

From: <[email-masked]>
Date: Tue, 22 Apr 2014 09:35:03 +0100

On continuous counterparts of Poisson I'm far from any expert and it would certainly be up to the user to decide if such functions were suitable replacements for the discrete Poisson function. Yes it would be a different function even if there was perfect fit (which they are not) as one is continuous and one is discrete:
http://cmscience.blogspot.co.uk/2008/04/mt-6-poisson-and-gamma-distribution.html
http://arxiv.org/abs/1303.5990

As I tried to say the current Information Model can take either discrete or continuous functions - only that there is currently no explicit support for specifying the interval used for a discrete function. I was questioning the need to add this.

Personally I'd think that Normal and Uniform distributions would cover most needs, but the framework should be flexible in this regard.

Trevor.

From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy (Timothy)
Sent: 19 April 2014 20:24
To: [email-masked]
Subject: [lmap] Timer: Poisson distribution question

Team,

Trevor responded:

Thanks,
Tim

---

From: Sharam Hakimi <[email-masked]>
Date: Tue, 22 Apr 2014 13:22:58 +0000

Tim,
I think the Periodic Timer distribution needs to have closer configuration control by the user and I think your 2nd  choice attempts to provide it but having a discrete interval definition is a better way to go.

Sharam

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 22, 2014 4:35 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 22 Apr 2014 19:16:02 +0000

Trevor,

The data model is extensible by vendors so we can add functions and input variables as we need.

However we have to decide on which small subset we actually want to standardize.

You suggested the Uniform and Normal which is fine but for the model we need to go farther by defining the specific function along with which inputs are used by the function to derive what random number. Otherwise we will have 2 implementers of the same standard algorithm implement different variations. - Not good.

So I suggest we keep this simple.

Uniform Discrete - input variables - maximum [positive integer]
Gaussian -input variables - mean of min/max, spread = standard deviation

The min/max would be milliseconds - Spread would be an integer.

This sound OK?

BR
Tim

From: Sharam Hakimi [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 8:23 AM
To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Tim,

Sharam

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, April 22, 2014 4:35 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Timer: Poisson distribution question

Trevor.

From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy (Timothy)
Sent: 19 April 2014 20:24
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] Timer: Poisson distribution question

Team,

Trevor responded:

Thanks,
Tim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 22 Apr 2014 16:22:28 -0400

Both the examples in the framework draft use Uniform,
http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-2
we're just trying to avoid strict periodicity -
let's keep it simple (to specify, to generate...).
Al

From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy (Timothy)
Sent: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: Sharam Hakimi <[email-masked]>
Date: Tue, 22 Apr 2014 20:59:11 +0000

Tim,
I think the min/max should have microseconds granularity. Milliseconds would not be accurate enough.

Personally, I would not trust my periodic tests in a large scale deployment to a random number generator and would want to know exactly how and when tests would be run.

Thanks,
Sharam

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 22 Apr 2014 21:07:11 +0000

Sharam,

We are talking about offsets for when to report; in the world we live in milliseconds is sufficient - IMHO.

From: Sharam Hakimi [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 3:59 PM
To: Carey, Timothy (Timothy); [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 22 Apr 2014 21:16:19 +0000

Al,

*  Normal (The Gaussian distribution function)
*  Uniform-Discrete (The Uniform.Discrete distribution function)
*  Uniform-Continuous (The Uniform.Continuous distribution function) - This was your uniform(0,180)

I was able to define fairly simply these functions in the data models.

What do you think?

BR,
Tim

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 3:22 PM
To: Carey, Timothy (Timothy); Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 22 Apr 2014 17:25:20 -0400

Hi Tim,
ultimately, the scheduling resolution will render a continuous function
discrete to some degree, right?
seems like Uniform-discrete would do it, match the resolutions if possible..
Al

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 5:16 PM
To: MORTON, ALFRED C (AL); Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Al,

What do you think?

BR,
Tim

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 3:22 PM
To: Carey, Timothy (Timothy); Sharam Hakimi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy (Timothy)
Sent: Tuesday, April 22, 2014 3:16 PM
To: Sharam Hakimi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Timer: Poisson distribution question

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 22 Apr 2014 21:33:25 +0000

Al,

Yes I think so - I am no expert on these functions but from what I understand the Discrete function only takes an upper limit; the continuous takes a lower and upper.

BR,
Tim

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 4:25 PM
To: Carey, Timothy (Timothy); Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Hi Tim,

Al,

What do you think?

BR,
Tim

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 22 Apr 2014 18:04:24 -0400

probably assumes LL = zero then, there have to be two limits.

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Al,

BR,
Tim

Hi Tim,

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 5:16 PM
To: MORTON, ALFRED C (AL); Sharam Hakimi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Al,

What do you think?

BR,
Tim

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 08:54:57 +0100

The random timing can be used for both specifying when a test runs, or when a report is sent (or any other task such as contacting the Controller). It doesn't have to be used, but it can be.

I don't really want different input variable for different functions. I don't see we need to. Also if we do, then we would have to have schema for each function to specify which inputs are expected (like the measurement task registry). I'd like to avoid that.

Trevor.

Trevor Burbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: 22 April 2014 22:07
To: Sharam Hakimi; [email-masked]; Burbridge,T,Trevor,TUB8 R
Subject: RE: Timer: Poisson distribution question

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 23 Apr 2014 11:59:24 +0000

Marc,

Thanks for the comments; I agree that microseconds is too small for this; milliseconds would be the smallest increment I could ever envision but I have no issue with seconds as well. I will leave it to consensus from the group.

-----Original Message-----
From: marc.ibrahim [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 3:24 AM
To: [email-masked]; Carey, Timothy (Timothy); [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

Hello,

In my opinion, if the random timing aims at spreading the load at controller/collector, 
uniform random timing is the only needed. 
It is a kind of backoff timer to avoid simultaneous events. So no need for other than 
uniform distribution.

Also I think that microseconds and milliseconds are too small compared to measurement 
duration or transmitting time of a report. For example, If we don't want 10 MAs to 
report simultaneously, the scale of seconds have to be used to avoid simultaneous 
connections to collector.

BR,

__________________________________
Marc Ibrahim
Assistant Professor, Engineering Faculty
Saint-Joseph University (USJ), Lebanon,
_________________________________

On Wed, 23 Apr 2014 08:54:57 +0100, trevor.burbridge wrote
> The random timing can be used for both specifying when a test runs, or when a 
> report is sent (or any other task such as contacting the Controller). It 
> doesn't have to be used, but it can be.
> 
> I don't really want different input variable for different functions. I don't 
> see we need to. Also if we do, then we would have to have schema for each 
> function to specify which inputs are expected (like the measurement task 
> registry). I'd like to avoid that.
> 
> Trevor.
> 
> Trevor Burbridge
> This email contains BT information, which may be privileged or confidential. 
> It's meant only for the individual(s) or entity named above. If you're not the 
> intended recipient, note that disclosing, copying, distributing or using this 
> information is prohibited. If you've received this email in error, please let 
> me know immediately on the email address above. Thank you. We monitor our 
> email system, and may record your emails. British Telecommunications plc 
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 
> 1800000
> 
> To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>; 
[email-masked]<mailto:[email-masked]>
> Personally, I would not trust my periodic tests in a large scale deployment to 
> a random number generator and would want to know exactly how and when tests 
> would be run.
> 
> Thanks,
> Sharam
> 
> To: Sharam Hakimi; [email-masked]<mailto:[email-masked]>; 
[email-masked]<mailto:[email-masked]>
> You suggested the Uniform and Normal which is fine but for the model we need 
> to go farther by defining the specific function along with which inputs are 
> used by the function to derive what random number. Otherwise we will have 2 
> implementers of the same standard algorithm implement different variations. -
>  Not good.
> 
> To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>; 
[email-masked]<mailto:[email-masked]>
> I think the Periodic Timer distribution needs to have closer configuration 
> control by the user and I think your 2nd  choice attempts to provide it but 
> having a discrete interval definition is a better way to go.
> 
> Sharam
> 
> From: lmap [mailto:[email-masked]] On Behalf Of 
[email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; 
> [email-masked]<mailto:[email-masked]> Subject: Re: [lmap] Timer: Poisson 
> distribution question
> 
> On continuous counterparts of Poisson I'm far from any expert and it would 
> certainly be up to the user to decide if such functions were suitable 
> replacements for the discrete Poisson function. Yes it would be a different 
> function even if there was perfect fit (which they are not) as one is 
> continuous and one is discrete: http://cmscience.blogspot.co.uk/2008/04/mt-6-
> poisson-and-gamma-distribution.html http://arxiv.org/abs/1303.5990
> 
> As I tried to say the current Information Model can take either discrete or 
> continuous functions - only that there is currently no explicit support for 
> specifying the interval used for a discrete function. I was questioning the 
> need to add this.
> 
> Personally I'd think that Normal and Uniform distributions would cover most 
> needs, but the framework should be flexible in this regard.
> 
> Trevor.
> 
> During the review of the timers we had addition questions regarding Trevors 
> response to the Poisson distribution for the Randomness of the Periodic Timer.
> 
> Trevor responded:
> 
> "Yes this does need to be clarified. I was assuming a distribution about the 
> mean (i.e. the timing given is the mean). The spread would be the standard 
> deviation (could use mean deviation or something else but I see no advantage 
> as long as we all know what it refers to) and need to change to a float. The 
> upper and lower cuts would be in seconds +/- the mean (also needs to change to 
> float) and are simply used to trim the function - obviously needed on a 
> uniform distribution but useful to constrain other functions.
> 
> I was really thinking about the first, but I don't see the problem with the 
> second. However I wouldn't do the third unless they was a demonstrable value 
> to supporting discrete functions (rather than continuous versions of them). "
> 
> I don't understand what Trevor means about the Poisson distribution.  As far 
> as I know, it is a discrete distribution, so a "continuous form" would be a 
> different distribution and not Poisson.  And I believe that we do need a 
> continuous distribution.  But what matters is that the definition is clear,
>  not the particular distribution (I don't have an opinion on that).
> 
> Could some please clarify this for us - Are we planning something other than 
> Poisson method; better yet is there a definition for the types of 
> distribution: Poisson, Normal and Uniform.
> 
> Thanks,
> Tim

--
Open WebMail Project (http://openwebmail.org)

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 23 Apr 2014 12:03:30 +0000

Trevor,

If we don't define the inputs for each function (leaving the inputs opaque) you will have interop problems.
MA vendor 1 uses these 2 inputs named "A" and "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the same function.

I think we need to avoid that if we realistically want the Randomness function to be used efficiently.

BR,
Tim

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 2:55 AM
To: Carey, Timothy (Timothy); [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 23 Apr 2014 12:14:03 +0000

I do not see why vendor A or B or C matters. They would all be under the control of one Measurement Controller which would specify what inputs to use for all MAs in a group.

As Trevor also mentioned this timer can be used for both testing and reporting and I would strongly suggest to have microsecond granularity. For reporting one could choose seconds in terms of microseconds.

Thanks,
Sharam

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:04 AM
To: [email-masked]; Sharam Hakimi; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 23 Apr 2014 12:15:34 +0000

So the burden is on the Measurement controller to know the functions and inputs specifications for each possible MA vendor; not something I would want to have to do as a Measurement controller vendor.

From: Sharam Hakimi [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 7:14 AM
To: Carey, Timothy (Timothy); [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 23 Apr 2014 12:24:06 +0000

The measurement controller has to communicate what tests have to be run on an MA, for how long, when to run them, what test results are generated, etc. Why would configuring this parameter be any different. Maybe I am missing something.

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:16 AM
To: Sharam Hakimi; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 23 Apr 2014 12:36:01 +0000

Its not that the Measurement controller has to configure the timer for the MA.

If we do not specify the functions and variable names, the measurement controller doesn't have a standard way of configuring a timer.

For example - If I specify for a Uniform distribution function called "Uniform" you have a  variable called "UpperLimit", the MA will implement the specification; the controller will implement the specification and things work.

If I do not specify anything for the Uniform distribution function - MA vendor 1 can call it "UniformDF" and "UL - which is typed real" and maybe an "Enable" parameter for good measure; MA vendor 2 can call it "U" and have an attribute "X that is an integer".

Now put that variation on steroids based on the number of MA vendors - That is why we specify things, right?

BR,
Tim

From: Sharam Hakimi [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 7:24 AM
To: Carey, Timothy (Timothy); [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 13:38:32 +0100

Let me make it clear that I agree. What I tried to say was that every function should have the SAME inputs - e.g. upper/lower cuts, spread, mean (interval for discrete functions?).

Trevor.

Trevor Burbridge

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: 23 April 2014 13:16
To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; [email-masked]
Subject: RE: Timer: Poisson distribution question

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 13:40:45 +0100

Agree we need to have well defined function names. I thought you were also suggesting different functions needed different input parameters.

Trevor.

Trevor Burbridge

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: 23 April 2014 13:36
To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; [email-masked]
Subject: RE: Timer: Poisson distribution question

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 23 Apr 2014 08:47:23 -0400

It seems as though a good part of this exchange has been skipped-over,
Tim and I clarified a lot of this last night...

One function will do, discrete Uniform seems to meet the need.

Al

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 23, 2014 8:41 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

Trevor.

Trevor Burbridge

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: 23 April 2014 13:36
To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

BR,
Tim

From: Sharam Hakimi [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 7:24 AM
To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:16 AM
To: Sharam Hakimi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

From: Sharam Hakimi [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 7:14 AM
To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Thanks,
Sharam

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:04 AM
To: [email-masked]<mailto:[email-masked]>; Sharam Hakimi; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Trevor,

BR,
Tim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 2:55 AM
To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Trevor.

Trevor Burbridge

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: 22 April 2014 22:07
To: Sharam Hakimi; [email-masked]<mailto:[email-masked]>; Burbridge,T,Trevor,TUB8 R
Subject: RE: Timer: Poisson distribution question

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 23 Apr 2014 12:47:23 +0000

Trevor,

No - I am using the variable of your Information Model (LowerLimit, UpperLimit, Spread) - works so far.
Marc suggested a TimeStep parameter so we don't lockin on a specific microsecond, millisecond, second thing - I am open to that.

BR,
Tim

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 7:41 AM
To: Carey, Timothy (Timothy); [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor.

Trevor Burbridge

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 23 Apr 2014 12:57:37 +0000

Marc's suggestion works for me. That allows better interoperability in my opinion.

I do agree that we need a common "structure" and "names".

Thanks,
Sharam

From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:47 AM
To: [email-masked]; Sharam Hakimi; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 13:58:44 +0100

Good to be dragged back to requirements.

Certainly uniform would be the single function of choice for any load balancing requirement - you want uniform peak load either on the test points or on the reporting system. If you want to test at a single point in time, uniform distribution gives you the minimum spread of time without exceeding the peak allowable load.

I could _maybe_ make an argument for a normal distribution. That you want the bulk of tests at a certain time, but want a reduced volume of outlier tests to say something about how the results look either side of that time.

I wouldn't be unhappy about either:

-        Assuming function is uniform

-        Allowing multiple functions but only currently defining uniform. Of course uniform doesn't need a 'spread' parameter, just upper/lower cuts so would probably want an eye to the future

Trevor.

Trevor Burbridge

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: 23 April 2014 13:47
To: Burbridge,T,Trevor,TUB8 R; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Al

Trevor.

Trevor Burbridge

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 14:03:40 +0100

I'm not sure I get the point of allowing coarser granularity that the MA is capable of. If I want the MA to test/report sometime within a minute window, why not allow that to happen with the maximum resolution the MA is capable of?

Trevor.

Trevor Burbridge

From: lmap [mailto:[email-masked]] On Behalf Of Sharam Hakimi
Sent: 23 April 2014 13:58
To: Carey, Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 14:13:34 +0100

So what is the argument for the latter (discrete) option?

Trevor.

>Sent: 23 April 2014 14:10
>To: Burbridge,T,Trevor,TUB8 R; [email-masked];
>[email-masked]; [email-masked]
>Trevor, you're right.
>it is just about whether we want a discrete or continuous generator.
>If we use a continuous uniform generator, than it is enough to specify the
>maximum time.
>With a discrete random generator, you need to specify an additional time
>granularity.
>
>BR,
>
>Marc.
>
>
>On Wed, 23 Apr 2014 14:03:40 +0100, trevor.burbridge wrote
>> I'm not sure I get the point of allowing coarser granularity that the MA is
>> capable of. If I want the MA to test/report sometime within a minute window,
>> why not allow that to happen with the maximum resolution the MA is capable
>of?
>>
>> Trevor.
>>
>> Trevor Burbridge
>> To: [email-masked]<mailto:[email-masked]>; Sharam
>Hakimi;
>[email-masked]<mailto:[email-masked]>
>> No - I am using the variable of your Information Model (LowerLimit,
>UpperLimit,
>>  Spread) - works so far. Marc suggested a TimeStep parameter so we don't
>> lockin on a specific microsecond, millisecond, second thing - I am open to that.
>>
>> BR,
>> Tim
>>
>> To: Carey, Timothy (Timothy);
>> [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> Agree we need to have well defined function names. I thought you were also
>> suggesting different functions needed different input parameters.
>>
>> Trevor.
>>
>> Trevor Burbridge
>> If we do not specify the functions and variable names, the measurement
>> controller doesn't have a standard way of configuring a timer.
>>
>> For example - If I specify for a Uniform distribution function called
>> "Uniform" you have a  variable called "UpperLimit", the MA will implement the
>> specification; the controller will implement the specification and things work.
>>
>> If I do not specify anything for the Uniform distribution function - MA vendor
>> 1 can call it "UniformDF" and "UL - which is typed real" and maybe an "Enable"
>> parameter for good measure; MA vendor 2 can call it "U" and have an attribute
>> "X that is an integer".
>>
>> To: Carey, Timothy (Timothy);
>> [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> The measurement controller has to communicate what tests have to be run on
>an
>> MA, for how long, when to run them, what test results are generated, etc. Why
>> would configuring this parameter be any different. Maybe I am missing
>something.
>>
>> To: Sharam Hakimi;
>[email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> So the burden is on the Measurement controller to know the functions and
>> inputs specifications for each possible MA vendor; not something I would want
>> to have to do as a Measurement controller vendor.
>>
>> To: Carey, Timothy (Timothy);
>> [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> I do not see why vendor A or B or C matters. They would all be under the
>> control of one Measurement Controller which would specify what inputs to use
>> for all MAs in a group.
>>
>> As Trevor also mentioned this timer can be used for both testing and reporting
>> and I would strongly suggest to have microsecond granularity. For reporting
>> one could choose seconds in terms of microseconds.
>>
>> Thanks,
>> Sharam
>>
>> To: [email-masked]<mailto:[email-masked]>; Sharam
>Hakimi;
>[email-masked]<mailto:[email-masked]>
>> If we don't define the inputs for each function (leaving the inputs opaque)
>>  you will have interop problems. MA vendor 1 uses these 2 inputs named "A"
>and
>> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the same function.
>>
>> To: Carey, Timothy (Timothy);
>> [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>> To: Sharam Hakimi; [email-masked]<mailto:[email-masked]>; Burbridge,T,Trevor,
>> TUB8 R Subject: RE: Timer: Poisson distribution question
>>
>> Sharam,
>>

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 23 Apr 2014 13:15:06 +0000

I would suggest "Immediate" an  option to allow for reporting after completion of a test. This would not need any parameters as the results would be sent after completion of a test. Sometime it is necessary to be able to diagnose situations based on the results, and combined results sent at later times do not allow for that. Again, That would be centrally managed through the Management controller.

Sharam

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:59 AM
To: [email-masked]; [email-masked]; Sharam Hakimi; [email-masked]
Subject: RE: Timer: Poisson distribution question

Trevor.

Trevor Burbridge

Al

Trevor.

Trevor Burbridge

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 14:17:40 +0100

Yes we allow for 'immediate' but we were talking about the random distributions that can be applied to the various timing options (immediate, periodic, calendar, one-off).

Trevor.

Trevor Burbridge

From: Sharam Hakimi [mailto:[email-masked]]
Sent: 23 April 2014 14:15
To: Burbridge,T,Trevor,TUB8 R; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Timer: Poisson distribution question

Sharam

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 8:59 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Sharam Hakimi; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Trevor.

Trevor Burbridge

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: 23 April 2014 13:47
To: Burbridge,T,Trevor,TUB8 R; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Timer: Poisson distribution question

Al

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, April 23, 2014 8:41 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Timer: Poisson distribution question

Trevor.

Trevor Burbridge

BR,
Tim

Thanks,
Sharam

Trevor,

BR,
Tim

Trevor.

Trevor Burbridge

Sharam,

Tim,

Thanks,
Sharam

Trevor,

This sound OK?

BR
Tim

Tim,

Sharam

Trevor.

Team,

Trevor responded:

Thanks,
Tim

---

From: "marc.ibrahim" <[email-masked]>
Date: Wed, 23 Apr 2014 16:59:48 +0300

Here is how I see the problem.

First we have to separate time granularity and random generation.

Time granularity depends on the timer running on the MA. e.g microseconds scale means 
that the MA timer increment each microsecond.

When MA wants to generate a random time, he has to choose an integer number of 
microseconds to count. So the problem is always an integer (discrete) number generation. 

Now, if the random generator can attain the maximum integer (so the maximum possible 
random time), then, as Trevor says, no need for the timeStep I talked about, since all 
possible durations will be expressed as multiple of microseconds.

For example, a 32 bits random generator could generate up to a maximum value of 4 
billions. In microseconds, this is equal to less than 2 hours. 

It all depends on the capacity of the generator.
Marc.

On Wed, 23 Apr 2014 14:13:34 +0100, trevor.burbridge wrote
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: <[email-masked]>
Date: Wed, 23 Apr 2014 15:22:08 +0100

So the question is really do we want to design for extremely constrained devices? I'd argue that if this is a problem for them then they are really going to struggle with the Instruction information or measurement results.

Trevor.

>Sent: 23 April 2014 15:00
>Time granularity depends on the timer running on the MA. e.g microseconds scale
>means that the MA timer increment each microsecond.
>
>When MA wants to generate a random time, he has to choose an integer number
>of microseconds to count. So the problem is always an integer (discrete) number
>generation.
>
>Now, if the random generator can attain the maximum integer (so the maximum
>possible random time), then, as Trevor says, no need for the timeStep I talked
>about, since all possible durations will be expressed as multiple of microseconds.
>
>
>For example, a 32 bits random generator could generate up to a maximum value
>of 4 billions. In microseconds, this is equal to less than 2 hours.
>
>> >If we use a continuous uniform generator, than it is enough to
>> >specify the maximum time.
>> >With a discrete random generator, you need to specify an additional
>> >time granularity.
>> >
>> >BR,
>> >
>> >Marc.
>> >
>> >
>> >> I'm not sure I get the point of allowing coarser granularity that
>> >> the MA is capable of. If I want the MA to test/report sometime
>> >> within a minute window, why not allow that to happen with the
>> >> maximum resolution the MA is capable
>> >of?
>> >>
>> >> Trevor.
>> >>
>> >> Trevor Burbridge
>> >> It's meant only for the individual(s) or entity named above. If
>> >> you're not the intended recipient, note that disclosing, copying,
>> >> distributing or using this information is prohibited. If you've
>> >> received this email in error, please let me know immediately on the
>> >> email address above. Thank you. We monitor our email system, and
>> >> may record your emails. British Telecommunications plc Registered
>> >> office: 81 Newgate Street London EC1A 7AJ Registered in England
>> >no:
>> >> 1800000
>> >>
>> >> Marc's suggestion works for me. That allows better interoperability
>> >> in my
>> >opinion.
>> >>
>> >> From: Carey, Timothy (Timothy)
>> >> [mailto:[email-masked]]
>> >>  Spread) - works so far. Marc suggested a TimeStep parameter so we
>> >> don't lockin on a specific microsecond, millisecond, second thing - I am open
>to that.
>> >>
>> >> BR,
>> >> Tim
>> >>
>> >> Agree we need to have well defined function names. I thought you
>> >> were also suggesting different functions needed different input parameters.
>> >>
>> >> Trevor.
>> >>
>> >> Trevor Burbridge
>> >> It's meant only for the individual(s) or entity named above. If
>> >> you're not the intended recipient, note that disclosing, copying,
>> >> distributing or using this information is prohibited. If you've
>> >> received this email in error, please let me know immediately on the
>> >> email address above. Thank you. We monitor our email system, and
>> >> may record your emails. British Telecommunications plc Registered
>> >> office: 81 Newgate Street London EC1A 7AJ Registered in England
>> >no:
>> >> 1800000
>> >>
>> >> From: Carey, Timothy (Timothy)
>> >> [mailto:[email-masked]]
>> >> If we do not specify the functions and variable names, the
>> >> measurement controller doesn't have a standard way of configuring a timer.
>> >>
>> >> For example - If I specify for a Uniform distribution function
>> >> called "Uniform" you have a  variable called "UpperLimit", the MA
>> >> will implement the specification; the controller will implement the
>specification and things work.
>> >>
>> >> parameter for good measure; MA vendor 2 can call it "U" and have an
>> >> attribute "X that is an integer".
>> >>
>> >> Now put that variation on steroids based on the number of MA
>> >> vendors - That is why we specify things, right?
>> >>
>> >> BR,
>> >> Tim
>> >>
>> >> MA, for how long, when to run them, what test results are
>> >> generated, etc. Why would configuring this parameter be any
>> >> different. Maybe I am missing
>> >something.
>> >>
>> >> From: Carey, Timothy (Timothy)
>> >> [mailto:[email-masked]]
>> >> So the burden is on the Measurement controller to know the
>> >> functions and inputs specifications for each possible MA vendor;
>> >> not something I would want to have to do as a Measurement controller
>vendor.
>> >>
>> >> I do not see why vendor A or B or C matters. They would all be
>> >> under the control of one Measurement Controller which would specify
>> >> what inputs to use for all MAs in a group.
>> >>
>> >> As Trevor also mentioned this timer can be used for both testing
>> >> and reporting and I would strongly suggest to have microsecond
>> >> granularity. For reporting one could choose seconds in terms of
>microseconds.
>> >>
>> >> Thanks,
>> >> Sharam
>> >>
>> >> From: Carey, Timothy (Timothy)
>> >> [mailto:[email-masked]]
>> >> If we don't define the inputs for each function (leaving the inputs
>> >> opaque)  you will have interop problems. MA vendor 1 uses these 2 inputs
>named "A"
>> >and
>> >> I think we need to avoid that if we realistically want the
>> >> Randomness function to be used efficiently.
>> >>
>> >> BR,
>> >> Tim
>> >>
>> >> The random timing can be used for both specifying when a test runs,
>> >> or when a report is sent (or any other task such as contacting the
>> >> Controller). It doesn't have to be used, but it can be.
>> >>
>> >> I don't really want different input variable for different
>> >> functions. I don't see we need to. Also if we do, then we would
>> >> have to have schema for each function to specify which inputs are
>> >> expected (like the measurement task registry). I'd like to avoid that.
>> >>
>> >> Trevor.
>> >>
>> >> Trevor Burbridge
>> >> It's meant only for the individual(s) or entity named above. If
>> >> you're not the intended recipient, note that disclosing, copying,
>> >> distributing or using this information is prohibited. If you've
>> >> received this email in error, please let me know immediately on the
>> >> email address above. Thank you. We monitor our email system, and
>> >> may record your emails. British Telecommunications plc Registered
>> >> office: 81 Newgate Street London EC1A 7AJ Registered in England
>> >no:
>> >> 1800000
>> >>
>> >> From: Carey, Timothy (Timothy)
>> >> [mailto:[email-masked]]
>> >> Burbridge,T,Trevor,
>> >> We are talking about offsets for when to report; in the world we
>> >> live in milliseconds is sufficient - IMHO.
>> >>
>> >> I think the min/max should have microseconds granularity.
>> >> Milliseconds would not be accurate enough.
>> >>
>> >> Personally, I would not trust my periodic tests in a large scale
>> >> deployment to a random number generator and would want to know
>> >> exactly how and when
>> >tests
>> >> would be run.
>> >>
>> >> Thanks,
>> >> Sharam
>> >>
>> >> From: Carey, Timothy (Timothy)
>> >> [mailto:[email-masked]]
>> >> You suggested the Uniform and Normal which is fine but for the
>> >> model we need to go farther by defining the specific function along
>> >> with which inputs are used by the function to derive what random
>> >> number. Otherwise we will have 2 implementers of the same standard
>> >> algorithm implement different variations. -  Not good.
>> >>
>> >> I think the Periodic Timer distribution needs to have closer
>> >> configuration control by the user and I think your 2nd  choice
>> >> attempts to provide it but having a discrete interval definition is a better way
>to go.
>> >>
>> >> Sharam
>> >>
>> >> [email-masked]<mailto:[email-masked]> Subject: Re: [lmap] Timer:
>> >> Poisson distribution question
>> >>
>> >> On continuous counterparts of Poisson I'm far from any expert and
>> >> it would certainly be up to the user to decide if such functions
>> >> were suitable replacements for the discrete Poisson function. Yes
>> >> it would be a different function even if there was perfect fit
>> >> (which they are not) as one is continuous and one is discrete:
>> >> http://cmscience.blogspot.co.uk/2008/04/mt-
>> >6-
>> >> As I tried to say the current Information Model can take either
>> >> discrete or continuous functions - only that there is currently no
>> >> explicit support for specifying the interval used for a discrete
>> >> function. I was questioning the need to add this.
>> >>
>> >> Personally I'd think that Normal and Uniform distributions would
>> >> cover most needs, but the framework should be flexible in this regard.
>> >>
>> >> Trevor.
>> >>
>> >> From: lmap [mailto:[email-masked]] On Behalf Of Carey,
>> >> Timothy
>> >(Timothy)
>> >> The BBF is looking at standardizing the model for Timers as
>> >> suggested by the IETF LMAP information model.
>> >>
>> >> During the review of the timers we had addition questions regarding
>> >> Trevors response to the Poisson distribution for the Randomness of the
>Periodic Timer.
>> >>
>> >> Trevor responded:
>> >>
>> >> "Yes this does need to be clarified. I was assuming a distribution
>> >> about the mean (i.e. the timing given is the mean). The spread
>> >> would be the standard deviation (could use mean deviation or
>> >> something else but I see no advantage as long as we all know what
>> >> it refers to) and need to change to a float. The upper and lower
>> >> cuts would be in seconds +/- the mean (also needs to change
>> >to
>> >> float) and are simply used to trim the function - obviously needed
>> >> on a uniform distribution but useful to constrain other functions.
>> >>
>> >> I was really thinking about the first, but I don't see the problem
>> >> with the second. However I wouldn't do the third unless they was a
>> >> demonstrable value to supporting discrete functions (rather than continuous
>versions of them). "
>> >>
>> >> I don't understand what Trevor means about the Poisson
>> >> distribution.  As far as I know, it is a discrete distribution, so
>> >> a "continuous form" would be a different distribution and not
>> >> Poisson.  And I believe that we do need a continuous distribution.
>> >> But what matters is that the definition is clear,  not the particular distribution
>(I don't have an opinion on that).
>> >>
>> >> Could some please clarify this for us - Are we planning something
>> >> other than Poisson method; better yet is there a definition for the
>> >> types of

---

From: "marc.ibrahim" <[email-masked]>
Date: Wed, 23 Apr 2014 18:02:45 +0300

I would say that choosing the millisecond as atomic time alleviates constraints on both 
timer granularity and generator capacity. 

I still don't see a real measurement example where few microseconds would really matter.

Practically, can a program deal with microseconds timers in computers and smartphones? 
This is the scale of the OS, no?

Marc.

On Wed, 23 Apr 2014 15:22:08 +0100, trevor.burbridge wrote
> So the question is really do we want to design for extremely constrained 
> devices? I'd argue that if this is a problem for them then they are really 
> going to struggle with the Instruction information or measurement results.
> 
> Trevor.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Apr 2014 17:10:59 +0200

I believe randomization with a granularity of milliseconds is good
enough. Within an implementation of a measurement task, one may use
more precise timers. But for the randomization of the start of
measurement tasks or the sending of reports, milliseconds seem to be
sufficient (since there will be likely other delays introduced by the
operating system that may get into the some order for starting a
measurement task or triggering a report).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 23 Apr 2014 15:33:27 +0000

It depends what the performance goal of the measurement is. A ping packet in a Gigabit network is just under 1 microseconds and with fast processors a packet can be sent and received at the same time if granularity is milliseconds.

This does not even take into account 10Gig networks, not that they would be at consumer sites, but they would sure exist inside a ISP network.

Sharam

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 11:11 AM
To: marc.ibrahim
Cc: [email-masked]; Sharam Hakimi; [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

/js

---

From: "marc.ibrahim" <[email-masked]>
Date: Wed, 23 Apr 2014 18:42:25 +0300

As JS stated, we are talking about randomizing reporting and measurement start times. 
It is not about randomizing inter-packet intervals inside a given measurement.

BR,

Marc.

On Wed, 23 Apr 2014 15:33:27 +0000, Sharam Hakimi wrote
> It depends what the performance goal of the measurement is. A ping packet in a 
> Gigabit network is just under 1 microseconds and with fast processors a packet 
> can be sent and received at the same time if granularity is milliseconds.
> 
> This does not even take into account 10Gig networks, not that they would be at 
> consumer sites, but they would sure exist inside a ISP network.
> 
> Sharam
>

---

From: KEN KO <[email-masked]>
Date: Wed, 23 Apr 2014 18:55:39 +0000

This example confuses resolution of the measurement result with resolution and accuracy of the time at which the measurement is initiated. Measuring round trip latencies on a Gigabit LAN may well require microsecond resolution, which could be within the capabilities of a higher end MA. But that doesn't require microsecond resolution of the time at which the measurement is initiated. In addition, for microsecond resolution on the Timer to be meaningful would require synchronization to that resolution across different MAs in the network.

I'm in favor of keeping things simple and specifying Timer resolution in milliseconds.

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Sharam Hakimi
Sent: Wednesday, April 23, 2014 11:33 AM
To: Juergen Schoenwaelder; marc.ibrahim
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

Sharam

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 11:11 AM
To: marc.ibrahim
Cc: [email-masked]; Sharam Hakimi; [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

I believe randomization with a granularity of milliseconds is good enough. Within an implementation of a measurement task, one may use more precise timers. But for the randomization of the start of measurement tasks or the sending of reports, milliseconds seem to be sufficient (since there will be likely other delays introduced by the operating system that may get into the some order for starting a measurement task or triggering a report).

/js

On Wed, Apr 23, 2014 at 06:02:45PM +0300, marc.ibrahim wrote:
> I would say that choosing the millisecond as atomic time alleviates 
> constraints on both timer granularity and generator capacity.
> 
> > So the question is really do we want to design for extremely 
> > constrained devices? I'd argue that if this is a problem for them 
> > then they are really going to struggle with the Instruction information or measurement results.
> > 
> > Trevor.
> > 
> > >Time granularity depends on the timer running on the MA. e.g 
> > >microseconds scale means that the MA timer increment each microsecond.
> > >
> > >When MA wants to generate a random time, he has to choose an 
> > >integer number of microseconds to count. So the problem is always 
> > >an integer (discrete) number generation.
> > >
> > >Now, if the random generator can attain the maximum integer (so the 
> > >maximum possible random time), then, as Trevor says, no need for 
> > >the timeStep I talked about, since all possible durations will be expressed as multiple of microseconds.
> > >
> > >
> > >For example, a 32 bits random generator could generate up to a 
> > >maximum value of 4 billions. In microseconds, this is equal to less than 2 hours.
> > >
> > >> >With a discrete random generator, you need to specify an 
> > >> >additional time granularity.
> > >> >
> > >> >BR,
> > >> >
> > >> >Marc.
> > >> >
> > >> >
> > >> >> I'm not sure I get the point of allowing coarser granularity 
> > >> >> that the MA is capable of. If I want the MA to test/report 
> > >> >> sometime within a minute window, why not allow that to happen 
> > >> >> with the maximum resolution the MA is capable
> > >> >of?
> > >> >>
> > >> >> Trevor.
> > >> >>
> > >> >> Trevor Burbridge
> > >> >> It's meant only for the individual(s) or entity named above. 
> > >> >> If you're not the intended recipient, note that disclosing, 
> > >> >> copying, distributing or using this information is prohibited. 
> > >> >> If you've received this email in error, please let me know 
> > >> >> immediately on the email address above. Thank you. We monitor 
> > >> >> our email system, and may record your emails. British 
> > >> >> Telecommunications plc Registered
> > >> >> Marc's suggestion works for me. That allows better 
> > >> >> interoperability in my
> > >> >opinion.
> > >> >>
> > >> >>  Spread) - works so far. Marc suggested a TimeStep parameter 
> > >> >> so we don't lockin on a specific microsecond, millisecond, 
> > >> >> second thing - I am open
> > >to that.
> > >> >>
> > >> >> BR,
> > >> >> Tim
> > >> >>
> > >> >> Agree we need to have well defined function names. I thought 
> > >> >> you were also suggesting different functions needed different input parameters.
> > >> >>
> > >> >> Trevor.
> > >> >>
> > >> >> Trevor Burbridge
> > >> >> It's meant only for the individual(s) or entity named above. 
> > >> >> If you're not the intended recipient, note that disclosing, 
> > >> >> copying, distributing or using this information is prohibited. 
> > >> >> If you've received this email in error, please let me know 
> > >> >> immediately on the email address above. Thank you. We monitor 
> > >> >> our email system, and may record your emails. British 
> > >> >> Telecommunications plc Registered
> > >> >> Its not that the Measurement controller has to configure the 
> > >> >> timer for the
> > >MA.
> > >> >>
> > >> >> called "Uniform" you have a  variable called "UpperLimit", the 
> > >> >> MA will implement the specification; the controller will 
> > >> >> implement the
> > >> >> If I do not specify anything for the Uniform distribution 
> > >> >> function
> > >> >> - MA vendor
> > >> >> 1 can call it "UniformDF" and "UL - which is typed real" and 
> > >> >> maybe an
> > >"Enable"
> > >> >> parameter for good measure; MA vendor 2 can call it "U" and 
> > >> >> have an attribute "X that is an integer".
> > >> >>
> > >> >> functions and inputs specifications for each possible MA 
> > >> >> vendor; not something I would want to have to do as a 
> > >> >> Measurement controller
> > >vendor.
> > >> >>
> > >> >> under the control of one Measurement Controller which would 
> > >> >> specify what inputs to use for all MAs in a group.
> > >> >>
> > >> >> As Trevor also mentioned this timer can be used for both 
> > >> >> testing and reporting and I would strongly suggest to have 
> > >> >> microsecond granularity. For reporting one could choose 
> > >> >> seconds in terms of
> > >microseconds.
> > >> >>
> > >> >> Thanks,
> > >> >> Sharam
> > >> >>
> > >> >> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for the 
> > >> >> same
> > >function.
> > >> >>
> > >> >> The random timing can be used for both specifying when a test 
> > >> >> runs, or when a report is sent (or any other task such as 
> > >> >> contacting the Controller). It doesn't have to be used, but it can be.
> > >> >>
> > >> >> functions. I don't see we need to. Also if we do, then we 
> > >> >> would have to have schema for each function to specify which 
> > >> >> inputs are expected (like the measurement task registry). I'd like to avoid that.
> > >> >>
> > >> >> Trevor.
> > >> >>
> > >> >> Trevor Burbridge
> > >> >> It's meant only for the individual(s) or entity named above. 
> > >> >> If you're not the intended recipient, note that disclosing, 
> > >> >> copying, distributing or using this information is prohibited. 
> > >> >> If you've received this email in error, please let me know 
> > >> >> immediately on the email address above. Thank you. We monitor 
> > >> >> our email system, and may record your emails. British 
> > >> >> Telecommunications plc Registered
> > >> >> We are talking about offsets for when to report; in the world 
> > >> >> we live in milliseconds is sufficient - IMHO.
> > >> >>
> > >> >> [email-masked]<mailto:[email-masked]>;
> > >> >> Personally, I would not trust my periodic tests in a large 
> > >> >> scale deployment to a random number generator and would want 
> > >> >> to know exactly how and when
> > >> >tests
> > >> >> would be run.
> > >> >>
> > >> >> Thanks,
> > >> >> Sharam
> > >> >>
> > >> >> The data model is extensible by vendors so we can add 
> > >> >> functions and input variables as we need.
> > >> >>
> > >> >> However we have to decide on which small subset we actually 
> > >> >> want to
> > >> >standardize.
> > >> >>
> > >> >> model we need to go farther by defining the specific function 
> > >> >> along with which inputs are used by the function to derive 
> > >> >> what random number. Otherwise we will have 2 implementers of 
> > >> >> the same standard algorithm implement different variations. -  Not good.
> > >> >>
> > >> >> Uniform Discrete - input variables - maximum [positive 
> > >> >> integer] Gaussian -input variables - mean of min/max, spread = 
> > >> >> standard deviation
> > >> >>
> > >> >> [email-masked]<mailto:[email-masked]>;
> > >> >> To: 
> > >> >> [email-masked]<mailto:timothy.carey@alcatel-
> > >> >lucent.com>;
> > >> >> On continuous counterparts of Poisson I'm far from any expert 
> > >> >> and it would certainly be up to the user to decide if such 
> > >> >> functions were suitable replacements for the discrete Poisson 
> > >> >> function. Yes it would be a different function even if there 
> > >> >> was perfect fit (which they are not) as one is continuous and one is discrete:
> > >> >> As I tried to say the current Information Model can take 
> > >> >> either discrete or continuous functions - only that there is 
> > >> >> currently no explicit support for specifying the interval used 
> > >> >> for a discrete function. I was questioning the need to add this.
> > >> >>
> > >> >> Personally I'd think that Normal and Uniform distributions 
> > >> >> would cover most needs, but the framework should be flexible in this regard.
> > >> >>
> > >> >> Trevor.
> > >> >>
> > >> >> During the review of the timers we had addition questions 
> > >> >> regarding Trevors response to the Poisson distribution for the 
> > >> >> Randomness of the
> > >Periodic Timer.
> > >> >>
> > >> >> Trevor responded:
> > >> >>
> > >> >> "Yes this does need to be clarified. I was assuming a 
> > >> >> distribution about the mean (i.e. the timing given is the 
> > >> >> mean). The spread would be the standard deviation (could use 
> > >> >> mean deviation or something else but I see no advantage as 
> > >> >> long as we all know what it refers to) and need to change to a 
> > >> >> float. The upper and lower cuts would be in seconds +/- the 
> > >> >> mean (also needs to change
> > >> >to
> > >> >> float) and are simply used to trim the function - obviously 
> > >> >> needed on a uniform distribution but useful to constrain other functions.
> > >> >>
> > >> >> I was really thinking about the first, but I don't see the 
> > >> >> problem with the second. However I wouldn't do the third 
> > >> >> unless they was a demonstrable value to supporting discrete 
> > >> >> functions (rather than continuous
> > >versions of them). "
> > >> >>
> > >> >> distribution.  As far as I know, it is a discrete 
> > >> >> distribution, so a "continuous form" would be a different 
> > >> >> distribution and not Poisson.  And I believe that we do need a continuous distribution.
> > >> >> But what matters is that the definition is clear,  not the 
> > >> >> particular
> distribution
> > >> >> Could some please clarify this for us - Are we planning 
> > >> >> something other than Poisson method; better yet is there a 
> > >> >> definition for the types of

---

From: "marc.ibrahim" <[email-masked]>
Date: Thu, 24 Apr 2014 02:07:45 +0300

Based on what has been exchanged, I suggest the following:

1- Exact randomness definition and operation
--------------------------------------------
IMHO, we need to define how exactly the randomness is applied.

For a given event E (e.g. running a measurement task, start reporting,...), let Ti be 
the predefined (scheduled) instant of the ith occurrence of E. 
Adding randomness means that the event E will happen at time Ti + X instead of Ti, where 
X is a random variable. If Xmin and Xmax denote the minimum and maximum possible values 
of X repectively, then the event E will take place at an instant randomly chosen between 
Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin

      Ti+Xmin             Ti                 Ti+Xmax
---------|-----------------|-------------------|-----------

         <------------------------------------->
                        Spread

Note that Xmin could be negative if E can occur before Ti like in the figure. I think 
that the most common values of Xmin would be 0 or (-spread/2).

2- Random generation of X
---------------------------
To make it simple as stated by many, X could an integer number of milliseconds uniformly 
chosen in the interval [Xmin, Xmax].
Xmin, Xmax, and hence spread, are all integers (milliseconds).

Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently UNIF(Xmin, spread) 
that generates a random number of milliseconds from [Xmin, Xmax] interval.
The controller has just to send two integer variables (Xmin, Xmax) or (Xmin, spread) to 
the MA in the timing object.

In this minimalist approach, no need to specify the nature of distribution in the timing 
object since it is assumed to be the uniform one. 

BR,

Marc.

On Wed, 23 Apr 2014 18:55:39 +0000, KEN KO wrote
> This example confuses resolution of the measurement result with resolution and 
> accuracy of the time at which the measurement is initiated. Measuring round 
> trip latencies on a Gigabit LAN may well require microsecond resolution, which 
> could be within the capabilities of a higher end MA. But that doesn't require 
> microsecond resolution of the time at which the measurement is initiated. In 
> addition, for microsecond resolution on the Timer to be meaningful would 
> require synchronization to that resolution across different MAs in the network.
> 
> I believe randomization with a granularity of milliseconds is good enough. 
> Within an implementation of a measurement task, one may use more precise 
> timers. But for the randomization of the start of measurement tasks or the 
> sending of reports, milliseconds seem to be sufficient (since there will be 
> likely other delays introduced by the operating system that may get into the 
> some order for starting a measurement task or triggering a report).
> 
> /js
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 23 Apr 2014 20:55:18 -0400

...
> object since it is assumed to be the uniform one.

Great, that's where we ended-up last night, too.
Al

> From: lmap [mailto:[email-masked]] On Behalf Of marc.ibrahim
> Sent: Wednesday, April 23, 2014 7:08 PM
> To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder
> > Cc: [email-masked]; Sharam Hakimi; timothy.carey@alcatel-
> lucent.com;
> [email-masked]
> enough.
> > > I still don't see a real measurement example where few microseconds
> would really
> matter.
> > >
> > > Practically, can a program deal with microseconds timers in computers
> and
> smartphones?
> > > > then they are really going to struggle with the Instruction
> information or
> measurement results.
> > > >
> > > > Trevor.
> > > >
> > > > >the timeStep I talked about, since all possible durations will be
> expressed as
> multiple of microseconds.
> > > > >
> > > > >
> > > > >> >> you were also suggesting different functions needed different
> input
> parameters.
> > > > >> >>
> > > > >> >> Trevor.
> > > > >> >>
> > > > >> >> Trevor Burbridge
> > > > >> >> inputs are expected (like the measurement task registry). I'd
> like to avoid
> that.
> > > > >> >>
> > > > >> >> Trevor.
> > > > >> >>
> > > > >> >> Trevor Burbridge
> > > > >> >> was perfect fit (which they are not) as one is continuous and
> one is
> discrete:
> > > > >> >> -        Have the discrete interval implicit in the function
> choice
> > > > >> >e.g."poisson_1_sec"
> > > > >> >>
> > > > >> >> distribution and not Poisson.  And I believe that we do need a
> continuous
> distribution.

---

From: KEN KO <[email-masked]>
Date: Thu, 24 Apr 2014 12:17:05 +0000

Since Ti+Xmin is non-random, Xmin is not really needed as a separate parameter. Just offset Ti to the desired minimum time and let the spread range from Ti to Ti+Xmax.

Other than that nit, +1

-----Original Message-----
From: marc.ibrahim [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 7:08 PM
To: KEN KO; Sharam Hakimi; Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Timer: Poisson distribution question

For a given event E (e.g. running a measurement task, start reporting,...), let Ti be the predefined (scheduled) instant of the ith occurrence of E. 
Adding randomness means that the event E will happen at time Ti + X instead of Ti, where X is a random variable. If Xmin and Xmax denote the minimum and maximum possible values of X repectively, then the event E will take place at an instant randomly chosen between 
Ti+Xmin and Ti+Xmax. The spread is equal to Xmax-Xmin

      Ti+Xmin             Ti                 Ti+Xmax

Note that Xmin could be negative if E can occur before Ti like in the figure. I think that the most common values of Xmin would be 0 or (-spread/2).

2- Random generation of X
---------------------------
To make it simple as stated by many, X could an integer number of milliseconds uniformly chosen in the interval [Xmin, Xmax].
Xmin, Xmax, and hence spread, are all integers (milliseconds).

Then the MA has to define a function UNIF(Xmin, Xmax) or equivalently UNIF(Xmin, spread) that generates a random number of milliseconds from [Xmin, Xmax] interval.
The controller has just to send two integer variables (Xmin, Xmax) or (Xmin, spread) to the MA in the timing object.

In this minimalist approach, no need to specify the nature of distribution in the timing object since it is assumed to be the uniform one. 

BR,

Marc.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 27 Apr 2014 12:14:23 -0700

On 4/23/14, 8:33 AM, Sharam Hakimi wrote:
> It depends what the performance goal of the measurement is. A ping
> packet in a Gigabit network is just under 1 microseconds and with
> fast processors a packet can be sent and received at the same time if
> granularity is milliseconds.

It's pretty easy to send a packet before it arrives with respect to
measurement. increasing the precision of your measurement doesn't
actually help you if can't recover the state of the clocks.

> This does not even take into account 10Gig networks, not that they
> would be at consumer sites, but they would sure exist inside a ISP
> network.

http://i.imgur.com/AkDRs9D.png

if you want to watch the microsecond precision clock generation in two
cross country routers drift past each other over 10gig links... the top
line is the rtt measured by the sender.

There's no reason to assume that consumer level connectivity won't  in
the future employ faster link layers.

> Sharam
> 
> 
> -----Original Message----- From: Juergen Schoenwaelder
> [mailto:[email-masked]] Sent: Wednesday, April
> 23, 2014 11:11 AM To: marc.ibrahim Cc: [email-masked];
> Sharam Hakimi; [email-masked]; [email-masked] 
> sufficient (since there will be likely other delays introduced by
> the operating system that may get into the some order for starting a 
>> would really matter.
>> Practically, can a program deal with microseconds timers in
>> computers and smartphones? This is the scale of the OS, no?
>> 
>> Marc.
>> 
>>> information or measurement results.
>>> 
>>> Trevor.
>>> 
>>>> -----Original Message----- From: marc.ibrahim
>>>> [mailto:[email-masked]] Sent: 23 April 2014 15:00 To:
>>>> Burbridge,T,Trevor,TUB8 R; [email-masked]; 
>>>> [email-masked]; [email-masked] Subject: Re:
>>>> [lmap] Timer: Poisson distribution question
>>>> 
>>>> integer number of microseconds to count. So the problem is
>>>> always an integer (discrete) number generation.
>>>> 
>>>> Now, if the random generator can attain the maximum integer (so
>>>> the maximum possible random time), then, as Trevor says, no
>>>> need for the timeStep I talked about, since all possible
>>>> durations will be expressed as multiple of microseconds.
>>>> 
>>>> 
>>>> It all depends on the capacity of the generator. Marc.
>>>> 
>>>> 
>>>>>> -----Original Message----- From: marc.ibrahim
>>>>>> [mailto:[email-masked]] Sent: 23 April 2014 14:10 
>>>>>> [email-masked]; [email-masked] Subject:
>>>>>> Re: [lmap] Timer: Poisson distribution question
>>>>>> 
>>>>>> Trevor, you're right. it is just about whether we want a
>>>>>> discrete or continuous generator. If we use a continuous
>>>>>> uniform generator, than it is enough to specify the maximum
>>>>>> time. With a discrete random generator, you need to specify
>>>>>> an additional time granularity.
>>>>>> 
>>>>>> BR,
>>>>>> 
>>>>>> Marc.
>>>>>> 
>>>>>> 
>>>>>>> I'm not sure I get the point of allowing coarser
>>>>>>> granularity that the MA is capable of. If I want the MA
>>>>>>> to test/report sometime within a minute window, why not
>>>>>>> allow that to happen with the maximum resolution the MA
>>>>>>> is capable
>>>>>> of?
>>>>>>> 
>>>>>>> Trevor.
>>>>>>> 
>>>>>>> Trevor Burbridge Network Infrastructure & Innovation | BT
>>>>>>> Innovate & Design Tel: 01473 645115 Fax: 01473 640929
>>>>>>> 
>>>>>>> This email contains BT information, which may be
>>>>>>> privileged or confidential. It's meant only for the
>>>>>>> individual(s) or entity named above. If you're not the
>>>>>>> intended recipient, note that disclosing, copying, 
>>>>>>> distributing or using this information is prohibited. If
>>>>>>> you've received this email in error, please let me know
>>>>>>> immediately on the email address above. Thank you. We
>>>>>>> monitor our email system, and may record your emails.
>>>>>>> British Telecommunications plc Registered office: 81
>>>>>>> Newgate Street London EC1A 7AJ Registered in England
>>>>>> no:
>>>>>>> 1800000
>>>>>>> 
>>>>>>> Sharam Hakimi Sent: 23 April 2014 13:58 To: Carey,
>>>>>>> Timothy (Timothy); Burbridge,T,Trevor,TUB8 R; 
>>>>>>> [email-masked] Subject: Re: [lmap] Timer: Poisson
>>>>>>> distribution question
>>>>>>> 
>>>>>>> Thanks, Sharam
>>>>>>> [mailto:[email-masked]] Sent:
>>>>>>> Wednesday, April 23, 2014 8:47 AM To:
>>>>>> Hakimi; [email-masked]<mailto:[email-masked]>
>>>>>>> Spread) - works so far. Marc suggested a TimeStep
>>>>>>> parameter so we don't lockin on a specific microsecond,
>>>>>>> millisecond, second thing - I am open
>>>> to that.
>>>>>>> 
>>>>>>> BR, Tim
>>>>>>> 
>>>>>>> From:
>>>>>> [mailto:[email-masked]]
>>>>>>> Sent: Wednesday, April 23, 2014 7:41 AM To: Carey,
>>>>>>> Timothy (Timothy); 
>>>>>>> Agree we need to have well defined function names. I
>>>>>>> thought you were also suggesting different functions
>>>>>>> needed different input parameters.
>>>>>>> 
>>>>>>> Trevor.
>>>>>>> 
>>>>>>> Trevor Burbridge Network Infrastructure & Innovation | BT
>>>>>>> Innovate & Design Tel: 01473 645115 Fax: 01473 640929
>>>>>>> 
>>>>>>> This email contains BT information, which may be
>>>>>>> privileged or confidential. It's meant only for the
>>>>>>> individual(s) or entity named above. If you're not the
>>>>>>> intended recipient, note that disclosing, copying, 
>>>>>>> distributing or using this information is prohibited. If
>>>>>>> you've received this email in error, please let me know
>>>>>>> immediately on the email address above. Thank you. We
>>>>>>> monitor our email system, and may record your emails.
>>>>>>> British Telecommunications plc Registered office: 81
>>>>>>> Newgate Street London EC1A 7AJ Registered in England
>>>>>> no:
>>>>>>> 1800000
>>>>>>> 
>>>>>>> [mailto:[email-masked]] Sent: 23 April
>>>>>>> 2014 13:36 To: Sharam Hakimi; Burbridge,T,Trevor,TUB8 R;
>>>>>>> Its not that the Measurement controller has to configure
>>>>>>> the timer for the
>>>> MA.
>>>>>>> 
>>>>>>> If we do not specify the functions and variable names,
>>>>>>> the measurement controller doesn't have a standard way of
>>>>>>> configuring a timer.
>>>>>>> 
>>>>>>> For example - If I specify for a Uniform distribution
>>>>>>> function called "Uniform" you have a  variable called
>>>>>>> "UpperLimit", the MA will implement the specification;
>>>>>>> the controller will implement the
>>>>>>> function - MA vendor 1 can call it "UniformDF" and "UL -
>>>>>>> which is typed real" and maybe an
>>>> "Enable"
>>>>>>> parameter for good measure; MA vendor 2 can call it "U"
>>>>>>> and have an attribute "X that is an integer".
>>>>>>> 
>>>>>>> Now put that variation on steroids based on the number of
>>>>>>> MA vendors - That is why we specify things, right?
>>>>>>> 
>>>>>>> BR, Tim
>>>>>>> 
>>>>>>> From: Sharam Hakimi [mailto:[email-masked]] Sent:
>>>>>>> Wednesday, April 23, 2014 7:24 AM To: Carey, Timothy
>>>>>>> (Timothy); 
>>>>>>> MA, for how long, when to run them, what test results
>>>>>>> are generated, etc. Why would configuring this parameter
>>>>>>> be any different. Maybe I am missing
>>>>>> something.
>>>>>>> 
>>>>>>> [mailto:[email-masked]] Sent:
>>>>>>> Wednesday, April 23, 2014 8:16 AM To: Sharam Hakimi;
>>>>>>> So the burden is on the Measurement controller to know
>>>>>>> the functions and inputs specifications for each possible
>>>>>>> MA vendor; not something I would want to have to do as a
>>>>>>> Measurement controller
>>>> vendor.
>>>>>>> 
>>>>>>> From: Sharam Hakimi [mailto:[email-masked]] Sent:
>>>>>>> Wednesday, April 23, 2014 7:14 AM To: Carey, Timothy
>>>>>>> (Timothy); 
>>>>>>> I do not see why vendor A or B or C matters. They would
>>>>>>> all be under the control of one Measurement Controller
>>>>>>> which would specify what inputs to use for all MAs in a
>>>>>>> group.
>>>>>>> 
>>>>>>> testing and reporting and I would strongly suggest to
>>>>>>> have microsecond granularity. For reporting one could
>>>>>>> choose seconds in terms of
>>>> microseconds.
>>>>>>> 
>>>>>>> Thanks, Sharam
>>>>>>> 
>>>>>>> [mailto:[email-masked]] Sent:
>>>>>>> Wednesday, April 23, 2014 8:04 AM To:
>>>>>> Hakimi; [email-masked]<mailto:[email-masked]>
>>>>>>> If we don't define the inputs for each function (leaving
>>>>>>> the inputs opaque)  you will have interop problems. MA
>>>>>>> vendor 1 uses these 2 inputs
>>>> named "A"
>>>>>> and
>>>>>>> "B"; MA vendor 2 uses 3 inputs named "A", "X" and "Y" for
>>>>>>> the same
>>>> function.
>>>>>>> 
>>>>>>> I think we need to avoid that if we realistically want
>>>>>>> the Randomness function to be used efficiently.
>>>>>>> 
>>>>>>> BR, Tim
>>>>>>> 
>>>>>>> From:
>>>>>> [mailto:[email-masked]]
>>>>>>> Sent: Wednesday, April 23, 2014 2:55 AM To: Carey,
>>>>>>> Timothy (Timothy); 
>>>>>>> The random timing can be used for both specifying when a
>>>>>>> test runs, or when a report is sent (or any other task
>>>>>>> such as contacting the Controller). It doesn't have to be
>>>>>>> used, but it can be.
>>>>>>> 
>>>>>>> I don't really want different input variable for
>>>>>>> different functions. I don't see we need to. Also if we
>>>>>>> do, then we would have to have schema for each function
>>>>>>> to specify which inputs are expected (like the
>>>>>>> measurement task registry). I'd like to avoid that.
>>>>>>> 
>>>>>>> Trevor.
>>>>>>> 
>>>>>>> Trevor Burbridge Network Infrastructure & Innovation | BT
>>>>>>> Innovate & Design Tel: 01473 645115 Fax: 01473 640929
>>>>>>> 
>>>>>>> This email contains BT information, which may be
>>>>>>> privileged or confidential. It's meant only for the
>>>>>>> individual(s) or entity named above. If you're not the
>>>>>>> intended recipient, note that disclosing, copying, 
>>>>>>> distributing or using this information is prohibited. If
>>>>>>> you've received this email in error, please let me know
>>>>>>> immediately on the email address above. Thank you. We
>>>>>>> monitor our email system, and may record your emails.
>>>>>>> British Telecommunications plc Registered office: 81
>>>>>>> Newgate Street London EC1A 7AJ Registered in England
>>>>>> no:
>>>>>>> 1800000
>>>>>>> 
>>>>>>> [mailto:[email-masked]] Sent: 22 April
>>>>>>> 2014 22:07 To: Sharam Hakimi;
>>>>>>> [email-masked]<mailto:[email-masked]>; Burbridge,T,Trevor, 
>>>>>>> We are talking about offsets for when to report; in the
>>>>>>> world we live in milliseconds is sufficient - IMHO.
>>>>>>> 
>>>>>>> From: Sharam Hakimi [mailto:[email-masked]] Sent:
>>>>>>> Tuesday, April 22, 2014 3:59 PM To: Carey, Timothy
>>>>>>> (Timothy); [email-masked]<mailto:[email-masked]>;
>>>>>>> Tim, I think the min/max should have microseconds
>>>>>>> granularity. Milliseconds would not be accurate enough.
>>>>>>> 
>>>>>>> Personally, I would not trust my periodic tests in a
>>>>>>> large scale deployment to a random number generator and
>>>>>>> would want to know exactly how and when
>>>>>> tests
>>>>>>> would be run.
>>>>>>> 
>>>>>>> Thanks, Sharam
>>>>>>> 
>>>>>>> [mailto:[email-masked]] Sent: Tuesday,
>>>>>>> April 22, 2014 3:16 PM To: Sharam Hakimi;
>>>>>>> However we have to decide on which small subset we
>>>>>>> actually want to
>>>>>> standardize.
>>>>>>> 
>>>>>>> You suggested the Uniform and Normal which is fine but
>>>>>>> for the model we need to go farther by defining the
>>>>>>> specific function along with which inputs are used by the
>>>>>>> function to derive what random number. Otherwise we will
>>>>>>> have 2 implementers of the same standard algorithm
>>>>>>> implement different variations. -  Not good.
>>>>>>> 
>>>>>>> integer] Gaussian -input variables - mean of min/max,
>>>>>>> spread = standard deviation
>>>>>>> 
>>>>>>> BR Tim
>>>>>>> From: Sharam Hakimi [mailto:[email-masked]] Sent:
>>>>>>> Tuesday, April 22, 2014 8:23 AM To: Carey, Timothy
>>>>>>> (Timothy); [email-masked]<mailto:[email-masked]>;
>>>>>>> Tim, I think the Periodic Timer distribution needs to
>>>>>>> have closer configuration control by the user and I think
>>>>>>> your 2nd  choice attempts to provide it but having a
>>>>>>> discrete interval definition is a better way
>>>> to go.
>>>>>>> 
>>>>>>> Sharam
>>>>>>> 
>>>>>>> Sent: Tuesday, April 22, 2014 4:35 AM To:
lucent.com>;
>>>>>>> [email-masked]<mailto:[email-masked]> Subject: Re: [lmap]
>>>>>>> Timer: Poisson distribution question
>>>>>>> 
>>>>>>> On continuous counterparts of Poisson I'm far from any
>>>>>>> expert and it would certainly be up to the user to decide
>>>>>>> if such functions were suitable replacements for the
>>>>>>> discrete Poisson function. Yes it would be a different
>>>>>>> function even if there was perfect fit (which they are
>>>>>>> not) as one is continuous and one is discrete: 
>>>>>>> either discrete or continuous functions - only that there
>>>>>>> is currently no explicit support for specifying the
>>>>>>> interval used for a discrete function. I was questioning
>>>>>>> the need to add this.
>>>>>>> 
>>>>>>> Personally I'd think that Normal and Uniform
>>>>>>> distributions would cover most needs, but the framework
>>>>>>> should be flexible in this regard.
>>>>>>> 
>>>>>>> Trevor.
>>>>>>> 
>>>>>>> Carey, Timothy
>>>>>>> Sent: 19 April 2014 20:24 To:
>>>>>>> [email-masked]<mailto:[email-masked]> Subject: [lmap]
>>>>>>> Timer: Poisson distribution question
>>>>>>> 
>>>>>>> Team,
>>>>>>> 
>>>>>>> The BBF is looking at standardizing the model for Timers
>>>>>>> as suggested by the IETF LMAP information model.
>>>>>>> 
>>>>>>> regarding Trevors response to the Poisson distribution
>>>>>>> for the Randomness of the
>>>> Periodic Timer.
>>>>>>> 
>>>>>>> Trevor responded:
>>>>>>> 
>>>>>>> mean). The spread would be the standard deviation (could
>>>>>>> use mean deviation or something else but I see no
>>>>>>> advantage as long as we all know what it refers to) and
>>>>>>> need to change to a float. The upper and lower cuts would
>>>>>>> be in seconds +/- the mean (also needs to change
>>>>>> to
>>>>>>> float) and are simply used to trim the function -
>>>>>>> obviously needed on a uniform distribution but useful to
>>>>>>> constrain other functions.
>>>>>>> 
>>>>>>> -        Have the discrete interval implicit in the
>>>>>>> function choice
>>>>>> e.g."poisson_1_sec"
>>>>>>> 
>>>>>>> I was really thinking about the first, but I don't see
>>>>>>> the problem with the second. However I wouldn't do the
>>>>>>> third unless they was a demonstrable value to supporting
>>>>>>> discrete functions (rather than continuous
>>>> versions of them). "
>>>>>>> 
>>>>>>> distribution and not Poisson.  And I believe that we do
>>>>>>> need a continuous distribution. But what matters is that
>>>>>>> the definition is clear,  not the particular
>> distribution
>>>>>>> something other than Poisson method; better yet is there
>>>>>>> a definition for the types of distribution: Poisson,
>>>>>>> Normal and Uniform.
>>>>>>> 
>>>>>>> Thanks, Tim
>>>>>> 
>>>>>> 
>>>>>> -- Open WebMail Project (http://openwebmail.org)
>>>>> 
>>>>> _______________________________________________ lmap mailing
>>>>> list [email-masked] 
>>>> -- Open WebMail Project (http://openwebmail.org)
>>> 
>>> _______________________________________________ lmap mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/lmap
>> 
>> 
>> -- Open WebMail Project (http://openwebmail.org)
>> 
>> _______________________________________________ lmap mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/lmap
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 27 Apr 2014 22:03:39 +0200

Are we still talking about the randomization of the start of
measurement tasks or reports?

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 27 Apr 2014 16:11:56 -0400

This thread spilt into two topics sometime last Thursday,
with a misunderstanding about the resolution of start times:
someone thought we were talking about packet scheduling
within a stream and that discussion mixed-in here too.

Al

> From: lmap [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Sunday, April 27, 2014 4:04 PM
> To: joel jaeggli
> Cc: Sharam Hakimi; [email-masked];
> [email-masked]; marc. ibrahim; [email-masked]