Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for charter)

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 2 Sep 2014 19:07:24 +0000

Fuyu,

Local resource management, example RF management. An amount of spectrum is allocated to a group of cells and they allocate the spectrum among themselves based on the need. From macro level heat map, it looks as single device, but among the peers, they could use some of it for p2p connections and some for access.

Dean

On Aug 29, 2014, at 11:47 PM, Fuyu (Eleven) <[email-masked]> wrote:

> Hi Dean,
> 
>>>> The AN chain includes analytics enabling to derive actual states via 
>>>> cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution.
>>> 
>>> Totally agree. I think the AN chain include performance measurement segment (e.g. probe )and information collection segment from the measurement. Then analytics and filtration from this information is needed to enable the policy adjustment for network configuration adjustment for the QoS.
>> I agree with Dimitri and you on this. Actually, I would suggest to do analysis of the information locally by the agent and agent would send analyzed information to other peering AN agents. Would also suggest that the probes would be very narrow, as the AN agent on the node is in constraint environment and data analytics is computationally expensive. This information can be used for other cases, not just for QoS.
> 
> What use cases ? Would you please take an example?
> 
> Cheers
> Yu
> 
>>> The orchestration of these processing is important for the monitoring use cases.
> 
> -----Original Message-----
> From: Dean Bogdanovic [mailto:[email-masked]] 
> Sent: Thursday, August 28, 2014 2:21 AM
> To: Fuyu (Eleven)
> Cc: Papadimitriou, Dimitri (Dimitri); Toerless Eckert; [email-masked]; Sheng Jiang
> Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for charter)
> 
> Yu
> On Aug 26, 2014, at 4:26 AM, Fuyu (Eleven) <[email-masked]> wrote:
> 
>> Hi Dimitri and all,
>> 
>>> The AN chain includes analytics enabling to derive actual states via 
>>> cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution.
>> 
>> Totally agree. I think the AN chain include performance measurement segment (e.g. probe )and information collection segment from the measurement. Then analytics and filtration from this information is needed to enable the policy adjustment for network configuration adjustment for the QoS.
> I agree with Dimitri and you on this. Actually, I would suggest to do analysis of the information locally by the agent and agent would send analyzed information to other peering AN agents. Would also suggest that the probes would be very narrow, as the AN agent on the node is in constraint environment and data analytics is computationally expensive. This information can be used for other cases, not just for QoS.
> 
>> The orchestration of these processing is important for the monitoring use cases.
>> 
>> BR
>> Yu
>> 
>> -----Original Message-----
>> From: Anima [mailto:[email-masked]] On Behalf Of 
>> Papadimitriou, Dimitri (Dimitri)
>> Sent: Tuesday, August 26, 2014 12:11 AM
>> To: Toerless Eckert
>> Cc: [email-masked]; Sheng Jiang
>> Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for 
>> charter)
>> 
>> Toerless,
>> 
>> The AN chain includes analytics enabling to derive actual states via cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution.
>> 
>> I should clarify though considering cases involving e.g. information out of traffic/flow monitoring/measurement in addition to source of information provided/exchanged by current protocols (note: there are use cases that can limit their processing to the latter), does not mean ANIMA would have to work on metrology and related infrastructure, one can rely on existing sources, feeders, etc.
>> 
>> The point is the latter shouldn't scope the former (AN is a "client" of such information but can't be client of close-loop state derivation and consistent state to action mapping because this is what AN is all about).
>> 
>> Now compared to SDN and other declinations --something which would need clarification in the charter-- is that it misses (referring to my previous email on the AN dimensions): "autonomy" and "distribution" and in terms of realization it assumes as prerequisite the transformation and homogeneization of the underlying infrastructure. AN aims at maximizing the gain in operational/control logic while minimizing the infrastructure change (SDN looks all the contrary to me).
>> 
>> Thanks,
>> -d.
>>> -----Original Message-----
>>> From: Toerless Eckert [mailto:[email-masked]]
>>> Sent: Monday, August 25, 2014 5:07 PM
>>> To: Papadimitriou, Dimitri (Dimitri)
>>> Cc: Sheng Jiang; [email-masked]
>>> Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for
>>> charter)
>>> 
>>> Dimitri,
>>> 
>>> Wrt to your thoughts about including what i would call 
>>> monitoring/reporting use cases (as you wrote below):
>>> 
>>> AFAIK there is a lot of work in pulling performance information from 
>>> the network, and doing aggrgation and analytics on it. I am not sure 
>>> what aspects are covered where in the IETF, and there may be a lot of
>>> (IETF) gaps in operationalizing comprehensive solutions. But i wonder 
>>> how we would best justify of taking on that work in Anima:
>>> 
>>> It seems a lot of this analytics could be well built as an overlay/"SDN"
>>> solution, with controller(s) pulling in the information, eg: using 
>>> methods like NETFLIX and others. And potentially having a hierarchy 
>>> of such controllers/agents do do aggregation, and incremental stages 
>>> of
>>> pre- analytics.
>>> 
>>> To me, the autonomic aspects would not be the model of that hierarchy 
>>> of information gasthering, analytics/agregation, but rather how to 
>>> autonomously orchestrate the active components in that model - 
>>> hopefully as agents inside the network. But without some pre-existing 
>>> model, i think we would have to do a lot more work in Anima than just 
>>> those autonomic aspects - we might need to come up with the model 
>>> first. A model that maybe better is defined first non-autonomic by a 
>>> better group of experts in that subjet matter ?
>>> 
>>> Cheers
>>>   Toerless
>>> 
>>> On Fri, Aug 22, 2014 at 08:19:06AM +0000, Papadimitriou, Dimitri
>>> (Dimitri)
>>> wrote:
>>>> o) Practically speaking, the use case set should include in my opinion:
>>>> 
>>>> - Path (segment) monitoring: this concerns all monitoring probes
>>> configuration (sampling rate) and placement inline with the routing 
>>> decision (and it would be interesting to confront how autonomics 
>>> would help automating/adapting such task with current practices).
>>>> 
>>>> - Traffic anomaly detection, routing anomalies detection (diagnostic 
>>>> out
>>> of a large set of information) which could help configuring ACL, 
>>> routing adjacencies or others.
>>>> 
>>>> - AQM parameters (re)configuration out of traffic measure
>>>> 
>>>> - Shared risk (hidden risk) detection out of routing/topological
>>> information analysis, the output of such process should prevent that 
>>> protecting routing path fail together with their primary path or that 
>>> an alternate path fails right after its selection due to delay in 
>>> propagation of routing information.
>>>> 
>>>> - Instead of bringing big words like SLA, consider a simple process 
>>>> by
>>> which the bandwidth x delay of running path segments could be 
>>> measured and estimated in order to anticipate possible effects out of outages.
>>>> 
>> 
>> _______________________________________________
>> Anima mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/anima
>> 
>> _______________________________________________
>> Anima mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 3 Sep 2014 01:47:20 -0300

Hi Dean.
I presented a draft at UCAN BoF
(https://tools.ietf.org/html/draft-irtf-nmrg-autonomic-sla-violation-detection-00)
which considers a local resource management problem in the context of
active measurement sessions. It seems close to your RF management
example.
I presented at NMRG (IETF 88) a P2P solution
(http://www.ietf.org/proceedings/88/slides/slides-88-nmrg-1.pdf) and I
am working on a draft to describe this solution. I hope to have it
ready for IETF 91.
Anyway, I think monitoring use cases will be out of scope considering
the last ANIMA charter version.

Jéferson

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Sep 2014 08:14:47 +1200

> the last ANIMA charter version.

They might be out of scope for the initial milestones, but that doesn't
mean they should not be discussed (in the NMRG if not in the proposed
WG). In the long run this will be important.

    Brian