Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model

From: Esteban Carisimo <[email-masked]>
Date: Tue, 13 Oct 2015 10:15:58 -0300

Hello,

I joined this WG a couple a weeks ago and I have been getting involved 
with lmap's threads. Although you discussed this topic a couple a weeks 
ago, my server has been misconfigurated so far. Now I think my mail 
server is fine and I am still interested in collaborate in this topic.

When I received this email I read that your are proposing to add a 
parameter so-called 
'Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson'. Then I read the 
full draft and I found that you are also interested in get the mean 
Poisson value. This information made me wonder if you are supposing that 
RTT probability density function is Poisson.

Maybe I misunderstood the meaning of Poisson in that parameter, if not, 
we cannot ensure that RTT probability density function is Poisson. 
Moreover, there is enough information among literature that proves that 
packet arrivals have a self-similar behaviour instead of Poisson's.

It would be interesting to discuss about RTT probability density 
function but I do not know if it concerns to this current WG and draft. 
For this reason, I think it is a very good idea to add the value of 
percetiles but I would write them uncategorized, without the Poisson label.

PS: My apologies if you have received this email twice.

Esteban Carisimo,
Universidad de Buenos Aires and CONICET.
850 Paseo Colon avenue, Buenos Aires, Argentina.

El 26/9/15 a las 13:51, MORTON, ALFRED C (AL) escribió:
> Hi Tim,
> good question (we're having Tuesday's meeting on Saturday :-(  )
>
> I think we need some approximate hierarchy like this:
>
> Measurement Capability [
>     Measurement Protocol [
>         Protocol Roles [ ]
>     ]
>     Registry URI  [
>         Method Roles [ ]
>     ]
> ]
> so, an example would be
>
> Measurement Capability [
>      TWAMP [
>         Control-Client; Session-Sender; Server; Session-Reflector;
>         ]
>      Prefix:Act_IP_UDP_Round-trip_Delay_95th-percentile_Poisson [
>         Src; Dst;
>      ... more URIs and Roles...
>         ]
> ]
> for a fully capable MA.
>
> I think you can easily conjure-up how to indicate a system
> with less than full capabilities, or how a different Meas. Protocols could
> be substituted in a different meas. capability that measures the *same*
> registered metric.
>
> Al
>
>
>> -----Original Message-----
>> From: Carey, Timothy (Timothy) [mailto:[email-masked]]
>> Sent: Saturday, September 26, 2015 12:16 PM
>> To: MORTON, ALFRED C (AL); Juergen Schoenwaelder
>> Cc: [email-masked]
>> Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task
>> Capabilities and ma conditions back into the information model
>>
>> Al,
>>
>> Indeed we do need that to be a list as you suggest but what is
>> relationship with the role to the list of registry entries?
>>
>> BR,
>> Tim
>>
>> -----Original Message-----
>> From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
>> Sent: Saturday, September 26, 2015 9:12 AM
>> To: Carey, Timothy (Timothy); Juergen Schoenwaelder
>> Cc: [email-masked]
>> Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task
>> Capabilities and ma conditions back into the information model
>>
>> Hi Tim and Juergen,
>>
>> Here's a small addition to what Tim proposed:
>>>> *         ma-task-capability-obj  ma-supported-tasks<0..*>;
>> It's necessary for all non-measurement tasks to have a registry
>> providing the details of each task (and someone needs to start that
>> development).
>>
>> But for measurement Tasks, there can be multiple Performance Metric
>> Registry entries involved now, and each task will be some combination of
>> registered metrics.
>>
>> So we also need ma-supported-registry-entries<0..*>;
>> and the text below (from 3.9) needs some revisions to keep-up with the
>> latest agreements (if I've got this right):
>>
>>     A Measurement Task Configuration is the same in information terms to
>>     any other Task Configuration.  Both measurement and non-measurement
>>     Tasks have registry entries to enable the MA to uniquely identify the
>>     Task it should execute and retrieve the schema for any parameters
>>     that may be passed to the Task.  Registry entries are specified as a
>>     URI and can therefore be used to identify the Task within a namespace
>>     or point to a web or local file location for the Task information.
>>     As mentioned previously, these URIs may be used to identify the
>>     Measurement Task in a public namespace
>>     [I-D.ietf-ippm-metric-registry].
>>
>> Al
>>
>>> -----Original Message-----
>>> From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy
>>> (Timothy)
>>> Sent: Friday, September 25, 2015 8:51 AM
>>> To: Juergen Schoenwaelder
>>> Cc: [email-masked]
>>> Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert
>>> Task Capabilities and ma conditions back into the information model
>>>
>>> Juergen,
>>>
>>> But the ma-status-object doesn't provide all the conditions of the MA
>>> might be experiencing (which might be implementation specific).
>>>
>>> BR,
>>> Tim
>>>
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
>>> university.de]
>>> Sent: Wednesday, September 23, 2015 9:52 AM
>>> To: Carey, Timothy (Timothy)
>>> Cc: [email-masked]
>>> Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert
>>> Task Capabilities and ma conditions back into the information model
>>>
>>> On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy)
>>> wrote:
>>>> Juergen,
>>>>
>>>> In draft 05 we removed the ability for a measurement agent to report
>>> its metrics that it supports.
>>>> We need to add
>>>>
>>>> *         ma-task-capability-obj  ma-supported-tasks<0..*>;
>>>>
>>>> *         [ma-condition-obj        ma-conditions<0..*>;]
>>>>
>>>> They were in the ma-status-obj.
>>> You are correct. There currently is no 'list' of tasks that are
>>> supported by a device anymore and we may have to put this back in.
>>>
>>> We changed the reporting of runtime failures to make them more useful.
>>> See the ma-task-status-obj.
>>>
>>> /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/>
>>>
>>> _______________________________________________
>>> lmap mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lmap
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 14 Oct 2015 07:54:46 -0400

Hi Esteban,

The Poisson distribution determines the inter-packet sending times 
for this metric, creating a form of unbiased sampling. This follows
the IPPM Framework RFC 2330, where you can read more.

So, these are metrics & and statistics on delay measured on a stream
of packets sent according to the Poisson distribution.

You're right that the distribution of RTT will not like have a Poisson
distribution, so in that we agree.

regards,
Al

> From: lmap [mailto:[email-masked]] On Behalf Of Esteban Carisimo
> Sent: Tuesday, October 13, 2015 9:16 AM
> To: [email-masked]
> Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task
> parameter so-called 'Act_IP_UDP_Round-trip_Delay_95th-
> percentile_Poisson'. Then I read the full draft and I found that you are
> also interested in get the mean Poisson value. This information made me
> wonder if you are supposing that RTT probability density function is
> Poisson.
> 
> > I think you can easily conjure-up how to indicate a system with less
> > than full capabilities, or how a different Meas. Protocols could be
> > substituted in a different meas. capability that measures the *same*
> > registered metric.
> >
> > Al
> >
> >
> >> From: Carey, Timothy (Timothy)
> >> [mailto:[email-masked]]
> >> Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert
> >> Subject: RE: [lmap] draft-ietf-lmap-information-model-06: Reinsert
> >> Registry entries involved now, and each task will be some combination
> >> of registered metrics.
> >>
> >> and the text below (from 3.9) needs some revisions to keep-up with
> >> the latest agreements (if I've got this right):
> >>
> >>> But the ma-status-object doesn't provide all the conditions of the
> >>> MA might be experiencing (which might be implementation specific).
> >>>
> >>> BR,
> >>> Tim
> >>>